A portable specification for AI agent harnesses: focus on function, control, and assurance

Introduction

Many of the people I have chatted with still have misconceptions around Large Language Models: they are intelligent models and bigger is always better. What they fail to connect is they are prediction engines under the hood, predicting the next best token for the input before. The true explosion with GenAI has been around agentic harnesses, the tools that maintain loop state and provide execution tools. These clever tools use smaller tasks to reach out and report back, communicate with each other, write ad-hoc scripts, and the like.

As mentioned agency often depends less on making the core model smarter and more on engineering the surrounding software layer so bounded model intelligence is sufficient. For example current benchmark scores and safety claims attribute outcomes soley to model weights. This masks massive performance swings by the harness. Specifically using SWE-Bench Mobile Claude Opus 4.5 scored 2% in OpenCode and 12% in Cursor [1]. GPT-4 went from 2.7% to a whopping 28.3% on SWE-Bench Lite in various harnesses [1]. All this to say, AI cost savings is within reach based on changing your toolset up.

This has led to a wildwest of technical explosion in this area often putting containment and control aside in the name of advancement. Most of the GenAI attack surface now lies in the agent harness rather than the neural network. Prompt injection, tool poisoning, privilege escalation have been focal attack vectors.

The Digital Ethics Center at Yale University led by Nicolas Gertler recently published a portable specification for the agent harness [1]. Borrowing from Floridi's concept of enveloping the specification aims to solve these blind areas to drive consistent behavior and control. Lets discuss it.

The 8 Functional Components of the Agent Harness

The research organizes the harness into three functional bands encapsulating the eight components the specification: cognitive, control, and assurance. Just imagine parenting a feral little human.

Cognitive is specific to what the agent can do and the limitations it should expect. Being upfront with an agent harness and treating it like a toddler is a mental jedi trick for the LLM to act a certain ways.

Okay so you gave the toddler specific instructions to not overload them and to keep them on task, what do you do when they get creative? Control. Control focuses on what the harness is allowed to do.

We still need an adult in the room with the toddler. Assurance observes and verifies the actions being taken are valid in the ruleset. In addition to observation guardrails are put up when things start going sideways.

The paper organizes the harness into three functional bands [1]. The cognitive band is what the agent can do. The control band is what it is allowed to do. The assurance band is how its work is checked and how a long job stays alive. If you keep the toddler picture in mind from the introduction, the cognitive band is telling the toddler what the job is, the control band is the fence around the yard, and the assurance band is the adult who watches, checks the work, and makes sure nothing gets lost when things go sideways.

For the sake of the rest of this article we are going to use a basic example: a research agent that investigates a topic on the web and writes a summary.

1. Orchestration and planning (cognitive). This is how the agent breaks a big job into steps and decides when it is finished. A research agent handed the question of whether solar power is now cheaper than coal first splits it into sub-questions, searches for sources, compares what it finds, and stops when each sub-question has a solid answer [1]. The failure version is an agent that keeps re-reading the same page and never finishes, or one that stops after a single weak source and presents it as done.

2. Context and memory (cognitive). This is what the agent is holding in its head right now, and what it writes down so it does not forget. Every instruction, tool result, and note takes up space in the model's working memory which is a finite space. When it fills up, the harness summarizes earlier material to make room. A well-run harness also keeps side notes, like the list of sources found so far and which claim each one supported. The research agent keeps a running list of the pages it has read. The failure version is subtle. During one of those summaries, the agent compresses away the one detail it needed, such as only trust sources published after 2020, and quietly drifts away from the goal it was given.

3. Tools and action interfaces (cognitive). This is where the agent's words become actions. The model can only produce text, so the harness turns that text into a real search query, an opened file, or a sent message. Think of it as giving the agent hands. The research agent gets a small set of hands: web search, a page reader, a PDF reader, and a note writer. There is a quiet danger in this band. The agent trusts the description of the tools it is handed. If a tool says it does one thing and does another, or if its description changes between the moment you approved it and the moment it runs, the agent can be steered without ever knowing.

