Patterns in Agentic-OS Architecture: What the Bundles Are Actually Doing

The bundled agentic platforms have been shipping for the better part of a year, and the dust is settling enough that the recurring patterns are starting to be visible. This piece is a reading of four of them — Sema4.ai’s Robocorp-rooted action platform, MultiOn’s browser-agent product, Adept’s ACT family, and Web4OS — across the architectural choices the bundles tend to converge on. We have run all four. We have read what is public. We have not been briefed on internals beyond what each vendor has documented.

The argument is that the bundles, despite very different surfaces, are answering a small number of architectural questions in similar ways. What is interesting is which questions they treat as settled and which ones they leave to the framework layer.

What we mean by “bundled agentic platform”

A bundled platform, in our usage, is a product that ships with an opinionated topology, a non-developer surface, an internal scheduler, and a billing model tied to work units rather than seats. It is the opposite end of the spectrum from a framework like LangGraph or AutoGen — frameworks expose primitives; bundles expose an experience. By that test, all four bundles in our set qualify: an action-runner shape, a browser-agent shape, an action-transformer shape, and a workforce shape.

The four are not interchangeable. They sit at different layers of the stack and target different users. But they converge on four architectural choices worth naming.

Pattern 1: the supervisor topology

The defining shape across the bundles is supervisor-led. A single coordinating agent receives the user’s goals and decomposes them into work for specialist agents.

Sema4.ai uses an “action” abstraction over a Python runtime; MultiOn coordinates a browser-context agent against a planner; Adept’s ACT pattern is a planner-actuator split; the fourth bundle in our set calls its coordinator the CEO. The names differ. The pattern does not. Each bundle commits to the supervisor pattern as the right default for its target user, and none of the four exposes a peer-to-peer mode.

The pattern is well-trodden in the research literature — supervisor-led multi-agent systems were the centre of CrewAI’s design from the start, and AutoGen’s GroupChatManager is in the same family. What the bundles add is total commitment. There is no “compose your own crew” escape hatch in any of them. The architectural cost is reduced flexibility. The benefit is that every customer’s deployment looks like the same kind of company, which makes the platform’s audit and observability work tractable in a way a peer-to-peer system would not be.

Pattern 2: the card-stream (not chat) surface

The second recurring choice is the user-facing surface. None of the four leads with a chat window as its primary interaction model. All four use some variant of a structured-card stream: the coordinator produces a typed card that asks a specific question or surfaces a specific result, the operator clicks, the work continues.

The chat surface exists everywhere — there is usually a coordinator-level conversation channel — but the workhorse interface is not chat. This is, in our reading, the right call. Chat-first surfaces are easy to build and difficult to live with, because they push the work of synthesizing the agentic state back onto the human. A structured-card surface forces the platform to do the synthesis — to decide what the operator actually needs to see — which is the kind of work an operating system should be doing on the operator’s behalf.

The choice has implications down the stack. A card-based surface needs typed responses, which means the platform needs a structured output discipline at every layer. It needs the specialists to return data the coordinator can render, not just text. It needs the audit layer to know which cards were shown and which were clicked. We do not have visibility into how cleanly each bundle implements this, but the surface implies the discipline.

Pattern 3: credit-based scheduling

The bundles price on credits, not seats. The credit is the unit of work — a token, a tool call, a model invocation, a browser action, depending on the platform — and the user buys a budget at a tier that gives them a volume discount on the credits themselves.

The pricing model is more architecturally important than it looks. A credit budget is, effectively, a scheduling constraint. The platform has to know, at every moment, how much budget remains, which agents are running, and how to slow down or shed load when the budget runs low. This is more than billing. It is the kind of resource accounting that a traditional OS does for CPU time and a cloud platform does for compute. Without it, an agentic platform either has to refuse jobs at provisioning time or let costs run away at execution time.

The tier models also rhyme. Sema4.ai sells Robocorp run-hours plus action quota; MultiOn sells action units; Adept sells task units; the workforce-shaped bundle sells credits with a commitment-level discount. Across the four, the tier is presented as a commitment level rather than a feature gate. This is the cloud-platform pricing pattern, not the SaaS pattern, and it matches the architecture: the platform is selling infrastructure, not features.

