A Job for Every Piece
In our report workflow, the model drafts. Code chooses the sources, checks permission, and records delivery. Each part owns a different responsibility.
The same division of labor works in a larger system—whether you build the pieces, borrow them, or buy them.
THE MAP
One component can own several jobs. A workflow may need no generated code or long-term memory. For every responsibility, decide what the job requires, who supplies it, and how to check that it works.
The handoffs matter as much as the pieces. Context is not permission. A sandbox is not business authorization. Every transition must preserve who owns the work and what may happen next.
USEFUL WORK
A fixed sequence, a model choosing tools, and an ongoing delegated task need different amounts of discretion. All three can share the same services.
Persistence, autonomy, and permission are separate choices. A scheduled report persists over time without a model planning its steps. An autonomous investigation can be short-lived and tightly scoped.
Application code Model judgment Person’s decision
ONE WORKING EXAMPLE
Our RD-platform supports conversations, analysis, and recurring reports. This report path is a defined workflow inside an agent-capable application: code runs the sequence, and a tool-free model drafts from prepared evidence.
“Check these sources. When they change, write a report and send it to this channel.”
Only the drafting step calls the model. Unchanged sources can skip inference. The separate interactive path can offer Python; this report does not need it.
Authority travels with the run. Permissions 01 and operations 08 apply throughout. Delivery checks the current grant and records a receipt; it is not a consequence of the model saying “send.”
We built and run this assembly on one shared host. It demonstrates the connections; it does not establish enterprise capacity or high availability.
Original system map ↗The worker loads the owned job, checks the active version, fetches its approved source URLs with bounded responses and private-address checks, and compares evidence hashes. Unchanged inputs stop the drafting path; unresolved delivery has separate recovery behavior.
The application saves the draft with source provenance. A separate delivery worker rechecks the job, document, standing grant, and destination version. Pauses and edits can hold a send. An uncertain outcome must be reconciled before repeating it.
SUPPLY THE PIECES
These are choices for each responsibility, not three competing architectures. Our system already combines custom application logic, adopted open-source components, and hosted model services.
Borrowing still requires integration, configuration, maintenance, and recovery. Buying changes the operating contract: a managed database and a finished workforce product take over different amounts of the job. Open-source software can also be offered as a managed service.
APPLIED EXAMPLE · AWS PROPOSAL
AgentCore could host our drafting code and provide identity, tool policy, execution, and telemetry services where needed. Other AWS services supply schedules, queues, and storage. Our application still defines who owns the report, what it may read, and when it may send.
Compare all eight responsibilities ↓The positions and responsibilities stay fixed when you switch. The service choices change. This is a proposed allocation of work, not a deployed AWS system or a one-to-one migration plan.
The agreed job stays the same. This proposal covers setup and execution; it keeps the known sequence in application code.
A short model call could stay in Lambda. AgentCore Runtime is a hosting choice, not a reason to add a planning loop. The report does not require Gateway tools, Python execution, or conversational Memory.
Move scheduling, hosting, and storage one boundary at a time. Keep owner checks, job versions, exact source URLs, approval hashes, and send receipts. The managed services run the mechanisms; our handlers define the application’s behavior.
Bind runtime sessions to verified owners in our backend. Give the drafting runtime only the model and logging permissions it needs. Keep database writes and the delivery credential in their designated services. Scope execution-role credentials, which can be accessed inside the VM.
Gateway + Policy can mediate interactive tool calls, while each handler enforces business scope. Constrain direct paths that bypass the gateway. Optional Code Interpreter needs a tested network and execution-role policy; SANDBOX mode still permits limited AWS access, including S3.
Check allowed and denied work, changed permissions, duplicate events, paused jobs, exhausted budgets, uncertain sends, and recovery. Managed invocation limits do not replace cumulative per-owner accounting, and Memory does not replace the business ledger.
WHAT OFFERINGS TAKE ON
Some offerings supply a mechanism. Others operate infrastructure, govern a fleet, or provide the whole agent experience. Use the eight responsibilities to see what each takes on—and what your organization still configures or supplies.
Bubblewrap and Firecracker provide execution primitives. OpenShell adds surrounding policy and supervision. They help with 06 execution boundaries; they do not define a business workflow.
AWS AgentCore spans hosting, identity, tools, and observation. TrueFoundry documents a control platform for agent policy, routing, budgets, and traces. The integration still defines the application’s work and authority.
Microsoft Agent 365 emphasizes inventory, identity, access, lifecycle, and governance. That is an organization-wide responsibility, distinct from how any one agent executes a task.
Muse, dots, and Duet illustrate ongoing delegation; Copilot Studio and Agentforce connect agents to business work. Products make more of the design choices, while administrators still decide access, connections, and permitted use.
Availability differs. Duet is a research preview; these examples are not an equivalent set of enterprise procurement options.Each profile uses the same responsibility map. It describes published behavior, followed by our design interpretation. Our own implementation is the report example above.
ACROSS A WORKFORCE
At enterprise scale, the same responsibilities serve many people and concurrent jobs. The challenge is keeping ownership, limits, and recovery intact as the shared system grows.
Verified owner · permitted context & tools · execution & spending limits · current action grants · durable progress
Every responsibility has shared-service and per-job concerns: one identity service, but a permission check for each action; one database, but owned records for each job. This diagram shows those two views, not a prescribed deployment topology.
Carry ownership through tools and queues. Make a pause, revoked account, or changed permission reach unfinished work before the next action.
Allocate budgets, concurrency, and execution limits. Test capacity and availability under expected load, including retries and noisy neighbors.
Connect decisions to external receipts. Evaluate output quality, rehearse recovery, and manage releases and incidents with named owners.
In our 24 October pilot, 48 scored model episodes across Bubblewrap, Firecracker, and OpenShell with Docker produced no verified restricted effects. The models still attempted forbidden actions. All 74 deterministic boundary checks passed.
The experiment tested specific command-sandbox configurations, with model inference and trusted orchestration outside them. It did not rank general escape resistance or validate our Podman implementation, the proposed AWS design, or enterprise-wide security.
Source: our internal containment results and recorded configuration. No product in the comparison was evaluated as a workforce platform.
TAKE THE MAP TO YOUR NEXT WORKFLOW
Take one workflow, such as monitoring supplier changes. Name its owner, the decisions the model may make, and the service responsible for each of the eight jobs.
Follow the handoffs: evidence into the model, a draft into storage, an approved action into delivery. Check that permissions survive each transition and that the final effect has a trustworthy receipt.
Use the eight-piece mapREFERENCE
Checked 25 October 2026. Our implementation, proposed architectures, documented product behavior, and experimental evidence are labeled separately. The eight-part map is this guide’s design framework, not a certification standard.
Use the details to inspect a claim. Product documentation is not evidence that we tested its security, quality, or scale.