An agent can make a convincing plan, change several files, and announce success while leaving the central problem unresolved. Adding three more agents does not automatically improve that situation. It can produce four confident reports about four incompatible changes.
Agent Harness addresses the surrounding workflow: how a task starts, which actions require a checkpoint, how workers are scheduled, and what evidence should exist before completion. Its most useful architectural decision is the separation between Pro, a structured single-agent workflow, and Ultra, a task graph with bounded workers. Parallelism becomes a choice about the work, rather than a badge of sophistication. Plugin overview
Research basis: We reviewed Agent Harness 2.0.1 by a0-community-plugins at
c4f2801fe976, the revision in the downloaded Plugin Hub index on October 28, 2026. We traced its lifecycle, guardrails, worker management, prompts, and workspace handling against Agent Zero coreff2a5b9c9c4e. The repository's 29 regression tests passed with real core imports in an isolated, network-disabled framework container. Worker execution in those tests uses controlled fixtures; this is not a measured comparison of real coding agents.
The short version
- Start with Pro for most serious coding work. It gives one agent an explicit workflow without worker coordination overhead.
- Use Ultra for independent work. Workers have separate contexts but share the filesystem.
- Completion needs a passing verification record. The check still has to answer the right acceptance question.
| Mode | Execution model | Background workers |
|---|---|---|
| Flash | Minimal single-agent workflow | None |
| Standard | Ordinary single-agent work | None |
| Pro | Structured single-agent workflow | None |
| Ultra | Main agent plus a dependency graph | 1–4 |
Start with the shape of the job
The plugin offers four modes. Flash provides minimal structure for small work. Standard keeps an ordinary single-agent flow. Pro adds explicit inspect, plan, implement, and verify discipline. Ultra adds a mandatory task graph and one to four background workers. The README recommends Pro as the default for serious coding work. Modes and settings Worker limits
Consider a change to an authentication endpoint. If the implementation, its tests, and the migration all depend on the same unsettled interface, assigning each to a different worker creates coordination work before it creates useful parallel work. A Pro run can resolve the interface first, implement the change, and verify it in one context.
Ultra makes more sense after the interface is stable. One worker might inspect a frontend consumer, another review an independent documentation path, and another implement a test fixture in a separate file. Dependencies in the task graph should describe the real sequencing constraints. A task that depends on an unfinished schema decision should wait, even when a worker slot is free. Planner Orchestration
That reasoning is our analysis of the design, not a benchmark result: the relevant quantity is useful work that can proceed independently, minus dispatch, review, and integration overhead. There is no reason to assume four workers are faster for a task with one narrow critical path.
Separate contexts do not create separate filesystems
Each Ultra worker gets an Agent Zero context and a harness run. Its live background task is tracked in a module-level registry because a running task cannot simply be serialized into the run document. Workers nevertheless share the filesystem. The README makes that limitation explicit. Parallel implementation
This distinction changes how a task should be written. “Improve the API” gives a worker permission to wander through shared files. “Inspect these two handlers and return findings without editing” is a much more bounded assignment. For editing work, give each worker a file boundary and a defined output. The main agent still owns integration.
The per-chat workspace is another useful boundary, but it serves a different purpose. Harness creates scratch, upload, and output directories under chat storage rather than adding a .harness folder to the attached repository. Upload and artifact handling check containment, including symlink escapes. That protects the artifact interface; it does not turn every shell command into a confined filesystem operation. Workspace handling
Approval attaches to an action
The guardrails look for dependency installation, destructive commands, Git mutations, protected paths, and excessive distinct-file edits. Default protected paths include agent.py, initialize.py, and usr/plugins/. A checkpoint is tied to the proposed tool name and arguments. Approval is consumed by one execution attempt, and unrelated tool execution remains blocked while an approval is pending. Guardrails
The valuable detail is the granularity. Approving one package installation is a decision about one proposed action. It is not a permanent grant to keep installing packages until the task feels complete. If arguments change, the approval identity changes. If a worker reaches a boundary, it reports the required action to the main chat.
This remains an application-level policy around recognizable tool actions. It should not be described as an operating-system security boundary, a proof that arbitrary programs cannot cause side effects, or a substitute for reviewing the command. Its purpose is to make consequential transitions visible and deliberate.
Completion needs evidence, and evidence needs interpretation
The run controller checks for unresolved checkpoints, incomplete Ultra tasks, and a latest verification record that passes. The lifecycle helper also recognizes familiar test-runner summaries in tool output. A failed test summary takes precedence over a passing one; unrecognized output remains unknown. Run controller Verification parsing and completion blockers
This is more disciplined than equating “the model stopped talking” with completion. It also has a clear limit: a passing record says that a check was recorded as passing. It does not establish that the check was sufficient. A model can select a weak test, miss the relevant acceptance condition, or describe a result too broadly.
For a bug fix, a useful verification should reproduce the original trigger and show the changed behavior. For a visual change, source checks may need an actual rendered inspection. For a multi-worker run, isolated worker tests should be followed by an integration check over the combined result. These are editorial recommendations for using the mechanism well, not extra guarantees supplied by the plugin.
The same distinction applies to usage reporting. Harness tracks approximate completion-token usage and can pause against a configured budget. Treat that as a steering aid. It is not an authoritative invoice covering every provider-specific charge. Cost tracking
A practical first run
Use a disposable project with a small, known defect. Enter a concrete objective in the Harness canvas and choose Start Pro. Send the next chat message to begin the workflow. Ask the agent to identify the failing behavior, propose a bounded change, run an appropriate check, and record the result.
Then try Ultra on genuinely independent work: two separate read-only reviews followed by integration in the main chat. Compare the total useful outcome, including the work required to resolve conflicting findings. Avoid judging the modes by how busy the dashboard looks.
Before enabling checkpoints in a project with its own engineering rules, compare the configured protected paths and approval policy with those rules. A generic default cannot know every repository's important files. Harness supports project and agent configuration, making this a place to encode local constraints explicitly. Configuration
What our checks established
We ran the repository's unittest suite with real Agent Zero imports: 29 tests passed. Coverage included approval identity and consumption, worker bounds, lifecycle behavior, prompt contracts, workspace containment, and renderer expectations.
No paid model calls, deployments, or real worker productivity trials were performed. The test result supports the exercised contracts. It does not establish that Ultra improves quality or speed on arbitrary work.
Agent Harness is most useful when the operator can state what good work looks like. It supplies places to express that judgment: objectives, task dependencies, exact-action checkpoints, and verification records. The number of agents is then a consequence of the plan.
Sources
Agent Harness 2.0.1 repository, a0-community-plugins; reviewed at
c4f2801fe976.Agent Zero core, reviewed at
ff2a5b9c9c4e.All motion illustrations are original and derived from the reviewed sources. Illustrative data is labeled.