AI Systems Architect Builds a "Canon" for Analysts: 17 Business Requirements Documents in 8 Days

Most stories about AI agents at work end at personal productivity: one enthusiast set up prompts, and everything flies for them. Nikolay Karpov, an AI systems architect, wrote on Habr about what happens next, when you need to deliver the same result to an entire department of analysts without making everyone take a prompt engineering course.

A Field Test Instead of a Presentation

The first real test did not happen in a sandbox. An analyst needed to hand a client a set of business requirements for a new payment product, just as the regulatory sources had been updated. By the analyst's own estimate, doing it manually would have taken more than two weeks. A minimal set of a template, roles, skills and tools was assembled on the fly, and for a week the author worked as the analyst's copilot, editing the canon right for the task.

The key takeaway: most of the time went not to generation, but to the conditions of trust. Which template to use to build a document, where to get data, how to look for conflicts, what to do when data is missing. When the agent started making things up, what helped was not only lowering the temperature to 0.2 and top-p to 0.85, but also rules for handling missing data. The parameters, incidentally, differed for other specialists: a temperature of 0.6 was enough for them. The result: 14 documents in 8 working days, later the set grew to 17, each proofread by a human and published in Confluence.

How the Canon Is Structured

The author separated four entities. A role is responsible for the boundaries of authority and for working with uncertainty. A skill describes a methodology: a Use Case, an interface and an API require different checks. A tool is a script for a repeatable operation, such as building a DOCX or validating XML. A template defines the form. Detailed instructions are loaded only when needed, so the context doesn't get clogged.

The project structure also had to be redone after feedback from colleagues. At first there were three layers: sources, drafts, artifacts. Then it turned out that a document goes through many iterations, so directories by document type appeared, with md/ and docx/ next to each other. The contract is simple: everything in working directories is a draft, even if the build succeeded. Versions accepted by the specialist go to a separate release directory.

Small Things That Decide

Digitizing sources is called the foundation: if the agent misreads a table, the error leaks into the requirements. Complex regulator tables with nested rows lost their hierarchy in a flat representation, so the rule became strict: tables only in HTML. Diagrams are converted to PlantUML, draw.io or BPMN, but checked against the original, since a syntactically correct diagram does not guarantee correct connections.

The agent registers data gaps in open-questions.md with an identifier and a status, and leaves an explicit note with a link in the document. Making up an answer is forbidden, and in the next session the agent reads the register and continues.

What to Take Away

If you are rolling out agents to a team, start not with choosing a model, but with contracts: who is responsible for what, where drafts live and where accepted work lives, how unknowns are recorded. User mistakes should be turned into edits to the canon rather than left in chat. And don't confuse an urgent setup with a permanent one: the author explicitly calls switching between models because of subscription limits a decision made under pressure, not a recommendation. The article breaks off midway, so support via messengers and memory can only be judged from the table of contents, but the foundation is already useful for those building this kind of harness.