Wrightery
How it worksWorkbenchUse casesLibrary
How it worksWorkbenchUse casesLibrary
Wrightery

Vibe working for analysis. Your AI analyst team researches, cross-checks, and drafts from trusted sources. You review the evidence and make the final call.

Product

How it worksWorkbenchUse cases

Company

TeamBook a meeting ↗
© 2026 Wrightery.
v1.2610.260322192c31a7d8
  1. Library
  1. 1Daniel’s Journey to Build a ChatGPT Challenger
  2. 2Chapter 1 — Nine Months
  3. 3Chapter 2 — The Product in the Sales Deck
  4. 4Chapter 3 — What Are We Competing For?
  5. 5Chapter 4 — The CTO in the Code Review
  6. 6Chapter 5 — The Architecture That Grew by Accident
  7. 7Chapter 6 — The First Customer Promise
  1. Library
Chapter 6 of 7·15 min read

Chapter 5 — The Architecture That Grew by Accident

Chapter 5 — The Architecture That Grew by Accident
Chapter 5 — The Architecture That Grew by Accident

“Forty-seven,” Elena said.

Daniel had guessed fifteen. He had not said so aloud, and he was now grateful for that.

She had taken the small room for five days and turned its longest wall into the drawing he had asked for. It was not a diagram for a slide. It was fourteen sheets of plotter paper taped edge to edge, covered in boxes, arrows, and Elena’s small upright handwriting, and it ran from the door almost to the window. Every box was something Aureline deployed, paid for, or answered for when it failed. Each carried a colored dot in its top corner.

“Green has an owner who can change it safely today,” Elena said. “Amber has an owner on paper. Red has nobody.”

Daniel counted the red without meaning to. He stopped at nine.

“How did you build it?”

“Not from memory. Nobody’s memory, including mine.” She pointed to a column of notes beside the door. “The Azure subscriptions, through Resource Graph. Sixty-three repositories in the GitHub organization. The Terraform state, for the part of the estate that has Terraform. The bill, for the part that does not. The Application Insights dependency map, to see what actually calls what. Then I had an agent read every repository and write me a page on each—what it does, what calls it, who commits to it, and why it exists.”

“And?”

“The first three were excellent. The fourth was excellent and wrong.” She tapped a box labeled agent-runtime. “It told me this was a migration in progress, replacing the original orchestrator. It read the commit history, saw a newer service doing the same job, and wrote the most reasonable story available. I checked eleven of its histories against the people who were there. Four were wrong in the same way. The code tells you what exists. It does not tell you what anybody decided, because mostly nobody did.”

Noah Williams had come in behind Daniel with a coffee and stood reading the wall from the doorway, the way a man reads a weather map for the coast he lives on. Hannah sat at the table with her laptop closed. Ravi and Sofia had joined on the screen, Ravi from his kitchen, Sofia from a phone booth with her knees against the glass.

“Walk me through it,” Daniel said. “Not every box. The pattern.”

Elena had prepared for the question. Along the bottom of the wall she had stuck three sticky notes, each a different color.

Prototype. Customer. Fashion.

“Almost everything here came from one of three places,” she said. “Something built to prove an idea and never retired after the idea was proved. Something built for one customer under deadline that never rejoined the product. Something adopted because it was what serious companies were said to use. Eleven, six, and eight. The rest are what you would draw on purpose.”

She started with Ravi’s.

There were two orchestrators. The first, orchestrator-v1, had been built on LangChain during the prototype, when the framework was the fastest path to a working agent and the whole company was six people. The second, agent-runtime, was custom Python that Ravi’s team had written a year later, because the framework hid too much of what happened between a request and a tool call. Both ran in production. The assistant builder still called the first.

“What share of agent traffic goes through v1?” Daniel asked.

“Seventy percent,” Ravi said. “We were going to move the builder across.”

“When?”

“When there was time.” He heard it as he said it. “Which is the same sentence as never.”

“It is the same sentence as nobody’s,” Elena said, not unkindly. “You own the runtime. Who owns v1?”

Ravi did not answer, which was an answer. The box had a red dot.

The next cluster was Noah’s, and he spoke before Elena reached it. A three-node AKS cluster, created eighteen months earlier for the day Aureline would need Kubernetes, ran exactly one workload: the PDF parser. Everything else had moved to Container Apps. The cluster cost more each month than the rest of the ingestion pipeline combined.

