The agent harness
So far, we have seen that agents can reason about a goal, use tools, and carry out multiple steps on our behalf — and that this lets us direct them with objectives instead of step-by-step instructions. But an AI model does not automatically know what information it should use, what tools it can access, or what rules it should follow. These things have to be provided as part of the agent's working environment. This environment is often called the agent harness.
Giving the agent what it needs to work
Earlier, we described an agent using a simple loop: reason → act → observe → reason again. For that loop to work, the AI needs more than a large language model. It needs to know what it is trying to accomplish, what information it can use, what tools are available, and what rules or limits it should follow.
Together, these elements form what is often called the agent harness. You can think of the harness as the working environment around the AI.
What goes into an agent's harness?
The exact setup depends on the task, but most agent harnesses provide four basic things:
| Part of the harness | What it provides |
|---|---|
| Instructions | What the agent is supposed to accomplish and how it should approach the task |
| Information and context | Files, policies, examples, business rules, or other information relevant to the task |
| Tools | Access to spreadsheets, Python, web search, databases, email, or other applications |
| Boundaries | Rules about what the agent may access, change, or do without human approval |
Example: A meeting-scheduling agent
A very simple example is a meeting-scheduling agent.
Goal: Schedule a 30-minute meeting with Alex next week.Its harness could be just:
- Instructions: Find a time that works for both people.
- Context: Your calendar and Alex's availability.
- Tools: Calendar access.
- Boundaries: Do not schedule outside working hours.
Where is the harness?
You may never see a harness as a single object or screen. Different parts of the harness can come from different places.
Some tools are already built in
Modern AI products often come with useful tools already available. For example, ChatGPT can work with uploaded files, search the web, and run Python code for data analysis. Claude can also use tools such as web search and, in some environments, interact with a computer. These built-in tools expand what the AI can do beyond simply generating text.
Access to a tool may still depend on the product, account, or permission settings. For example, an agent may need permission before it can access a file, connect to an application, or take an action on your behalf.
Other tools have to be connected
An agent may also need access to systems that are not built into the AI product. For example, a company might want an agent to read information from Salesforce, query an internal database, access Google Drive, or interact with a project-management system.
One increasingly common way to make these connections is through MCP, or Model Context Protocol. An MCP server acts as a standardized connection between an AI application and an outside source of data or tools. For example, an organization might connect an MCP server that gives an agent controlled access to its database, documents, or internal applications.
Instructions and context can be simple documents
Other parts of the harness may be much simpler. Instructions, business rules, policies, examples, and background information can often be provided as ordinary text or data files. A company might give an agent a written travel policy, a spreadsheet of sales data, examples of good reports, or a document explaining how certain decisions should be made.
AI products also come with some instructions and boundaries already built in. These help determine how the system behaves by default. When you design an agent for a particular task, you add additional instructions and context that are specific to your project, team, or organization.
Context can also accumulate through memory
Not all useful context has to be supplied again every time you start a new conversation with the AI. Given the right setup, AI systems can retain or retrieve information from previous interactions. This is often referred to as memory. For example, an agent might remember your preferred reporting format, decisions made earlier in a project, or recurring information about your team or organization.
It is important to know that memory is part of agent design and you can control what AI remembers. We will discuss these design methods in later sessions. For now, the important idea is that memory allows useful context to build over time instead of starting from scratch with every interaction.
Example: Setting up a price-tracking agent
Suppose a retail team wants an agent that checks a handful of competitors' pricing pages and flags anything that changed.
Giving the agent a powerful AI model is not enough. The agent also needs the right working environment for the task.
Here is what each part of its harness could look like in practice.
Instructions (with boundaries built in)
Instructions are provided in a prompt — plain text describing the task, including the rules the agent should follow:
Check the pricing pages listed in competitors.txt. Compare today's
prices to the last saved snapshot in price-history.csv and list any
changes by product and competitor.
Only use the official pricing pages listed — do not use prices from
forums, reviews, or other unofficial sources. Do not add any product
you do not recognize from our catalog. Flag the summary for review
before it is sent to the team.Context
Context in this case is files sitting in a folder the agent can read:
price-tracking/
├── competitors.txt (list of competitor pricing-page URLs)
├── price-history.csv (last known prices, by product)
└── our-catalog.csv (our product list, for matching)Tools
- Web browsing, to check the pricing pages
- Access to the local folder containing the context
- Access and permission to post in the team's Slack channel
The same model can become very different agents
One important implication is that the AI model is only one part of agent design. The same underlying model can perform very different jobs depending on the harness around it.
A research agent might receive instructions about how to evaluate sources and have access to web search and documents. A financial-analysis agent might instead receive company reporting rules and have access to spreadsheets, financial data, and Python. A customer-service agent might be given company policies and access to customer records and an order-management system.
The underlying model could be the same in each case. What changes is the context it receives, the tools it can use, the rules it follows, and the actions it is allowed to take. These choices determine not only what the agent can accomplish, but also how useful, reliable, and appropriate it will be for the business task.