Lexicon · III · Orchestration
Harness
Also: scaffolding
The working environment built around an AI model: its tools, its access rights, its rules and its guardrails.
The analogy
A brilliant LLM without a harness is an expert locked in a phone booth: they can advise you, but they cannot touch anything. The harness is the workstation you set up for them: the computer, the folder access, the internal phone line, the procedure to follow, and the list of things they are not allowed to do. The same expert, depending on the workstation, will be useless or decisive.
One model, four workstations
Switch the harness and watch: the model does not move, its capabilities do.
Pick a workstation:
The model
identical in all four cases
The harness
Tools
- Web search
- Reading your attached files
Access
- The conversation's documents, for the length of the conversation
Guardrails
- No writing to your systems
- Conversations siloed per user
- It can
- analyze your documents, search, produce polished answers.
- It cannot
- act on your systems: this harness has no writing tools.
The model has not changed by a single weight. Only the workstation has.
The four organs of a harness
Every harness, from the consumer chat app to the line-of-business agent, assembles the same four organs. The tools: what the model can do (search, read, write, pay). The access: what it can see (which folders, which systems, which data). The rules: the standing instructions that frame its work, meaning tone, procedures and prohibitions (often called the "system prompt"). The guardrails: what limits the damage when things go wrong (permissions, approval thresholds, action logs). Reading any "AI" offer through this grid changes everything: you stop asking "which model?" and start asking "which organs, tuned by whom?".
A concrete example
Claude Code is a harness: it takes a model (Claude) and equips it for software development work: reading files, running commands, seeing its own errors, trying again. The Claude chat application is a different harness on the same model, equipped for conversation, not action. When two teams get wildly different results "with the same AI", the difference is almost always in the harness, not the model.
Why it is an organizational decision
An organization onboarding an employee already builds a harness without knowing it: a job description (the rules), clearances (the access), equipment (the tools), a probation period with milestones (the guardrails). Nobody delegates those choices to the IT department alone: they are management decisions. The same applies here: deciding that an agent may write to the CRM but not send emails, pay up to €500 but no further, is work design, not engineering. Hence the right question to ask, of your teams as of your vendors: not "which model do you use?", but "what did you put in the harness, and who decided it?".
What it is NOT
It is not the model: swapping the harness without touching the model radically changes what the AI can do. Nor is it cosmetic "packaging": deciding which access, tools and guardrails a model gets is an organizational decision (the same one you make when onboarding a new employee), not an implementation detail.
Often confused with
The distinction that changes the conversation.
- Agent
- The harness is the equipped workstation; the agent is the work being done. You install a harness; you watch an agent.
- Framework
- A framework is a developer tool for building software. The harness is what the model uses to do its work. Some harnesses are built with frameworks, but the confusion leads people to file this under 'purely technical'. It is an organizational matter.