Harness engineering

The simple model

Harness Engineering turns AI work into a controlled sequence: goal, bounded workspace, approved tools, controlled execution, evidence package, review gate, and then promote, resume, redirect, or stop.

• PROMI coordinates the work lifecycle.
• Cortex remembers decisions, handoffs, evidence, and resumable project memory.
• The harness limits where the worker taskss, which tools it can use, and what proof must be captured.

Controlled workspace

Each task starts with scope. The boundary should make clear which project, branch, files, routes, systems, or documents are in scope and which surfaces must be left alone.

• The handoff files and verification field define the practical work boundary.
• A stronger permission, different repository, deploy command, or policy exception should become a consult or review gate.

Approved tools and actions

AI workers should receive only the tools, connectors, files, credentials, and actions that match the task. The same project identity and steering should flow across supported worker harnesses so the project rules remain stable when the underlying AI tool changes.

What users see

Users should not need to manage the technical harness. They should see the practical outcome: scoped work, visible tools or capabilities, evidence, pause/resume points, and clear approval gates before high-impact actions.

Evidence packages

When work is ready for review, the evidence package should answer what changed, why it changed, how it was verified, and what risk remains. A confident summary without proof is not a review package.

• Evidence can include files touched, route checks, screenshots, tests, build output, decisions, handoffs, and residual-risk notes.
• If the evidence is missing, the work should not be treated as complete.

Pause, resume, and rollback

Long-running AI work should be resumable from Cortex boot context, handoffs, decisions, and evidence instead of fragile chat memory. Pause when scope is ambiguous, verification fails, a required source is missing, or the work touches high-impact systems.

Before approving a gate

Before approving a gate, check whether the work stayed inside the requested scope, whether the evidence supports the claim, whether important risks are named, and whether the next step is reversible or high impact.

What remains human-approved

The harness can draft, test, document, compare, and prepare, but production deployment, protected-branch merges, customer-visible release changes, billing, credentials, authentication, data deletion, security exceptions, and unclear architecture choices should remain approval-led.

What can go wrong

Harness issues usually show up as unclear scope, excessive permissions, missing evidence, or a task trying to do too much at once. The safest response is to narrow the handoff and require clearer verification.

Read next

Read Trust and security for enterprise controls, or Cortex handoffs and evidence for the review package pattern.