The engineer teams spent a decade designing out
Most engineering organisations remember the silo engineer. They disappeared into one corner of the codebase for weeks and came back with something that worked and that nobody else understood. Teams spent years designing that pattern out. Code review, pairing, design documents, shared ownership and architecture forums all exist partly to stop it.
Those practices were expensive. They were also how architectural knowledge moved between people. A reviewer who said "we don't call the billing database from here" was passing on a decision, not only checking a diff.
AI coding agents are bringing the silo engineer back. This time it is not one person working alone for weeks. It is every engineer, working with an agent, producing large changes with little help from anyone else.
How the silo comes back
Nobody decides to work in a silo. It follows from a sequence of reasonable steps:
- More individual capacity. One engineer with a coding agent can now complete work that once needed a small team.
- Fewer coordination points. Work that needs fewer people needs fewer conversations, handoffs and design reviews.
- Less architectural knowledge exchanged. Those conversations were where people learned which boundaries mattered and which options had been ruled out.
- Local context dominates. The engineer and the agent act on what is in front of them: the ticket, the files they opened, the documents the agent happened to retrieve.
- Divergence surfaces late. The mismatch shows up in review, in an incident, or months later when two parts of the system no longer fit.
None of these steps is a mistake. Higher individual output is the point of adopting agents. The cost is that a developer and an agent now form a unit that rarely needs to talk to anyone else.
What it looks like on a real team
Two illustrative cases. First, two engineers in the same week each need retries on outbound calls. One asks an agent to add a popular retry library. The other has an agent write a small wrapper around the existing HTTP client. Both changes are tested. Both pass review, because different people review them. The codebase now has two retry strategies, and the next agent to touch either service will copy whichever one it sees first.
Second, an agent adds a message queue client to a service. Eight months ago the team rejected that client after an incident, and agreed to use the platform's managed queue instead. The reason lives in a chat thread and in the memory of two senior engineers. The agent never saw either. The change is clean, tested and wrong.
In both cases each change is locally correct. The system is less coherent than it was. Engineering coherence, the extent to which independently executed changes stay consistent with the decisions that govern a system, is what the silo erodes. Architectural drift, the gradual move away from those decisions, is what that loss looks like over time.
The same silo, one level up: decision silos
Engineering teams are not the only place this happens. Across a company, the decisions that should constrain a change are spread over architecture decision records (ADRs), tickets, wikis, chat threads, security policies and people's heads. Each AI tool sees the slice it is connected to. A coding agent sees the repository. A knowledge assistant sees the wiki. None of them sees what the organisation decided.
Retrieval only partly closes the gap. Finding a document that mentions a database is not the same as knowing it records an approved decision, which services it covers, whether a later decision replaced it, and whether breaking it should stop the change. A person can ask a colleague in another team. An agent that starts each session fresh cannot.
So the silo that matters is not data. It is decisions. The answer is not one all-knowing agent with access to everything. Specialised agents can stay specialised if they share one authoritative set of decisions and are checked against it. We made the longer case for that layer in Your Most Valuable AI Dataset May Be the Decisions You Already Made and The Agent Economy Needs a Decision Layer.
Don't bring back the meetings
The obvious response is to restore the old coordination: more design reviews, mandatory pairing, approval for every agent-written change. That trades the speed teams adopted agents for, and it does not scale with agent output. Review capacity grows with headcount, not with agent output.
The better question is what the old coordination carried. Mostly it carried decisions: what the team agreed, why, where it applies, and which earlier choices it replaced. Keep that. Drop the cost of moving it through meetings.
There is a people cost too. EY-Parthenon's 2026 survey of 400 European software CTOs found that 13% say AI has weakened how juniors learn from seniors, through fewer trainable tasks or less senior review time. The report recommends "deliberate exposure to architectural decisions." A junior engineer working mostly with an agent gets less of that by default.
What engineering leaders should do
- Name the decisions a solo engineer and agent are most likely to miss. Start with the ones made in a meeting or chat thread they were not part of.
- Give each decision a scope and a status. Say which code it covers and whether it is current. A decision without scope is advice. A decision without status may already be obsolete.
- Put decisions where the work happens. Engineers and agents should meet the relevant decision when they change the code it covers, not in a wiki search afterwards.
- Check the enforceable ones automatically. If a decision can be expressed as a rule, check every change against it before merge. Reviewers can then spend their time on trade-offs.
- Spend coordination time on decisions, not status. Use the conversations you keep to make and change decisions, then record the outcome where tools can use it.
Where Mneme fits
Collaboration is still how a team creates and changes its architectural intent. Mneme's job is to carry those decisions into work that happens far from the conversations that produced them.
Today that covers architectural decisions in a repository. Mneme, an open-source decision and control layer for agentic software development, compiles the enforceable parts of accepted decisions into typed rules: machine-checkable rules with exact meaning. It checks proposed changes against them through hooks inside supported agents, which intercept a file write before it lands, such as Claude Code and OpenAI's Codex command-line interface (CLI), and in continuous integration (CI) before merge. Agents can also query the local Decision Index MCP server, which uses the Model Context Protocol (MCP), for the decisions that apply to the files they are about to change. Decisions that live in chat tools, tickets or wikis outside the repository are not ingested today.