“I upgrade it myself,” Noah said. “Every few months, before the Kubernetes version falls out of support. Usually on a Saturday.”

“Why do you keep it?”

“Because keeping it alive was always cheaper than finding out why it was alive.” Noah looked at the box as though it had been his for a long time and he had only now noticed. “The parser needed more memory than the default Container Apps profile gave it. That was true two years ago. I have not checked since.”

Sofia owned the next one, though she disputed the word. A GraphQL gateway sat in front of three internal services so that the web application would have a single API. It had been set up during a fortnight when every conference talk Marcus attended seemed to be about federation. The Next.js application had since started calling two of the three services directly from server code, because that was faster and simpler.

“We never really used it,” Sofia said.

“It is still deployed,” Elena said. “It is still on the bill, and it is still in Omar’s threat model as an entry point. A thing you do not use is still a thing an attacker can.”

Then she reached the six boxes marked Customer, and the room changed temperature.

The largest was ingest-halvorsen, a fork of the ingestion worker kept for Halvorsen Group, Aureline’s first paying customer. Halvorsen had needed a different chunking strategy and a seven-year retention rule, and Evan’s predecessor had agreed to both in a contract signed on a Friday. The fork was four hundred and twelve commits behind the main worker. It ran as its own Container App with its own credentials.

“Who deploys it?” Daniel asked.

“Arjun did,” Elena said. “Arjun left in June. It has not been deployed since. It still runs.”

Daniel looked at the dot. Red.

“So that is what happens when they leave,” he said.

“That is what happens when they leave,” Elena said. “Nothing, for a while.”

Hannah opened her laptop for the first time.

She had been studying a small box near the edge of the wall, off the main flow, with a single thin arrow running back to the product. similar-docs. A Qdrant vector database on one virtual machine, stood up during a hackathon to power the Similar documents panel in the workspace sidebar. Users liked the panel, so Sofia’s team had shipped it. The panel called the vector store directly. Elena had given it an amber dot.

“This holds a second copy of the embeddings,” Hannah said. “Outside Azure AI Search.”

“For every tenant?”

“For every tenant who has ever uploaded anything.” She was typing as she spoke. “Our deletion job removes the database rows, the blobs, and the search-index documents. It was written before this existed. It has never heard of it.”

Nobody spoke while she ran the query. Daniel watched Noah set his coffee down.

“Calder and Finch,” Hannah said. “The pilot that ended in March. They asked for deletion of all their data, and we confirmed it. There are thirty-one hundred of their embeddings in this store. It takes nightly snapshots to a storage account with no lifecycle policy.”

“Can someone reconstruct a document from an embedding?”

“Not easily, and not completely. That will not matter to anyone reading the confirmation letter.”

Daniel called Rachel from the room. She listened without interrupting, which he had learned was the most serious thing she did.

“I signed that letter,” she said. “It says all data, in all systems.”

“It was true about every system you were told about.”

“That is a sentence for my notes, Daniel. It is not a sentence for Calder and Finch.” There was a pause. “I want it deleted today, verified by someone other than the person who deletes it, and I will write to them myself. And I want to know how many other letters I have signed about systems nobody told me existed.”

When the call ended, Daniel crossed out the amber dot on similar-docs and drew a red one in its place, on the box that had looked least important on the wall.

Marcus arrived twenty minutes later, having been told, and stood at the wall for a long time before speaking.

“You have drawn a crime scene,” he said.

“I have drawn a history,” Elena said.

“Every one of these was the right call.” He touched the Halvorsen box. “We were six people. If we had not shown Halvorsen something in a fortnight, there would not have been a company to draw. LangChain got us an agent in a week. The cluster was cheaper than being caught without one.”

“I agree,” Elena said, and Marcus turned, because he had not expected her to. “That is the problem. I cannot find a bad decision on this wall. Each one was reasonable, local, and urgent. Nobody decided the whole, and nobody was ever asked to undo anything, so everything stayed.”

Marcus looked along the paper again, from the door to the window, and Daniel saw him make the same move he had made on Friday over the citation payload: stop defending, start reading.

“Then we stop patching it,” Marcus said. “One orchestrator, on Foundry Agent Service. One ingestion path. Everything on one compute platform. I can draw the target in an afternoon. It is the system we would build if we started today.”

