Stop Counting AI Agents. Start Governing the Jobs.

A practical operating model for agent runtimes, delegated authority, evidence, and accountability across engineering, finance, and HR.

A coding agent can run in a terminal, an integrated development environment (IDE), a browser, or the desktop app. The appearance changes, but the same harness runs underneath. And it is an intelligent choice. Many companies are not only buying new interfaces and tools but are also trying to redesign work.

While this already sounds familiar to us developers, something bigger is happening outside of software development. Finance teams are testing agents for reconciliation, research, and reporting. HR teams are using them for candidate briefs, policy questions, and case preparation. Sales, procurement, operations, and legal teams are getting their own assistants, agents, copilots, and digital workers. Everybody is asked to embrace the new overlords more or less subtly these days.

While all of this sounds very different, the concepts underneath are similar and it is no surprise that each agentic vendor explains their technology with a slightly different but somewhat similar diagram. The model usually sits in the middle, surrounded by tools, skills, memory, workflows, guardrails, and people. Sometimes this is called an agent, a platform, or a harness.

This mixed language makes not only technical discussions difficult but also leads to all kinds of weird articles out there mixing one thing up for another. The unclear vocabulary also creates a leadership problem. If everything is an agent, what are we buying? What are we configuring and securing? And what exactly are we adding to the workforce?

This is why this article exists. To propose a simple vocabulary. A harness is the runtime that turns a model into a system that can act. A work system is the larger environment that an organization builds around it. Workforce planning should focus on governed jobs, with clear authority and ownership.

Why harness means several things

OpenAI gives us a precise definition in its article about the Codex App Server. Codex is available through the web, a command-line interface (CLI), IDE integrations, and the desktop app. These interfaces all use the same harness. It manages the agent loop, conversation threads, saved state, configuration, authentication, tool execution in a sandbox, Model Context Protocol (MCP) integrations, skills, and policies.

In this architecture, the interface is a client and the harness is the runtime.

OpenAI uses the term more broadly in its article about harness engineering. The article covers repository structure, documentation, architecture rules, local monitoring, tests, evaluation, and feedback loops. The engineering team creates an environment where Codex can make reliable progress. This environment has a larger scope than the runtime, so I give it a separate name later in this article.

Anthropic describes an agent harness, also called a scaffold, as the system that lets a model act. It processes input, coordinates tool calls, and returns results. Claude Code is one example. Anthropic also defines an evaluation harness. This separate system gives tasks to an agent, records each step, applies graders, and combines the results.

IBM’s latest Bob architecture describes a shared agent and harness as the common execution foundation for several user experiences. A workflow engine provides reusable multi-step processes, tools, human approvals, subagents, parallel work, and background tasks. Premium packages add platform knowledge, skills, integrations, and governed workflows. IBM separates the agent from the harness and places orchestration and enterprise management around both.

A June 2026 preprint, What makes a harness a harness, addresses this naming problem directly. The authors describe current usage as loose and propose four required parts: an adaptive agent loop, a tool interface, task-aware context management, and runtime controls that do not depend only on the model following instructions. This gives us a practical definition to discuss and a nice additional angle for this article.

All four descriptions contain a runtime layer that connects a model to action. The exact boundary changes between them. I think we need to define the word harness before we start using it in an architecture or articles. And I am probably guilty of misusing it earlier too.

What I mean by an agent harness

I prefer the above clear definition because it gives me a boundary that I can inspect and test. This is more interesting when you are working more closely with teams that actually develop this, but still my main motivation to clear up the language being used.

An agent harness is the runtime that connects one or more models to an external environment so they can complete tasks. It maintains a loop of observing, deciding, and acting. It presents tools to the model, manages context and state, and applies controls while the work runs.

You can use the following four questions to identify if you are looking at a harness or not:

1. Does it maintain a loop where each observation can change the next action?

2. Can the model use tools to read or change an external environment?

3. Does the runtime decide which context and state the model receives?

4. Does it contain at least one control that still works when the model makes a bad decision?

The fourth question separates guidance from enforcement for me. A system prompt can tell an agent to avoid deleting production data. A credential that has no permission to delete production data prevents the action effectively. And a harness is responsible for executing noch only the guidance but also the controls and guardrails. Prayers and hopes in markdown or even specs are not effective and can not be the only system a harness relies on.

