A two-plane worksheet for agent operating systems—and an explicit infrastructure boundary

An agent platform can fail review even when its components are individually understandable. The ambiguity often sits between policy and execution: who decides what an agent may do, which runtime enforces that decision, and who owns the infrastructure when deployment conditions change.

A recent AOS paper proposes a vendor-neutral split between a Control & Governance Plane and a Runtime & Coordination Plane. The control plane covers intent, policy, trust, authority, auditability, observability, and human oversight; the runtime plane covers lifecycle, workflow coordination, routing, memory, scheduling, traffic management, and runtime assurance (src-2-1). That is a proposed reference architecture, not evidence that the industry has adopted a standard.

A separate U.S. government notice describes AI agent systems as operating in varied deployment environments and seeks information about how those systems are documented (src-2-2). The notice does not establish a particular implementation. It does, however, make deployment context and operational boundaries relevant inputs to an architecture review.

Turn the split into a review worksheet

Use the two planes as a labeling exercise for each runtime contract. For every capability, record five fields:

1. Decision: What intent, policy, trust judgment, or authority grant is being represented?
2. Enforcement: Which runtime component actually blocks, permits, routes, schedules, or records the action?
3. Handoff: What data and authority cross from governance into execution, and in what format?
4. Infrastructure owner: Which team owns the host, network, identity, storage, and operational controls in the declared deployment context?
5. Evidence: What artifact could a reviewer inspect to confirm the decision, enforcement behavior, and boundary conditions?

This worksheet is an SGL design prescription derived from the two source observations. It is useful precisely because the sources do not claim that one plane automatically governs the other.

Consider routing. A governance decision might constrain an agent to a named task and approved tools. Runtime coordination then selects a route, schedules work, and manages traffic. The review question is not merely whether a policy exists; it is whether the handoff preserves the policy’s scope when routing or scheduling changes. If the runtime can select a different worker, model, or memory store, record that transition as part of the contract.

Memory deserves the same treatment. The AOS proposal places memory in runtime coordination, while trust and authority sit in governance (src-2-1). An operator worksheet can therefore ask which governance decision controls retrieval, which runtime component performs retrieval, and which infrastructure owner is responsible for persistence and deletion behavior. The paper does not document a universal memory-control mechanism, so those answers remain system-specific.

Make deployment context explicit

The Federal Register notice’s varied-environment framing supports a practical requirement for documentation: name where the system runs and what surrounds it (src-2-2). A useful record includes the execution environment, external services, identity boundaries, data stores, network paths, human-oversight channel, and failure destination. Treat this as an architecture-review checklist, not as a claim that the notice mandates these exact fields.

For each boundary, capture the transition and its owner. A governance service may issue an authority decision; a runtime scheduler may enact it; an infrastructure team may operate the scheduler’s host; and a security reviewer may verify the resulting evidence. Separating those roles makes gaps visible without implying that organizational structures are universal.

The operator takeaway

The two-plane model is most valuable as a disciplined question set. Use the AOS proposal to distinguish governance concerns from runtime coordination, and use the government notice to force deployment context into the record (src-2-1; src-2-2). Then test every handoff for preserved authority, named infrastructure ownership, and inspectable evidence. Teams ready to turn that worksheet into implementation work can continue at /build.