Engineering harness in practice: six plans to transform intention into evidence

An agent receives a task, opens files, uses tools, produces a change, and announces that it is finished. The result may be right. The problem is that “might be right” is not an operational property.

To trust the work, we need to know what was asked for, what authority existed, what environment was used, what was verified, what evidence was preserved, and who decided to accept. This is what an engineering harness organizes.

This article is a technical companion to “The Model is Not the System”. Instead of discussing the thesis at a high level, it presents a minimal design in six plans: intent, policy, execution, verification, evidence and feedback.

Executive summary

A harness does not need to be a monolithic platform. It is a set of explicit boundaries around a probabilistic executor.

Each plan has a contract, a typical failure and minimum evidence:

The sources examined by FORGE support the separation between session history, orchestration, and execution isolation; also show that additional complexity can improve a task and materially increase cost and latency. These conclusions are limited to the implementations studied, not a universal recipe. [HARNESS31-C2] [HARNESS31-C3]

The minimum contract

Before thinking about specialized agents, a flow can be described like this:

task:
  objective: "publicar o artigo aprovado"
  subject: "FORGE-ARTICLE-A09"
  out_of_scope:
    - "alterar o texto aprovado"
    - "expor conteúdo antes de publish_at"

authority:
  read: ["projecao-editorial"]
  write: ["artefato-estatico"]
  external_effects: ["deploy-pages"]
  requires_human_approval: ["aprovar-artigo", "alterar-agenda"]

verification:
  required: ["digest", "links", "a11y", "secrets", "clock-boundary"]

evidence:
  bind_to: ["article_digest", "commit_sha", "build_id", "deploy_id"]

The format may change. Responsibilities should not disappear within a prompt.

Plan 1 — intention

Intent turns open language into an executable problem.

Contract

• outcome and affected public;
• asset or system that will be modified;
• authorized entries;
• out of scope;
• acceptance criteria;
• expected external effects;
• authority approving the conclusion.

Typical fault

The agent chooses a plausible interpretation, optimizes a local metric and delivers something technically correct for the wrong question.

Minimal evidence

A versioned spec, linked to the issue and the revision produced. If the intention changes, the change needs to show up — not be silently absorbed during execution.

Design question

Would anyone else be able to distinguish “done” from “looks good” without talking to the executor?

Plan 2 — policy

Policy defines authority before the tool is called.

Contract

• readable and writable resources;
• allowed commands, APIs and channels;
• data classification;
• cost, time and trial budget;
• reversible and irreversible actions;
• stopping and climbing conditions;
• human gates.

Typical fault

The model interprets the availability of a tool as permission for any use. Convenient access becomes organizational authority.

Minimal evidence

An addressable policy and a mechanism that enforces it: allowlist, scoped token, isolated environment, branch protection, approval or deny-by-default.

The public sources examined describe shared and scoped capabilities, but do not offer a universal authorization model. Each product still needs to define revocation, least privilege, and boundary testing. [HARNESS31-C4]

Plan 3 — execution

Execution is where intent and authority meet tools and state.

Contract

• session identity;
• exclusive review or worktree;
• runtime and dependencies;
• context sources;
• checkpoint and resumption strategy;
• parallelism limits;
• destination of outputs and logs.

Typical fault

Two tasks modify the same scope, a session inherits old context, a failure erases progress, or a result cannot be attributed to the environment that produced it.

Minimal evidence

Session ID, base commit, final revision, environment, duration and outcome. For long tasks, checkpoints need to be artifacts, not just messages.

Separate session, model and role

The session preserves continuity. The model offers capacity. The role defines responsibility. Mixing the three makes it difficult to change the model, resume work or audit authority.

Plan 4 — verification

Check answers specific properties. It is not a vote between agents.

Contract

For each control:

• accurate subject and review;
• observed property;
• tool, version and configuration;
• approval policy;
• necessary independence;
• known limits and false negatives.

Typical fault

The same executor creates the change, writes the test, interprets the result, and publishes the conclusion. A single error of understanding cuts across all layers and is given several “green” names.