4. Operational knowledge (cognitive). These are the standing rules the agent is expected to follow, the house rulebook if you will. In practice this is a file of conventions, things like always cite primary sources and record the URL behind every claim. The research agent gets rules such as prefer primary sources, note when two sources disagree, and flag it instead of picking a side. The weakness of this band is that the rules are words, not physics. The model can claim to follow them and not actually do so in reality. Unless a hard check lives somewhere else in the harness, the rules are only as reliable as the model's mood that day. Sound familiar? Curtain climbers exposed.

5. Sandboxing (control). The containment fence. Sandboxing is the outer wall of the system. It limits where the agent may read and write, which websites may reach, and how much memory or time it may use. A research agent might only be allowed to talk to a short list of websites, and to save files in a scratch folder that is wiped when the job finishes. The failure this band stops is the sneaky kind. The agent downloads a paper, and hidden inside that paper is an instruction telling the agent to run a command and read files it has no business reading. A careful agent might ignore the instruction, but the reliable defense is the one that makes the attempt impossible. That is the fence's job.

6. Permission model (control). Inside the fence, the permission model decides which actions run freely, which need your approval first, and which are banned. Reading a public page: free. Downloading a file: ask first. Deleting anything: banned. The toddler analogy fits here. You do not need to approve every bite of fruit, but you do want to be asked before the toddler opens the front door. A permission failure is different from a sandbox failure. The agent never leaves the fence. It uses a tool it was legitimately given, in this case a tool for running database commands, and it uses that tool to drop a table it was never meant to touch. Every step was technically allowed. Nothing was humanly intended.

7. Verification and observability (assurance). The adult checking the work. This band checks results after actions happen and keeps a record of everything that happened. For the research agent, that means matching claims in the final summary back to the source, flagging any source it does not trust, and logging every tool call so a person can replay what happened later. If the checker is set too loose, the whole band fails. A verifier that always says pass gives the team the false confidence that a job is done while the underlying tests are actually broken.

8. Execution runtime and lifecycle (assurance). The plumbing that keeps a long job alive. Jobs fail in boring ways: a network hiccup, a busy server, a step that takes too long. This band sets time limits, retries hiccups after a pause, and saves progress at checkpoints so a crash does not send the agent back to the start. The research agent saves its notes after every batch of sources, and treats a busy web server as try again in a minute rather than a failure. Without this band, a four-hour job that dies in hour three because of a blip is simply gone, along with everything it learned along the way.

Why the Fine-Grained Breakdown Matters

Most failure lists stop at the agent did something wrong. That is not useful, because it does not tell you what to fix and potentially loses valid findings. The point of naming eight separate components is that they fail for different reasons, and each has its own remedy [1].

Two pairs are worth spelling out.

Context versus operational knowledge. Both have the same goal being the instructions the model reads. But an agent that has all the information and no rules will stall, while an agent with perfect rules and missing information will confidently do the wrong thing. Swapping in a bigger model fixes neither one. Adding the missing rules, or fixing the missing note, does.

Sandboxing versus permissions. The sandbox is the physical boundary. The permission model is the policy inside that boundary. A sandbox failure lets the agent reach outside the boundary at all. That is the class of failure that showed up during OpenAI's July 2026 cybersecurity evaluation, when a test agent gained access to systems it should not have reached. A permission failure keeps the agent fully inside the boundary but lets it do something the owner never intended, like an isolated coding agent that deletes the codebase it was asked to fix because deleting files never required approval.

The practical payoff is that when something goes wrong, you can point at a component instead of a model, and the fix tends to be smaller and cheaper.

When Agents Start Editing Their Own Rules

The paper singles out a failure pattern that is especially hard to catch when a system can rewrite itself [1]. Coding agents do this constantly. They edit configuration files, add new tools, and change how the project is built. Each individual change is usually harmless, and usually exactly what you asked for. This is exactly what happened that Cohere discovered with Qwen 3.8 Flash Next when it tried to escape it's own sandbox [2].

The dangerous version is a sequence where no single step looks wrong, but the sequence as a whole dismantles the safeguards. Step one, the agent loosens a check threshold because it keeps getting in the way. Step two, it adds a new tool with a wider reach. Step three, it turns off the ask-first prompt for that tool. Each step is defensible on its own, and a person looking at the finished state may never notice that the fence, the rulebook, and the adult in the room were all quietly removed one step at a time.

