How Agent Operating Systems Handle Stateful Coordination Across Hundreds of Concurrent Runners
Running hundreds of long-running AI agents reliably requires a runtime that preserves session state, schedules work, and governs shared effects. UFO is one purpose-built option for this infrastructure layer, where conflicting writes, stale authorization, and context loss become operating-system problems.
Why concurrent agents create a coordination problem that stateless tooling cannot solve
CoAgent’s K8S trace shows two agents that each do their tasks correctly when judged on their own, and both report success. Yet the work they do together leaves a canary deployment built on a known-bad image, waiting to take live traffic. The cluster’s final state matches no serial execution of the two agents. Neither agent’s individual task explains the failure. The fault lies in the interleaving of their reads and writes.
That distinction becomes critical when AI moves from suggesting actions to executing them. A text response can be reviewed and discarded, but a refund, inventory reservation, or financial transfer changes a live system. Once that write takes effect, the chance for human interception closes or narrows to milliseconds. Purpose-built agent operating systems like UFO treat state management and visibility across concurrent executions as runtime concerns because individual agent correctness does not guarantee collective correctness.
What an agent OS is and why it is structurally different from adapted general-purpose tooling
An agent operating system is a coordination layer that manages memory, tools, scheduling, and access control. Unlike a workflow with AI steps inserted into a predefined path, it supports paths that emerge as an agent reasons through a task. The comparison with a conventional OS is useful because both allocate resources among concurrent workers. But an agent OS must also manage context, reasoning state, and execution loops. Its job extends beyond hosting the code that calls a model.
Durability added to general-purpose tooling has a useful role, including checkpointing work so it can pause and resume. That preserves execution progress, but it does not by itself settle whether concurrent writes are compatible or an earlier permission remains valid. Those problems need coordination over shared state. UFO puts memory, scheduling, tool access, and governance in the runtime, so application code no longer has sole responsibility for those boundaries. The architectural inversion is that the session becomes the atomic unit of isolation and state, with its own compute, state, and lifecycle.
Why classical concurrency control fails when the transaction spans minutes of inference
Running one agent at a time preserves correctness but gives up parallel work. Static write partitioning needs to know what each agent will change before the agent has formed its plan. Fork-and-merge offers only weak isolation, equivalent to read-committed in databases, and cannot prevent the anomaly in CoAgent’s K8S trace.
Classical database controls encounter three further mismatches, beginning with lock duration. Two-phase locking holds locks for the whole task, so minutes or hours of reasoning block other agents that touch overlapping state. Optimistic concurrency control avoids that waiting but can discard the entire transaction after a single conflict at validation, wasting minutes of inference. The deeper mismatch is logical state, because an operation such as kubectl apply must affect the live cluster before the agent can observe its result and continue. That effect must reach the live cluster before commit, so a runtime needs concurrency control built for agent work instead of rapid, deterministic transactions.
How CoAgent's MTPO protocol uses LLM judgment to repair conflicts rather than roll back the whole transaction
CoAgent, submitted by Lyu et al. at Shanghai Jiao Tong University in June 2026, uses a capability classical transactions lack. An agent’s LLM can judge whether a conflicting write actually invalidates its plan. Rather than treating every conflict as grounds to restart, the runtime can ask the agent to repair the operations that depended on the changed state. This makes conflict handling advisory rather than blocking. It preserves useful reasoning where a narrower correction is sufficient.
The protocol is MTPO, or Monotonic Trajectory Pre-Order. It fixes a serialization order at launch, serves each read the order-filtered value, and applies writes speculatively in place. When a conflict occurs, a one-way notification asks the affected agent to re-judge and patch its plan. Meanwhile, the framework mechanically undoes and reorders misplaced writes through a saga-style inverse that each tool registers in advance. At quiescence, the run is serializable in the pre-decided order, meaning its effects match that ordering of the agents.
That guarantee is not immunity from undo work. Tool authors must supply the inverse operations that make mechanical repair possible. CoAgent implements the protocol as toolcall middleware, while its privileged ToolSmith component grows footprint-declared, undoable tools during execution. But after a plan is repaired, the permission for its next action may no longer be valid.
Why authorization decisions go stale during long-running concurrent agent work, and what serializability means for policy
A policy decision may be valid when a request arrives but stale when its effect commits because a budget, inventory count, approval status, or risk signal has changed. Request-local governance examines the principal, action, resource, and arguments at the boundary. Yet rolling refund histories, live inventory holds, and spending that adds up across concurrent sessions reach beyond that one request. Passing a snapshot of those conditions as ordinary context does not protect them from change.
The distinction is visible in routine operations. A refund policy may depend on a customer’s recent refund history, while a travel reservation depends on current inventory and existing holds. A cloud quota check likewise needs live consumption. CoAgent addresses the ordering and repair of concurrent work. MasuGate handles stateful governance, which checks whether the policy state still permits the effect when it occurs.
MasuGate calls its correctness condition policy-state serializability. Committed effects must be explainable as authorized against the policy state immediately before they occur. Its design puts provider contracts and certified policy state inside the trusted boundary so it protects both the decision and the governed effect. Its database-backed prototype stops stale authorizations that baselines miss when they pass policy state as ordinary request context, while keeping delayed approvals and letting unrelated work go ahead. Human review then retains its meaning during the review interval, rather than being overtaken by another agent’s commit.
How AgentRoom's CRDT-backed approach handles file-level conflicts in concurrent coding workflows
AgentRoom (2026) illustrates a narrower coordination pattern for coding agents sharing a repository. It provides a structured runtime object with file-level claim semantics on top of a CRDT-merged shared filesystem. Agents claim files, work within the scope they claimed, broadcast state changes that matter to the work, and release their claims when they finish. The CRDT-backed approach allows concurrent writes to merge deterministically without a central lock coordinator. Claims make each agent’s working scope explicit rather than leaving other agents to infer it from changed files.
AgentRoom exposes claims, shared state, broadcasts, and agent status through MCP tools including room_claim, room_release, room_state, room_broadcast, and room_read. Its append-only broadcast log records both coordination and the resulting code, giving agents near-real-time visibility into one another’s work. This addresses a practical need that a final merged filesystem alone cannot meet, because agents also need to know what work is underway. This file-level coordination leaves the transaction and policy guarantees described earlier to other mechanisms.
How can long-running agents remember context across sessions that span hours or days
Shared-state correctness is not enough if an agent loses its own context between steps. Without persistent memory, a later call has no record of prior decisions, user preferences, or task history unless that context is supplied again. Short-term memory holds the active context for the current task. Long-term memory persists across sessions in databases or vector stores. Together, they let work continue across hours or days rather than forcing each invocation to reconstruct its starting point.
Storing full transcripts can make retrieval noisy and fill the context window with history that has no bearing on the task. Storing conclusions and decisions instead keeps in memory what the agent will need when it reasons later. A layered architecture places hot session state in a fast store, retrieves relevant past cases semantically from a vector database, and archives long-term summaries in durable SQL. After a crash, that pattern restores session state from the hot store and semantic context from the vector database.
Slack’s complex security investigations show why this becomes an infrastructure problem. One of its multi-agent applications can span hundreds of inference requests and generate megabytes of output. It manages context through a director’s journal containing structured working memory, a critic’s review containing annotated findings with credibility scores, and a critic’s timeline containing chronological findings with credibility scores. Slack identified context management as its most significant challenge in building useful AI agents. It began putting thread and channel context management into the platform to reduce expensive API round trips needed to reconstruct conversation history.
How scheduling and orchestration determine whether multi-agent work compounds or collapses
Memory preserves what an agent knows, but orchestration determines when that knowledge can be used. The runtime must route tasks, track dependencies, and identify work that can proceed in parallel. It must also handle a sub-agent that fails or returns an unexpected result. Because plans take shape as agents run, those decisions need the current workflow state.
Centralized orchestrators are easier to debug, while decentralized models are more resilient to single points of failure, so most production deployments combine them. Whatever the arrangement, proactive scheduling lets agents act on a schedule or respond to external triggers. Durable workflow state complements this capability by checkpointing after each step so work can pause for review and resume without losing context. Memory preserves what the agent knows, while the checkpoint preserves where it is in its plan.
What the agent OS stack looks like in practice, and where UFO fits within it
UFO provides a purpose-built runtime environment for deploying, managing, and operating autonomous agents at scale. Its design places session-level isolation, persistent state, scheduling, tool access, and stateful governance in the operating layer. The hosted service is installable through a single curl command, with developer-first, CLI-native onboarding. That makes it an option for teams seeking persistent and scheduled agents without building the persistence layer themselves. The comparison with the research protocols discussed here concerns UFO’s architecture alone.
The wider stack has three layers, which are the framework for agent logic, the runtime for state, isolation, and scaling, and the platform for surfaces and integrations. Confusing those roles leaves essential responsibilities without an owner. A framework does not become a runtime simply because it can express an agent loop, and a saved workflow does not establish policy-state serializability. CoAgent, MasuGate, and AgentRoom describe different coordination mechanisms. Together, they make clear what runtime design must account for, including repairable effects, live policy state, and visibility into concurrent work.
The same boundary matters when agents are accessible through CLI, Slack, web, or SMS. State must live independently of the interaction surface so changing the channel does not mean changing the agent’s memory or execution history. For concurrent coding, DevOps, and data analysis agents, that is the practical case for treating coordination as infrastructure from the beginning. Teams that establish these boundaries early can build later work on preserved state and governed effects. Teams that bolt them on later inherit the cost of retrofitting assumptions about isolation, memory, and permission into work already underway.