Ravi was already nodding on the screen. Noah was not.

“Which problem does that remove?” Elena asked.

“All of these.”

“No. It removes the boxes. Name the problem.” She waited. “The fork exists because a contract promised something the product did not do, and a new platform does not change the contract. The vector store escaped deletion because nobody owned the path between what we store and what we promise to delete, and a new platform has the same gap unless somebody owns it. The cluster exists because nobody was ever asked whether it should. Every one of these is a decision-rights problem dressed as a technology problem. If we rebuild without changing who decides, in eighteen months I will draw this wall again with newer names on it.”

Marcus did not concede, but he did not argue either.

“We have nine months,” Daniel said. “A rewrite spends them on a system no customer has asked for, while the one customers use stays unowned. I am not going to approve a rewrite. I am going to ask for a decision on every box.”

He wrote four words on the whiteboard beside the wall.

Own. Consolidate. Freeze. Retire.

“Own means a named team will carry it, change it, and answer for it. Consolidate means it moves into something already owned, by a date. Freeze means nobody changes it until the owner of whatever depends on it says so. Retire means it is gone, and somebody proves it is gone.”

“Some of those are not technical decisions,” Noah said, and pointed at Halvorsen.

“No. Halvorsen is Evan’s conversation with a customer, with Hannah beside him. Calder and Finch is Rachel’s. Most of the rest are yours.”

Elena had one more observation, and Daniel suspected she had been saving it.

“The count went down exactly once in two years,” she said. “Three weeks ago. One of the three ingestion paths disappeared and its traffic moved to the main worker. Two hundred and six files.”

“Mei,” Daniel said.

“Mei. In a weekend, with an agent, without a review, inside her own boundary and within every rule we have.” Elena let it sit. “The largest simplification in the history of this system was made by the most junior engineer in the building, in the same way Marcus made the citation change. I do not have a lesson for that yet. I only think we should not pretend speed is always the problem.”

They went box by box. It took two hours and was less comfortable than the drawing. The managers claimed what they already ran, then argued, carefully, about what they would rather not. Ravi took v1 with a consolidation date and asked for two engineers he did not have. Noah agreed to test the parser on a larger Container Apps workload profile and retire the cluster if it held. Sofia said she would retire the gateway once Omar confirmed nothing else depended on it. Hannah took similar-docs on one condition: its next state was retirement, its panel moved onto Azure AI Search, and the deletion job learned to find every store by reading a register rather than a list written into its code.

At the end, five boxes still carried red dots and no name.

Daniel picked up the marker. He had begun to write his initials beside the first of them before he noticed Elena watching him.

“If you put your name there,” she said, “you have just become the drawing in Marcus’s head.”

He held the marker over the paper a moment longer than he would have liked, then capped it.

“Then they go to Monday’s staff meeting,” he said, “with a date beside each one and nobody’s name. If the people who run this organization cannot find an owner for something, that tells us whether we should still be running it.”

Elena photographed the wall, then took a second photograph, closer, of the five red dots.

“This is the version I will compare against,” she said.

Hannah’s message arrived at six-forty. The Calder and Finch embeddings and snapshots were gone, and Noah had verified the deletion from a separate identity. Rachel’s letter went out at seven.

Before she left, Rachel came up to the small room, found the box, and stood in front of it long enough that Daniel joined her.

“Northstar asks nineteen questions about deletion,” she said.

“I know.”

“I was going to answer them from the policy.” She looked along the paper toward the window, where the boxes ran out. “I am going to answer them from this.”


Director’s Lens

Accidental architecture is built from reasonable decisions

Few systems are designed badly. Most are never designed as a whole at all. Each component answered an urgent, local question—prove the idea, keep the customer, adopt what credible companies use—and each answer was defensible when it was made. What makes the result accidental is not poor judgment. It is that no one was responsible for the sum, and no decision ever carried an obligation to revisit it.

The origins are worth naming, because each leaves a different residue:

Origin Why it was right at the time What it leaves behind Question to ask now
Prototype Proved an idea quickly A second implementation nobody retired What breaks if this disappears tomorrow?
Customer exception Won or kept a customer A fork that drifts away from the product Which contract term does this honor, and does it still apply?
Fashion Looked like what serious companies use Operational surface without a matching problem Which problem does this complexity remove?
Quiet heroics One person kept it running Knowledge held by a single individual Who could change this safely if that person left this week?

