Skip to content
Pyrana
Resources
AI and data leadersPyrana HarnessAgent runtimeDurable execution

Enterprise AI? It's all about the harness

Writing an agent loop takes an afternoon. The runtime around it, which decides what an agent may see and do, what survives a failure, and who approves what, is where enterprise programs stall. Pyrana built that runtime once, so that building an application is configuration of agents and workflows rather than a rebuild of the fundamentals.

Sam Merkovitz · Head of Product and Engineering, Pyrana · September 17, 2026 · 10 min read

When ChatGPT arrived, it felt as if there were a person on the other side of the window. You could ask it for advice, have it draft an email, or let it walk you through a piece of code. What it could not do was act. It could explain how to rebook a flight, but it could not rebook one. Text went in and text came out, and the model had no way to touch anything in the world.

The obvious next question was why, if it can tell me what to do, it cannot do the thing itself. Agents are the answer to that question. An agent gives a model a way to act, and the part that gives it that way is the harness.

What a harness is

An agent is a model and a harness. The model reasons over what it is given, which is the task, the relevant context, and the results of whatever it did last, and from that it proposes a next step, picks a tool, and reads the result. The harness is everything around the model. It decides what the model gets to see, carries the actions the model proposes into real systems, keeps track of where the work stands, and decides when the work is done. Anthropic describes the same split as decoupling the brain from the hands. By that definition the original ChatGPT had a harness too, a very small one that accepted text and returned text. Agents make the harness far more capable, and that is the whole difference.

There is a third piece, and it is the one that makes an agent yours. Call it the job. The job is the role the agent plays, the systems it may use, what it needs to know about your company, and who signs off on what. The job is different for every agent. The harness should not be, and the rest of this piece is about why.

The loop is the easy part

Building a basic harness has become easy. Claude Code, Codex, and any modern agent framework will give you something that reasons, calls tools, and completes real work in an afternoon. The loop itself is a few lines. Give the model a task, let it call a tool, return the result, and repeat.

flowchart LR I[Task and context] --> H[Harness] H --> M[Model] M -->|tool call| H H --> T[Tools and systems] T -->|result| H H --> M M --> O[Typed outcome]

What surrounds the loop is the hard part, meaning what the loop can see, what it may do, how it remembers, how it recovers, and what it costs to run. More machinery does not help by itself. In a June 2026 survey of agent-system design, mini-SWE-agent, which is roughly a hundred lines of Python, and the much larger OpenHands framework finished within a point of each other on SWE-bench Verified, a standard benchmark of real coding tasks, when run on the same model. A recent HarnessTax evaluation found that on two coding benchmarks, switching harnesses moved cost far more than it moved task success for a fixed model.

None of that means a production runtime should be small. It means that what improves an agent is deliberate, well-scoped guidance, and that a harness should be judged on quality, reliability, and cost rather than on feature count or a benchmark score.

The job varies. The runtime should not.

Modern models are extraordinary reasoners. They can score near the top of the LSAT, disprove decades-old conjectures in mathematics, and write working software. The harness should make that intelligence useful without burying it. In practice an agent needs four things.

  • The right inputs. Context from the sources that matter for this work, rather than a pile of everything.
  • A clear job. A concrete goal, a role, and a definition of done.
  • The right actions. The tools needed to finish the work, and no more.
  • The right model. Not every task needs the most capable model, and some do not need a large language model at all. A small language model, conventional machine learning, or a different kind of model may do the job better. Model choice should be intentional, appropriate to the risk, and tested against the work it has to complete. We are watching approaches such as Jev closely.

Everything on that list belongs to the job. The tools, data, approvals, limits, and knowledge change with each use case. The runtime underneath them should not.

Production is where the whole system has to hold up

A demo is one user, one path, and one process humming along. In production the whole deployment gets a vote. A connector goes down, a worker disappears in the middle of a run, a provider slows to a crawl, a reviewer takes three days, and then someone deploys a change while the work is still in flight. The runtime needs a plan for all of it, which means preserving state, recovering safely, and making a failure understandable to the operator at 2 a.m. and not only to the engineer who wrote the code. A demo shows what an agent does when everything goes right. Only the harness can show what happens when it does not.

Trust starts with restraint

Letting an assistant reorganize your inbox while you get a coffee is a great experience, and it also means a model is reaching something real, where it could send a message on your behalf. This summer the Codex team investigated reports of unexpected file deletion. The lesson there was less that agents are reckless than that we have to be deliberate about what we let a model reach, especially when full access is granted without sandbox protections.

In an enterprise the consequence is usually quieter and more expensive. A payment goes out twice, a record changes for the wrong customer, or an action is taken with more authority than the person who asked for it had. So the people responsible for an agent need plain answers to a few questions.

  • What may the agent do, and what requires a person to approve first?
  • Who is it acting as? An agent should not reach beyond the person or schedule that invoked it.
  • What state survives a crash, a deployment, or a long wait for approval?
  • What happens at scale, when many agents are waiting, retrying, and competing for the same resources?
  • How do agents finish together? When agents hand work to other agents, who knows when the whole job is done?

None of these are questions about the loop. All of them are questions about the harness.

How enterprises end up with a dozen harnesses

Most enterprises never decide to build many harnesses. They arrive there one use case at a time. A team builds an agent, and before it can launch, the team has to answer what the agent may call, which identity it acts with, what happens when it fails, and what needs human eyes. They answer those questions in application code, for that one agent. Then another team does the same. A year later the enterprise has a dozen agents and a dozen different answers about permissions, retries, audit trails, and what finished means. Eric Tarnowski looked at the identity side of this in Twelve agents, twelve permission models.

