Outcome
AURA can start, continue, and complete work independently of a live human request, client connection, or individual process, while remaining observable and steerable by humans and other systems.
Work may be initiated by a human, a schedule, a webhook, a polling condition, another agent, or another supported system. AURA can continue that work beyond the lifetime of the initiating request or connection, preserve the state needed to inspect or resume it, and allow a human to attach and intervene when needed.
Problem
Today, AURA's useful interactive behavior is tightly coupled to the request or connection driving it.
- A CLI can attach to a daemonized AURA and steer it, but an open turn and its context are lost when that connection goes away.
- A2A provides a headless path, but it is designed for agent-to-agent delegation rather than a human starting work and later observing or steering it.
- Long-running work can outlive an HTTP request and be lost when the request times out.
- Conversation and execution state is largely request- or process-bound. OTEL provides a durable record of what happened, but not durable state that AURA can resume or a human can inspect and steer.
- Integrations such as Slack or Teams require brittle, one-off glue because AURA has no consistent input/output adapter contract.
- AURA has no first-class way to run autonomously from schedules, polling, or inbound events.
The result is that "headless AURA" is currently a degraded mode rather than the same AURA runtime operating without an attached client.
Scope
This initiative establishes a first-class headless runtime and the product capabilities it enables.
The work is expected to ship through user-visible increments:
-
AURA where users already work
A consistent way to connect AURA to conversational and operational surfaces such as Slack, Teams, Google Chat, dashboards, metrics, and future user-provided adapters.
-
Autonomous headless work
AURA can start and control work without a live interactive request, including scheduled work, polling/wait conditions, inbound and outbound webhooks, A2A delegation, and APIs for observing or steering running tasks.
-
Durable headless execution
Work can outlive web-request limits and process restarts. State required to inspect, resume, or continue work is durable and can be recovered across AURA instances or pods.
Existing runtime, agent-event, session, A2A, and state-management work may provide enabling architecture for these outcomes. This initiative is organized around shipped product capabilities rather than mirroring those implementation boundaries.
Outcome
AURA can start, continue, and complete work independently of a live human request, client connection, or individual process, while remaining observable and steerable by humans and other systems.
Work may be initiated by a human, a schedule, a webhook, a polling condition, another agent, or another supported system. AURA can continue that work beyond the lifetime of the initiating request or connection, preserve the state needed to inspect or resume it, and allow a human to attach and intervene when needed.
Problem
Today, AURA's useful interactive behavior is tightly coupled to the request or connection driving it.
The result is that "headless AURA" is currently a degraded mode rather than the same AURA runtime operating without an attached client.
Scope
This initiative establishes a first-class headless runtime and the product capabilities it enables.
The work is expected to ship through user-visible increments:
AURA where users already work
A consistent way to connect AURA to conversational and operational surfaces such as Slack, Teams, Google Chat, dashboards, metrics, and future user-provided adapters.
Autonomous headless work
AURA can start and control work without a live interactive request, including scheduled work, polling/wait conditions, inbound and outbound webhooks, A2A delegation, and APIs for observing or steering running tasks.
Durable headless execution
Work can outlive web-request limits and process restarts. State required to inspect, resume, or continue work is durable and can be recovered across AURA instances or pods.
Existing runtime, agent-event, session, A2A, and state-management work may provide enabling architecture for these outcomes. This initiative is organized around shipped product capabilities rather than mirroring those implementation boundaries.