Agent Harness Architecture: Checkpoints, Approvals, and Recovery

An agent harness is the software around a model that manages execution: receiving work, selecting tools, recording progress, handling approvals, and delivering results. The model proposes what to do next. The surrounding system determines what can run, what survives an interruption, and what evidence remains afterward.

This article examines mechanisms in Harp, the implementation behind Luffy, reviewed on November 9, 2026. It is a source-code walkthrough, not a production reliability benchmark. The examples below are illustrative; they are not customer results.

Start with a workflow that can fail halfway through

Consider a weekly operating report assembled from a CRM, a project tracker, and Slack. The agent reads two sources, waits for a third, drafts a report, and prepares a delivery. A worker can stop at any of those boundaries. If the only record is a conversation transcript, a replacement worker has to infer which actions happened. That becomes dangerous when an action changes an external system.

A useful architecture separates the request, execution state, authorization, and delivery record. Saving the generated answer is only one part of the job.

1. Admit scheduled work with explicit ownership

Harp’s job-admission path first repairs expired claims, then claims due jobs within a configured budget. It separates work into lanes and handles a failed worker wake-up as its own failure. This keeps “the scheduler noticed a job” distinct from “a worker successfully completed it.”

The engineering lesson is to give ownership a lifetime and make recovery explicit. A queue notification is useful for waking a worker, but it should not be the only evidence that work exists. Capacity limits also matter: starting every due job at once can shift the failure into downstream APIs.

2. Protect checkpoints from stale workers

The checkpoint writer stores state by session and checkpoint key. Its database write is guarded by the session lock holder, and an update cannot move the stored epoch backward. It also preserves selected recovery-accounting fields across rewrites. These checks address a concrete race: an older worker returning after a newer worker has taken ownership.

Imagine worker A pausing during a tool call and worker B taking over recovery. Without a write guard, A could overwrite B’s newer progress. Persisting state is therefore insufficient by itself; the system must also decide who is allowed to persist it.

This does not make external actions atomic with the checkpoint. If a provider accepted a write but the receipt was not saved, recovery must reconcile the external result or use a provider-supported idempotency mechanism. Blindly repeating the call is not a general solution.

3. Resume an approval against the saved action

Harp includes approval-resumption logic that selects items associated with the option the user chose. Its SDK checkpoint repair path checks the approval marker, request identifier, provider receipt mapping, and matching tool call before preparing resume state. Invalid or ambiguous shapes are rejected by that helper.

For a lead-enrichment workflow, approving a proposed CRM update should remain associated with that action and its arguments. It should not be interpreted as permission to email the lead or update unrelated records. The code demonstrates a mechanism for connecting a decision to saved work; it does not establish that every provider or workflow has identical approval behavior.

4. Track delivery separately from generation

The outbox layer can read reply status and store a provider timestamp for a delivery part. The part insert uses conflict handling so an existing part key is not overwritten. This provides a ledger that resume logic can consult instead of treating an interrupted response as wholly unsent.

A delivery-part ledger is not a concurrency fence. Nor does it remove the uncertainty between a remote service accepting a message and the local system recording the acknowledgement. These boundaries need their own ownership rules, reconciliation, and failure testing.

Implementation evidence

The source review covered the job-admission path in harp/job_admission.py, the guarded checkpoint writer in harp/store/core.py, SDK approval checkpoint repair in harp/approval_resume.py, and delivery-part persistence in harp/store/_compiled/outbox.py. These are implementation references, not a claim that the repository is publicly available or that every path has been exercised in a production benchmark.

What we would measure before claiming reliability

Source inspection shows the intended mechanisms. To measure their behavior, run the same workflow with controlled failures: interrupt a worker before and after an external write, expire a claim, submit a late approval, and retry a partially delivered reply. Inspect both durable state and the actual external result.

• Did the workflow resume from the correct recorded state?
• Did a stale worker fail to overwrite newer progress?
• Did the approved action preserve the selected target and arguments?
• Were uncertain external writes reconciled rather than blindly repeated?
• Did the user receive the intended result without an unsupported success claim?

We are not publishing success rates, recovery times, or cost comparisons here because this article does not include a measured benchmark. Those results require a declared workload, environment, failure model, and repeatable evaluation.

How this connects to work in Slack

For a team using AI agents for Slack, these details affect whether a delegated job remains understandable after a pause or failure. Start with automated weekly reporting or automated lead research, define the expected output, and inspect the evidence before expanding its authority.

The goal of an agent harness is not a convincing account of what happened. It is execution state and results that people can check.