The paper's answer is about where the record is kept [1]. If an agent can change the envelope it runs in, then the log of what it did cannot live inside an envelope it controls. The record must be append-only, which means it can only be added to, never rewritten or deleted, and it must be stored outside the space the agent can write to. A log that the actor can edit is not a log. It is a suggestion.

The Portable Specification, or a Parts List for Your Agent

The paper's practical proposal is that every agent deployment keep a standard record, in the spirit of the parts list that hardware ships with (called an SBOM [software bill of materials] in the software world) [1] [3]. When you buy a car, a label tells you which engine, which brakes, which safety systems are inside. When you deploy an agent, you currently get no equivalent. The specification asks for five records.

At the release level, three of them are:

• The exact release version of the harness paired with the exact model version, for example a specific version of a coding tool running a specific version of a model. This turns into a thumbprint.
• The starting configuration of all eight functional components.
• A declared list of what the agent is allowed to edit on its own versus what is locked. The project files it is building can be editable. The permission policy and the sandbox boundaries should not be.

At the run level, two of them, one for every time the agent actually runs:

• A run-start snapshot, a fingerprint of which model was active, what the environment looked like, and which rules were in force at step zero.
• A material-change record, an append-only log of anything that changed mid-run. Each entry shows what changed, who asked, who authorized it, the previous state, the new state, and whether the change can be reversed. It is topped off at the end by the run-end state: the configuration the agent actually finished with, whether the task completed, and a signature on the artifacts it produced.

The paper's argument for why this matters is simple [1]. The same model can score very differently in different harnesses, and it can even change how it performs within one run if it edits its own settings. A benchmark score or an incident report that does not name the harness configuration is like a weather report that never says which city it is describing or what time of year it relates to.

What This Means for Rules and Rankings

Model cards and agent cards, the short public documents that describe an AI system, are written at release time and describe the model. The paper's point is that they do not capture what happens after the model is in the wild [1]. Tools get added, configurations drift, and the agent may rewrite its own settings mid-run. A static card is the factory spec sheet of a car. It tells you nothing about what happened on the road, or whether the driver added a leet turbo killing the longevity of the vehicle.

The regulatory side is moving the same direction. The EU AI Act requires high-risk systems to keep technical documentation (Article 11) [4] and to record events automatically over the lifetime of the system (Article 12) [4]. Colorado's new AI law, SB 26-189 [5], which takes effect January 1, 2027, requires developers of automated decision-making tools to hand over documentation about how a system works, and adds a three-year record-keeping requirement. South Korea's AI Basic Act sets similar duties. None of these laws prescribes a common format for a harness record, which is the gap the paper is trying to close [1]. A standardized harness record is the kind of technical audit trail these regimes ask for without yet naming it.

There is a second audience for the record that we didn't anticipate... benchmark leaderboards. If the harness can swing a model's score by several-fold on the same test [1], then a leaderboard that does not record the harness configuration is measuring the harness, not the model. The paper's position is that harness disclosure should become a requirement for any score that gets published. I'd argue that an acurate benchmark would need to be done in many harnesses and scenarios to fully understand the capabilities with different constraints.

Wrap It Up

If the paper leaves one thing behind, it is a reframe. The model is not the agent, the harness is the agent. And for the first time the harness has a name, a parts list, and a standard way to say what changed and who approved it. A car has a VIN. An agent should too. The toddler from the start of this article was never the problem. The missing fence, the missing rulebook, and the missing adult in the room were. Function, control, assurance. That is the whole specification, and it is a lot easier to hold a vendor to than the word trust. We're excited to see where this goes and hope to help the adoption of this new endeavor.

References

• [1] Gertler, Novelli, and Floridi, Towards Portable Specification of the Agent Harness
• [2] Inferise, When a Model Phones Home
• [3] Khan, Goodwin, What is a software bill of materials (SBOM)?
• [4] European Union, REGULATION (EU) 2024/1689
• [5] Rodriguez, Coleman, Duran, Bacon, Automated Decision-Making Technology (SB26-189)