The sprawl happens because every team that ships an agent, whether from scratch or on a framework, has to build two things. The first is the agent itself, meaning the prompts, the context and memory, the tool descriptions, the model choice, the curated knowledge, and the tests that say whether it is any good. That work is real, and it is different for every use case. The second is the runtime, and it is much more than a loop. Before an agent is allowed near a real system, someone has to write the code that saves state so a crash mid-batch does not pay an invoice twice, that decides which errors are worth retrying, that passes the requester's identity through to every tool, that holds risky calls for a person to approve, that caps how many steps and writes a run may take, that checks whether the job is actually finished, and that logs all of it for audit. A framework makes the loop easier and leaves every one of those to the team.

The runtime is the same for every agent even though the job is different, which is what makes this a multiplication problem. Each one-off runtime also encodes assumptions about what a model could not do when the code was written, and as models improve those workarounds become dead weight that nobody owns and nobody removes. This is why programs so often stall after the first demo. Each new agent adds another implementation of the same controls, and security, audit, and platform teams end up reviewing all of them, none of which match.

The choice in front of an enterprise is whether to rebuild the runtime for every agent or to run one shared harness that covers the common needs and lets each team configure the rest.

How Pyrana handles it

At Pyrana we built our harness to be enterprise-ready from the start. It is designed to support scaling, from pilot to production, from one user to many, and across multiple use cases and applications, while managing every element required to mitigate risk. We built it once so that you do not have to. Building on Pyrana becomes configuration of agents and workflows, rather than engineering capacity and time spent recreating the fundamentals.

An agent on Pyrana is defined by four things: its objective, the capabilities it may use, the business knowledge it needs, and the policies that govern it. Capabilities say which tools and data the agent may reach. Policies say which calls need approval and where the limits are. The team writes those down and the platform enforces them. Workflows are declared the same way, as which agents run, which run in parallel, and what each one waits on. None of it is code.

Consider an agent that processes supplier invoices. Built from scratch, the team writes the checkpointing, the retry rules, the identity pass-through, the approval queue, the step caps, and the audit log, and only then gets to the invoices. On Pyrana the team writes the objective, the list of systems the agent may read and write, what the agent needs to know about the company's vendors and terms, and the rule for which payments need a person. Where a client needs domain logic of its own, it builds an extension, a service the platform calls under the same identity and policy controls.

Underneath, the platform handles the runtime concerns one by one.

Runs recover. Execution runs on Temporal workers (Temporal is an open-source engine for long-running work). State is durably checkpointed at turn boundaries, so a run can resume after a worker failure with the configuration version it began with. Retries are classified. A rate limit can be retried, while a configuration or output-contract error should not be, because repeating it changes nothing.

Actions stay bounded. Tool calls return typed results to the harness, never straight to the model. Each call is evaluated against configured capabilities, tenant and entity scope, the calling principal (whoever or whatever invoked the run), authorization, and tool policy. Per-agent limits bound steps, tool calls, and writes.

Approvals remain meaningful. Approval policy evaluates the actual tool-call arguments and can allow, deny, or request review. A call under review is frozen and revalidated before it runs, so the approved call is the one that executes. Eric covered the design in Approval is a policy, not a boolean.

Waiting does not consume workers. A run waiting on a reviewer, a connector, or a child agent exits the worker and resumes on a signal. Many waiting runs do not need many processes held open.

Context stays deliberate. Playbooks, schemas, and examples live in a reference mount, a library the agent opens when it needs something, rather than in every prompt. Skills load when needed. Memory across runs is declared and capped instead of accumulating invisibly. Business knowledge comes from cortIQ, which records what was retrieved, what was used, and what was cited on every run.

Work finishes on evidence. Workflows can dispatch agents in parallel and coordinate their outputs, and a parent cannot finish while its children are still running. Agents can carry finish contracts for required artifacts, plans, or citations, so that the model going quiet and the job being done are two different things.

Every run is accountable. Audit events, traces, token usage, and tool errors are captured for every run. Models are assigned per agent and do not change mid-run, so a model choice is a versioned configuration decision that gets tested like any other.

None of this makes a model smarter. It makes the runtime around the model behave the same way for every application, including when something goes wrong. More detail is on the Pyrana Harness page.

Try this on an agent you already run

To learn whether you have a harness or only a loop, choose one production agent and ask six questions.

  1. Kill the worker mid-run. What state comes back, and under which version of the agent configuration?
  2. Which identity does every tool call carry? Can the agent reach anything its invoker cannot?
  3. Where are the limits on steps, tool calls, and writes? Who set them?
  4. When a call needs approval, is the call that executes the one that was approved?
  5. What evidence must a run produce before it counts as finished?
  6. If the model changes tomorrow, what do you re-test, and where is the model and harness pairing recorded?

If the answers live in application code that one team wrote for one agent, the harness is still ahead of you, and the question is whether to build it once or once per agent.

The takeaway

Building an agent should be easy, and the models get better every few months without any help from you. The runtime around them should not be something every team rebuilds. Give it the right inputs, the right actions, and firm limits once, make sure it recovers when something fails, and then spend your time on the agents and workflows that are specific to your business. That is what decides whether an agent makes it past the demo.

Sources

More for ai and data leaders

Bring your hardest process.

We will run it through admission, approval, and the record, and show you what comes out.

Book a demoHow it works