# From Sessions to Tasks: Infrastructure for Agent Fleets > Source: > Published: 2026-11-08 15:08:26+00:00 DeepSeek Harness recently published its [Super Agent Architecture](https://x.com/DeepSeekHarness/status/2116857257245987236) in which a Router maintains continuity with the user while multiple Workers execute tasks in isolated sessions. Once several agents are working in parallel, the user can become responsible for remembering what each session is doing, how the tasks relate to one another, and where their results will appear. The design moves that responsibility into the system and makes concrete a transition I have been working toward over the last few months. A conversation is an interface. A task is an operational contract. Earlier this year, I wrote about the major components of an [agentic architecture](https://softwareguru.substack.com/p/the-agentic-architecture-understanding), including an execution platform for autonomous remote agents. Sub-agents and the Orchestrator-Worker pattern have since made that model more concrete: an orchestrator holds global context, delegates distinct tasks to workers that see only what they need, and processes their results. As the pattern moves beyond a single machine, the challenge is no longer launching more agents. It is building infrastructure whose primary users are agents. ## Agent-First Infrastructure Delegated agent work changes the infrastructure contract. A task must continue after the submitting client disappears, retain a durable identity and lifecycle, and leave behind artifacts that can be inspected later. Each task needs an owner, explicit context, a budget, and scoped permissions. The platform must isolate its execution and allow it to recover from failures without affecting other tasks. Security is part of this contract rather than a layer added later. Every worker should receive only the tools and data required for its task, use short-lived credentials that are refreshed only when needed, and produce an audit trail showing who authorized its actions and under which constraints. The difficult part is enforcing these guarantees across a fleet. The platform must contain workers that hang or enter loops, enforce token and resource budgets during execution, and prevent noisy workloads from starving other tasks. It must also manage the startup cost of isolated workers and preserve enough state to recover interrupted work. These operating concerns distinguish an interface that can launch several agents from an execution platform that can manage an agent fleet. ## Agent Execution Platform Once the larger architecture becomes clear, I prefer to build from the bottom up by identifying the components that connect orchestration to compute. The agent execution platform connects these two layers. It accepts work from humans or agents and runs it as a self-contained package that includes the prompt, relevant Skills, and MCP tools. Callers that need a customized environment can also provide a container image. The control plane accepts the request and validates identity, policy, limits, and budget. It selects the data plane cell that should execute the task, assigns a task identifier, and places the work on the durable queue within that cell. Inside the selected cell, a dispatcher leases the request and creates an isolated worker using either a MicroVM or an AgentCore Runtime. The worker records its lifecycle state in DynamoDB and writes its results, logs, and traces to Amazon S3. A local LiteLLM process provides observability for model calls sent to Amazon Bedrock. When the task reaches a terminal state, a notifier publishes lifecycle events to EventBridge so callers can receive completion notifications or initiate follow-up work. These AWS services illustrate one possible implementation of the architecture rather than requirements for building it. The data plane follows a [cellular architecture](https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html) for scaling and fault isolation. This limits how much capacity pressure or a failure within one cell can affect the wider platform. To keep the main execution path readable, the diagram compresses identity and authorization into the Auth and policy step. This function remains critical: it authenticates the caller, evaluates policy, and brokers short-lived credentials through an On-Behalf-Of (OBO) flow. Each worker then receives a task-scoped identity and only the access required for its work. ## Conclusion Earlier this year, I was trying to understand how the components of an agentic system fit together. I now see the agent execution platform as the layer that turns delegated work into durable tasks with identity, limits, and inspectable outcomes. The orchestrator decides what work should happen, and the platform ensures it can run reliably beyond the session that initiated it. This architecture also opens a question I have not answered yet: what should an ephemeral worker persist so that later runs of the same task can improve? Any answer will need a way to determine which learnings are worth retaining, how they should be evaluated, and when they should influence future work. The future of agentic computing will not look like millions of chat windows. It will look like millions of durable, isolated, accountable jobs working inside feedback loops designed by humans.