Ownership is the ability to change something safely

A name in a CODEOWNERS file is not ownership. Neither is a team tag on a resource group. A component is owned when a team can explain why it exists, deploy it, change it without fear, carry its pager, and decide to delete it. If any of those is missing, the organization has an owner on paper and a liability in practice.

The test is practical. For each component, ask who last deployed it, who is paged when it fails, and who could remove it. If those are three different people, or nobody, the dot is not green.

Unowned components are not inert. They hold data, carry credentials, appear in threat models, and sit inside—or outside—the commitments the company makes. The most dangerous box on Elena’s wall was one of the smallest: a convenience feature whose second copy of customer data sat outside every promise the company had made about deletion.

A rewrite does not end the accident

The natural response to an inventory like this is a target architecture. It is clean, persuasive, and aimed at the visible symptom. But if the forces that produced the accident are unchanged—urgent local decisions, no obligation to retire, no owner for the whole—a rewrite reproduces it with newer components.

Decide per component instead. Every element receives one of four states—own, consolidate, freeze, or retire—with a named team and a date. Consolidation and retirement are deliverables, not cleanup, and they need capacity in the plan. A component that no leader will claim is strong evidence that the company should stop running it.

AI leverage

AI makes a complete inventory affordable. An agent can read every repository, query cloud resource inventories, reconcile infrastructure-as-code with the bill, walk dependency maps from telemetry, and draft a summary of each component faster than an architect can open the repositories. It can surface commit concentration that reveals single-person knowledge, find data stores the deletion path never touches, and compare a customer fork with the main line to estimate drift.

What it produces is a description of what exists, often accompanied by a plausible story about why. Those stories are inferred from artifacts, and accidental architecture is precisely where artifacts mislead: a newer service looks like a migration, and an abandoned experiment looks like a strategy. Treat generated histories as hypotheses to check with the people who were there.

Human boundary

Humans must decide:

  • Which components the company will own, and which it will stop running.
  • Whether a customer exception is still a contractual obligation or only a habit.
  • How to tell a colleague that something they built is being retired.
  • What the company tells a customer when one of its promises turns out to have been untrue.
  • Who carries a component that no team wants.

The last is the hardest, and the Director is the wrong default. A leader who absorbs every orphan becomes the single point of knowledge the inventory was built to remove.

Reusable artifact: architecture ownership map

One entry per deployed component, built from systems of record rather than memory, verified with the people involved, and redrawn on a fixed schedule so the counts can be compared over time.

ARCHITECTURE OWNERSHIP MAP

System:
Map owner:
Sources used (cloud inventory, repositories, IaC, billing, telemetry):
Date drawn:                     Next redraw:

1. SUMMARY
Deployed components:
  Owned:            Owner on paper only:            Unowned:
By origin:
  Deliberate:   Prototype:   Customer exception:   Fashion:
Components only one person can change safely:
Stores holding customer data outside the deletion path:

2. PER COMPONENT
Name:
What it does, in one sentence:
Origin, and the decision that created it (verified with whom):
Problem it removes today:
Owning team:              On-call:              Last deployed by:
People able to change it safely:
Customer data held:       Inside deletion and retention path? (Y/N):
External commitments that depend on it:
Monthly cost:
Decision:  Own / Consolidate into ____ / Freeze / Retire
Target date:              Evidence of completion:

3. UNCLAIMED
Components with no owner after review:
Leadership meeting where each will be decided, and by when:

The map is not a verdict on the people who built the system, and it should never be presented as one. Its value is in the comparison. The second drawing, three months later, shows whether the count fell, whether the red dots found owners, and whether the organization has begun to decide the whole rather than inherit it.

Your next report, with a team behind it.

Wrightery is in private build. Join the waitlist and we'll bring you in as soon as a seat opens — then describe one deliverable you already produce, and watch your AI analysts research it, cross-check it and draft it for your review.

No credit card. We'll email you the moment your seat is ready.

Rather talk it through? Book a 30-minute meeting ↗

← PreviousChapter 4 — The CTO in the Code ReviewNext →Chapter 6 — The First Customer Promise