The Agent Harness Makes Business Work Executable

An illustrative incident agent receives an alert after a production latency spike. It needs to inspect monitoring data, compare recent deployments, find similar incidents, identify the service owner, open an investigation record, and prepare a response brief. Halfway through, the ticketing API times out after accepting a create request.

The model can suggest the next step. It cannot know from the timeout alone whether the ticket exists, whether retrying is safe, or how the partial run should resume.

That is harness work: turning model decisions into controlled execution across tools and state.

The runtime owns what a prompt cannot

A system prompt can tell an agent to avoid duplicate tickets. Preventing duplicates requires implementation:

• assign a stable incident identifier;
• pass an idempotency key to the create action where supported;
• retain the request and response status;
• query for the committed record after an ambiguous timeout; and
• stop or escalate if the system cannot establish the result.

The harness coordinates this behavior around the model. It stores observable state, enforces limits, dispatches tools, and decides how a failed step returns to the workflow.

For simple read-only questions, that machinery can appear excessive. For multi-system work, it is the difference between an answer and an operation.

Tools should return execution facts

A tool response should provide enough structure for the harness to choose a safe next step. A create action might return:

status: committed
record_id: INC-4821
created_at: 2026-07-30T08:42:11Z
retry_safe: false
evidence_ref: run-91/action-06

This is more useful than “Ticket created successfully.” It gives the workflow a stable record, a time, a retry instruction, and an evidence reference.

Errors need similar precision. Authentication failure, rate limiting, validation rejection, pre-commit timeout, and unknown commit status should not collapse into one generic exception.

Fabria focuses on this capability boundary: tool schemas, permissions, testing, deployment, and evidence are designed as part of the agent’s workflow rather than left as an API wrapper.

The harness decides what enters model context

Monitoring queries and log searches can produce large results. Returning every row to the model increases cost and can bury the relevant signal.

The harness can keep raw results outside the context window, use code or deterministic filters to reduce them, and present the model with selected evidence plus references to the underlying records. It can also isolate subtasks so the deployment comparison does not carry an unrelated ticket history.

Runtime choices should be validated against the workflow rather than assumed to improve it. A smaller model context may lower cost but omit the evidence needed for the next decision; a programmatic tool path may run faster while introducing a wider execution surface.

Programmatic execution also adds risk. Generated code needs a sandbox, bounded resources, restricted network and file access, and a clear inventory of callable capabilities. A faster tool path is not acceptable if it widens the action surface.

Checkpoints make long work recoverable

The incident workflow should checkpoint after meaningful state transitions:

• alert and scope confirmed;
• recent changes collected;
• comparable incidents selected;
• owner identified;
• investigation record established;
• response brief prepared; and
• human decision or production action requested.

If a later step fails, the agent can resume from an inspected checkpoint instead of replaying every call. The checkpoint should record source versions and timestamps because the environment may change before the run resumes.

Too many checkpoints add storage and coordination overhead. Too few make recovery expensive or unsafe. The boundary should follow business state, not every model turn.

The harness cannot invent authority

The incident agent may prepare a rollback proposal. Permission to query deployment history does not grant permission to change production. The harness must call an explicit policy check and route the action to the authorized human or automation.

The Coryntas workflow library treats human authority and recovery as part of the path from context to outcome. An agent harness makes that path executable. It does not decide which business risks the organization should accept.

Models will continue to improve. The runtime still has to know what happened when a request timed out.