Agentic Requirements Engineering

Agentic coding tools now write and ship code faster than most teams can decide what that code should actually do. Tickets get closed faster than they get written. The bottleneck moved to requirements engineering, the one part of the process nobody has figured out how to blind-accelerate, because it's the part where the actual hard work happens: figuring out what's true, what's agreed, what's still open.

You can't fix that by making RE faster the same way coding got faster. Throwing more autonomous agents at RE activities doesn't touch why the work is hard in the first place. The more interesting question is what it would take to build Agentic Requirements Engineering: not just an LLM doing RE tasks one at a time, but a system that keeps a project's understanding of its own domain intact across all of it’s activities, the way an experienced practitioner does.

That's where the IREB AI4RE Prompt Guide turns out to be a surprisingly good starting point, not because it was built with this in mind, but because of a small design choice that matters more than it looks like at first.

What the AI4RE Prompt Guide is, and what it gives you

IREB's AI4RE syllabus organizes AI support in requirements engineering around four activities: elicitation, documentation, validation, and management. The Prompt Guide that goes with it is a growing set of prompt templates, one cluster per activity, meant for a practitioner to pick up and use directly: draft interview questions during elicitation, turn workshop notes into a structured spec during documentation, check two requirements for contradictions during validation.

Nothing about any of this is sequential. You don't have to finish elicitation before you touch documentation, and a validation session can send you straight back to elicitation if it surfaces a question nobody asked. IREB doesn't pretend otherwise: the four activities are described as things a requirements engineer does, revisited as often as the project needs, not stations on a conveyor belt.

Why free access is the interesting part

Here's what that non-sequential structure sets up, whether or not it was designed with this in mind: four activities you can reach in any order are four equally available sources of input about the same domain. That's a different property than "four steps you complete in sequence," and it matters for a very specific reason. It's the property something needs before you can build a system around it that doesn't work through a queue: a system that can react to its own internal state and to external triggers, carry out state changes on its own, and work continuously across all four activities.

The layer underneath, in five parts

Move from "four inputs" to "a system that actually uses them together," and you run straight into what the 2026 conversation around AI has started calling context engineering: the layer below prompting that decides what a model actually knows at the moment it's asked to do something. It breaks down into five recognizable parts.

Sources. Four activities, four different jobs on the same domain: elicitation generates new information, documentation formats and prepares it for whoever has to read it next, validation checks it against what's already agreed, and management tracks what changed and why. None of the four is more authoritative than the others.

Memory. Not one growing document, but individual entries with two things attached: where they came from, and how settled they are. A decision from Tuesday's workshop that three stakeholders agreed on is a different kind of fact than a guess someone typed into a spec on their own. A recent proposal for tracking architectural decisions makes exactly this case: that AI-assisted engineering should record not just what was decided, but its epistemic status and how long it stays valid. "Agreed" and "assumed" are not the same kind of memory, and treating them as the same kind is where a lot of these systems quietly go wrong.

Retrieval. Not a step anyone has to trigger by hand. If the four activities are all writing into the same memory, then whichever activity runs next queries that memory for whatever bears on the task in front of it - this decision, that ambiguous term, a stakeholder's earlier statement - instead of starting from a blank page. Retrieval, done right, isn't a step someone bolts on afterward. It's what makes shared memory usable instead of just accumulated.