A harness can run behind a CLI, an IDE, a chat window, an application programming interface (API), or a scheduler. It can run a single or multiple agent synchronously or asynchronously. But it does not make any assumptions about the underlying models. One model operating in a controlled loop is enough.

Several related terms describe other parts of the architecture:

• An SDK provides building blocks for messages, tool calls, and runs. The team uses those parts to build a runtime.

• A framework provides abstractions for building and combining agents. It may include a harness or help a team create one.

• An orchestrator coordinates steps, jobs, or agents. For example, code that always runs steps A, B, and C is an orchestrated workflow, even if one step calls a model.

• An evaluation harness gives tasks to the agent and grades the results. It measures the working system from the outside.

• A surface is the interface where a person uses the system. An IDE panel is a surface. The runtime and tools behind it do the work.

Products often include several of these layers. Naming them separately helps us locate a failure.

We can also ask who chooses the next step. In an assistant interaction, a person usually controls the sequence. In a workflow, code follows a predefined path. In an agent, the model chooses its next action from the information it observes. The harness limits which actions are possible. Anthropic uses a similar distinction between workflows and agents, while placing both in the wider category of agentic systems. This distinction keeps a process with one model call from automatically becoming an agent. And if there are already a ton of definitions of harness out there, pretty much everything today is effectively labeled an “agent” or “agentic” even if all it does is call an API endpoint.

An agent is a configured runtime

OpenAI’s practical guide to building agents starts with three parts: a model, tools, and instructions. Enterprise work also needs identity and context, authority plus memory, and additional controls coupled with an execution environment.

I use agent profile for the reusable configuration of these parts:

• instructions and role;

• available skills;

• tools and data sources;

• identity and permissions;

• model choices and budgets;

• memory and context rules;

• approval and escalation conditions.

An agent run is one execution of that profile for a specific task. If you like, you can describe it with a simple formula:

Agent run = harness(model, agent profile, work order, environment, controls)

This description is more precise than agent = model + harness. In reality the very same model and harness combination can not only prepare a candidate briefing but also investigate a failed build or even reconcile invoices. The combination of profile, work order, tools, data, and authority define the job.

If we expand the definition in that way, we can also more easily explain why model comparisons often fail to predict production results. In practical applications, we compare models coupled to a harness. Each comparison does include a lot more than just the call. Next to the already mentioned elements, it might even come with a sandbox and additional verification and evaluation loops. Anthropic makes the same point in its evaluation guidance: an agent evaluation measures the model and harness together. Changing a model without the harness is equally ineffective like putting a super capable harness on top of a local model.

Skills teach the procedure; tools provide the action

People often describe skills as another layer on top of the harness. This simple description might work in marketing or product demos. I have called them workflows before myself but for them to become part of a corporate governance definition we need better and more defined terms here too.

A tool gives an agent an action. It might query an enterprise resource planning (ERP) system, fetch an employee record, edit a file, run a test, or send an email.

A skill teaches the agent how to perform a type of work. The Agent Skills open format stores instructions in a SKILL.md file and can include all kind of assets to fulfill the job. A skills enabled harness can find the package and load it when a task requires that particular procedure.

I want to see this similar to how we humans work. Access does not automatically contain knowledge. Just because you can access a spreadsheet it does not automatically make you understand how taxes work. And for this definition exercise I am taking the shortcut here and say that:

• Tools provide the available actions, while

• Skills provide procedural knowledge.

Some people go as far as calling skills guardrails. I recommend to not do that. Elements that earn the name guardrail need to build on a mechanism that is enforceable. Not just a gentle ask in markdown. A guardrail should limit and check or even interrupt unwanted or dangerous behavior. It can reject sensitive input and block unsafe tool call. But should also have the ability to enforcea spending limits and request human approval for relevant activities. Permissions define what an identity is allowed to do. A sandbox limits the systems and resources that the runtime can reach. Evaluations measure whether the result meets a defined standard. Observability provides records that help people understand what happened during the run.

Six questions keep these terms separate:

• Can it? Tools provide the action.

• Does it know how? Skills provide the procedure.

• May it? Identity and permissions grant authority.

• What limits apply? Policies and guardrails enforce boundaries.

• What did it do? Traces and audit records show the execution.

• Did the result meet the standard? Evaluation and outcome evidence show the result.

