Running AI Agents in Production: Internal Platform Team vs Managed AI Operations

By Kehinde Ogunlowo · July 27, 2026

Running AI Agents in Production: Internal Platform Team vs Managed AI Operations

The pilot worked. An agent answers internal questions, triages tickets, or drafts responses, and the demo convinced leadership. Now someone asks the question that decides the next two years of budget: who operates this?

There are two honest answers. Build an internal AI platform team that owns the agents the way a platform engineering team owns Kubernetes. Or buy managed AI operations — a provider who runs the agents, the guardrails, the evaluations, and the governance evidence as a service. Most organizations drift into a third, dishonest answer: the engineer who built the pilot keeps it alive part-time until they change jobs. This post is about choosing deliberately, based on what operating agents actually costs.

What "Operating AI Agents" Actually Involves

The build-vs-buy comparison only makes sense once the work is itemized. Running production agents is not "keep the API key funded." The recurring workload looks like this:

• Model and API churn. Providers deprecate models, change behavior between versions, and adjust pricing. Every model change requires re-running evaluations, adjusting prompts, and sometimes re-tuning guardrails. This is not an annual event; expect it multiple times per year per provider.

• Evaluation maintenance. A golden test set decays as the business changes. New products, new policies, and new edge cases mean the eval suite needs the same continuous investment as a regression test suite — plus human review sampling, because automated metrics miss real failures.

• Guardrail and permission tuning. Prompt-injection patterns evolve, new tools get added to the agent's registry, and permission boundaries need review whenever scope grows. The security posture of an agent is a moving target, as the threat models in AI agent deployments make clear.

• Incident response. Agents fail in ways conventional software does not: confident wrong answers, tool misuse, data leakage through outputs. Someone must be on call who understands both the agent stack and the business context, with runbooks and a tested kill switch.

• Cost management. Token spend, retrieval infrastructure, and evaluation runs all scale with usage. Without active management — caching, model tiering, quota enforcement — cost grows faster than value.

• Governance evidence. Audit trails, access reviews, model change records, oversight documentation. If your organization aligns with ISO/IEC 42001 or the NIST AI RMF, or sells into buyers who ask, this evidence must exist continuously, not be reconstructed before each audit.

Every one of these lines exists whether you build or buy. The question is only who staffs it.

The Build Path: An Internal AI Platform Team

Staffing reality

A minimal credible team for production agents serving real users:

• One to two platform/LLM engineers who own orchestration, RAG infrastructure, and integrations
• Evaluation ownership — often a fraction of an engineer plus domain experts' review time, but it must be someone's explicit job
• A security engineer's allocation for permission reviews, guardrail testing, and incident response
• On-call coverage, which for a two-person team means those two people, always

That is roughly three to four full-time-equivalents before the team builds anything new — this is the standing cost of operating what already exists. Salaries dominate the budget; in most deployments we see, people cost a multiple of the model API spend. Teams that budget for tokens and forget the humans are the ones that end up with the part-time-hero anti-pattern.

Hidden costs

• Ramp time. Hiring engineers with production LLM experience is slow, and training existing platform engineers takes quarters, during which the pilot's author is a single point of failure.
• Underutilization at small scale. Three FTEs operating two agents is expensive per agent. Internal platforms earn their cost at portfolio scale — five, ten, twenty agents sharing the same orchestration, evaluation, and governance machinery.
• Governance is a second product. The audit trail, the access reviews, the evidence pipeline — internal teams routinely build the agent and defer the governance layer, then pay for it under audit pressure. The architecture required is well understood — we detailed it in Building an Enterprise AI Stack in 2026 — but understood is not the same as staffed.

When build wins

• The agents are core to your product or competitive position, not internal utilities. You do not outsource the thing you sell.
• You are heading toward portfolio scale, where shared platform cost amortizes across many agents.
• You already have a strong platform engineering organization and can extend its on-call, observability, and change-management practices rather than creating them from scratch.
• Your domain integration is deep enough that an external operator would spend most of their time learning your systems.

The Buy Path: Managed AI Operations

Managed AI operations means a provider takes responsibility for the operating lines above: they run the orchestration and guardrails, maintain the evaluations, watch the models, handle AI-specific incidents, and produce the governance evidence — against agents that work on your systems, under your permissions, with your data boundaries contractually defined.

Cost profile

The trade is headcount for subscription. Instead of three to four FTEs of fixed cost, you pay a recurring service fee that typically lands well below the loaded cost of the equivalent team — because the provider amortizes its engineers, its eval tooling, and its incident experience across many clients. Cost becomes predictable and scales with agent count rather than jumping in hiring-sized increments.

The often-overlooked line is governance overhead transfer. Evidence production — audit trails, change records, oversight documentation in the shape auditors and enterprise buyers expect — is exactly the work internal teams defer and providers systematize, because they produce it for every client. What a governed operating model looks like is described in what are governed AI agents; a managed provider's pitch, in one line, is that governance arrives operational on day one rather than as a phase-two project.

The risks, stated plainly

• Context gap. An external operator knows agents; they do not know your CRM's quirks or your finance team's unwritten rules. Mitigate with a named internal owner who holds business context and reviews agent behavior — buying operations does not mean buying absence.
• Lock-in. If the provider's orchestration is proprietary and your prompts, evals, and ledgers live only in their systems, switching is expensive. Contract for exportability: your evaluation sets, your audit trails, your configurations are yours.
• Accountability boundaries. Shared-responsibility must be written down. Who approves a new tool in the agent's registry? Who is on call for a data-leakage incident? Who talks to your auditor? Ambiguity here is where managed relationships fail.

When buy wins

• The agents are internal capabilities, not product — support triage, document processing, operations automation — where differentiation comes from having them, not from operating them.
• You need governance credibility early: enterprise buyers or auditors are already asking questions your team cannot yet evidence.
• Your engineering organization is small or fully committed, and three FTEs of new standing cost is not realistic.
• You are running one to a few agents, below the scale where an internal platform amortizes.

The Hybrid Path

The choice is not permanent, and the common successful sequence runs managed-first: start with managed operations to get agents into production under real governance, build internal familiarity through the named-owner role, and insource operations later if agent count grows to platform scale — taking the provider's evaluation sets and audit history with you (which is why exportability belongs in the contract).

The reverse hybrid also exists: an internal platform team owns the engineering while a provider owns the governance layer — evaluations, audit evidence, oversight reporting. This suits organizations with strong engineers and no appetite for building compliance machinery. For enterprise teams answering security questionnaires about their AI features, that governance layer is frequently the urgent half.

A Decision Checklist

Score yourself honestly:

1. Are these agents product or plumbing? Product → build. Plumbing → buy.
2. How many agents in 18 months? One to three → buy. Ten-plus → build, or start managed and insource.
3. Can you hire and retain LLM-experienced engineers on your timeline? No → the build path is slower than the plan says.
4. Who is asking for governance evidence today? If auditors or enterprise buyers are already asking, buy the operational governance first; it is the slowest thing to build.
5. Does anyone own the pilot right now? If the answer is "the person who built it, informally," decide before they resign — that is the deadline.

Where to Go From Here

Whichever path you take, the governance requirements are identical: attributable actions, scoped permissions, audit trails, human oversight, and a tested shutdown path. The Enterprise AI Agent Blueprint documents that control set in vendor-neutral terms — use it to hold an internal platform team and a managed provider to the same standard. It is free.

If you are weighing this decision for a real deployment, our managed services practice operates exactly this stack for clients — book a call and we will walk through your agent portfolio, the staffing math, and which side of the line your situation falls on.