A mid-market firm adds an AI agent to handle customer requests or an internal workflow. A decision arrives that nobody put on the project plan. Someone has to run the thing: patch it, watch it, answer for it at nine on a Tuesday morning when it does something wrong. That decision, not the choice of model, drives most of what the project costs in its first year.
The decision hiding inside every agent project
An agent framework decides how the system reasons and calls tools. A runtime decides where that system lives, and who is on call when it breaks. Most vendor conversations focus on the first question. They skip the second. That is backward. The second question carries the real cost.
Amazon made this case plainly when it introduced Bedrock AgentCore. Developers building agents on open frameworks such as CrewAI, LangGraph, LlamaIndex, and Strands Agents could reach a working prototype fast. Then they spent months on the infrastructure a production system actually needs: session management, identity controls, memory, observability (AWS News Blog, July 2025, updated October 2025). Microsoft built the same case for Azure AI Foundry Agent Service. It reached general availability with more than 10,000 customers already running production agents on it (Microsoft Community Hub, May 2026). Two of the largest cloud vendors reached the same conclusion independently. The gap between a demo and a production system is mostly infrastructure work nobody wants to repeat.
This is not a hypothetical decision reserved for firms with a large engineering team. Gartner projects that 40% of enterprise applications will carry task-specific AI agents by the end of 2026, up from under 5% a year earlier (Gartner newsroom, August 2025). Most of that growth will arrive inside software a mid-market firm already buys. It will not arrive as a project the firm chooses to start. The question of who operates the resulting agent lands on someone’s desk either way.
What a hosted runtime actually takes off your plate
A hosted runtime is a bet. The bet: a cloud vendor will run the unglamorous layer better than your own team can. Running it is the vendor’s core business. For most IT teams, it is a side project. Concretely, that layer includes isolating each user’s session so one conversation cannot leak into another. It includes managing the tokens and credentials an agent needs to reach a CRM or a calendar, without over-granting access. It includes persisting memory across sessions without a homegrown database. It includes producing the traces an engineer needs at two in the morning to find out why an agent gave a wrong answer.
None of that work shows up in a sales demo. All of it shows up in the first serious incident. Picture a firm without a dedicated platform function, which describes most mid-market operators. Every time it self-manages this layer instead of buying it, it takes on a small piece of cloud infrastructure with no ongoing reason to own it. That is a fair choice for a firm with unusual data residency requirements, or a platform team already in place. For most others, it is a cost paid to prove a point about control, one nobody downstream will thank them for.
Buying the runtime does not buy you governance
Here is the part a vendor pitch will not volunteer: outsourcing the infrastructure layer does nothing to answer who is accountable for what the agent does. Gravitee’s 2026 survey of 750 senior technology leaders across the US and UK found that only 7.2% of organizations name one individual formally accountable for agent behavior. The rest call accountability unclear, shared but undefined, or simply never discussed. The same survey found that 48% of production agents run with no active security monitoring. Fifty-four percent of organizations already had a confirmed or suspected AI agent security incident in the past year (Gravitee, State of AI Agent Security 2026, updated April 2026).
Routing an agent through AWS, Microsoft, or Google changes none of those numbers. Identity, access scope, escalation rules, and who to page during an incident: the buyer decides all of it, no matter who operates the servers underneath. A hosted runtime hands an organization better tools for governance: tracing, access policy, audit logs. A tool does not enforce its own use, though. Gravitee’s survey does not break its numbers out by hosted versus self-managed infrastructure. [UNVERIFIED — see flags list below.] The accountability gap it measures sits across the whole surveyed population, hosted and self-managed alike. Someone still has to configure the audit logs a hosted runtime makes available, and someone still has to watch them.
The sequencing that avoids expensive rework
The buy-versus-build question and the governance question are separate. Treating them as one conversation with a vendor is how firms end up answering neither well. Governance comes first, and it costs nothing to decide. Name one person, not a committee, accountable for each agent already running in the business. Define what data that agent can reach, and log every access to it. Write down who to call when it fails, and what they can authorize in the first hour. None of this depends on which runtime the agent uses.
The infrastructure question comes second. It is genuinely a capacity question. Does the team have, or want, the ongoing discipline of running session isolation, identity, and observability as a permanent function, the way it runs any other production infrastructure? Most mid-market firms answer no, correctly. A hosted runtime is the more defensible choice for them. A smaller number already have the platform capacity, plus a specific regulatory or architectural reason to keep the layer in-house. Neither answer replaces the governance decision. That one happens either way.
The decision in front of you
One vendor conversation usually bundles two separate questions: who operates the infrastructure underneath your agents, and who answers for what those agents do. Most firms resolve the first question by picking a platform. They treat the second as settled by implication. The data says it is not. Before adding the next agent to the business, name the person accountable for the ones already running. Only then, decide whether your team should operate the infrastructure layer, or buy it from someone whose core business is running it well.
Origo’s advisory work starts with that separation: an audit of who owns which layer of an organization’s AI stack, before any recommendation about which platform to run it on. We work alongside a limited number of clients on both the infrastructure decision and the governance structure underneath it. A technology choice is something a business has to live with. It is not a feature a vendor gets to define. See Origo’s approach to AI and automation implementation, or bring the question to us directly.
Schedule a free discovery call to get a layer-by-layer read on your AI agent stack. → Book a discovery call
Ready to explore what AI can do for your team?