A developer and a product person had an idea and decided to just build it. No architecture review, no long design phase. Architecture has a reputation for slowing things down, so skipping it can feel like the fast option. They were using GitHub Spec Kit, so they wrote a constitution and a spec, let the agent produce a plan, and started building. Things were moving fast, which is pretty much the promise of agentic development.
Then they got stuck on a problem. A little later, they added a solution architect and me to the chat.
A few back-and-forths in, the questions started to change. Less "how do we fix this?" and more "wait, what exactly are we building here?" That is when it came out. Part of what they were building was an integration point that already existed. Another system already did that job, and it could have been reused.
Nobody did anything wrong. The agent wrote a reasonable plan. It just planned with what it was given, and what it was given did not include the thing that already existed.
That chat stuck with me, mostly because it is the exact conversation I have been leading at work: what does architecture look like when agents are doing a lot of the building?
An agent builds exactly what it can see
How much an agent sees depends on how you work with it. If you are vibe coding, it sees your prompt and whatever code is already in the repo. Spec-driven development shows it a lot more: a constitution with the guardrails, a spec with what you are building, and a plan for how you will build it.
That is a big step up from "hey agent, build me a thing." But notice who writes all of it. One team. Whether it is a quick prompt or a full spec, it describes one team's piece of work. I like to think of it as an iceberg.
Above the waterline is team context, everything the team knows and handed to the agent. Below it is enterprise context, and it is much bigger. Every company has answers to those seven questions, but almost none of them live with one team.
Before agents, we filled those gaps by talking. Someone in standup says "doesn't the other team already have that?" and a week of work disappears. An agent doesn't wander over to someone's desk. If it is not written down somewhere the agent can read, the agent does not know it.
The pet store test
Let me make it concrete with something more fun than enterprise software. A pet store. It has a grooming salon, an in-store vet clinic, and an app where customers book grooming. The grooming team picks up a new spec:
Add vaccine checks to grooming bookings. Don't let a dog be booked if its shots are not current.
Sounds simple enough, right? The grooming team knows their app inside out. But whether they vibe code this or write a proper spec, the agent has to decide what "vaccinated" means, where the records live, and how it hears about changes. Here is the plan it comes up with. Now give it the whole iceberg.
The records table is the story from the chat. A whole new integration, planned with care, for something that already exists. The agent is not bad at building. The answers were just with the clinic team and the architects, not in the spec.
Agents don't lack skill. They lack enterprise context.
This is the shift for me. For a long time, architecture has mostly been guidance. Diagrams on a wiki, standards in a document, a review board before something big. Useful, but easy to route around, especially now that an agent can get you from idea to working code before the review meeting is even on the calendar. And as long as architecture stays a slow, manual step, people will keep routing around it. It has to move at the same speed as everything else.
Whether it is a prompt or a spec, the agent builds from what it is handed. So architecture has to be part of what it is handed. Not a gate at the end, but context at the start, written down and kept current.
Architecture is no longer just guidance. It is context.
So I started building architecture skills
If agents need enterprise context, someone has to write it down in a form they can use. Doing that by hand would just make architecture the bottleneck again. So architecture needs to be agentic too. That is what I have been working on: a set of architecture skills, in the skill format Claude Code, Copilot and Codex can all read.
The skills are grounded in rules most companies already have but agents have never seen: approved tech, API guidelines, naming, how decisions get logged. Each one does one piece of architecture work, like defining the words, drawing the systems or recording a decision, and they read from what already exists. That last part is what would have caught the integration in the chat.
The agent drafts, an architect approves. The architect reviews a glossary, a system map or a decision instead of writing it from scratch, so architecture keeps up with delivery instead of holding it back. From there, the architecture goes wherever agents look: the constitution and specs for spec-driven teams, an AGENTS.md for teams that vibe code. Either way, the agent building the grooming feature would start with the glossary, the system map and that decision already in front of it.
Back to the chat
So what would have changed for that developer and product person? Not much on their end. They would still move fast with the same tools. And the architecture would not have slowed them down, because it was built the same way they were building: with agents. The difference is that their spec would have started from an architecture that already said "this integration exists, here is how you use it," and the agent would have planned to reuse it. No getting stuck, no architect pulled in after the fact.
Agents don't lack skill. They lack enterprise context. Architecture is how we give it to them, and with skills, it moves just as fast.