“deploy to prod. make no mistakes.” is the prompt I wrote to Claude one evening at the end of July from the Italian Founders House (si apre in una nuova scheda), on the H-FARM campus, with my twin Raffaele (si apre in una nuova scheda) next to me prompting like a madman. It was launch week for Yempik's Company Brain: a governed company brain that people and agents read and add to from their AI assistants.
The deploy was the easy part. No deploy saw the real mistakes. Real use found them, along with tests placed on the right boundaries, and almost all of them had the same shape: every piece worked, and the whole path didn't.
Approved data can exist and still be invisible
In the first days an agent worked on the Brain for a full, real day: proposals, revisions, reads from one session to the next. Approvals worked. Search didn't: natural questions that should have found freshly approved knowledge came back empty. The data was there. The step that makes approved data searchable was failing without leaving a trace, and there wasn't a single error in the logs.
Write succeeded, approval succeeded, data stored: it looked like a complete flow. Only one test would have caught it, and it walks the whole path the way a user does: create, approve, search, find. Recovering the data left behind closed the incident and left the assumption that caused it untouched, namely that every background step always reaches its destination. So that same day I added a periodic check that repairs whatever fell behind on its own, made the product tell “there's nothing” apart from “I'm still catching up”, and put that end-to-end test on the real environment.
The same questions, asked again from the same assistant, found the right answer in first place. A few days later we built GitHub repository review on the same pattern from day one: every event stored before it's processed, and a reconciliation for the ones that get lost.
A feature is really missing if the busiest entry point can't feed it
Soon after, the same bug came back in another form. The Brain could link knowledge to people, companies and projects: the graph had existed for a while, stored and navigable. But the tool assistants used to propose knowledge had no way to declare those links, so everything that came in through it was born disconnected. Each part had been validated on its own. Nobody had walked a real object from the entry point to the feature that used it.
The same goes for CI. An honest audit told us the pipeline checked types, lint, core logic and database permissions. The production build, the app tests and the remote environment tests we ran by hand in session, and one of the evaluations switched itself off without warning. The green badge only said that the checks it ran were green. The rest was trust me bro. Since then every release states what was verified, what was skipped and what's still to do. I ask the same of every PR: this site's template wants Testing, Risk and How to revert (more here).
And the test belongs on the deepest real boundary you can exercise without faking. For some actions, testing the path from the interface meant simulating half the framework, and we would have tested the simulation. We put the test on the real operation in the database, and we look at the interface on a preview environment.
A successful first call says nothing about the session
The connector that links assistants to the Brain passed the initial check: identity verified, first call green. A few minutes later it asked to sign in again. It looked like access expiring too early. The cause was the way one assistant's parallel connections renewed their access: they stepped on each other, and the authentication system, being careful, shut them all down.
Reconnecting and seeing another green call would have proved nothing. The only proof I accepted was a real, long session, with the access renewal happening in the middle, between two successful calls. For any connector the right check is a long session, with several connections open at once and recovery when one drops.
Show useful knowledge first, then ask them to connect the assistant
Connecting your own assistant to the Brain was what set us apart, so it felt natural to put it at step one of onboarding. We chose the opposite order: first connect email and approve the first proposal, then connect the assistant, then invite the team. An assistant connected to an empty Brain has nothing to say, and it burns the best moment of attention you'll get.
In the same decision we dropped the signup questions and the multi-screen wizard. In their place there's a checklist on the home page, with one primary action at a time, because a wizard hides the exact point where people get lost. The signal we watch is how long it takes to reach the first approved knowledge, in the same session.
Human approval is a production dependency
The Brain has one ground rule: everything that comes from chat, files, email, routines or assistants enters as a proposal, and becomes truth only after a human decision. Our own team, though, read the Brain straight from their assistants, without opening the app. Proposals piled up, and the approved part got staler every day.
An approval screen covers half of governance. The other half is getting the decision to whoever has to make it, where they already work. We designed reminders to owners outside the platform: batched, deduplicated, with a direct link to the queue, and stopping on their own once the queue is empty. An approval queue deserves the same attention as any other production backlog: if nobody approves, new knowledge never reaches the people who use it.
An approval holds for the action you saw
From the Brain an approval can at most prepare an email draft, never send it. Even so, we had to decide what happens when you don't know whether the action went through. Retrying is the standard answer to a temporary error, and here it would produce duplicate drafts. On a send, duplicate emails to a client. When the outcome is unknown, the system says so and waits for a person.
And the approval is tied to the exact action the person saw: content, sources, recipients, conditions. If anything changes afterwards, the approval lapses. Right before acting, the system rechecks that whoever approved still can. An “approved” left sitting in the interface while the action changes underneath authorizes something nobody saw.
The objection: too much governance for a newborn product
The strongest objection to all this: a freshly launched product has to ship and learn, and this much governance slows it down. I haven't changed my mind on that. Governance is the part we use every day, because it's what lets us have agents read and propose without writing truth on their own.
From Monday
- Write a test that walks the whole path from the user's side: create, approve, search, find.
- Next to every background step that can fail silently, put a check that repairs it.
- Walk a real object from the busiest entry point to the last feature that depends on it.
- Test connectors on a long session, with several connections open.
- Give approvals a channel to whoever has to decide.
- For every external effect, decide up front what you do when you don't know whether it went through.
- In every release, state the checks run, skipped and still to do.
// the Brain entry documenting the links bug is also the first to come in from an assistant with its links declared.