01
Instructions and rules
The job, the rules and the tone, given to every run. Rules sit apart from the job, so they can be reviewed on their own.
Agent harness
The agent harness: everything around the model.
The model reasons. The harness decides what it sees, what it may touch, and how it runs for every user at once.
Every Botminds agent runs inside one enterprise-grade harness: the loop that drives it, the tools it is granted, the context it is given, the people who approve its changes, the models it can fall back on, and a record of every step. The same harness runs thousands of agents for thousands of users.
Instructions & rulesthe job, the rules, the tone
Context & memoryexactly what this run needs
Toolsgranted one by one
Model poolproviders and regions, with fallback
The modelany approved model
Approvalsa person, wherever you choose
Structured outputtyped fields, checked
Spend governancequotas checked at the door
Run recordstreamed live, kept, replayable
Agent = model + harness
What is an agent harness?
An agent harness is the software around a language model that lets it work as an agent: it runs the loop of thinking and acting, hands the model its tools and context, applies policy, asks people for approval, recovers from failures and records what happened. In short, agent = model + harness. The model is rented; the harness is where an enterprise agent becomes safe, predictable and accountable.
Scales out on KubernetesServices and workers add capacity as work arrives, and give it back when it is done.
Built for millionsMillions of documents, records and agent runs — the indexes and workers grow with them.
Any cloud, any regionAzure, AWS, Google Cloud or on-premises, in the region your data must stay in.
Always onRedundant services, rolling releases and continuous backups, for mission-critical work.
Secure and governedSingle sign-on, encryption, least privilege and a sealed audit trail.
Anatomy
Anatomy of an agent harness: eight parts, one policy.
A framework hands you the parts and leaves the policy to you. The Botminds agent harness ships each part with its rule already in it — and the rule holds whichever model is underneath.
02
Context and memory
Exactly what this run needs, assembled within a budget. Recent turns word for word, and a rolling summary of older ones.
03
Tools
Granted by name, checked before every call. Outside MCP servers are attached and narrowed by an allow-list.
04
Model pool
One model or several, across providers and regions. On document and background runs, a failing call moves to the next model in the pool.
05
Approvals
You choose which tools wait for a person, who approves, rejects or edits the request.
06
Structured output
Extraction and classification agents return typed fields against a schema, so the next step reads values.
07
Spend governance
Token quotas are checked at the one door every run passes — chat, schedule or API — and settled when it ends.
08
Run record
Every step streamed live and kept: the request, each tool call, each approval, the answer and its cost.
The run loop
One agent run, from request to record.
Every run follows the same path. What changes from agent to agent is the instructions, the tools and the data — the safety checks sit in the loop itself.
- Requesta message, a document, an event or an API call
- Admitidentity and token quota, at the door
- Choose a way to runfast or thinking, per request
- Assemble contextinstructions, memory, data, within budget
The loop · until done
- Model decidesanswer, or call a tool
- Grant checkis this tool allowed?not granted → refused
- Approvalthinking & autonomous: when the tool is set to wait for a personperson decides
- Actthe tool runs; the result comes back
- Shape the answertyped fields when a schema is set
- Recordevery step streamed live and kept
The grant check applies to every tool call the model asks for — the first one and the fiftieth — and a tool outside the grant is refused, whatever the model asked for. On thinking and autonomous runs, a tool set to wait pauses the run until a person answers.
Ways to run
Fast, thinking, auto and autonomous — one harness.
A greeting should come back in a moment; a comparison across ten documents should be planned, split and checked. Set an agent to Auto and the harness picks fast or thinking for every message.
AutoPicks fast or thinking for every messagefrom signals in the request — a rule, so it adds no wait
On purposeA person starts it
one passFasta single pass with toolsBest for lookups, short answers, conversation
plansThinkinga plan, a to-do list, working files, sub-agents, a final checkBest for analysis, comparison, many steps
long jobsAutonomoushours of work toward one goal, started by a person on purposeBest for building a whole solution
Six answer shapes — the agent type
- Generalanswers and actions
- Chatgrounded conversation
- Datatyped fields
- Classificationa type, with confidence
- Quality checka verdict, with reasons
- Standardizationone form for every value
Tool access
Tools in the agent harness: granted, never assumed.
The riskiest default in agent software is “all tools unless told otherwise”. Ours is the opposite: an agent reaches the tools it was granted, and when its settings are missing it falls back to read-only basics.
700+platform tools in the catalogue
Tools granted by nameThe read-only basics, plus exactly the tool sets it was givengranted
Nothing grantedJust the read-only basics: who am I, where am I, what is hereread-only
Settings missing or unreadableThe same read-only basics — never the full cataloguefails closed
Explicitly deniedNothing at allnone
Four kinds of tool
Built-in tool sets, your own APIs as typed tools, working tools for agents that plan, and outside MCP servers — each reached the same way.
One rule in every runtime
The grant is decided in one place every way of running asks, so a fast run and a thinking run reach exactly the same tools.
Exceptions written down
A tool given beyond the basics without a grant needs a recorded decision and a reason, and each one is read-only or owner-confirmed.
Why it matters. Text inside a document can try to talk an agent into something else. With granted tools, the most a successful attempt reaches is what the agent was already allowed to do. See AI agent security.
Context and memory
What the model sees — and what it remembers.
Most agent failures are context failures: too much, too little, or the wrong thing. The harness assembles context the same way every time, and shows you the exact prompt before a run.
- Sources
Who is asking, the conversation, the project, the page and the knowledge available — each switchable.
- Budgeted tiers
Each tier has its own token budget; the least important blocks give way first.
- Two kinds of memory
Recent turns word for word, and a rolling summary of older ones.
- Variables, eight scopes
From the platform down to one tool call, so one agent serves many teams.
- Preview
See exactly what the model will receive, before it runs.
Retrieval draws on the collections the asker may see — see agentic RAG. How context is chosen and trimmed is covered in context engineering.
People in the loop
Approvals inside the loop, not after it.
An agent that proposes a change and waits is more useful than a read-only one. You set which tools wait for a person; in a conversation, thinking and autonomous runs pause on an approval card until the person answers.
An approval, as the reviewer sees it
You
Close out the three loan files that passed review today.
Agent
Three files are ready. Moving them to Decided changes their stage and notifies the processors. Approve, reject, or edit the list?
You
Edit: leave out the Lopez file, it needs a second look.
Agent
Done — two files moved to Decided. The Lopez file stays in review. Your decision and your edit are kept with this run.
Per tool, per agent
Any tool, or a whole sub-agent, can be set to wait.
Three answers
Approve, reject, or edit the arguments first.
Plain words
The card says what will change, in words a reviewer can judge.
On the record
The decision and any edit are kept with the run.
Review stages and four-eyes sign-off: human in the loop.
When things go wrong
Failure handling: one owner for every kind of fault.
When every layer retries, one fault becomes a storm and the cause disappears. In the Botminds agent harness each kind of fault has exactly one owner, and every retry is counted.
rate limits
Paced within provider limits
Declare a model’s limits and calls are paced within them; a refusal moves to the next model in the pool.
model pool
Another model takes the turn
On document and background runs, a failing call moves to the next model in the pool — another deployment, provider or region.
network
Blips absorbed
A dropped connection to a store or service is retried within the run’s deadline, by the layer that owns it.
named cause
Clear stops
A fault a retry cannot fix — such as an input too long for the model — ends the run at once with its cause.
- Stop
Stop a run mid-way from the screen.
- Replay
Recent runs replay step by step from their journal.
- Read the log
Every run’s steps, tool calls and cost stay in the run log.
- Watch first-try success
Retries are counted, so a pattern shows up as the defect it is.
Enterprise scale
An agent harness for thousands of agents and thousands of users.
The harness is built for internet-scale workloads: runtimes that scale out on Kubernetes with every run’s stream and record kept outside them, model pools that span providers and regions, and governance at the door — on Azure, AWS, Google Cloud or on-premises.
Thousands of callers
Peoplechat, Piper and apps
Workflows & meshesagents as steps and members
Schedules & eventswork that starts on its own
Your systemsan OpenAI-compatible API
One door
- who is asking
- token quota
Agent runtimes · KubernetesEvery run’s stream and record live outside the runtime, so any runtime serves any run’s stream. Capacity grows by adding runtimes, and each release lets a runtime finish its work before it stops.
Model pools
Azure OpenAIEast US
Azure OpenAIWest Europe
Googleany region
Your own deploymentthrough the gateway
document and background runs: a failing call → the next modelThe run recordevery step · streamed live · stopped from the screen · kept with its tool calls, approvals and cost
Runs kept outside the runtime
Every run’s stream and record live outside the runtime, so any runtime serves any run’s stream. Capacity grows by adding runtimes, and each release lets a runtime finish its work before it stops.
Every run, streamed and recorded
Millions of runs, each streamed as it happens and kept: steps, tool calls, approvals, cost. One run surface for agents, workflows and meshes.
Model pools across providers
Spread load over deployments in several regions and providers. On document and background runs, a busy or failing call moves to the next model in the pool.
Governance at the door
Identity and token quotas are checked at the one door every run passes — whoever or whatever started it; tool grants hold on every call.
Every agent can also be called from your own systems through an OpenAI-compatible API, with per-key rate limits and idempotency keys, so a retry from your side never runs the work twice. Workflows and meshes run on the same surface: see agentic workflows and the agent mesh.
Side by side
Agent harness vs agent framework vs orchestration.
The three words get used for each other. They are different layers, and an enterprise needs to know which one it is buying — or building.
| Agent framework | Workflow orchestration | Botminds agent harness | |
|---|---|---|---|
| What it is | A library to build agents with | A scheduler that runs steps in order | The running system every agent lives in |
| Tool access | Whatever the code passes in | Outside its scope | Granted by name; read-only basics by default |
| People in the loop | Build it yourself | Manual steps between tasks | Approve, reject or edit, on the tools you choose |
| Context and memory | Build it yourself | Outside its scope | Budgeted tiers, two kinds of memory, a preview |
| When a model fails | Build it yourself | Retry the whole step | On document and background runs, the next model in a pool across providers and regions; one owner per fault |
| Spend | Outside its scope | Outside its scope | Quotas at the door; cost settled per run |
| Scale | Your servers | Add workers | Runtimes scaling out on Kubernetes, runs streamed and recorded outside them |
| Who maintains it | Your engineers | Your engineers | The platform, for every agent at once |
Build or adopt? Most of an agent’s reliability comes from the harness, not the model. Teams that build their own spend that effort on every agent. The build vs adopt whitepaper sets out the costs.
Questions people ask
Agent harness, answered.
More from the platform: the full architecture, and how security works at Botminds.
What is an agent harness in AI?
An agent harness is the software around a language model that lets it act as an agent: the loop of thinking and acting, the tools and context it is given, the policy it works within, approvals by people, recovery from failure and a record of each run. Agent = model + harness.
What is the difference between an agent harness and an agent framework?
A framework is a library you build agents with; you still decide tool access, approvals, memory, failure handling and records yourself. A harness is the running system that does those things for every agent, with the policies built in.
Is an agent harness the same as orchestration?
No. Orchestration decides which step or agent runs next. The harness governs what happens inside each agent’s run. Botminds has both: the harness for each agent, and workflows and the agent mesh for connecting them.
How is an agent harness different from MCP?
MCP — the Model Context Protocol — is a standard way for agents to reach tools. A harness decides whether a given agent may use a given tool, and when a person must approve it. Botminds speaks MCP in both directions and puts every MCP tool behind a grant. See MCP for the enterprise.
What is harness engineering?
Harness engineering is improving an agent by changing what surrounds the model — its tools, context, checks and recovery — rather than the model itself. Harness changes alone can move an agent’s results a long way.
How does an agent harness scale to thousands of users?
Botminds runs agents on runtimes that scale out on Kubernetes. Every run’s stream and record live outside the runtime, so any runtime serves any run’s stream, and capacity grows by adding runtimes. Model pools spread calls over providers and regions, identity and token quotas are checked at the door, and every run is streamed and recorded.
Can an agent take actions without anyone approving them?
An agent acts through the tools it was granted, and the grant check applies to every tool call. You choose which of those tools wait for a person; on thinking and autonomous runs, a tool set to wait pauses the run on an approval card where the person approves, rejects or edits the request. Every decision is kept on the run’s record.
Which models does the Botminds agent harness work with?
Azure OpenAI and Azure AI Foundry deployments, Google Gemini, and any model added to the gateway’s model list — OpenAI, AWS Bedrock or models you host. An agent can name several models as a pool; on document and background runs, a failing call moves to the next model in the pool. See the LLM gateway.
How do you know a harness change made things better?
By measuring it. Agents are tested against golden datasets with repeated runs. Set an agent’s evaluations to run on every publish; workflows and meshes are measured nightly, weekly or on demand against their baselines, and a worse change is flagged with the reason. See AI agent evaluation.
Can I see exactly what an agent was told?
Yes. The context preview shows the exact prompt an agent will receive, and every run’s record keeps the request, each tool call, each approval and the answer.
Agents that work like your best people.
Bring one task your team does every day. We’ll show you the agent, its tools, its approvals and its record, running on your own data.