For years, designing something new at Purple meant finding the one person who'd been here long enough to know which systems would break — and hoping they had an afternoon. The design itself was usually a page or two, written on face value, because nobody had the time to write the real thing. Often there wasn't even a page: just a meeting where someone said "we want this new feature," and the developers were left to reverse-engineer what the actual work was.

That gap quietly cost us on both sides. Product would assume a change was small and couldn't fathom why it touched so many systems. Engineers drowned in back-and-forth, because the thinking hadn't been done or written down up front — and the job of producing some kind of design, then chasing everyone for sign-off, usually landed on whichever developer drew the short straw. And because the estate was siloed, you often had no real idea what a neighbouring system even did. So the blast radius got discovered late, in code, instead of early, in design.

Now an architect opens the workspace, an AI facilitator that already knows the whole estate starts asking the questions, and it won't begin the design until every one of them is answered.

That place is the Architecture Workspace, and it's the closest thing we have to a shared brain for how Purple builds software.

One shared brain, three pillars

The workspace is documentation-as-code: everything is Markdown and diagrams, kept in Git, and published as a browsable internal site. Underneath, it rests on three pillars. There's the landscape — the map of what already exists, drawn automatically; that auto-map is its own story, the subject of Episode 06, and here it matters only as the context a new design reads from. There's standards — the principles, conventions and dozens of reusable patterns that apply to everything. And there's projects — one folder per initiative, each holding the full design pack for something we're building. More than thirty initiatives the group is running now live there, designed in the same place, to the same rigour, instead of scattered across heads, chats and wiki pages.

The point of pulling all three together isn't tidiness. It's that when you sit down to design the next thing, you're not staring at a blank page. You're designing against everything we already know.

It won't start until it has all the answers

Here's the turn. When an architect kicks off a new initiative, they don't open a blank document — they open a guided, multi-phase design workflow, facilitated by a Cursor AI agent that already has the estate loaded in its head.

And the first thing it does is refuse to design.

It interrogates the idea first. It produces the questions — the ones a seasoned architect would ask if they had a free afternoon and a long memory — and it makes you go and get the answers before it will move on. What's the real requirement? Which systems does this actually touch? What breaks downstream? Because Landscape Forge has already onboarded so much of the estate, the agent can read the actual code of the systems in scope and reason over the whole solution, surfacing impacts a human might genuinely not know to look for. It's the institutional memory we used to keep in one or two people's heads, available to whoever opens the workspace.

Then it walks you through the design itself — capturing requirements, analysing the current state, shaping the high-level architecture with proper C4 diagrams, detailing it, checking it against the standards, and breaking it into developer-ready work — recording every decision as you go. The architect is the author throughout; the AI facilitates, challenges, and holds the line. It's the difference between writing alone and writing with someone who's read everything and forgets nothing.

The quieter benefit is the one architects mention first: it keeps you honest on an off day. When you're rushed and tempted to skip the awkward question, the enforced patterns and guardrails push back. The floor under a tired Friday afternoon is the same as the floor under your best work.

The spec used to be a meeting. Now it's the entities, the database, the Kafka topics.

What comes out the other end is the part developers care about. Not a vague ticket and a hallway conversation — a detailed, developer-ready technical specification. The entities. The database. The Kafka topics. The contracts between services. The actual shape of the thing, written down before anyone opens an IDE.

Alongside the spec come two things that used to live only in memory. There are per-repo work bundles — one consolidated handoff per repository, so a developer touching a given service gets exactly the slice of the design that applies to them, with the relevant patterns cross-referenced. And there are ADRs — architecture decision records that capture the why, not just the what. Months later, when someone asks "why on earth did we build it this way?", the answer is written down with its context, its trade-offs and its risks, instead of lost with the person who made the call.

This isn't a hypothetical. Take one of the initiatives recently designed end to end inside the workspace. Its pack is a full high-level design with a rendered C4 container diagram, a current-state analysis, a detailed design and tech spec, a compliance review, and a stack of real ADRs — including the foundational one recording the decision to retire a legacy stack in favour of a .NET 8 modular monolith, with the context and consequences spelled out. From that design flowed the developer work bundles, repo by repo. A developer joining that build doesn't start by asking what's going on. They start by reading.

Capture once, enforce everywhere

The third pillar — standards — is where the leverage compounds. Instead of every team reinventing how to do a thing, the workspace holds dozens of battle-tested, copy-ready patterns: "this is how we build X." A new design doesn't argue its way to first principles; it inherits the house way and spends its energy on what's actually novel.

And it learns. Say a team is deep in code and hits a convention the workspace never pinned down — how a Kafka consumer should handle a poison message and commit its offsets, the exact retry-and-dead-letter shape we want every .NET 8 consumer to follow. Rather than each service quietly solving it differently, the team writes that convention back into the workspace, and from then on it's enforced into the next tech spec automatically. The macro-architecture gets captured once and applied everywhere. Hit a missing pattern once, and every design after inherits the fix.

That's the loop that turns a documentation site into something alive: standards flow down into every new design, and hard-won lessons from code flow back up into the standards.

The asymmetry is the whole unlock: few hands author it, everything downstream inherits it. A small number of architects do the deliberate design work, and every developer — and every coding agent — builds from it.

One honest word

The real test isn't whether the workflow is good. It's whether architects reach for it when they're under pressure and a deadline is breathing down their neck — or quietly route around it and go back to the two-page doc.

We're honest that adoption-under-pressure is the thing to watch, not a box already ticked. The standards and guardrails are designed precisely to make the right path the easy one on a bad day — but the proof is in the habit, and we're still building it.

Where it fits

This is the design heart of the operating system, and it doesn't stand alone. Landscape Forge (Episode 06) feeds it the map — the current truth about what already exists. The Architecture Workspace turns that knowledge into intent: a deliberate, reviewed design for what should exist next. And that intent flows straight into delivery — to the developers and the coding agents who build it. Knowledge becomes intent becomes build, and the lessons from the build flow back up into the standards. That round trip is the point.

What's next

The direction of travel is to tighten the loop until it's seamless: a design that lands as a spec, a spec that hands cleanly to a coding agent, code that writes its own learnings back into the standards without anyone having to remember to. Fewer gaps between knowing, deciding and building. More of the company's architectural judgement living in a place you can open, read and reuse — instead of in a calendar invite with the one person who remembers.