Seven agent runs for a single feature. That's what the first version of my harness looked like: specialized subagents for product owner, architect, UX designer and software engineer, later also for QA, clean handoffs, clear responsibilities. On paper, that sounded like good architecture. In practice, it was slow and complicated.
So I got rid of the subagents again.
In this last part of the series about my harness sparc, I show why the supposedly better architecture failed and how an idea turns into a tested, documented change today.
What went wrong with the subagents
The idea was obvious. Every role gets its own agent with its own context. The product owner writes the requirements, the architect the design, the engineers build, QA checks. The work moves from agent to agent.
With the change that introduced the QA agent, I took a closer look. One feature needed seven agent runs, and every single one had costs:
- Every agent read the same files again, because it had its own empty context.
- Questions took detours. If an agent had a question for me, the main session had to pass it on and return the answer.
- Agents simply stopped as soon as a tool failed.
- Changes to an agent weren't usable right away, because Claude Code loads agent types only at the start of a session.
- Parallel engineers in their own git worktrees produced false warnings that the docs didn't match the code, and saved hardly any time.
The solution was almost disappointingly simple: every agent became a rule file. A skill now just says "Follow the software engineer role", and the running session works through the roles in sequence. No handoffs, no forwarded questions, no worktrees. A changed role takes effect immediately.
That doesn't come for free, and the ADR says so: by default there's no independent check from a fresh context anymore, and the main session's context grows. A code review and automated tests as evidence help against that. If you still want an independent view, you can hand QA and acceptance to a single, fresh subagent on purpose. Sascha explains why a fresh context is sometimes exactly right in Context Management.
More agents don't automatically mean more structure. Often they just mean more coordination.
The workflow today: propose, apply, archive
sparc builds on OpenSpec. Every change is its own folder with a proposal, spec deltas, a design and tasks, and goes through three steps. I tell sparc about a project exactly once, during setup. After that I only describe individual features or fixes.
propose creates only planning documents, no code. The product owner writes the requirements as testable scenarios in WHEN/THEN format and records what is explicitly out of scope. If the change has a user interface, the UX designer builds static HTML mockups. The architect writes the design, records relevant decisions as ADRs and breaks the work into small tasks, each naming its verification. At the end, I read a short summary. I described how requirements mature in cycles rather than in one go in The Requirements Cycle. propose is exactly such a cycle on a small scale.
The approval was the second simplification. At first, sparc waited for a "yes" in the chat after every proposal. But I've long made the decision by the time I start the implementation. Today, running apply is the approval. If a project works with pull requests, the approval or the merge counts.
apply implements the change. The software engineer works through the tasks test-first, one commit per task. Then they check the entire diff in a code review. After that, the QA engineer proves every spec scenario with integration or end-to-end tests: the scenarios are the test plan. The product owner accepts based on this report and only checks what couldn't be automated.
archive wraps up: update specs, tick off the backlog, write the changelog, accept ADRs, sync the documentation, run the check.
A real finding from the code review
What this looks like in practice is shown by the report of the change that taught sparc to work trunk-based. Every change has a qa.md file, and its code review section looked like this:
## Code review
Reviewed: `d5eb542..64bf322` (software engineer role, `git diff main...HEAD`)
| Finding | Fix |
|---|---|
| A typo in `sparc.workflow` (for example `trunkk`) fell back to
`pull-request` without a message. | 64bf322 |
A typo in the configuration would have silently sent a project into the wrong workflow. The review found it, it was fixed in its own commit, and both are traceable in the report. Below that, the same report lists every spec scenario with its result and evidence, meaning the test and the command it was checked with. Without a code review, or with a failed scenario, there's no acceptance.
The review doesn't replace a human review. I described why code reviews need more attention with coding agents, not less, in Code Reviews in the Age of Coding Agents. But it makes sure I get a diff that has the obvious problems behind it.
Trunk or pull request
There was a course correction here too. At first, sparc required a branch and a pull request for every change. In a team that's right, because the pull request is the review. In a project I work on alone, it's effort without a reviewer: create a branch, open a PR, merge it myself. Today, sparc asks during setup: "Do you work alone or in a team?" Alone means commits directly on the main branch, in a team pull requests.
In both cases, Keep a Changelog, Semantic Versioning and Conventional Commits apply. Agents produce many changes in a short time, and without fixed conventions the history no longer tells anyone anything. sparc calculates the next version from the commit types. And because projects get outdated over time, every project stores its sparc version. The migration steps are in the breaking entries of the changelog, so an update replaces only the sparc part and leaves project rules untouched.
Takeaway: three questions before your next subagent
Subagents aren't bad in principle. But before you introduce one, three questions are worth asking, which I took away from this experience:
- Does the task really need an empty context? If the agent first reads the same files as the main session, you pay twice.
- Does the agent need to talk to you? Every question that goes through the main session costs time and loses context.
- Would a rule file be enough? A role is often just a set of instructions. The running session can follow those too.
If all three answers favor the subagent, for example for an independent check at the end, it's the right choice. Otherwise it's coordination without value.
Conclusion
The sparc workflow isn't a new process model. It's what a good team does anyway: clarify requirements, record decisions, build test-first, review, test against the requirements, accept, document, version. The difference is that I no longer have to explain it to any agent.
The most important insight of the whole series: a harness doesn't get better with more building blocks, but with fewer. Two of the most important decisions in sparc removed something, the subagents and the mandatory pull requests. Both times the harness became faster, simpler and more reliable.