Consider an agent that prepares a supplier payment. An ERP connector lets it create a payment draft. A finance skill explains invoice matching and the company’s payment process. The service identity allows the agent to create the draft, but not approve it. A guardrail sends payments above a set amount to a person. The audit record combines the complete call stack: the source invoices, the agent run, and the approver. Finally, a reconciliation check confirms that the ledger still balances.

A long system prompt could describe all six parts but it surly can not provide the same enforcement, access control, or evidence. At least not with any kind of guarantee higher than a wish.

Instructions and controls serve different purposes

Teams call almost every instruction a guardrail today. This hides the difference between guidance that the model may fail to follow and controls enforced by software or infrastructure. And it is dangerous if we do this.

For example, an instruction can tell a model to avoid protected characteristics when it prepares a candidate brief. A data-access policy can prevent the agent from reading fields that the task does not require. An output check can detect protected information before the brief leaves the system. A human recruiter can keep responsibility for the hiring decision.

Each measure reduces a different risk. The access policy and output check can still act when the model ignores its instructions.

Anthropic explains this distinction in its article about containing Claude across its products. Model-level defenses influence the actions an agent is likely to choose. Sandboxes, virtual machines, file-system boundaries, credentials, and network controls limit what it can do. These controls do not provide complete security. An allowed network destination or connector may still open a path that the designers did not expect. And on top, the models become more capable when it comes to reasoning and a lot more creative when thinking about ways around existing policies and defenses.

Another good reminder that security engineering is nothing we should even think about handing to a model anytime soon. It is the exact discipline that keeps infrastructures in check for now while everyone is drilling holes into established protections with custom made MCP servers, cookie-injected web scrapers and even home-grown VPN approaches. And I am not thinking about how Ngrok is recommended by many models for certain scenarios.

Organizations do need identity, least privilege, separation of duties, containment, audit records, and incident response. Least privilege means giving each identity only the access it needs. Separation of duties means that one identity cannot complete every sensitive step alone. A clear system prompt supports these controls; it does not replace them. And yes, I am done preaching now.

The larger environment is a work system

Now that i have pulled the definition of a harness very tight, I need to give you an answer on how to call the remaining things around the harness.

I call this the agent work system. It contains:

• business outcomes and work queues;

• agent profiles and human roles;

• workflows and handoffs;

• enterprise data and applications;

• job-specific skills and knowledge;

• identities, permissions, policies, and approvals;

• sandboxes and execution environments;

• evaluation, observability, audit records, and cost controls;

• ownership for deploying, changing, and retiring agents.

An agent control plane is a technical management layer for a group of agents. It can manage all the above. AgentOps covers the practices used to develop, test, deploy, monitor, and improve the agents. Both sit inside the larger work system.

The work system also includes organizational decisions that a vendor cannot make. People must define the required outcome, the exceptions that need human review, the errors they can accept, and the person who owns the result.

OpenAI’s harness-engineering article gives us a strong example for the software development process. The team organizes the repository so the agent can understand it. Tests and local monitoring provide feedback while automated checks enforce architecture rules. People translate user needs into acceptance criteria and make decisions where the system needs judgment.

An engineering team may reasonably call this complete environment a harness. At a company level, the work system provides a clearer boundary: the harness runs the agent, and the work system defines and governs its work.

Plan the workforce around jobs

Now with all this in place, let’s also make sure how I envision that workforce can be aligned around those new agentic job definitions. There are many approaches on how to call this. I do not want to reiterate them here or even make them sound human. Agents are automated processes. Not humans.

An agent has no legal accountability or personal duty to protect a human. Not a customer, company, or colleague affected by any of its actions. The organization and its people keep those responsibilities. And hopefully will for the foreseeable future.

There is one similarity I like to point out when it comes to implementing agents. They also suffer from the same challenges we humans experience when we get thrown into a new job. Learning about procedures, access, and how supervision works and the hole onboarding procedure. For agent workforce planning, I prefer a more precise unit: the job contract. This could be defined as a clear description of delegated work:

To me a job contract for an agent should state:

• the outcome being delegated;

• the trigger and scope of the work;

• the systems and data the agent may use;

• the decisions the agent may make;

• the actions that require approval;

• the evidence required for completion;

• the limits for quality, time, and cost;

• the conditions for escalation;

• the accountable person or business owner.

An agent role is a reusable profile that can accept this contract. A work order is one specific instance of the job. One agent role may handle several related jobs, and one job may use several agents and services that follow fixed rules.

