Every AI agent session starts as a fresh mind. It has no memory of yesterday, no memory of the correction you gave it last week, and no idea what your company has already decided.
That is fine for one developer with one project. It falls apart the moment you have five teams, because now the things that must be true everywhere have to somehow be true in every session, of every project, forever.
The obvious answer is to write a good prompt and paste it into each project. That answer fails twice. It drifts out of sync the first week, because six copies of a rule are six rules. And every pasted line is paid for in every session forever, so the document that encodes your standards becomes a tax on all future work.
The better answer is the one your company already uses for people: inheritance, scoped by the org chart, with a channel for asking a human.
Here is the architecture, and then the part where I show you the data on which half of it worked.
Tier one is the constitution. One document at the root, loaded automatically by every session in every project beneath it. It holds identity and the things that are never negotiable: what counts as evidence, what "done" means, the safety boundaries that are legal rather than stylistic.
Mine is capped at about forty lines, and the cap is the design, not tidiness. Every line here is read by every session of every project, forever. A constitution that grows is a bill that arrives every time anyone starts work. If a rule is not needed by every project before it knows what it is doing, it does not belong in tier one.
Tier two is the project constitution. What is true for this project and nothing more. It inherits tier one for free, so it never restates it.
Tier three is everything else. In my case, several hundred documents. None of them load at startup.
Notice that the cost runs opposite to the volume. The smallest tier is the most expensive because everyone pays for it always. The largest tier is nearly free because nobody pays for it until something asks. Most people build this upside down: they put the huge context at the top and wonder why every session is slow and expensive.
A pile of documents nobody reads is not memory. What turns it into memory is a short table in tier two that maps an action to the thing you must read before doing it. Before you touch billing code, read this. Before you change anything a customer sees, read that.
The agent does not go looking for knowledge. The knowledge is delivered at the moment of the action that needs it.
This distinction sounds like a detail. It is the entire difference between the half of my system that worked and the half that died, and I have the numbers.
An agent organization needs two human channels, and they are not the same thing.
Escalation is the agent saying "I need a decision that is not mine to make." A production change, a spend commitment, anything irreversible.
Calibration is a human saying "that was wrong, and here is the shape of the wrongness." This is the more valuable of the two and the one most setups drop entirely. A correction that lives only in a chat window is a correction you will pay for again in three weeks.
Both should run through the channel your organization already lives in. For most companies that is Teams. Not because Teams is special, but because a notification surface people already have open is the only kind that gets read. I have built beautiful dashboards for this. Nobody opened them, including me.
Threads matter here more than they look. A thread gives a correction a durable home attached to the thing being corrected, which is exactly the raw material you need if you ever want to fold that correction back into tier two.
Once you accept the org chart as the scoping model, most of the hard problems stop being yours.
Identity and permission: your existing directory. An agent becomes a principal in the directory you already govern. It joins groups, it inherits those groups' rights, and it is revoked exactly the way a leaver is revoked. The alternative is a second permission model that lives beside the real one and drifts away from it, which is the security incident everyone eventually writes up.
This also answers the question every risk team asks first, which is not "is the AI accurate" but "what can it reach, and who decided that." If the answer is "the same groups that govern the humans doing this work," you are having a very different conversation.
The tiers: your existing document storage. Tier one is a site everyone reads, referenced rather than copied, so a change to the rules is a reviewable, versioned event instead of an edit nobody noticed. Tier two lives with the team that owns the work, so the boundary is one the company already agreed on rather than a folder convention somebody invented on a Tuesday. And personal scope goes in personal storage: private by default, follows the person, cannot leak into shared tiers by accident, because the permission is the boundary rather than a naming rule.
Audit: your existing audit log. Who told the agent what, and when. You inherit the answer instead of building an audit system for agents from scratch.
None of this is a product to buy. That is the point. The boring parts of an agent platform, identity and scoping and audit and a channel humans actually read, are precisely the parts your company solved years ago for its people. An agent organization should inherit them, not reinvent weaker copies.
Information has to flow upward or the upper tiers are fiction. But if individual identity flows upward, you have built surveillance, and surveillance destroys the thing you were collecting.
The resolution is that the signal carries the pattern, not the person.
PERMITTED: "4 people flagged this standard as unclear this month"
NOT PERMITTED: "Sarah flagged it 4 times"
Identity is stripped at the team tier. Everything above receives patterns only, and no reverse lookup is possible by construction. That last clause matters: it is a structural property of how permissions and aggregation are built, not a policy somebody promised to follow.
There is also a threshold. A single event is not a pattern, so nothing escalates until several signals of the same type appear. This stops one bad afternoon from being surfaced upward as an organizational trend.
The governing shape is: private truth, then anonymous patterns, then organizational intelligence.
Here is why this is engineering and not ethics decoration. If people believe their personal tier can be used against them, they will populate it performatively. Performative input produces false patterns. False patterns produce confident, wrong decisions at the top of the organization, which is worse than having no system at all. The entire intelligence value of the system depends on the bottom tier being genuinely private, so the privacy guarantee is load-bearing infrastructure.
A memory system that only stores is a filing cabinet. What makes it compound is routing the questions.
When someone asks the assistant about a standard or a policy:
That last inversion is the valuable one. Three people asking the same question about a rule is evidence about the rule, not about the people. Most organizations read it the other way around and send the three people to training.
The accumulating question log turns out to be a real-time map of where the organization is confused, produced continuously, with no survey and no focus group.
I added one more piece: a shared log where each project session ends by writing one line about what moved, feeding a cross-project summary.
Twenty two days later I counted what was actually in it.
Ten entries. Eight of them in the first three days. One more eleven days ago. Then nothing.
All ten came from a single project, out of five. The live one with a real customer has never written a line.
The shared summary, the entire reason the layer existed, was last modified the day it was created. It still confidently describes a project as a shell folder that I retired eight days afterward. It is not stale. It is wrong, and it looks authoritative while being wrong, which is considerably worse than being empty.
There was also a schema drift I never noticed: the timestamp is an integer in the first row and a formatted string in the last. I only found out because the script I wrote to analyze all this crashed on it.
The design was fine. The trigger was not.
Writing that line was a remembered act. Nothing fired it. It sat at the end of a session and depended on somebody choosing to do it while tired and finished. That works for about three days.
Tier three works because it is bound to an act. Touch the file, get the rule. Nothing depends on anyone remembering the rule exists.
Same system. Same week. Same author. The only difference is what starts the write.
I have a second case that removes any remaining doubt. I built a lookup table for operational answers, seeded it with eight rows, and told the agent to add to it as it went. A day later it had eight rows. Zero added, while that same day's work had produced at least three entries that qualified and filed them somewhere else. The table did not need more rows. It needed a trigger.
Anything that depends on remembering will not happen. Bind it to an act, or it does not exist.
Not because agents are careless. Because every session is a fresh mind with no memory of having agreed to the habit. You cannot build organizational memory out of good intentions distributed across amnesiacs.
And pull-based systems fail in the most flattering way possible. The file is still there. The design still reads well in the diagram. Nothing errors. You do not find out until you go and count the rows, which is why you should go and count the rows.
Two corollaries I paid for:
The read side needs pushing too. I assumed someone would open the summary. Nobody did for three weeks, including its author. A summary nobody is handed is a summary nobody reads. Surface it unprompted at the start of a session, or accept that it does not exist.
Anything derived needs a freshness check. A dashboard that is silently eleven days stale is worse than no dashboard, because it still looks like an answer. Stamp it with when it was generated and make it complain when that gets old.
In the order I would do it again:
Start with a software team, whatever the eventual target is. Developers already live in this world, already use context files, and already feel the specific pain of losing the reasoning behind decisions. You do not have to explain the concept to them. You show them, and two weeks later either someone says it changed how they work, or it did not, and you have your answer cheaply.
The architecture is not the hard part. Getting it to still be running in three weeks is the hard part, and that is decided entirely by what fires the write.