We run 20-something repositories and about 34,853 files under one workspace. The thing that keeps the whole portfolio coherent is a planning layer we call Brain - and its most important design decision is a refusal: Brain is not allowed to build or deploy anything. Ever.
That sounds backwards. Every agent demo right now is about doing more: write the code, open the PR, deploy it, close the ticket. We went the other way, and it is the reason the system is still trustworthy a year in.
What Brain actually does
Brain knows the state of every project we run. Ask it "where did we land on the pricing page copy" and it answers from the actual state of the repo, the docs, and the decisions around them - with one boundary: it will not mix two projects into one answer. If the evidence for an answer lives in two repos, it tells you that instead of merging them into a plausible-sounding fiction.
Three rules do the work:
- Read everything, write nothing. Brain can inspect any repo, any doc, any deploy state. It cannot touch any of them. The moment a system that advises can also act, every wrong answer becomes an incident instead of a bad suggestion.
- No cross-project answers. A question about project A gets answered from project A's evidence. Contamination between contexts is how you get confident answers about the wrong system - the worst kind.
- Memory has to be verifiable. Company context persists between sessions through a memory layer (we build on Alchemyst AI for this), and what it recalls can be traced back to where it came from. If the system can't show you why it believes something, it doesn't get to assert it.
Why the constraint is the feature
The failure mode we were designing against is not "the AI is too dumb." It is the opposite: a system smart enough to act, acting on a stale or contaminated picture of reality, at 3am, with full permissions.
Every operator we know has a story like this now. An agent that "helpfully" resolved something against the wrong state. An automation that kept running confidently after the world changed around it. Silent failure is the norm once systems can write.
So we split the layers. A judgment layer that reads, remembers, routes, and answers - and separate, boring, deterministic systems that write. The reasoning session can draft; only the deterministic sender is allowed to put anything in front of the world. We use the same two-plane pattern in client work too: the smart part proposes, the dumb part disposes, and the dumb part is auditable line by line.
The planning layer got more useful as it got more constrained. Because it cannot act, we let it see everything. Because it sees everything, its answers are worth reading. Permissions and trust turned out to be the same budget.
The part that is still wrong
Honesty section, because these write-ups are usually too clean:
- Brain still goes stale on fast-moving deploy state unless the refresh loop is watched.
- "Don't mix projects" is enforced by construction for repos, but docs and chat history leak across boundaries and have to be filtered.
- The verifiable-memory trail is only as good as the discipline of writing decisions down somewhere it can cite.
If you're building agent systems
The question worth asking of any agent you operate is not "what can it do?" It is "what is it structurally unable to do, and is that the same list as the things that would scare you?"
We build and operate systems like this for operations teams - company brains, content engines, outreach systems - and the pattern holds every time: constrain the smart layer, make the acting layer boring, keep memory verifiable. The full write-up with the working diagram is on our site.
Happy to answer questions about the architecture in the comments.
Top comments (1)
Great article I completely agree, granular agents which are composed with intention are far safer than generalized agents with large margins of access. Being able to restrict what agents are capable of I think is paramount to building reliable and compliant agents.