Software is starting to operate itself.
Not in flashes - full systems that wake themselves up when needed, work through tasks, call tools, coordinate with peers, recover from failure, and keep going until the job is done. Software is starting to take responsibility for how it will achieve its goals. That kind of software is moving from demos into real businesses. It raises a question the current agent stack does not answer: where does it run?
Assembling an agent inside a framework is not the same as operating one inside a system a business depends on. Software that initiates its own work needs the properties that have always separated a service from a script - identity, durable state, recovery, scheduling, coordination, observability, governance, and human control.
We call that an autonomous operating environment: a single place where autonomous systems are designed, built, deployed, observed, and governed, alongside the services they already work with.
Today, Akka is introducing AutonomousAgent: a new SDK component for goal-directed, model-driven processes that run inside Akka's durable runtime - with the identity, state, recovery, coordination, and governance of any other component in the system.
That is the difference between a framework and an operating environment.
Agent frameworks provide the application model:
Agent harnesses provide the operating surface:
The convergence point is an autonomous operating environment:
"Orchestration" has become a catch-all. Calling one agent after another, routing a request to a specialist, fanning out and summarizing — all of it gets the same label. Those patterns are useful. They are not what makes a system operable.
An operable system has identity and role boundaries, durable execution and state, event-driven activation, reliable handoff, retries and recovery, traceable decisions, human review where it matters, governance over models and actions, and a path to deployment. Without these, multi-agent systems fail in predictable ways: they lose context, repeat side effects, burn tokens in loops, and make progress that cannot be resumed.
Agent infrastructure is starting to look less like prompt engineering and more like application infrastructure. That is the right direction.
The current frameworks each solve part of the problem.
| Framework type | What they do well | Common gap |
|---|---|---|
| Agent composition frameworks (Google ADK, CrewAI, OpenAI Agents SDK, Pydantic AI) |
Define agents, tools, roles, handoffs, structured outputs, and guardrails. | They help compose agents, but durable execution, business state, activation, and operations remain mostly outside the agent model. |
| Graph and workflow frameworks (LangGraph, LlamaIndex Workflows, Mastra, Semantic Kernel / Agent Framework) |
Model multi-step flows, branching, checkpoints, handoffs, and human-in-the-loop paths. | They improve orchestration, but developers still own side-effect safety, service runtime, deployment, and state consistency. |
| Agent harness frameworks (LangChain Deep Agents, Claude Code, Codex, Cursor, Zed) |
Give agents workspaces, files, tools, tasks, review, permissions, and isolation. | They are strong for supervised workspace execution, but not general runtimes for deployed autonomous services. |
| Multi-agent society and swarm frameworks (CAMEL, AutoGen, Strands Agents, MetaGPT...) |
Explore agent teams, role-based collaboration, swarms, debates, and simulated organizations. | They emphasize coordination patterns, but production reliability depends on an external runtime. |
The categories differ, but the gap is consistent: agent reasoning and application execution remain separate.
Frameworks help define agents, tools, handoffs, graphs, workflows, guardrails, and collaboration patterns. Harnesses add workspaces, files, terminals, permissions, review loops, and isolation. Both are useful. Neither, by itself, is the same as a runtime for autonomous services. They help specify how agents reason, but stop short of specifying how the system should operate.
The missing layer is responsible for waking the system up, preserving durable state, executing long-running work, handling side effects, recovering from failure, exposing operational state, enforcing control, and making distributed behavior explainable.
Without that layer, the agent can reason about work, but the surrounding application still has to make the work happen.
AutonomousAgent is a model-driven, durable process that works typed tasks to completion. It is not invoked once and returned. It is started — and from there it runs its own iteration loop, decides what to do next, calls tools, and persists progress until the task is finished. A few ideas hold it together:
A description, instructions, and a set of accepted tasks. Each agent declares what it is for with a component description, which other agents and planners can use to understand its capabilities. The model-facing behavior comes from instructions, which can be defined statically or supplied per instance. Accepted task types bound what kinds of work can be assigned to the agent. An agent stays narrow on purpose, so context stays scoped to one objective rather than being overloaded with competing ones.
Tasks as first-class entities. Work given to an AutonomousAgent is a typed task instance created from a task definition. The task definition has a stable description and result schema. The task instance carries per-run instructions and optional attachments. A task is created, runs to completion across many model iterations, and its result is persisted independently of the agent that produced it. External callers can start a task, query its state while it runs, and retrieve the typed result after the agent has moved on.
A durable execution loop. The agent runs as a process, not a request. It iterates against the model, invokes tools, and writes its progress as it goes. If the node, the model call, or an external API fails, the agent resumes from where it was. Iteration limits are part of the capability declaration, so the loop is bounded by design.
Built-in coordination. Akka supports coordination through durable workflows and autonomous-agent capabilities, not untracked glue code around the model. An AutonomousAgent can delegate a subtask to a specialist, hand a task off to a peer, lead a team sharing a task list, or moderate a turn-taking conversation between other agents. These patterns are exposed to the model as tools, so coordination is a decision the agent makes inside the runtime's component model.
Notifications and observability. The runtime emits a stream of events for the agent's lifecycle, task progression, delegation and handoff, team activity, conversations, and detected struggle. External systems subscribe to that stream to monitor, react, and intervene.
Governed AI systems. AutonomousAgent is part of Akka's broader AI systems approach. Guardrails, interaction logging, evaluations, and feedback loops are built into the runtime around the agent, not left as separate infrastructure. That matters more as coordination becomes more dynamic: tracing, evaluation, and interaction history turn distributed multi-agent execution into something humans can inspect, debug, and improve.
| Concept | Meaning in AutonomousAgent |
|---|---|
| Description | Component metadata that states the agent's purpose and capabilities for discovery, planning, and coordination. |
| Instructions | Model-facing guidance that shapes how the agent works on an instance or task. |
| Accepted task | A task type the agent accepts, with the iteration limit allowed for that task. |
| Task instance | A concrete unit of work with its own identity, instructions, typed result, and persisted lifecycle. |
| Iteration loop | The agent's own execution loop against the model, persisted at each step and resumable after failure. |
| Coordination | Built-in patterns the model can invoke: delegate, hand off, lead a team, moderate a conversation. |
Consider an agent that monitors temperature readings, decides whether each one is normal, needs follow-up, or requires escalation, and produces a typed decision that outlives the agent's run.
The agent is defined by its component description, instructions, and the task types it accepts.
@Component(
id = "escalation-specialist",
description = """
Drafts on-call escalation notices for temperature readings flagged
as critical, including a recommended runbook step.
"""
)
public class EscalationSpecialist extends AutonomousAgent {
public record EscalationNotice(String summary, String recommendedAction) {}
public static final TaskDefinition<EscalationNotice> DRAFT_NOTICE =
Task.define("draft-notice")
.description("Draft an on-call escalation notice for a flagged reading.")
.resultConformsTo(EscalationNotice.class);
@Override
public AgentDefinition definition() {
return define()
.instructions("""
Produce a concise escalation notice and a recommended first runbook
step for the on-call engineer.
""")
.capability(TaskAcceptance.of(DRAFT_NOTICE).maxIterationsPerTask(4));
}
}@Component(
id = "temperature-monitor",
description = """
Monitors temperature readings and classifies each reading as normal,
follow-up, or escalation. Delegates escalation notice drafting to the
on-call specialist.
"""
)
public class TemperatureMonitoringAgent extends AutonomousAgent {
public record MonitoringDecision(
String readingId,
Severity severity,
String rationale,
boolean requiresEscalation) {}
public static final TaskDefinition<MonitoringDecision> REVIEW_READING =
Task.define("review-reading")
.description("Review a single temperature reading and decide what to do.")
.resultConformsTo(MonitoringDecision.class);
@Override
public AgentDefinition definition() {
return define()
.instructions("""
For each reading, classify it as normal, follow-up, or escalation,
explain the rationale, and flag readings that require escalation.
When a reading requires escalation, delegate drafting of the on-call
notice to the escalation specialist before returning your decision.
""")
.capability(TaskAcceptance.of(REVIEW_READING).maxIterationsPerTask(8))
.capability(Delegation.to(EscalationSpecialist.class));
}
}A caller starts a task on the agent and later retrieves the typed result.
var task = TemperatureMonitoringAgent.REVIEW_READING
.instructions("Review this temperature reading: " + reading);
var taskId = componentClient
.forAutonomousAgent(TemperatureMonitoringAgent.class, UUID.randomUUID().toString())
.runSingleTask(task);
var snapshot = componentClient
.forTask(taskId)
.get(TemperatureMonitoringAgent.REVIEW_READING);
MonitoringDecision decision = snapshot.result().orElseThrow();What is happening underneath is what makes this an autonomous agent rather than an agent call. The agent runs its own loop against the model, persists each step, can call tools or other agents along the way, and survives restarts. The task is a durable entity: it has an ID, it can be queried while it runs, and its result is available after the agent's process has moved on.
The monitor declares Delegation.to(EscalationSpecialist.class) as a capability and the runtime exposes it to the model as a tool. When the model decides a reading warrants escalation, it delegates the draft to the specialist within the same task. The monitor's typed result is unaffected; the specialist's task runs and persists independently, and both are visible to the surrounding system as first-class entities. No external workflow describes the steps — the coordination is a decision the agent makes inside the runtime's component model. Handoff, teams, and moderated conversations are declared the same way, and the samples below show each pattern end to end.
This pattern carries across the sample applications: summarizing release notes from upstream sources, classifying and tagging medical discharge records, and monitoring IoT sensor data. In each one the shape is the same: a clear component description, model-facing instructions, typed task acceptance, a durable loop, and results that live as first-class entities.
The AutonomousAgent documentation and the Autonomous Agent Playground ship the patterns end to end. The playground includes:
AutonomousAgent is the first component built specifically for software that operates on its own. It is not a wrapper, a workflow pattern, or an SDK helper layered over an LLM call. It is a runtime component — with the identity, state, recovery, observability, and governance that Akka already gives every other component in a system.
That is what completes an autonomous operating environment. The same runtime that hosts a service's endpoints, entities, workflows, and views now hosts the agents that operate them. One platform to design, build, deploy, observe, and govern the whole system - no second stack to bolt on, no separate plane for the autonomous parts.
For complex multi-agent systems, explainability becomes harder precisely when it matters most: when interactions are dynamic, long-running, and distributed. Akka's durable cloud stack brings those interactions back under operational control, with enhanced transaction tracing, evaluation support, interaction logging, and HA/DR recovery for complex coordination.
Frameworks made agents programmable.
Harnesses made agents usable.
Runtimes make agents operable.
Akka is the operating environment for autonomous software.