What the harness does
The model can propose a next step. The surrounding software decides how a tool call is executed, what information comes back and how the task continues. A harness can also manage state and the records needed to resume work. Implementations vary; the name alone does not tell you which controls are present.
Anthropic describes a harness for work spanning multiple sessions.
When it becomes relevant
A person drafting a short message in a chat may only need clear instructions and a review. A workflow that reads company records, updates a ticket and sends a response needs more explicit execution rules.
You may already have a platform that provides those rules. Check its capabilities before commissioning a new system. A custom harness is one possible implementation choice; a focused workflow built on existing tools may meet the requirement.
An example: triaging an incoming request
Consider a hypothetical workflow that reads an incoming request, checks an approved knowledge source and proposes a response. Reading a document and sending an email are different permissions. The proposal could remain a draft until a person approves it.
If a source is unavailable, the workflow should have a defined next step: stop, retry within a limit or ask for help. If a send operation is retried, the system also needs a way to avoid duplicate messages. A prompt by itself is not an access-control boundary.
Questions to ask before connecting company tools
- Which actions can the agent actually execute, and under whose account?
- Which steps need approval, and where is that enforced?
- What happens when a tool times out or returns incomplete information?
- Can someone inspect the actions taken and pause the workflow?
- How are access and sensitive records limited?
- What test cases must pass before a change is used?
Test the boundaries
Include cases with missing documents, conflicting records and denied permissions. Check that an unapproved action remains blocked even if a model requests it.
Logs should help the team understand a run without collecting unnecessary information. Decide who can inspect them and how long they are needed. Changes to tools or instructions should go through the same review criteria as the original workflow.
Describe the required behaviour in the project scope
A useful brief lists allowed tools, approval points, failure handling and the evidence needed to review a run. It also identifies who operates the workflow after handover.
That gives both the buyer and the builder something to assess. The deliverable is a workflow with understandable operating rules; the choice of harness or platform follows from those requirements.