This gives leaders better measures for agent planning. The number of agents in a department tells us very little. We need to know how many governed jobs the organization has delegated, how often those jobs run, which outcomes they produce, and how much human review or recovery they require. These are also very helpful metrics when it comes to measuring value in these new times.

Microsoft’s 2026 Work Trend Index reports that advanced AI users were more likely to document agent workflows, human handoffs, and quality standards. The research is sponsored by a vendor, and much of the organizational data is self-reported. It surly is no general purpose proof of productivity but it might slightly hint into the direction what happens when you give humans AI access and redesign work around them. Both humans and agents.

The same vocabulary works across departments

I think that the vocabulary so far is very neutral and works across various departments or use-cases.

Engineering: resolve a failed build

The job is to find and fix the cause of a failed continuous integration (CI) check. The harness maintains the investigation loop. Git, the CI system, the shell, and the test runner are tools. Repository conventions and debugging procedures are skills. The agent identity may push changes to a work branch, but protected-branch rules prevent it from bypassing review. Passing tests, a reviewed code change, and a link to the original failure provide evidence. The developer remains accountable for merging the change.

Finance: reconcile invoice exceptions

The job is to match invoices, purchase orders, and receipts, then prepare unresolved cases for review. The ERP and document systems provide the tools. Accounting policy and exception procedures provide the skills. The agent may read the required records and prepare adjustments. Amount limits, separation of duties, and approval rules define its authority. The reconciliation report and ledger checks provide evidence. Finance owns the policy and the final accounting result.

HR: prepare a candidate briefing

The job is to collect sourced evidence against an approved role rubric before an interview panel meets. The applicant tracking system and approved documents provide the tools. The interview rubric and company procedure provide the skills. Data-minimization rules limit the information that enters the context. Guardrails check for protected characteristics and claims without sources. Every statement in the output links to a source, and a recruiter reviews the brief before using it. The hiring decision remains with the responsible people.

The label “AI agent” alone removes most of the details that leaders need. A job contract makes them visible.

Standardize what the organization needs to keep

Companies often begin with the most visible choice: one chat interface or one model for every function. While a common interface may simplify procurement and support, it does not create a shared operating model automatically. Not only will the models change, the interfaces will have to be very different for each department and use-case. Sitting HR people in front of a CLI is going to be impressive but in a very different way. And education the hole company on using an IDE for generating Powerpoint slides is also going to be an expensive exercise in wasting token.

Models will change, interfaces will multiply, and harnesses will improve at different speeds going forward. The organizational assets that need to remain stable should stay stable in the work system:

• job contracts and acceptance evidence;

• versioned skills and organizational knowledge;

• tool contracts and connector policies;

• agent identities and delegated authority;

• approval and escalation rules;

• evaluation suites;

• execution records and outcome measures.

Standardizing these assets gives teams room to choose an interface that suits the people doing the work. It also makes future changes easier because job contracts and controls can move to a new model or harness.

Open standards help with specific parts of the architecture. MCP defines how AI applications connect to tools, data, and workflows. It covers integration. A2A, the Agent2Agent Protocol, defines communication between agents even when their internal implementations differ. Agent Skills make procedural knowledge easier to move between compatible systems. These standards do not define the business job or assign accountability. The organization must do that in parallel.

When a vendor says “agent,” ask about the profile, runtime, identity, and tools. When it says “guardrails,” ask which controls still work without the model’s cooperation. For a “workflow,” ask which decisions follow fixed rules and which decisions a model makes. For an “enterprise-ready” product, ask who owns each job and how the system records, evaluates, and escalates the work.

Start with one job

People are under pressure to use AI across companies in all functions. That pressure does produce hundreds of experiments without creating much shared structure or value. It is good for educational purposes and we all do see the humans getting more comfortable around these very capable tools.

If you want to move any of those experiments to the next level, choose one real job and write its contract. Name the outcome and owner. Give the agent only the tools and data required for that job. Package the procedure as a skill. Enforce authority through identity and policy. Define the evidence that proves completion. Then run realistic evaluations, including cases where the agent should stop or ask a person for help.

This order lets the organization keep its operating model while vendors and products change. A better model can enter later. A new interface may make supervision easier. A different harness may improve context management or containment. The people still define how good work looks like and remain accountable for the results.