Pattern 4: the canonical-host bet

The most consequential recurring choice is what each bundle treats as canonical. None of the four wants to own everything.

• Sema4.ai treats the user’s existing automation runtime (Robocorp, or a customer-owned worker) as canonical for execution.
• MultiOn treats the user’s browser as canonical for state.
• Adept’s ACT family delegates to whichever application surface it is acting on.
• Web4OS treats the user’s code repository as canonical for files and a third-party PaaS account as canonical for deployments.

The shape is the same in every case. The platform owns the orchestration and the surface; it leases the substrate. This is a real architectural commitment. It removes a class of trust problems — the operator is not putting their files or actions on a vendor’s storage they cannot inspect — and it commits the platform to a per-user OAuth model in which every operation is performed on behalf of the user, against tokens the user has scoped.

The cost of the bet is that the platform’s quality depends on integrations it does not control. If GitHub changes a rate limit or a browser deprecates an automation API, the bundle has to chase. The benefit is that the platform inherits a well-understood substrate without having to invent it.

In our reading, the canonical-host decision is the single most consequential architectural choice in this generation of products. It is the difference between a vendor-lock product and a substrate that an operator could conceivably leave without losing their work. It is also the choice that, more than any other, lets a bundle plausibly claim the operating-system label: the platform is mediating between the user’s existing infrastructure and the agents that act on top of it.

A second-order pattern: the pre-installed audit skill

Three of the four bundles ship a continuously-running audit pass over specialist output. Sema4.ai calls it “process visibility.” MultiOn has an action-replay log. The workforce-shaped bundle ships an audit specialist that is not optional. (Adept’s ACT family has the weakest audit story of the four, and is the bundle whose lock-in story we are most uncertain about.)

A continuous audit pass is what we would expect of a serious agentic OS. Without it, the supervisor topology produces output the user has to trust blindly. With it, the platform is checking its own work.

The more interesting variant is the “level-up” or capability-growth skill that some bundles ship — a meta-agent that learns about the user’s capabilities (do they have a CLI installed, do they have a workspace account, do they know how to use the deploy target) and proactively nudges them toward integrations that would unlock more of the platform. We have seen this most clearly in two of the cohort, and in a quieter form in Sema4.ai’s onboarding. It is a posture closer to an operating system than to a chat product: the platform considers user capability part of its own state.

What is not yet settled

A few questions are not answered by the public architectures.

The first is third-party agent installation. An OS has to be a target other developers build on. The bundles today are, with one partial exception, closed products — the agents that ship are the vendor’s. If the platforms expose real SDKs and other developers ship specialists for them, the OS label gets a lot more credible. If they do not, the bundles are very good vertical platforms, not OSes.

The second is the audit story under failure. A pre-installed audit pass is a strong design choice, but it has to handle the case where the coordinator and the audit specialist disagree. We have not seen public documentation of how that conflict is resolved in any of the four bundles.

The third is scheduling under contention. The credit-based pricing model implies a real scheduler. The current surfaces — one operator, a handful of concurrent goals — do not stress it. Whether the schedulers hold up when one operator is running twenty parallel jobs against a tight budget is a real question, and the answer will determine how much load each platform can carry per-seat.

A working assessment

The bundled agentic platforms are converging on a small number of architectural choices. Supervisor-led topology. Card-stream surface. Credit scheduling. Canonical-host integration. Pre-installed audit. The convergence is, in our reading, evidence that those choices are right rather than coincidence: four products targeting different users have independently arrived at the same shape because the shape is what the operator-facing layer of an agentic OS has to be.

The interesting comparisons within the convergence are about which canonical hosts the bundles pick (filesystem vs browser vs deploy-target), how strict the topology commitment is (supervisor-only vs supervisor-by-default), and how much capability-growth work the platform takes on. Those choices are the ones that will determine which bundles survive once the category settles. The next piece in this series will look at the framework layer’s response to the bundles — particularly LangGraph’s “templates” work and the CrewAI Studio surface — where the framework world is borrowing from the bundles’ surface decisions in real time.