Why AI Agents Need a Runtime, Not Just a Framework · Blog · Phrony<br>ai-agents<br>runtime<br>infrastructure<br>governance<br>llmops<br>Why AI Agents Need a Runtime, Not Just a Framework<br>Building agents is solved. Governing, versioning, approving, auditing, and operating them once they touch real systems is not — and that's a runtime's job, not a framework's.<br>July 8, 2026Emad Mamaghani15 min read

The review

The agent works. That's not the problem.

Your team built it in a sprint — a support agent that reads tickets, looks up accounts, and issues refunds. The demo landed. Leadership loved it. Then it went to deployment review, and the questions started:

"Show us every action it can take, and prove it can't exceed these limits."

"Where does a human approve the risky ones — and where's the record of that approval?"

"Which version is running in production right now? Who changed its permissions last month?"

"How many agents like this do we have, actually?"

Nobody in the room could answer. Not because the engineers were sloppy — because the answers don't exist anywhere. The project didn't fail; it stalled. Parked in permanent pilot, next to the other three agents other teams built the same quarter, each on a different framework, none of them inventoried anywhere.

If this sounds familiar, that's because it's the norm. PwC finds 79% of executives report agents already being adopted in their companies — while trust collapses precisely for higher-stakes tasks like financial transactions. Deloitte's 2026 research expects three-quarters of companies to be using agents at least moderately by 2027, yet finds roughly 80% lack mature agentic governance: decision boundaries, approval rules, monitoring, audit trails. McKinsey's agentic-security guidance reads like a spec nobody has implemented — lifecycle governance, ownership, escalation triggers, agent portfolios, logging.

Notice what's not on the list of gaps: building agents. That problem is solved several times over — OpenAI Agents SDK, LangGraph, CrewAI, Bedrock Agents, your own internal framework. The gap is everything after the demo: deploying, versioning, governing, approving, auditing, and operating agents once they touch real systems.

So before reaching for a solution, it's worth understanding precisely why a well-built agent can't answer those four questions.

Why the answers don't exist

Look at what "the agent" physically is when it's built framework-style:

Python<br>Copy<br>agent = Agent(<br>model="...",<br>tools=[search_crm, lookup_account, issue_refund],<br>system_prompt=PROMPT, # constants.py, v3, probably

Now run the review questions against it.

What can it do, and what are its limits? The tool list says what it can call. The limits are an if-statement inside issue_refund() — which nothing prevents the next commit from removing. There's a difference reviewers care about deeply: this agent is instructed not to exceed limits, not unable to.

Where's the human approval? Maybe a Slack webhook someone wired into one tool. The decision, if it happened, lives in a chat scrollback.

Which version is in production? Whatever was on main when the pod last restarted. The prompt lives in one file, the tool code in five others, the permissions in environment variables. There is no single artifact that is the agent, so there's nothing to version.

How many agents do we have? Unanswerable by construction. Each agent is a pattern of code inside some application, invisible to any inventory.

None of this is the framework's fault. A framework is a library: it structures code, gets compiled into your artifact, and disappears. It lives inside your process and has no opinion about what happens after deploy. Asking it to enforce limits, record approvals, or version behavior is asking a library to do an environment's job.

And that phrase — an environment's job — is the tell. We've been exactly here before.

We've solved this problem before

Every generation of consequential software has gone through the same arc: code first, environment later — and the environment is what made the code trustworthy.

Early programs owned the whole machine; one bad pointer took everything down. The operating system introduced the idea that programs run inside something — scheduled CPU, protected memory, mediated I/O. The 1990s repeated it: the JVM put a managed layer between code and machine, and engineers who grumbled about the overhead never went back. The 2010s repeated it again: Kubernetes made the environment declarative. You stopped SSH-ing into boxes and started writing manifests — replicas, resource limits, health checks — with a control loop enforcing them. The manifest, not the shell session, became the source of truth.

By now the pattern has hardened into how enterprises treat everything that matters: infrastructure is Terraform, access is IAM policies, APIs are OpenAPI schemas, deployments are Kubernetes manifests. Each is a declared, versioned, owned, enforceable artifact .

Except one thing. Agents —...