Agent Runtime en

中文 | English

Agent Runtime

Maintained version: v0.51.2 ｜ Last updated: 2026-07-06

EnerOS Agents are OS scheduling units; each Agent is an independent process that collaborates via the event bus. This page summarizes the 7 domain Agents, lifecycle, 3 collaboration modes, and LLM task decomposition; for full design see ADR-0010 and the main repo docs/developer-guide.md §4.

7 Domain Agents

Agent	Binary	Responsibility	Typical latency
Dispatch	dispatch-agent	Dispatch decisions (unit commitment / economic dispatch)	seconds~minutes
Forecast	forecast-agent	Load / renewable generation forecasting	minutes~hours
Operation	operation-agent	Operation execution (switching / regulators / AGC)	seconds
Planning	planning-agent	Operations planning (day-ahead / monthly)	hours~days
Trading	trading-agent	Power market trading (bidding / settlement)	minutes
Self-Healing	self-healing-agent	Fault self-healing (fault location / isolation / restoration)	milliseconds~seconds
Maintenance	(submodule)	Equipment health management / maintenance planning	hours~days

Lifecycle

Created → Initialized → Running → Paused → Stopped → Destroyed
                ↑            ↓
                └─── Error ──┘

State	Trigger	Behavior
Created	Start binary	Load config
Initialized	init() completes	Register with AgentOrchestrator
Running	start()	Receive events / execute decision loop
Paused	pause() or resource pressure	Stop decision loop, preserve state
Stopped	stop() or external signal	Release resources
Error	Exception	Report to event bus, Self-Healing takes over

3 Collaboration Modes

Master-Slave

Master Agent decomposes tasks, dispatches to slave Agents for execution; suitable for hierarchical dispatch scenarios.

Dispatch (Master) ─┬─→ Forecast (Slave)
                   ├─→ Operation (Slave)
                   └─→ Trading (Slave)

Peer-to-Peer

Agents communicate directly, no central coordination; suitable for distributed energy coordination scenarios.

Forecast ↔ Trading
   ↕          ↕
Operation ↔ Self-Healing

Bidding

Agents submit action proposals; PriorityArbiter arbitrates by priority and conflict resolution rules; suitable for multiple Agents competing for the same resource.

[Dispatch proposal] ─┐
[Trading proposal]   ─┼→ PriorityArbiter → [winning action]
[Operation proposal] ─┘

PPO Reinforcement Learning (v0.43.0+)

EnerOS integrates PPO (Proximal Policy Optimization) for:

• Dispatch policy online learning (based on historical load and generation data)
• Self-healing policy optimization (based on fault scenario feedback)
• Market bidding strategy (based on historical transaction prices)

Training data comes from eneros-timeseries historical time-series; trained policies are written to eneros-memory for Agent loading.

LLM Task Decomposition (v0.50.0+)

LlmAgent<T> decorator decomposes complex tasks into subtasks:

pub struct LlmAgent<T: LlmClient> {
    client: T,
    prompt_template: PromptTemplate,
}

impl<T: LlmClient> LlmAgent<T> {
    pub async fn decide(&self, context: &DecisionContext) -> Result<Vec<AgentAction>> {
        let prompt = self.prompt_template.render(context);
        let response = self.client.complete(&prompt).await?;
        LlmDecisionParser::parse(&response)
    }
}

Supports OpenAI / Anthropic / Ollama LlmClient implementations. See the LLM Integration page.

Known Limitations (v0.51.2)

• Transient integration is steady-state stub, not real transient stability computation
• PPO training is offline only; online reinforcement learning not supported
• Agent P2P communication is currently in-process only; cross-process IPC pending v0.52.0

Related Documentation

• ADR-0010 Agent Orchestration
• LLM Integration — LlmAgent / LlmClient / verification
• SafetyGateway — Gatekeeping for Agent actions dispatched to RT domain
• Main repo docs/developer-guide.md §4 — Adding new Agent flow
• Main repo crates/eneros-agent/ — source code