Five ways to tell an agent what to build

Last time I argued that the hard part of software has moved: producing code is cheap, knowing exactly what should exist is not. So where do people keep that knowledge today, and what does an agent get out of it? I count five families of tools. Each is good at something, and each stops somewhere.

Requirements systems (DOORS Next, Jama). Every requirement has an id, a status and a trace to tests. This is where regulated industries have lived for decades, and in 2026 the vendors opened the door to agents: Jama’s MCP server feeds approved requirements into the IDE and writes a trace link back when the work is done. Where it stops: the model lives in a separate system from the code, and it still describes what should be, never what the running system did.

Trackers and wikis (Jira, Confluence, Notion). The most common home for requirements, and agents can now be assigned a ticket. Where it stops: a ticket describes a change. Close it and the knowledge is gone; the system as it is now is nowhere written down.

Instruction files (AGENTS.md, CLAUDE.md). A plain text file the agent reads before it starts, in more than 60,000 open-source projects. Simple and portable. Where it stops: it is prose with no structure, and it grows. An ETH Zurich study this February found that files generated by a model lowered task success by about 3% while raising cost by over 20%; files written by developers helped by about 4%, at up to 19% more cost. The agent follows the file; the file just does not know enough.

Spec-driven kits (Spec Kit, Kiro, OpenSpec). The spec comes before the code: requirements, design, tasks, then implementation. This is the right order, and OpenSpec even keeps a folder that is meant to stay the current truth after each change is archived. Where it stops: the spec is a plan for one feature. Nothing ties it to the code that actually runs, acceptance is a checklist the same agent ticks, and once the feature ships the spec starts to age.

Agent memory (Mem0, Hindsight, Zep). The newest family: the agent remembers what was said across sessions, and benchmarks reward it for recalling the right fact. Where it stops: memory of a conversation is not a description of a system. Nothing in it has a status, a test or a link to code.

Put the five against five questions an agent needs answered: a stable id for one requirement; a description of the system as it is, not a change; a link to the code in both directions; acceptance that can be executed; and knowledge of what the system actually did. The chart is my honest reading. No family answers the last question, and only the oldest one answers the first two well.

Matrix of five tool families against five questions an agent needs answered: a stable id for one requirement, describes the system as it is, linked to the code both ways, acceptance that can be executed, knows what the system actually did. Requirements systems: yes, yes, partly, partly, no. Trackers and wikis: yes, no, partly, partly, no. Agent instruction files: no, partly, no, no, no. Spec-driven kits: partly, partly, partly, partly, no. Agent memory: no, no, no, no, partly. — Five tool families against five questions an agent needs answered. Author's assessment from each tool's current documentation, October 2026. Chart by the author.

That gap is where we started building. The next post will be about the first decision we made.

Five ways to tell an agent what to build, and where each one stops