Habr AI shows how to prepare structured input for an AI agent instead of a raw spec

Habr AI has published a detailed breakdown of what exactly an AI agent should receive as input when the task is to check technical requirements rather than just summarize them. The core idea: instead of the full spec, the agent gets a set of atomic requirements in the form of JSON passports.

Why a single spec isn't enough

The author starts with a problem familiar to almost anyone who has tried handing a large document to a neural network in one go. When a model receives a multi-page spec without any preprocessing, it loses focus, mixes up requirements from different sections and produces overly generic comments. The system may spot individual inaccuracies, but it struggles to explain which item is flawed, why, and what needs fixing.

So the document is first cut into individual requirements: one action, one rule or one constraint per fragment. To avoid losing context in the process, each element gets fields such as `parent_section` and `parent_object`, and logically related items are marked as `linked`. This matters when several requirements must be checked together — for example, when the system has to send a notification both by email and to Telegram, not just to one of the two channels.

The requirement passport

The next step turns a human-written statement into a set of features a classifier can work with. In this scheme, the LLM is not the final judge and doesn't try to "understand everything." Its role is much narrower: it pulls structured signals out of the text and packs them into JSON. That gives the team control: features can be checked, compared and, if needed, corrected in post-processing. As the author puts it,

"the agent works not with text, but with structures like these."

The article describes six basic features that the passport rests on. Instead of an abstract quality score, the model looks for concrete signals: numbers, vague words, exceptions, boundaries and explicit actors in the scenario. In practice, the passport turns a phrase like "the user should be able to flexibly configure the report" into a clear set of flags that immediately show what the requirement is missing. This interpretability is what sets the scheme apart from simply asking a model to rate the text as a whole.

• `has_numbers` — whether the requirement contains numbers, limits, dates and other concrete parameters
• `stopword_score` — how vague the wording is because of words like "flexibly," "conveniently" or "quickly"
• `has_negative_keywords` — whether exceptions and errors are described
• `boundary_conditions_mentioned` — whether empty values, maximums, minimums or other boundaries are specified
• `actor_count` — how many actors explicitly appear in the requirement

The features are extracted using JSON mode and few-shot examples to keep the model from drifting off format. If the LLM still misses something obvious, such as numbers in the text, regular expressions in post-processing fill the gap. A decision tree then takes the numeric features and assigns the requirement a label such as `ok`, `unverifiable`, `no_negative`, `no_boundary` or `ambiguity`. For training, the author annotated 90 specs, split them into 270 requirements and reached roughly 82% accuracy on the test set.

The critic and scaling

The pipeline doesn't stop there. Even a good classifier sees only one requirement at a time, so it can easily miss contradictions between sections. For those cases, a separate critic agent receives the full spec text, the list of JSON passports and the predicted labels. Its job is not to re-evaluate every sentence but to look at the document from above and hunt for conflicts, gaps in access permissions and errors in integration mapping. Such a critic might notice, for example, that the "Warehouse" field is mandatory in one place but allowed to be empty in another.

To make the scheme work beyond short examples, requirements are processed in parallel via `ThreadPoolExecutor`, and local models run in Ollama. The author writes that on an ordinary gaming PC the system comfortably handles 4–6 parallel requests without noticeable degradation, and on a batch of a hundred requirements this yields a speedup of roughly 3–4x. Linked requirements stay in the same thread so the order and shared context of the check remain intact.

What it means

The Habr AI write-up neatly shows where practical AI agent development is heading: away from attempts to "feed the model everything at once" and toward narrow, controlled pipelines with explicit features, local models and a separate arbitration layer. A team that wants to build an applied agent for analytics, QA or documentation work will have to think not only about which model to pick, but also about how the input data, annotation and final verification of results are structured.