Skip to content

Latest commit

 

History

History
21 lines (11 loc) · 4.54 KB

File metadata and controls

21 lines (11 loc) · 4.54 KB

The agents

Twenty-three specialised sub-agents work alongside the pipeline, and the reason they exist comes down to a single idea about context. The session you are talking to was in the conversation — it remembers what was said, what was meant, what was waved off. That memory is an asset when the job is to catch what was discussed but never written down. It is a liability when the job is to judge what was written down, because a participant reads a document already knowing what it was supposed to say. A sub-agent has no such memory. It reads the artifact cold, with nothing but the artifact in front of it, and that is exactly what makes its critique worth having. The orchestrating session catches what was said but not written; the fresh agent catches what was written but not right.

Every one of these agents is stateless — each time it runs it starts from nothing and is given its inputs in full — and every one hands back a short, structured result. Most write their findings to files rather than into the chat, so the conversation is not flooded. None of them touches git or changes your project's state; committing and record-keeping belong to the orchestrating session and the engine alone. The agents propose; nothing they produce becomes part of a plan or a specification without passing through a gate you control.

They divide naturally by when in the work they act.

While you converse. Behind a live research or discussion session, background critics read the growing document with clean eyes and look for what is missing — coverage gaps, shallow spots, assumptions taken on faith. A researcher can be sent off to investigate a single thread in real depth while the conversation carries on. And when a decision has two genuinely competing answers, a pair of them argue it from deliberately opposing viewpoints, after which another reconciles the two into a map of the real trade-offs. Their findings never dump on you all at once; they surface one at a time, as questions, when you are ready for them.

When a document must be validated. As a specification or a plan nears completion, agents check it in a strict sequence — one finds what was missed or distorted coming in from the sources, the next reads the finished document as its future consumers will, and because they run in order, the second is always reviewing the corrected version rather than the original. A bugfix's root cause gets the same treatment: an independent agent re-traces the code from scratch to confirm the diagnosis holds.

While the plan is built. The plan is not drafted in one pass by one mind. One agent designs the phase structure from the specification, another breaks a phase into a task list, another writes the full detail of those tasks, and another works out the dependencies and ordering across the whole plan — each doing one job well, with you approving between them.

While the code is written. Each task in the implementation loop is handled by a pair: an executor that writes the code test-first, and an independent reviewer — which did not write that code — that checks it against the specification and the task's acceptance criteria. The reviewer's verdict is what drives the fix loop.

After the code exists. Once the tasks are built, a set of examiners looks back over the whole result from different angles — architecture, duplication, standards conformance — and a synthesiser turns their overlapping findings into a clean list of remediation tasks for you to approve. In the final review, verifiers check the completed tasks against what was agreed, working in parallel, and another agent turns the review's findings into remediation work.

The common shape

Read across all of them and the same discipline repeats. Their inputs are always explicit — the exact material to work from, handed over in full, never a vague "everything we've discussed so far" — which is what lets a stateless agent do a reliable job. Their outputs are always structured, so the orchestrator can act on them without guessing. Each is given only the capabilities its job actually needs and no more. And every point where judgment is exercised stays with the orchestrating session and with you: the agents surface, propose, and argue, but the decisions, and the commits that record them, are never theirs to make. That is the whole arrangement in one line — a workforce of fresh, narrow experts that produce findings, feeding a single conversation that decides what to do with them.