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 wikis, shared drives, slide decks, spreadsheets, 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.
Sequential delivery: blocked on documents
Requirements gathering, architecture, and solution design had to complete before engineering could proceed. Every epic waited on documents that took days to produce from scattered sources.
AI without grounding fails at enterprise scale
Raw prompting over unstructured documents produced hallucinations, no lineage, and no constraints. Teams tried Cursor, hit the same wall, and went back to manual work.
The platform existed. The consuming product did not.
I had already built the Context Lifecycle and its underlying library infrastructure. What the migration programme needed was a product on top of it: a system that turned governed context into signed-off SDLC documents, on demand.
Cursor can accelerate documentation, but only when it has structured context to draw from. Solve fragmentation, and the rest follows. ADG is the consuming application. The Context Lifecycle is the framework underneath it.
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.
Technically feasible
Built on existing GitHub Enterprise infrastructure. No new platforms to provision. Foundation used proven internal sync scripts. No autonomous agents, no external services: stayed within enterprise AI guardrails.
Adoptable (90%+ expected)
Technical users get native Cursor commands that feel like an acceleration of their existing workflow. Non-technical users get a web interface and natural-language chat. No terminal required. A citation-grounded draft in under two minutes was designed to sell the tool faster than any training session.
The architects and engineers in the room were skeptical. They did not commit time to the build. I would have to prove it alone.
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 domain of thousands of staff. 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 wiki sources, asset team templates, and sub-domain blueprints.
Four agents. Four lifecycle phases. One command each.
Collector · Collection · /collect
Reads from external sources (wikis, shared drives), converts to machine-readable context files, and places them in the team's sub-domain repo.
Librarian · Processing · /process
Validates structure, classifies content, builds relationships, and creates search indexes. Raw pages become governed distillations.
Researcher · Retrieval
When a document is requested, searches the library scoped to the product, ranks by relevance with citations, and presents context for review.
Author · Generation · /create-requirements · /go-live
Structures output using team templates, applies validation criteria, stages for review, then stamps with reviewer name and date on go-live.
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.
10 automated validation gates
Every generation run passes schema, source-integrity, template, citation, and completeness checks. On a live migration epic: 8 pass · 1 warn · 1 fail. Gate 1 (source-integrity) flagged a missing asset file for BA review before PO sign-off. The retrieval-side "20 high-relevance" check is a RAG coverage metric (fused BM25 + vector), a coarse proxy for context recall, being upgraded with sensitivity tags (PII, payments, auth, consent, reg-risk) that escalate to SME review regardless of hit count.
Author agent self-review
Before staging, the author agent produces a review report: overall confidence rating, what it included, and what it doubts. It flags thin NFR coverage and gaps the BA must validate, not hide.
Judge agent: adversarial eval
The Judge challenges the draft before staging, integrated into platform workflows. Default: 1–2 adversarial passes; a third only when remediating blocking findings. Output classified blocking / medium / low (contradictions, ambiguity, cosmetic), as Q&A with options and recommendations, not a wall of critique.
Mandatory HITL + Human Reviewer Handoff
Every draft ships with a HITL review report: gate summary, confidence rating, BA checklist, and lineage back to library sources. Shipping next: a Human Reviewer Handoff block at the top of every output: what AI validated, what needs human eyes, likely challenges, known gaps, plus stable section anchors and section-level feedback for large HTML reviews.
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 staging preview, a session brief, a lineage.json, 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 files in outputs/staging/, with human confirmation in the middle and a mandatory review gate at the end.
Five files. Two observability artifacts.
Every ADG run ships a bundle, not a single document. Two files do different observability jobs:
Session brief: what happened in the run
Records the session: blueprint version, feature scope, goal, scope confirmed with the user, output destination, and timestamps. This is the operational record of the run, the same signal that feeds the Context Library reporting pipeline and aggregates into the platform operator dashboard, so I (and my Cursor agent) can observe patterns across Collection, Processing, Retrieval, and Generation.
lineage.json, how RAG context was handled
After the Researcher retrieves governed context from the Context Library, the Author writes a structured trace of which distillations and source links fed which sections of the draft: context hashes, loaded contexts, blast-radius scope, and a section-by-section source map. On the live migration epic: 23 source citations mapped section-by-section. Raw prompting (Method 2 in the results analysis) had no lineage; ADG (Method 0) was validated, cited, and auditable before PO sign-off.
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, low quality risk, validated, cited, auditable with lineage.json. A human BA took 27 to 40 hours. Raw prompting without the library was faster than a human but carried high hallucination risk, no lineage, and used 2 to 4× more tokens.
Three layers stack to create the speed: clean distillations with schema (eliminates source noise), pre-configured templates (eliminates formatting guesswork), and automated validation gates (eliminates manual QA cycles). Remove any one layer and speed drops sharply.
Inference economics (measured): bulk library build consumed ~30–50k tokens per document end-to-end (1,609 raw files · 4.6 GB → 1,331 distillations). Recurring Author sessions run ~80–250k tokens. Method 0 on the same epic: ~600–800k total vs Method 2 raw prompting ~1.5–2.5M with no lineage. Per-phase token logging is being added to the platform observability feed.
What the output looked like
On a live migration epic, a single /create-requirements run produced a staged requirements draft, session brief, lineage.json, 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.
Session brief and lineage.json are separate files with separate jobs: the brief records what happened in the run (and feeds platform reporting); lineage records how governed RAG context was retrieved and mapped. The HITL panel is the eval layer before sign-off.
Architect review drove the next platform increment.
After the demo converted skeptics, a principal architect sent the questions that separate a demo from an enterprise platform: gate semantics, adversarial eval economics, human review at scale, enterprise architecture fit, and end-to-end token cost. I responded with concrete product decisions, the same week.
Eval squad formalised
PIE-ADG now runs a multi-agent eval crew (SME, QA, Judge, Senior Reviewer) alongside lifecycle agents (Collector, Librarian, Researcher, Author). Judge adversarial passes are cost-bounded: two by default, a third only when blocking findings need remediation.
Human review at scale
Stable section anchors, a Human Reviewer Handoff block at the top of every output (what AI validated, what needs human eyes, known gaps), and section-level feedback compiling into structured correction data for the session brief and observability feed.
Observability upgraded
Session briefs feed the Context Library reporting pipeline; lineage.json traces RAG handling separately. Next demo adds per-phase token logging and per-output cycle tracking (generation → correction cycles → ship-ready) so Method 3's true end-to-end cost is measurable, not just first-draft speed.
Full platform context (lifecycle observability, drift handling, sensitivity-tag roadmap) on the PEB Intelligence Ecosystem case study.
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 a pilot group of BAs and 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:
Manager
Programme sponsorship
Co-presenting to executives and teams, securing approval to expand ADG across the migration programme and into adjacent asset teams.
Engineer
Architecture review
Technical partner for agent workflow design, validation gate criteria, and enterprise integration with the Context Library.
Delivery Mgr
Delivery alignment
Aligning ADG rollout with migration programme milestones, epic cadence, and sign-off workflows across BA and PO cohorts.
Coach
Adoption and change
Co-designing how BAs and POs integrate ADG into existing ceremonies, template customisation, and feedback loops.
Engineer
Demo and review
Review partner for agent definitions, slash commands, and staging workflow before each programme demo and rollout gate.
What changed
| Before | After |
|---|---|
| Requirements docs taking 14+ days from kickoff to sign-off | First draft generated in ~19 minutes, with human review gate before sign-off |
| Context scattered across wikis, shared drives, slide decks, spreadsheets | 1,331 governed distillations, searchable, classified, with source lineage |
| AI prompting: tedious, repetitive, high hallucination risk | Single slash command, template-driven, citation-traced, validation-gated |
| Architects and engineers skeptical, no time allocated | Executive approval secured; architects scaling in for architecture doc templates |
| Requirements and PO briefs only, manual workflow | Requirements + PO briefs live; architecture docs scaling; onboarding pipeline for next teams |
| Context Lifecycle: platform with no consuming product | First Generation-phase proof point: context in, signed-off SDLC documents out |
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 the BA and PO pilot group landed at W4. We are now in Pilot Beta, scaling architecture doc templates to architects. Next: solution designers, then self-serve onboarding for asset teams.
The pace-setter is trust, not ship dates. Each phase proves one persona and doc type on real programme content before the next cohort onboarded. That is how you get 100% adoption instead of a launch announcement nobody uses.
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.
Two weeks to demo. Pilot group at 100% adoption. 10 validation gates on every run. ~19 minutes vs 27 to 40 hours. The architects who said no became the team scaling it forward.