concepts
What Is an Agent Harness? How AI Agents Run in Production
An agent harness is the software around an AI model that gives it a computer, tools, permissions, approvals, and an audit trail. A plain guide for ops, risk, and payments leaders.
An agent harness is the software that surrounds an AI model and turns it into an agent that can do real work. The model reasons. The harness gives it a computer to work on, tools and data to use, permissions on what it can touch, approvals before sensitive actions, and a record of every step.
Runtime is the AI agent harness for payment and fintech teams. Every agent runs on its own computer in your cloud, with your approvals and a full audit trail, and anyone on ops, risk, compliance, or support can build one.
Every rock climber knows strength isn't what keeps you alive on a hard route. The harness does. AI agents work the same way. The model is the strength: it can read a bank RFI, trace a payout across three systems, and draft a reply in seconds. But strength alone is how you fall. In production, the harness decides whether an agent is useful or dangerous.
This guide is for leaders who own the queue, not the code. If you're the engineer building one, read How to build an AI agent harness.
The Model Isn't the Agent
When people say "we built an agent," they usually mean they wrote a good prompt and connected an API. That works in a demo. It breaks the first time the agent hits a timeout, runs out of context, or tries to touch something it shouldn't.
The model only does one thing. It takes in text and decides what to do next. Everything else is harness work:
- Where does the agent run, and what happens to that machine afterward?
- Which systems can it read, and which can it change?
- Who approves before money moves?
- What happens when the model provider goes down mid-task?
- How do you show an auditor exactly what the agent did last Tuesday?
None of those are model questions. All of them decide whether you can trust the agent on a real queue.
What's in a Harness
A production harness has a handful of parts. Skip one and you find out which one the hard way.
| Piece | What it means for your team |
|---|---|
| An isolated computer per run | Each agent works on its own sandboxed machine with a browser, terminal, and files. Nothing leaks between cases, and nothing touches production directly. |
| A coding agent that does the work | An agent like Claude Code, Codex, or OpenCode reads, queries, and writes small scripts to finish the job, instead of just chatting about it. |
| Tools and credentials | Access to your APIs, databases, MCP servers, and a browser for portals with no API. Secrets are masked, so the agent can use a key but never see it. |
| Runbooks and skills | Your SOPs, written once, so every run follows the same procedure and carries lessons forward. |
| Triggers where work happens | Agents start from Slack, Teams, WhatsApp, voice, email, an alert, or a schedule. Your team doesn't learn a new tool. |
| Guardrails and approvals | Agents start read-only. Anything that moves money or replies to your bank pauses until a person says yes. |
| Evals and budgets | Agents are tested on real resolved cases before a change ships, and spend is capped per run and per person. |
| Role- and team-based access | Each team sees its own agents and data. A support agent can't open compliance files. |
| An audit trail | Every query, tool call, approval, and cost is stored and exportable, so you can answer "why did the agent do that?" |
Each of these is a project on its own. Together, they're the difference between a demo and a teammate.
Why Payments Raises the Bar
Most agent harness writing assumes the worst case is a bad answer. In payments, the worst case is a bad action.
An agent that releases a held payout to the wrong account costs real money. An agent that misses a sponsor bank's RFI deadline puts the bank relationship at risk. An agent that copies a card number into a prompt creates a PCI problem. And when an examiner asks how a case was handled, "the AI did it" isn't an answer.
So the harness for a payment team has stricter jobs:
- Run where the data lives. Agent computers in your own cloud, so PCI data never leaves your environment.
- Keep card data out of the model. Masked credentials, plus filters that strip card numbers and SSNs from prompts and logs.
- Start read-only. Agents investigate freely, and anything that moves money, applies a reserve, or replies to your bank waits for approval.
- Keep the evidence. Every run stored end to end, ready when compliance, an auditor, or your sponsor bank asks.
- Stay up. Build in retries, recovery paths, and provider-aware routing, because a transient outage shouldn't stop a payout investigation.
This is also why most internal builds stall. The first agent is easy. The approvals, audit trail, and access controls take a team of senior engineers a couple of quarters before that agent touches real data. Meanwhile the queue keeps growing.
Where Runtime enters the picture
You can assemble a harness from cloud primitives and open-source parts. Most teams that try spend two quarters on plumbing before the first agent touches a real payout. Runtime is the AI agent harness for payment and fintech teams, with every piece above ready on day one.
- No single vendor to depend on. Runtime is connected to several sandbox providers (Google Kubernetes Engine, AWS Lambda microVMs, E2B, Daytona, and Modal), several model providers including open-weight models, and several coding agents (Claude Code, Codex, and OpenCode), with fallbacks between them. If one provider has an outage, operations keep running.
- Controls built in. Evals and benchmarking, budgets, role- and team-based access, guardrails, approvals, skills, a repository of MCP servers and tools, and handoffs from one agent to another.
- Built for the people doing the work. Lower-level agent platforms are for engineers only. Runtime is a web app built for non-technical team members. Once engineering sets the guardrails, ops teams build and run agents themselves, and engineering gets its time back.
- Proven where it matters. Runtime is live with customers that handle hundreds of billions of dollars in payments. Reliability matters because these are mission-critical operations for every team that touches a transaction: protecting it (fraud, risk, compliance), moving money (payment ops, reconciliation), onboarding and implementation, and ongoing customer support.
Create a banking ops agent that handles RFIs, hold-harmless requests, and returns of funds from our partner bank, verifies against our ledger, and drafts replies for my approval.
bank-ops-agent
Tools picked from your prompt
Day to day, it works in four steps:
- Describe the job. Someone on the team writes what the agent should do in plain English and attaches the SOP. Runtime builds the agent and gives it its own computer.
- Connect your tools. APIs, databases, and MCP servers, plus a browser for processor and bank portals with no API. Role-based access sets what each agent can read and do.
- Run it. Call the agent from Slack, Teams, WhatsApp, email, text, or a phone call, or trigger it from an alert or a schedule. It investigates on its own computer and shows every step.
- Keep a human in the loop. Money movement, reserves, and replies to your bank wait for approval. Every run is stored with its evidence, cost, and outcome.
Evals route routine work to the smallest model that still passes, so runs get cheaper over time. Every run also becomes memory the next one can use. We call that a system of intelligence.
If you want to see it on a specific queue, the payment operations, compliance, and underwriting pages walk through real cases. The security page covers deployment and controls. Technical readers can go deeper in How to build an AI agent harness.
Frequently asked questions
What is an agent harness?
An agent harness is the software that surrounds an AI model and turns it into an agent that can do real work. The model reasons. The harness gives it a computer to work on, tools and data to use, memory between runs, permissions on what it can touch, approvals before sensitive actions, and a record of every step. Runtime is the AI agent harness for payment and fintech teams.
What's the difference between an agent harness and an agent framework?
A framework is a library you use to write an agent's logic, like the loop that decides which tool to call next. A harness is what that agent runs inside in production: the isolated computer, credentials, access control, approvals, audit trail, evals, and failover. You can run agents built with many frameworks, or coding agents like Claude Code and Codex, inside the same harness.
If we already use Claude Code or Codex, do we still need a harness?
Claude Code and Codex are excellent agents, and they include their own local harness for a single developer. Running them for a team on production payment data adds requirements they don't cover on their own: isolated computers per run, scoped credentials, role-based access, approvals in Slack or Teams, a stored audit trail, and recovery paths when infrastructure or provider calls fail. Runtime runs Claude Code, Codex, and OpenCode inside that harness.
Can an agent harness run inside our own cloud?
It should, if the agent touches card data or PII. With Runtime, agent computers run in your own AWS, GCP, or Azure account while we manage the control plane, or you can self-host the whole platform. PCI data stays in your environment.
What does an agent harness cost compared to building one?
Building a production harness in-house usually takes a team of senior engineers a couple of quarters before the first agent touches real data, because approvals, audit trails, and access controls come first. Runtime has a free plan with one session, Teams from $99 per seat per month, and custom Enterprise pricing for self-hosting. Most teams weigh it against the work of the analysts they were about to hire.
Do non-technical teams need engineers to use an agent harness?
Only to set it up. Engineering connects the systems and sets the guardrails: what each agent can read, what needs approval, and the budget. After that, people in payment ops, risk, compliance, and support build and run agents themselves from Runtime's web app, writing what the agent should do in plain English. Lower-level agent platforms are built for engineers only, so every new agent becomes an engineering ticket.
What happens if a model or sandbox provider goes down?
A good harness doesn't depend on one vendor. Runtime is connected to several sandbox providers (Google Kubernetes Engine, AWS Lambda microVMs, E2B, Daytona, and Modal), several model providers, and several coding agents (Claude Code, Codex, and OpenCode), with fallbacks between them. If one provider has an outage, agents keep running on another.
Clip In
Strong models are everywhere now. Anyone can rent the same strength.
What separates teams that get value from agents and teams that get burned is the harness around them. Pick the route your team actually needs to climb, the queue that keeps growing, and make sure you're tied in before you start.
Then climb.
Put an agent on your busiest queue
Bring one SOP. A forward-deployed AI engineer builds the first agent with your team, inside your cloud, with your approvals.