[EPIC]: Agents Runtime #562

Outcome

AURA agents can run independently of an HTTP request, CLI connection, or A2A task, be started by humans or external systems, continue working unattended, and remain observable and steerable while they run.

Headless execution should use the same agent runtime as interactive AURA rather than introducing a separate, degraded execution path.

Current state

Today, agent lifetime is still tightly coupled to the protocol or request that created it.

• Agents are created inside HTTP requests or A2A tasks rather than running inside a protocol-independent runtime.
• A2A provides a headless path, but it is designed for agent-to-agent interaction rather than a human or API starting work and later observing or steering it.
• There is no native AURA interface for starting and controlling headless work.
• Long-running work can outlive the web request that started it.
• Once work is running headless, there is no consistent way to discover it, observe it, attach to it, steer it, or take control.
• Agent events are increasingly protocol-independent, but runtime lifecycle and control are still coupled to the request path.
• Agent and MCP instances are generally created for one request rather than managed as reusable runtime resources.

Use cases

The runtime should support headless work such as:

• Polling an MCP or another source until a condition is met, without external glue repeatedly triggering AURA.
• Running scheduled work such as a recurring correctness or security sweep.
• Receiving a task through an inbound webhook, running it unattended, and reporting results through an observer such as Slack or OTEL.
• Starting A2A work when an agent needs information or capability from another agent.
• Calling an outbound webhook as part of completing a task.
• Continuing work after the HTTP request or interactive client that initiated it has disconnected or timed out.
• Allowing a human to discover a running task, observe it, attach to it, provide additional input, nudge it, or cancel it.

Runtime requirements

Agent lifecycle

• AgentRuntime is a core AURA concept for running agent instances independently of HTTP, CLI, or A2A request lifetimes.
• A running agent is associated with a session and has a distinct run / agent identity.
• Runtime policy determines what happens when clients or other observers attach or detach.
• Runtime-owned work can continue without an attached human or request.
• Agent configuration remains separate from the lifecycle of a running agent instance.
• The runtime can create or reify agents from their configuration and session state.

Events and observers

• Agents emit protocol-independent AURA events rather than writing directly to SSE, A2A, Slack, OTEL, or another transport.
• Multiple observers can subscribe to the same running agent.
• Observers may project events into protocol-specific outputs such as SSE, A2A, OTEL, or collaboration adapters.
• The runtime understands whether an observer represents human presence.
• Presence can inform lifecycle and HITL behavior, including whether approval should happen conversationally or through an unattended path.
• Observers can be passive, maintain a claim on running work, or represent an actively present human.

Task control

AURA needs a native control surface for headless work that can:

• start work;
• list running, waiting, or parked work;
• inspect task status and relevant runtime state;
• observe a task without taking control;
• attach to and steer an active run;
• provide additional input or a nudge;
• park work for approval;
• cancel work.

Headless operation should not require pretending that a human or API caller is another A2A agent.

Autonomous triggers and actions

The runtime should support first-class mechanisms for:

• scheduled / cron execution;
• polling and wait-for conditions;
• inbound webhook triggers;
• outbound webhook actions;
• initiating A2A work.

These mechanisms should start or interact with the same AgentRuntime used by interactive AURA rather than introducing separate execution models.

Related work

Existing agent-event work provides much of the protocol-independent event model required by this epic.

State durability and cross-pod recovery are related but are owned separately under the durable headless execution work in #747.

User-facing collaboration adapters such as Slack, Teams, and Google Chat are owned by #751. This epic provides the runtime and observer/control model those adapters consume.

Stretch

• Warm agent and MCP caching to improve multi-turn latency.
• Generalized observer/plugin extensibility beyond the supported adapter model.