As most teams take on more agents and strive to make AI more useful the questions that becomes even more pressing is where do we store the information they need to access, what they act on, create and how do we manage it. Give everyone and their agents free access to your context layer and they will create chaos. But we allow all agents to write into our company brain and we sleep well at night. So how do we do it? We built a workspace that says no.
What does a workspace that says no look like you may wonder?
For us there are three core concepts. Let’s jump into each one of them starting with the door.
Door - one way in
There is one door. Every write goes through the same checks, no matter if it comes from a person, an agent, or a scheduled job. We basically ask: are you allowed to write here? Does the write have the right shape for this item, a number for a metric, a text for a document, an entry for a list. Are you pointing at a real item, not a name you guessed? If you are updating a document, do you have the latest version? If the answer to any of those is no, the write is refused and you need to go back and redo. If it passes, it is stamped with who wrote it and what kind of caller they were, and it lands all at once or not at all. There is no other way into the context layer. The admin console goes through the same door as the agents.
Rules - what defines an item
Each item comes with its own rules. It specifies who can read this information, who can write to it. A scheduled job may be allowed to write one number and nothing else. Only the owner of an item can make fundamental adjustments to it.This is important since local items can differ from the company brain and that flexibility needs to be enabled otherwise you will get an input window that becomes to rigid.
Logs - the traces of what has been touched
Everything that is touched in our company brain gets logged regardless if it succeeds or fails or is authored by machine or human. If context is touched in any way we log it. It has been instrumental in bug resolutions, understanding agent reasoning and decision making as well as enabling us quickly to validate which context is essential for our team.
Why saying no becomes even more important with scale
Yep, all the time especially towards new agents running different tasks and towards new team members trying to edit sensitive information. Each time the company brain says no we enforce a healthy structure and a way of working that can scale and hold. Because each human or agent you add you will hav another writer. In our team each human has about 7 agents. So it is pretty easy to imagine what happens when you move beyond two people with multiple agents. Context will start drifting and a handful of scheduled chron jobs is enough to create unrepairable chaos. Today we pull in transcripts, numbers, change logs and it happens so quickly that we have double digit additions almost every 2 hours to the context layer.
What we see is that the things that go wrong at that point are, the wrong writer, the wrong version or information going to the wrong place. That is why we built Sento to map towards these rules and protect the company context with scale.
The numbers
Since our workspace opened on 14 August: 25710 calls by agents. 22584 went through, 2780 were refused, 346 errored. It snowballs quickly.
Frequently asked questions
Isn't this just a git repository with branch protection?
Closer than most comparisons, and git is the honest first step for a technical team. The differences are the ones a non-engineer notices. Rules live per entity, not per repository. A courier can be allowed to write one metric and nothing else. Content written by an automated source is served to agents marked as data rather than instructions, which git has no concept of. And the reader is an agent asking over a connector at the moment it acts, not a person opening a file.
Why let agents write at all? Just have people write.
People do write, and everything that defines a term or sets a rule here was written by a person. But the things that keep a company brain current are the boring things: what merged today, what the number is this morning, what a customer said on the call. Nobody feeds those into a central archive by hand for long. The critics of central repositories are right about that. Our answer is that ours feeds itself, through the gate, with a name on every write.
Doesn't a strict gate teach agents to stop writing?
That is the real risk, and it is testable. A rejection is silent and teaches a caller that writing here is unreliable, which is exactly how a context layer decays. So we watch the rejection rate rather than argue about design intent.
What happens when two agents write the same thing at once?
For texts, the second write carries a version number that no longer matches and is rejected. The caller re-reads, re-applies its change and writes again. Nothing is merged over anything. For lists, both entries land, because a list is a record and the record is the point.