Minimal evidence

Reproducible report or result tied to review. Unit testing, contract, secret scanner, behavioral eval and actual navigation are separated because they prove different things.

Complexity has a cost

In a public experiment on the development of long-term applications, planner, generator and evaluator improved the observed results, with a material increase in cost and duration. The data supports measuring and ablation; does not support creating three agents for every task. [HARNESS31-C3]

Maintain a control because it reduces a class of failure or measurable risk. Remove it when a simpler alternative demonstrates the same protection.

Plan 5 — evidence

Evidence links assertion to what was actually observed.

Contract

• subject and digest;
• origin and version;
• executor and verifier;
• applied controls;
• receipts and reports;
• validity and limit of inference;
• approver;
• known residual.

Typical fault

A page claims “safe,” “complete,” or “approved,” but the report belongs to another commit, another environment, or another date. The evidence exists; the binding does not.

Minimal evidence

An immutable manifest that allows you to resolve claim → source → receipt → published asset. The absence of any link needs to fail in a closed way.

State is part of the claim

“Specified” says that there is a drawing. “Observed” says something was seen. “Enforced” says that a mechanism applies a rule. “Qualified” requires a defined acceptance cutoff. No state inherits the next by proximity or enthusiasm.

Plan 6 — feedback

Feedback closes the gap between correcting an incident and improving the system.

Contract

• event that opened the loop;
• cause and impact;
• immediate correction;
• durable change;
• regression or control;
• owner and residual term;
• closing criteria.

Typical fault

The agent tries again until it gets green. The execution ends, but the failure class remains intact.

Minimal evidence

A test, pattern, decision, context update, or policy linked to the original event. Closing the issue without lasting change is just closing the queue.

Example 1 — software change

Request: add social authentication.

• Intention: providers, journeys, errors and acceptance criteria.
• Policy: server-side secrecy, allowlisted callbacks, minimal data and security approval.
• Execution: isolated worktree, test environment and deployment identity.
• Verification: OAuth contracts, tenant isolation, scanner, tests and real mobile flow.
• Evidence: reports and deploy linked to the same commit.
• Feedback: Failures generate regressions, documentation and policy adjustments.

Without harness, the login demo can work while the identity boundary remains wrong.

Example 2 — article publication

Request: publish tomorrow at 9am.

• Intention: approved text, canonical, sequence and time.
• Policy: automation can design and publish; You cannot rewrite the content.
• Execution: build time with credentials outside the repository.
• Verification: digest, sources, links, accessibility, secrets and clock.
• Evidence: commit, build, deploy and public URL.
• Feedback: correction preserves date and records note; social failure does not duplicate posts.

This example shows that harness is not exclusive to code. It organizes any flow in which AI produces artifacts and there is external effect.

Metrics per plan

Avoid a huge dashboard at the beginning. Choose signs that help you decide:

Cross these signals with outcome, cost and time. A system can become more controlled and no longer be economically useful; or stay fast while increasing invisible risk.

How to start small

1. Choose a flow with a real and reversible effect.
2. Write intent and out of scope on one page.
3. List the minimum capabilities and deny the rest.
4. Bind two or three controls to different properties.
5. Generate a simple manifest with review, reports and approver.
6. Make the first fix produce a regression.
7. Measure the cost of each plan and simplify with evidence.

After that, decide whether you need one orchestrator, multiple agents, or a larger platform. The architecture must respond to the observed load and risk.

Conclusion

Engineering harness is the discipline of making agentic work governable.

Intent prevents speed in the wrong direction. Policy prevents a tool from becoming authority. Execution preserves identity and state. Verification separates properties. Evidence links the result to its origin. Feedback turns correction into durable capability.

The goal is not to surround AI until it is no longer useful. It’s about creating enough trust to delegate more — and hold humans accountable for the decisions that define purpose, risk, and effect in the world.

Previous reading: The model is not the system. Next reading: AI amplifies the business you already have.