The Requirements Pipeline AI Development Has Been Missing

What does a good requirement look like when the reader is an agent?

The instinct is to write more. More detail, more precision, more edge cases covered. I tried that early on, and it helped, but it wasn't enough. The problem is structural. A verbose point specification still converges on a single solution. The agent presses toward that solution. Anything the spec didn't address is a gap the agent fills without asking.

We've been writing requirements for humans for decades. Humans tolerate ambiguity. They infer. They go find someone to ask. The gap between what the spec says and what gets built gets bridged by conversation, by experience, by good judgment in the moment. Remove the human from that loop, and the gap is still there. The agent just fills it with whatever the training data suggested.

When More Detail Isn't Enough

In Lean Product Development, we solved a version of this problem with set-based design. Instead of handing a design team a point solution specification, you hand them a constraint space. What the solution must do. What it must not do. Where the hard limits are. Explore within them.

An AI coding agent is a design team of one, running at machine speed. The same principle applies. A requirement that works for an agent describes the space the solution must live in. It defines what behavior is required under which conditions, what behavior is prohibited, and what specific outcome applies to a given edge case. The rest is implementation.

A user story frames it differently. As a user, I want X so that Y. In the hands of a skilled developer, that's fine. The developer asks questions, reads adjacent code, uses judgment. The agent converges. A user story just doesn't constrain an agent enough to be safe.

The Agent Constitution

Early in building the requirements pipeline I work with now, I was writing the first behavioral specification for one of the agents in the system. Trying to define what the agent was and wasn't allowed to do, what it had to check before acting, and what it had to hand off when it couldn't proceed on its own. Halfway through, I realized I was writing a set-based constraint document. Same structure I'd used in Lean Product Development, twenty-plus years prior, in a completely different context.

In Lean, it's the chief engineer's concept. In agentic development, we're starting to call it an Agent Constitution. Different name. Same idea.

Inside the Pipeline

What that looks like at scale is a pipeline with distinct phases, each with its own agent set and purpose.

The first phase runs before elicitation. An agent analyzes the raw problem statement and surfaces gaps before requirements are gathered. What is still unknown? Where is the scope ambiguous? The goal is to flag what needs to be answered before the conversation happens, not after.

The second phase takes the post-elicitation artifacts (meeting notes, transcripts, screenshots) alongside the carried gaps from phase one. A triage agent normalizes those inputs into a single context. Then two agents work as an adversarial pair. One makes the affirmative case. The requirement is complete. The carried gaps are resolved. The acceptance criteria are testable. The other challenges it. It steelmans the affirmative argument first, then attacks its strongest claim. Its job is to argue.

Synthesis adjudicates. It reads the confrontation, decides which objections are build-blocking and which are theoretical, and derives a confidence score by reasoning from what was actually disputed. Below threshold, the system stops and asks. Clarifying questions surface, ordered by priority, each one targeted at a specific gap, carrying the reason it matters.

And no gap that enters the pipeline can vanish between phases. Each one must be explicitly resolved or explicitly carried forward. A gap that disappeared without resolution is a defect, caught by the orchestrator independently of any agent.

The Chain

That is the chain. Requirement to constitution to agent to output to verification. Each link traceable. In a regulated environment, that chain isn't optional. It's what allows the system to be audited. And a system that can't be audited doesn't go to production.

The Lean practitioner recognizes this chain. It's standard work. You define it so you can measure it. You measure it so you can improve it.

Who Closes the Gap

The community that knows how to build this already exists. Requirements engineers, Lean practitioners, systems architects who've spent careers thinking about how to specify intent in a way that survives ambiguity, handoffs, and time. The AI development world has the tools. Those tools still need people who know how to write the specifications they can actually use.

The artifact has changed. The community was already there. And the people who understand both are rare right now. That gap is closing. The ones closing it fastest are the ones who already knew both sides.

The emerging discipline is the translation layer. Requirements rigorous enough for a system to enforce, written by people who understand both what they mean and how agents fail.

Three questions for your team

• What would it look like to define the constraint space your agents operate in, rather than the solution you want them to build?

• If you have an Agent Constitution today, written or unwritten, what does it actually say? And who enforces it?

• What's the gap between the requirement you're handing your agent and the behavior you're expecting from it?

If you're building agentic systems and need the specifications and controls to match, Source Allies helps engineering organizations build that discipline from the ground up.