Managed vs Assembled AI Agents Which Path Fits Your Team
Both paths build the same agent system—what differs is whether your team becomes the roadies, the sound engineer, or the label itself.
Session Musicians or a Road Band
The logical design of a two-agent system does not change between a managed runtime and assembled primitives. The list of things your team owns for the next three years changes completely.
Aja took over a year to record. Donald Fagen and Walter Becker brought in some of the finest studio musicians in Los Angeles, sometimes auditioning multiple players for a single part, running take after take until the performance matched the sound that existed in their heads. The drummer on one track might be gone by the next. The guitarist who played the session might never hear the final mix. Every element was controlled individually, assembled with precision, and optimized as an isolated contribution to a larger thing that only Fagen and Becker could hear in full.
A working road band does it differently. The players already know each other's tendencies. The arrangement is settled before the first day of tracking. The record gets made because the unit functions as a unit, and what you gain in speed and coherence, you trade against the fine-grained control you never had to begin with. Neither method is superior. They are answers to different questions about what you are optimizing for, and confusing one question for the other produces records that nobody wanted and sessions that cost twice what they should have.
The current conversation about agent platform selection is being had mostly as a question of identity: are you a team that builds or a team that buys? That framing produces bad decisions in both directions, because it makes the answer a statement of character rather than a consequence of constraints. This article identifies the specific layer where the two paths actually diverge, and the four constraints that decide which path fits your situation.
The Constraint Set
Start with a design that is already settled. Two agents in separate trust domains, one on the provider side and one on the payer side, sharing nothing but a protocol. The payer agent runs a five-stage pipeline: intake, benefit check, medical necessity, routing, human review. Negotiation happens over one persistent task identifier with four possible outcomes, and a confidence gate that never permits an automated denial on uncertainty. Both sides write immutable audit records.
Every sentence in that paragraph is true regardless of what the system runs on. The pipeline stages, the trust boundary, the confidence gate, the audit obligation, and the protocol itself do not move when the platform moves. That is the fact the entire decision rests on, and it is the fact most teams skip past on the way to arguing about infrastructure.
The pressures that make this hard are not technical. There is a compliance function that needs to see where data sits, a platform team with a fixed headcount and existing commitments, an executive timeline measured in quarters, and a genuine uncertainty about whether this system will be one workload or thirty. Those four pressures decide the answer. The architecture diagram does not.
What makes this scenario real rather than textbook is that the teams involved do not get to start from a clean slate. The platform team is already carrying two other programs. The compliance review has a known set of questions it will ask, and some of those questions have different answers depending on where inference happens. The sponsor will fund one meaningful effort this year, and a pivot in month six is not a planning assumption anyone will accept. The textbook asks which runtime is architecturally superior. The real meeting asks which path the organization can actually execute and defend.
What Actually Differs, Layer by Layer
The design is fixed. The execution surface is not. Walking through the operational layers makes the difference visible without requiring a conclusion before the evidence is in.
Agent hosting and the runtime itself. Someone has to run the process that executes the agent loop. In a managed runtime, that is the platform's obligation: scaling, isolation, and lifecycle are handled. Assembling primitives, your team owns the container, the orchestration layer, and the decisions about how the agent process restarts when it fails.
The protocol server layer. The endpoints, streaming behavior, task lifecycle management, and capability publishing all have to exist somewhere. A managed runtime provides them as a surface. Assembled, your team builds and maintains them, which means owning the upgrade path when the protocol specification updates, and the protocol between two agents in separate trust domains is the part that does not change regardless of runtime, so the investment in getting it right is not wasted in either shape.
Model invocation. Routing calls to a model, handling retries, managing rate limits, and controlling which model version is in use. A managed platform abstracts this; you inherit its choices. Assembled, you own the routing logic and every cost and latency consequence that follows from it.
Backend tool connectivity and authentication. The agent needs to reach systems of record. In a managed runtime, the connectivity model is the platform's, and your credentials must conform to it. Assembled, you design the authentication pattern yourself, which is flexibility that carries an audit surface with it.
Peer identity between agents in separate trust domains. This is the layer where the stakes are highest in a two-party design. How does the payer agent prove to the provider agent that it is who it says it is? A managed runtime offers an answer that may or may not satisfy your counterparty's requirements. Assembled, you specify the trust model, which means you can make it satisfy the requirements and means you are responsible when it does not.
Authorization policy. Which agent can invoke which capability, under which conditions, for which principal. Managed runtimes offer policy surfaces of varying expressiveness. Assembling gives you full control and full responsibility for correctness.
Durable task and session state. A five-stage pipeline with a persistent task identifier requires state that survives restarts, and the persistent state and audit obligations in a design like this are exactly what a stateless deployment cannot satisfy. Managed runtimes handle durability internally. Assembled, you choose the store, the schema, and the consistency model.
Observability and tracing. Distributed tracing across a trust boundary, in a regulated context, requires trace data to land where compliance says it can land. Managed runtimes emit to their own observability infrastructure first. Assembled, you decide where traces go from the beginning.
Deployment and infrastructure as code. Managed runtimes reduce the infrastructure footprint that your team manages. Assembled, every component has a Terraform module and an owner, and one of your senior engineers may find that their primary professional identity, eighteen months in, is custodian of three YAML files, one identity broker, and a load balancer they have developed complicated feelings about.
The conclusion the list produces is not about capability. Both shapes can run this design correctly. The difference is custody: how many operational obligations your team is holding three years from now, and in which direction those obligations move when something upstream changes.
The Four Constraints That Decide It
Four constraints settle this question, and none of them is a technology preference. The first is portability requirement. If the workload must run across more than one cloud, or must be capable of moving on a contractual timeline, assembled primitives are the answer and the extra plumbing is the price of the option. If it will live where it is born, that option is being paid for and never exercised.
The second is platform team capacity, measured honestly rather than aspirationally. Assembling the identity, state, and observability layers yourself is not a one-time build, it is a standing obligation with an on-call rotation attached. A team that cannot fund that obligation for three years should not take it on for three months.
The third is the compliance question that will actually get asked, and the fourth is workload count. One workload almost never justifies building a platform. Thirty workloads almost always do, because the plumbing amortizes and the operational patterns become shared assets rather than per-project overhead.
For portability, the question to bring into the room is specific: does a signed agreement or a regulatory boundary require this workload to move, or does the portability requirement exist because someone is uncomfortable making a commitment? If it is the latter, assembled primitives are not solving the problem.
For platform team capacity, count the people who would hold the pager for the identity broker at 2 a.m., then ask whether those people have that capacity for the foreseeable future. Aspirational headcount does not count.
The compliance question is the most underspecified of the four, and it deserves precision. Your compliance team will ask where inference happens, where session state persists, what is retained and for how long, and who can see the trace. Those questions have concrete answers on any runtime you are evaluating, and the answers are knowable before you commit. Every managed platform demo ends at the moment just before the part your compliance team cares about, so that part requires specific inquiry rather than assumption.
For workload count, the honest version of the question is not how many workloads you hope to have, but how many you have funding and staffing to build in the next eighteen months. If the number is one, the platform amortization argument is not available to you yet.
Where This Goes Wrong
The strongest argument against a managed agent runtime is that it abstracts precisely the layer that is still moving. Agent identity, protocol support, and durable session semantics are all being defined in public right now, and adopting a managed abstraction over an unsettled layer means inheriting whatever the platform decides that layer should mean. When the abstraction leaks, it will leak at the boundary you understand least.
That argument is correct, and it is also symmetric. The primitives are moving too. Assembling the layer yourself does not exempt you from the churn, it makes you the owner of every migration instead of none of them. The risk does not vanish in either direction. It changes hands.
Here is the condition under which I would reverse the recommendation in either direction. If the system's differentiating value lives in the platform layer itself, meaning the identity model or the state semantics are the product, buy nothing and assemble everything. If the differentiating value lives in the domain logic, which for most enterprise systems it does, then owning the platform layer is a tax on the part that matters.
Reversibility is a design property worth protecting regardless of which path you take. Three things should stay yours in both shapes: the protocol contract between agents, the schema of the durable task state, and the format of the audit record. If those three artifacts are owned by your team and specified independently of any runtime, your migration cost in either direction is bounded. If they are implicit in the platform's implementation, you will discover their shape only when you try to leave. Keep those artifacts explicit, versioned, and under your control from the first sprint.
Both paths are legitimate. The article's conditional leaning is toward assembled primitives when portability is required or platform team capacity is genuinely available, and toward managed runtimes when compliance requirements are satisfiable within the platform and the workload count does not justify building a platform. That leaning is a consequence of the four constraints, not a view about any vendor.
What to Bring to the Next Meeting
Write down the four constraints before the next platform meeting: portability requirement, platform team capacity, the compliance question that will actually be asked, and workload count. Put real answers next to each one. Bring that page instead of a preference.
The decision that follows will be defensible because it follows from something other than infrastructure instinct. The teams on both sides of the table will be able to evaluate it against their own constraints rather than against a vendor's positioning.
The song was never the question. Fagen and Becker knew exactly what they were making before the first session booked. The only question was how the session would be run.
References
[1] Anthropic. "Building Effective Agents." Anthropic Engineering, December 2024. https://www.anthropic.com/engineering/building-effective-agents
[2] Google. "Announcing the Agent2Agent Protocol (A2A)." Google Developers Blog, April 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/ — Specification: https://a2a-protocol.org/latest/specification/
[3] Amazon Web Services. "Amazon Bedrock AgentCore is now generally available." AWS What's New, October 2025. https://aws.amazon.com/about-aws/whats-new/2025/10/amazon-bedrock-agentcore-available
[4] Anthropic. "Introducing the Model Context Protocol." Anthropic, November 2024. https://www.anthropic.com/news/model-context-protocol — Documentation: https://modelcontextprotocol.io
[5] Temporal. "Durable Execution for AI Agents: State, Retries, and Long-Running Workflows." Temporal Blog, 2025. https://temporal.io/blog/build-durable-ai-agents-pydantic-ai-and-temporal