How to Use a Claude Harness for Reliable Agent Tasks

A Claude harness is the code and configuration that wraps the model and gives agent tasks their structure: it sets the tools Claude can call, the scope it can change, the checkpoints where a person reviews progress, and the verification steps that confirm the run succeeded. Without a harness, an agent task is open-ended and hard to restart after a failure. Tools like fenbs preserve the task record and handoff state so each run continues from where the last one stopped.

Reliability comes from structure, not from the model alone. Claude is capable, but a run that can touch any file, call any API and continue without checkpoints is hard to debug when something goes wrong. The harness is how you get the output you can trust.

What a harness does that a plain prompt cannot

A prompt tells Claude what to do. A harness controls how the session runs. It handles tool permissions (which tools are available and under what conditions), session state (what the agent knows at the start of each step), and stopping conditions (when the run should pause for review rather than continue).

The agent harness topic hub covers the full landscape of these patterns. This guide focuses on using the harness rather than building one from scratch, specifically the four elements that make Claude agent tasks repeatable: bounded scope, tool access, checkpoints and verification.

Bounding the task scope

Before running an agent task, define the boundaries. Which files or directories may be changed? Which API endpoints may be called? Which systems are off limits in this run? Write these as explicit constraints, not as "Claude should know not to touch X."

A bounded task is also easier to restart. If the run fails at step three, you know that steps one and two completed within their scope, so recovery starts at step three, not at the beginning. Scope boundaries turn a failure into a resumable checkpoint.

Record the task scope and any standing constraints in fenbs as Decisions and rules. When the next run reads the project context, it sees those boundaries without requiring you to re-state them in the prompt.

Controlling tool access

Give Claude access to the tools the task actually needs, and remove the rest. If the task involves reading and editing files but not running shell commands, configure the session accordingly. Minimum tool access limits the blast radius of an unexpected action.

For each tool you grant, decide whether Claude should call it autonomously or whether it should show you the proposed call before executing. For reversible actions in a test environment, autonomous calls are usually fine. For production writes, network calls or irreversible changes, a confirmation step is worth the extra latency.

Adding checkpoints

A checkpoint is a point in the run where Claude stops and reports what it has done before continuing. Build them at natural boundaries: after the plan is complete, after the first significant change is applied, after a set of related changes is finished.

At each checkpoint, verify the output against the task plan. Does the current state match what you intended? If not, correct the task description or the plan before the run continues. A ten-second review at a checkpoint is far cheaper than untangling a diverged run at the end.

Verifying the result

When the run completes, verify the result against the acceptance criteria you wrote before starting. Run tests, check the output against expected values, or review the changes in a diff. Do not rely on Claude's own summary of what it did; verify against the actual output.

If the run produced partial results, record exactly where it stopped and what remains. That is the handoff note for the next run, whether the next runner is you, a teammate or a fresh Claude session.

Maintaining the harness over time

A harness that worked well for your first few tasks will need updating as the project evolves. Tool APIs change, scope boundaries that were right for an early task may be too narrow for a later one, and verification steps that caught problems early may miss new classes of issue. Review the harness after every three to five runs, not only when something goes wrong.

Record changes to the harness configuration as decisions in your shared task record. A confirmation requirement you add after an unexpected action, a scope boundary you narrow after a near-miss: both are decisions worth preserving. The next person to use the harness needs to understand why the boundaries are where they are, not just what they are.

How to do this with fenbs

1. Create a free account and add the project. Record the task scope and standing constraints as Decisions and rules. Every connected assistant reads these first.
2. Add a task for each agent run. Write the plan with the steps, the acceptance criteria and the file scope. This is the record the next run reads at the start.
3. Connect Claude Code or your agent client over MCP from Integrations. Ask it to read the project context and the active task before starting.
4. After each checkpoint, update the task with what was completed and what remains. If the run paused for a person, mark that as Waiting on you in the progress note.
5. When the run ends, record the verification result in the task. Add any recurring failure pattern as a Lessons learned entry so the next run does not repeat it.