Structured outputs. Each activity needs to produce more than its own artifact. A validation check that finds an ambiguous term shouldn't just flag it. It should hand back a definition the other three can use, not a paragraph of prose they'd have to re-interpret each time (a boundary that turns a model's raw, differently-worded output into something a team has actually agreed on).

Feedback loops. The part that makes the other four worth building. When validation finds that "active" meant three different things to three different people, that correction needs to update shared memory, not just the validation report. Without this, four activities reading from a common store but never writing a correction back into it quietly becomes the same problem as not having shared memory at all.

RAG, then an Agent, and why we stop there

Solid arrows are where we're building. The dashed line is a deliberate stop, not a gap we haven't gotten to yet. Read this as a maturity comparison, not a fixed build order - RAG and agents are components you combine, not strict prerequisites for one another.

It's worth naming what's actually being built here in the vocabulary the rest of the AI world already uses. Domain Knowledge and Constitutions are RAG (retrieval-augmented generation), built for requirements engineering instead of generic document search; the five parts above are what a domain-specific RAG layer needs that a generic one doesn't. On top of that sits the AI Agent, in the strict sense: it plans, it uses tools, it produces artifacts, it runs part of a workflow, and it doesn't just fetch information and hand it back.

There's a stage past that worth naming, even though we're not aiming at it: Agentic AI, where multiple agents coordinate autonomously toward a goal with minimal human involvement. It's easy to picture what it would look like here. Documentation revises what "active" means. Something notices, on its own, that a validation check from last week is now wrong, and re-runs it, without anyone deciding to.

We don't think that's where RE should go. Requirements engineering's job is to surface disagreement and half-settled decisions so people can resolve them, not to resolve them autonomously on a project's behalf. An agent that decides for itself what "active" means isn't removing the bottleneck. It's hiding one, exactly where being wrong is most expensive and least visible. That may well be the same blind spot a lot of Spec-Driven Development (SDD) tools share, too. Coding tolerates autonomy well because a bad autonomous decision usually shows up faster and more visibly, as a failing test. A bad autonomous decision about what a requirement means can sit quiet for months.

There's still real autonomy to build at the AI Agent stage, short of that line. Take a change request: a policy's entry age changes, a household requirement drops. That's not a note to file. It's a change that has to ripple through everything downstream that depended on the old definition. Reading the change, working out what it touches, and flagging the affected pieces is a natural job for an agent. That's quite helpful, but not a step toward Agentic AI.

This is how Speclr does it

In our own AI Requirements Engineering tool Speclr we started with another dimension, closer to project management than to requirements engineering. A pipeline of PM activities: Discovery, Exploration, Planning, Refinement. This might look very familiar. Discovery is where a product idea gets pitched, Exploration is where a user journey takes shape, Planning is where that becomes milestones, and Refinement works out the user story in detail. RE, in IREB's sense, mostly lives one level down, at the user-story level, which means it doesn't map onto our four stages one at a time. It cuts across them.

Elicitation happens twice, at Discovery and again at Refinement. Refinement does four things in one pass. Planning schedules work. It isn't Management in IREB's sense. Management cuts across all stages.

Elicitation isn't a single stage for us: it happens at Discovery, when a product idea first takes shape, and again at Refinement, when a specific story gets worked into something implementable. Refinement does more in that one pass: it also validates what's being said against what's already agreed, documents the result in a form the rest of the pipeline can use, and tracks what changed about the story and why. Perspective Agents carry validation on their own, wherever they're invoked, separate from any single stage. And Planning, the stage that sounds closest to IREB's "management," isn't that at all. It schedules work. It doesn't track what changed about a requirement or why beyond a single story. That's a Change Agent's job.

The RAG layer that holds it all together, and the agents that act on it without pretending to decide things they shouldn't, are the real frontier, and they're not specific to us. Coding didn't get fast because someone made typing faster. It got fast because the tools started holding context between one step and the next, and because being wrong there is cheap and visible. Requirements engineering gets neither of those for free. That's why the honest version of this is slower to build than the coding version was, and why skipping straight to full autonomy would solve the wrong problem.

Speclr's Domain Knowledge and Constitution building blocks are our ongoing attempt to build that layer - feedback loops included, since that's the part most systems quietly skip. Not a finished answer, but a fellow researcher on the same question.

Further Reading

Requirements Engineering for modern Software-Teams

IREB's four AI4RE activities are the starting point of this article. This course covers them from the ground up, AI-assisted and IREB-aligned.

View the course