Three problems. One structural gap. One week to act.
Give 230 designers AI tools and output multiplies overnight. Give them no shared infrastructure and that output has nowhere to land. It scatters across personal repos, chat threads, and inboxes faster than anyone can govern it. This is the paradox most organisations are walking into right now: AI makes a team more productive and less coordinated at the same time. The failure isn't the tool. It's the missing layer underneath it.
Three problems looked unrelated to everyone else. They were symptoms of one structural gap. Naming it as a single systemic failure, rather than three complaints, is what made it solvable.
No single source of truth for design intelligence
Research, insights, and team output were scattered across SharePoint, Confluence, Teams, Figma, and personal folders. Product, BAs, and engineering leads had no way to pull live design context without hunting across five tools, so the same questions were asked, and the same research duplicated, quarter after quarter.
AI outputs had nowhere to go, creating governance exposure
With every designer on a Cursor licence, AI-generated output exploded (prototypes, tools, research pages) and ended up in personal repos and chat threads outside approved channels. Good Cursor commands were passed around informally, with no library, no attribution, no reuse.
Designers needed AI for high-friction tasks but had no structured access
Nobody was asking AI to replace design thinking. They wanted it to clear the path so they could spend more time on work that moves the needle. The demand was unambiguous. The infrastructure to answer it did not exist.
The instinct at this point is to build. I polled first, because assumptions about where AI helps a team are usually wrong. Leadership imagines the glamorous use cases; practitioners just want the friction lifted off the boring ones. The honest answer clustered around two categories: quality-assurance tasks where AI acts as a first-pass checker, and speed-to-explore tasks where it shortens the distance from idea to something shareable.
This is not an AI problem. It is an infrastructure problem. AI tools make it worse before they make it better: more output than ever, with no shared home, no governance layer, and no audit trail.
The pitch nobody asked for. The mandate secured in a day.
Mandates are rarely granted. They're recognised, usually sitting inside a problem someone else hasn't solved yet. The DesignOps Principal responsible for the organisation's GitHub Enterprise had been handed a new org with no governance strategy and no adoption model for it. That gap was the opening, and I moved on it the same day.
"I got this GitHub now, and I am still figuring out how to set it up."
DesignOps PrincipalI drafted and presented a proposal the same day. One repository per design chapter, GitHub Pages for zero-infrastructure publishing, and a central Intelligence Hub to aggregate everything into an org-wide view. Designers would never touch a terminal. The system would handle everything through natural language commands in Cursor.
I was granted org owner rights the same day. By day five, I had a live proof of concept on GitHub Pages: demo-ready, running without a single developer, a single line of manually written code, or a single infrastructure dependency. Pure AI-first development. Idea to shipped internal SaaS in five days.
The architecture: three layers, one command, zero overhead.
I designed the system to solve all three problems simultaneously and to do it invisibly, with no added workflow burden on the people using it. That constraint was not a limitation. It was the design brief.
The designer
They create output in Cursor and say "publish this." One command handles everything (WCAG 2.2 and design-token checks, metadata, correct folder placement, commit, push), and the page is live on a permanent, shareable URL before they close their laptop. Governance runs at the point of creation, not after review.
The team repo
A single sync command scrapes every published page, extracts structured metadata from tags and git history, and regenerates the dashboard that powers the team hub. No manual data entry, no reporting cycles.
The central hub
The org-level hub aggregates every chapter's data plus external sources (research library, people directory) into one view across all 10 chapters. Product, engineering, and execs pull live prototypes, journeys, and research directly, with no design handoff.
Three-layer intelligence flow: designer publish command, team hub sync, central org-wide Intelligence Hub. Every layer runs from a single natural language instruction in Cursor.
The designer never touches git, terminal, or config files. They work in Cursor, say "publish", and it is live. The governance layer runs invisibly. The intelligence layer builds itself. The system is designed to disappear.
Adoption is won at the least technical person in the room.
Technical architecture is the easy half. Adoption is where most internal tools quietly die: shipped, announced, then ignored. The harder problem here was a 100% onboarding rate across designers with wildly varying technical confidence, many anxious about anything developer-adjacent. So I treated it as what it was, a self-serve product activation problem, and designed for the least confident person in the room, not the average one. That's the difference between 80% activation and 100%.
I built a step-by-step onboarding wizard that runs entirely inside Cursor. One URL, one paste, and it takes over: prerequisites checked, authentication handled in a single browser click, repo cloned, all rules and commands installed. The designer never opens a terminal.
The onboarding wizard I built: a guided self-serve activation flow inside Cursor. The designer never touches a terminal at any stage.
Alpha testing with three designers in week two surfaced anxiety spikes and drop-off points, which I fixed through real-time iteration. Week three: 25 designers onboarded, 100% activation, zero support tickets, no dependency on a technical champion within each team.
Every designer who started the wizard completed it. The system scaled without adding coordination overhead or dedicated support resource. That is the activation bar I set for myself from the beginning.
One demo. One week. Embedded in a new team.
While scaling the Design Intelligence Hub across remaining design chapters, I demoed the system to the Personal Banking Enablement Manager, responsible for scaling Cursor adoption across 1,000+ staff in the Personal Banking domain: Product Managers, Business Analysts, Engineers, Solutions Architects, and Executive General Managers.
He had been hitting a wall. His developers were telling him the only way to build the context library he needed was to ask every member of staff to manually upload their knowledge into it. He had three fears blocking progress entirely. I had already solved all three.
| The fear blocking progress | How the hub eliminates it |
|---|---|
| Nobody has time to maintain a context library manually | The context library populates itself as a side effect of normal work. Publishing an output automatically generates structured metadata. No separate maintenance step exists. |
| Nobody will use it if it adds friction to their workflow | The system is embedded in Cursor, the tool people are already using. Publishing is a single natural language command. There is no new tool, no new login, no new habit to form. |
| Non-technical roles cannot understand Cursor well enough to contribute | The onboarding wizard handles setup end-to-end. The 100% activation rate in the design chapter proved this works for non-technical users. The same approach applies at scale. |
The demo did not just impress him. It removed every blocker that had been stopping him for months. He requested my capacity immediately. I was embedded in his team within a week of that conversation.
This was the moment the Design Intelligence Hub became something larger. The proof of concept had validated the architecture. But scaling from 230 designers toward a 1,000-person domain across five disciplines surfaced a deeper problem, one a publishing platform alone could not solve. It needed a framework.
The breakthrough wasn't a bigger model. It was treating context as a product.
A publishing hub answers one question: where does output land. It does not answer the harder one: how does the collective knowledge of a 1,000-person domain become something an AI agent can be trusted to reason over. Every team experimenting with internal AI was discovering the same uncomfortable truth: point an agent at a pile of documents and you get confident nonsense. The missing ingredient was never intelligence. It was a lifecycle.
So I designed one. The Context Lifecycle is my framework for context engineering, built as a product: four phases that move raw organisational knowledge from captured, to curated, to queryable, to generated. Each phase has its own owners, quality bar, and governance. It is the conceptual spine the entire ecosystem is built on.
A bigger model doesn't fix bad context. The unlock is a lifecycle that keeps knowledge curated, governed, and current, so the agent reasons over what's true, not over whatever happens to be lying around.
Collection: capture knowledge where work already happens
Research, decisions, personas, requirements, and meeting outputs flow in from the tools people already use, rather than asking 1,000 people to file documents into yet another system. Capture is a side effect of normal work, not a second job. This is the phase that quietly solved the "nobody has time to maintain it" objection.
Processing: distil raw material into agent-readable entries
Raw input becomes a distillation: a curated, structured markdown file with frontmatter metadata and a classification by type and stability. This is where unstructured organisational knowledge becomes machine-reasonable: the difference between a document an agent can scrape and an entry an agent can trust.
Retrieval: govern what the agent is allowed to see
Retrieval is schema-driven and scoped. Stability tiers separate slow-moving foundations from in-flight work, a "blast radius" setting controls how far a query reaches across domains, and freshness rules decide what needs re-verification before it can be trusted. Governance is not a review gate bolted on at the end. It is a property of how knowledge is retrieved.
Generation: produce real artifacts grounded in governed context
Dashboards, board decks, product specs, market analyses, research synthesis: all generated by agents reasoning over curated, current, owned knowledge instead of whatever a search happened to surface. This is the phase stakeholders see and feel. Everything upstream exists to make this phase trustworthy.
Governance isn't a final review bolted on at the end. Human-controlled gates sit between the phases (curation review, library quality review, go-live approval), and the lifecycle can't advance without them. Every correction flows back as a refined rule, so each pass makes the next output sharper for everyone. That feedback loop is why the system compounds.
What the lifecycle runs on: a library, a brain, and one shared schema.
The Context Lifecycle is the operating model. The system that runs it has a deliberate separation at its core, one most internal AI projects get wrong by collapsing everything into a single bucket.
The Context Library: what the organisation knows
The curated distillations themselves, distributed across ten sub-domain repositories, each owned by the team closest to the work. One schema, many owners. A central index aggregates all ten and builds the cross-domain search and relationships graph, so a question in one sub-domain can reach context held in another.
The Brain: how the organisation uses what it knows
A separate, central source of truth for the schema every entry validates against, the classification rules the Processing phase applies, and the retrieval templates agents follow. It updates itself into every workspace, so improving how retrieval works once improves it everywhere, without touching a single line of content.
Keep what you know separate from how you use it. The Library holds the knowledge. The Brain holds the method. Collapse them into one and you can't evolve either without breaking the other.
The unit of knowledge: a distillation
Every entry follows the same shape: a curated markdown file with structured frontmatter that makes it searchable and agent-readable. The format is deliberately aligned to the bank's wider enterprise knowledge standard, so context produced in this domain is interoperable with the broader organisation rather than trapped in a silo.
--- title: "First-home-buyer persona" tags: [persona, deposits, first-home-buyer] created: 2026-06-09 modified: 2026-06-09 verified: 2026-06-09 status: active domain: personal-deposits phase: processing complexity: beginner source: "research/2026-q1-fhb-study" --- # First-home-buyer persona (curated content follows...)
A distillation's frontmatter: status and verified drive freshness, domain and phase place it in the lifecycle, and source keeps a traceable line back to the raw material. Metadata is what turns a document into governed, queryable context.
Two stability tiers, one blast radius
Not all knowledge ages at the same rate, so retrieval shouldn't treat it as if it does. Every distillation belongs to one of two stability tiers, and a separate "blast radius" setting controls how far across the ten sub-domains a query is allowed to reach.
| Tier | What lives there | Behaviour |
|---|---|---|
| L1 · Stable | Slow-moving foundations: decisions, principles, personas, glossary. | The authoritative backbone. Rarely changes once verified. Searched by default in every query. |
| L2 · Volatile | In-flight work: requirements, research, architecture, change. | Evolves as initiatives progress. Held to a stricter freshness check before it's trusted. |
Blast radius scopes how wide a retrieval reaches: narrow stays inside one sub-domain, bounded and wide pull related context from adjacent sub-domains via the relationships graph. It is the dial between a focused answer and a fully cross-functional one.
The lifecycle in production
The framework is not theoretical. It is already generating real artifacts and onboarding its first cross-functional pilot teams.
The first Generation-phase proof point: a Voice-of-Customer dashboard regenerated each month from curated customer-feedback distillations: context in, living artifact out.
A major platform-migration programme is the first team to run the full lifecycle end to end, with Product Managers and BAs as both contributors and consumers of context.
A human-paced roadmap
The system components can be built incrementally. The real pace-setter is trust. The roadmap is deliberately measured against human adoption milestones (onboarding, feedback, iteration), not fixed delivery dates, because go-live depends on people changing how they work as much as on anything technical shipping.
Done: planning and the framework
The Context Lifecycle defined and named, the ecosystem pitch complete, the Library architecture and sub-domain structure designed, and the first generation-phase dashboard running.
We are here: POCs and foundations
Proving each phase of the lifecycle works: the Context Library infrastructure, the migration pilot, and the early intelligence hub, alongside AI-governance reviews.
Next: implementation and pilot testing
Product Managers and BAs as the first pilot group through all four phases, contributing to Collection and consuming at Generation, iterating templates on real-use patterns.
Later: go-live and persona expansion
Architects, solution designers, and product designers join the ecosystem and start using the full lifecycle, with the academy reaching full track coverage.
Ongoing: iteration and maintenance
Growing the Library as new sub-domains onboard, exploring new generation modalities, and evolving the Brain as the system's single source of truth.
Growing people, not just building systems.
My most important output here is not the platform. It is the capability of the people using it. Building infrastructure that nobody knows how to use is just expensive shelf-ware. The real work is the change management loop that turns non-technical creators (BAs, PMs, and engineers) into high-velocity AI operators who reach for these tools instinctively. They can both contribute to the lifecycle at Collection and Processing, and draw from it at Retrieval and Generation.
Working with the Enablement Manager and an Agile Coach, I designed a persona-based, level-based learning programme (an AI academy) running across two parallel tracks.
Self-guided course
Structured modules I designed around each of the five personas, allowing individuals to onboard at their own pace without blocking their team. Non-technical roles get a different entry point from engineers, but both arrive at the same outcome: confident, independent Cursor use embedded in their daily workflow.
Masterclass series
Deeper capability sessions I run as cohort learning across disciplines. Designers, PMs, BAs, and engineers in the same room, learning to use the ecosystem and Cursor agents together across the full SDLC. Cross-functional understanding built through shared practice, not slide decks.
Advanced command authoring, prototype generation, publishing workflows. From individual contributor to chapter AI champion.
Querying the ecosystem for live context via Cursor agents. AI to accelerate briefs, specs, analysis, and cross-functional documentation.
High-level access to live E2E service blueprints and product status. Board-ready context from a single natural language query.
The training is not just about tool adoption. It is about shifting how an entire 1,000-person domain across five disciplines thinks about knowledge sharing, cross-functional handoff, and AI-assisted work. The system is the infrastructure. The enablement programme is the culture change. Both are required for either to work.
I conceived and built the foundation, then led the team that scaled it.
The concept, the architecture, and the Context Lifecycle framework are mine, as was the original proof of concept, which I designed and built end to end. But scaling it from a five-day prototype into an enterprise ecosystem was never a solo act. As the system proved itself, I brought together and led a cross-functional team, turning early believers into contributors and co-owners. That is product-led growth operating as an internal organisational dynamic: the work earned its team.
Initial collaborators
Principal
Tooling
I identified his problem before he had articulated it, and pitched the solution directly. He granted org owner rights the same day and championed the initiative to DesignOps leadership.
Principal
Design Systems
Validated the hub as a potential replacement for existing project management tooling and provided strategic direction on governance and org-wide adoption.
Developer
Architecture validation
Collaborated with me on validating the architecture, framework, and Cursor commands. We updated shared Cursor guides together to reflect the new system.
Designers
Alpha testing and onboarding
Chapter designers were end users and feedback partners through alpha testing and onboarding. Their friction points shaped every iteration of the publish command, quality checks, and onboarding wizard.
The team that assembled after the demo
Manager
Enablement Manager
Requested my capacity immediately after the demo. We have been presenting together to executives and teams across the domain, co-leading the expansion strategy and cross-functional programme governance.
Engineer
Distinguished Engineer
Technical architecture partner for the ecosystem infrastructure, Context Library schema design, and integration with enterprise data sources.
Full-Stack Developer
Building and extending the Context Library and hub infrastructure alongside me as the platform scales toward the full 1,000-person domain.
Coach
Agile Coach
Co-designing the training strategy and masterclass programme with me, ensuring the learning approach works across all five discipline personas and seniority levels.
What it delivered.
A reusable framework, not just a platform
The Context Lifecycle gave the organisation a shared language and operating model for context engineering: a productised approach that any sub-domain can adopt, rather than a one-off tool tied to a single team.
Executive endorsement and expansion mandate
DesignOps leadership identified the system as a potential replacement for existing project management tooling. The Enablement Manager requested my capacity within a week of the demo, expanding the mandate from 230 designers to a 1,000+ person cross-functional domain.
Context library problem solved
The context library that developers said required manual uploads from 1,000 staff now populates itself as a side effect of normal work. Machine-readable, Cursor-queryable, governed by schema, zero maintenance burden.
Cross-functional velocity unlocked
Product Managers, BAs, and engineers can now pull live context, user research, and journey maps directly via Cursor agents, removing the standard design-to-product handoff friction loop entirely.
What changed
| Before | After |
|---|---|
| Design outputs buried in personal repos and email | Every output has a permanent URL, indexed and discoverable org-wide |
| Knowledge treated as documents to store | Knowledge treated as a product with a lifecycle, owners, and a schema |
| Duplicate research across chapters every quarter | 600+ outputs indexed, searchable by keyword, author, type, or team |
| AI agents reasoning over whatever search surfaced | Agents reasoning over curated, governed, freshness-checked context |
| Context library requiring manual maintenance by 1,000 staff | Machine-readable context builds itself as a side effect of normal work |
| Tool adoption stalled by technical complexity | 100% activation rate via self-serve wizard, zero support dependency |
| AI capability siloed in individual experts | Cursor command library shared, attributed, and inherited by every new joiner |
What I learned, and what I'd do differently.
The biggest shift in my own thinking was this: the hard part of enterprise AI is not the model, and it is not even the tooling. It is context, and context only becomes trustworthy when you stop treating it as storage and start treating it as a product with a lifecycle. Naming the Context Lifecycle was not branding for its own sake. It gives the domain a shared mental model for why the work is structured the way it is, which is what makes a system like this adoptable rather than merely impressive.
What I'd do differently: the system scaled faster than the change management. I would invest in the enablement programme in parallel with the technical build rather than sequentially, which would have compressed the timeline between POC and enterprise expansion. The infrastructure was ready before the culture was. A more deliberate communication strategy from week one would have made the difference.
What I am most proud of is not the technology. It is that I treated an internal operational problem as a product problem, validated it through a proof of concept, and let the results earn the mandate for scale. The cross-functional team that now delivers this programme assembled organically around the platform. That is the outcome I was engineering for from day one.
Five days to POC. A 1,000+ person domain in scope. A framework for context engineering, built as a product. No developers. AI-first from day one.