From pitch to proof in two weeks: 90× faster requirements generation.

Documentation was gating a high-stakes migration.

A major platform migration programme had dozens of epics in flight across Product, Business Analysis, Architecture, and Solution Design. The delivery cycle was sequential: teams could not start building until requirements, architecture, and solution design documents were written and signed off. Manual documentation was the bottleneck, and it was getting worse as the programme scaled.

The root cause was not writing speed alone. It was knowledge fragmentation. Context lived across Confluence, Word, PowerPoint, Excel, and people's heads. Collecting it to inform a single document was time-consuming. AI tools like Cursor were already licensed, but without structured context to draw from, trust in AI accuracy stayed low. Prompting was tedious, there was no reusable process, and the learning curve added friction on top.

I pitched the value before I had the product.

The migration programme needed a reason to believe before they would commit time. I built a proposal site and presentation framing the problem, the approach, and the projected ROI. The pitch came first. The working system came two weeks later.

Everything in this section is projected, not measured. I was explicit about that with stakeholders. These were the numbers I used to secure attention and sign-off on the plan.

Nine features that addressed every objection.

The pitch did not sell AI magic. It sold reliability: easy contribution, team-customised templates, accuracy targeted at 70–80% with mandatory human review, built for speed, reusable across domains, low maintenance, no prompt engineering, human-in-the-loop at every gate, and a system that improves with use.

Two weeks. Solo build. Then cross-functional rollout.

With no engineering support and no architect time allocated for the initial build, I defined and shipped the entire Agentic Document Generator myself: the agent definitions, the slash commands, the distillation pipeline, the team templates, the 10 validation gates, the adversarial review pass, and the staging output workflow. Two weeks from pitch to a demo-ready system running on real migration content.

Rollout was never solo. From reviews and demos onward, I worked with an Enablement Manager, a principal engineer, a senior delivery manager, an agile coach, and a senior engineer, presenting to business executives and securing approval to expand across the programme.

The constraint was the design brief. If the system only worked when a technical champion was in the room, it would never scale across a 1,000-person domain. Every command had to be self-explanatory. Every output had to ship with lineage. Every draft had to arrive with a human review checklist, not a black box.

ADG: an agentic system built on governed context.

The Agentic Document Generator is a product within the bank's intelligence ecosystem (PIE). It consumes the Context Library I built as part of The Context Lifecycle, customised for the migration programme's Confluence sources, asset team templates, and sub-domain blueprints.

Four agents. Four lifecycle phases. One command each.

What was in the library at demo time

Each distillation carries a title, body, source link, classification, tags, and lineage. The system retrieves by relevance. The document cites every source. When a BA reviews a generated doc and notices a gap, that correction feeds the learning loop. The library improves with use.

Responsible AI: evals baked into every run

Enterprise documentation cannot ship on blind trust. ADG treats responsible AI as workflow design, not a policy slide: human-in-the-loop gates, automated validation, and agent self-critique before a human ever opens the draft.

The demo did the selling. Not the slides.

I ran a live demo on real migration content: a BA types /create-requirements, the author agent asks a few questions, loads team settings and library context, and produces a full requirements draft with citations, a Confluence preview, a lineage file, and a HITL review report. Under two minutes. Citation-grounded. Ready for human review, not blind trust.

The Generation workflow: seven steps from a single slash command to five staged output files, with human confirmation in the middle and a mandatory review gate at the end.

Measured results: four methods compared

After the demo, I ran a structured analysis comparing four approaches to generating the same requirements document on a live migration epic. This is where projected becomes measured.

Measured on a live epic. Method 0 (ADG: PRP cascade + Context Library) completed in ~19 minutes with low quality risk. A human BA took 27 to 40 hours. Raw prompting without the library was faster than a human but carried high hallucination risk and used 2 to 4× more tokens.

What the output looked like

On a live migration epic (RS-WSS-001), a single /create-requirements run produced a staged requirements draft, session brief, lineage file, and HITL review notes. The draft included 16 functional requirements, 12 NFRs, and 23 source citations. Overall confidence: medium-high, with explicit gaps flagged for human validation.

Every run ships five files. The HITL panel is the proof layer: author self-review, 10 validation gates, adversarial pass results, and a BA checklist before PO sign-off. Not perfect. Not autonomous.

The skeptics became contributors. Then the programme adopted.

The architects and engineers who did not give me their time during the pitch were at the demo. After seeing a citation-grounded requirements draft generated from their own migration content in under two minutes, the conversation changed. They wanted in: to help refine the system, customise templates for their domains, and start using it themselves.

That conversion unlocked production rollout. The migration programme now has 11 active users (6 BAs, 5 POs) at 100% adoption, generating requirements docs and PO briefs in daily use, with architecture doc templates scaling to architects next.

Business impact (early)

Dollar ROI is still being measured; this is a new production rollout. Early projected FTE savings from the pitch remain the working estimate: ~7.1 hours saved per person per week across drafting and information gathering, and 66 days of capacity recovered on requirements alone across 22 in-flight epics. I was explicit with stakeholders that these were projections at pitch time; adoption metrics are now measured, dollar impact is next.

Cross-functional team

I defined and built the system in the first two weeks. Scaling it required a team. I led rollout alongside:

What changed

Persona by persona. Doc type by doc type.

ADG did not launch to everyone at once. The roadmap expands by persona and document type: requirements for BAs first, PO briefs next, architecture docs for architects now scaling, then solution design and UX, then a self-serve onboarding pipeline for asset teams across the domain.

100% adoption for POs and BAs landed at W4 (11/11 active). We are now in Pilot Beta, scaling architecture doc templates to architects. Next: solution designers, then self-serve onboarding for asset teams.

Pitch the promise. Ship the proof. Let the demo convert.

The ADG story is really two stories stacked: a platform story (The Context Lifecycle) and a product story (ADG). The platform gives you governed context. The product turns that context into documents people actually sign off on. Neither works without the other, and having both is what makes this credible as an AI product narrative, not just an infrastructure experiment.

What I learned: skeptical technical stakeholders do not convert on projections, no matter how well-framed. They convert when you show them their own content, cited correctly, in a format they recognise, with a review checklist they would have written themselves. The two-week solo build was not a compromise. It was the strategy. Speed forced focus. Focus produced a demo that sold faster than any slide deck.

What I'd do differently: I would still pitch first (the projections secured the mandate), but I would loop one friendly BA into the build earlier, even without architect time. A co-builder during week one would have surfaced template gaps before the demo, not after it.