One of the first design decisions I made for Sempleo was also one of the easiest. When an agent learns something new about your team — a client preference, a stakeholder map, a vocabulary shift — it does not write that thing to your context. It proposes the change. A human approves, edits, or rejects it. Only then does the context change.
Pending, not silent. That is the whole pattern.
This is the design choice I get asked about most often in early demos, and it is the one I am least willing to soften. I want to explain why, because I think the question of how agents learn about teams is going to be the defining product question of this category, and I have an opinionated answer.
Silent writes are the failure mode of every context platform I have seen. The temptation is obvious. An agent notices that your client seems to prefer short emails; it writes “prefers short emails” to the client layer; next time, the draft is shorter. The team is delighted in the moment. Nobody is delighted three months later when the context is full of claims nobody remembers approving, half of which were right and half of which were a model’s plausible guess on a small sample. The team loses trust in the context. Without trust, the layer becomes useless, because you cannot let agents act on a layer you no longer believe.
The governance property you want is simple to state: every claim in your context has a human who can be pointed at. Silent writes violate that property on day one.
What pending changes actually look like. When an agent drafts an email and picks up on a pattern — say, three consecutive responses from a client asking for tighter summaries — it does two things. It completes the task it was given, using its current best guess. And it files a pending change against the client layer: Preference detected: short-form summaries. Evidence: three threads, last 30 days. Proposed field: client.{id}.preferences.summary_length = “brief.” The account lead sees the pending change in their review queue. They accept it, edit it, or mark it as a one-off.
The review queue is ordered by who owns the affected layer. The account lead sees client proposals. The team lead sees team proposals. Brand and Legal see company proposals. The user sees their own. Nobody is buried under changes they do not own.
The cost is real. It is also worth it. Pending-not-silent costs you a small amount of speed. The agent is not quite as autonomous as it could be. The first time a team sees a review queue they sometimes flinch — wait, I have to approve everything?— and then they realise they only approve the proposals, which arrive at a rate of three or four a week, not the outputs, which arrive by the hundreds. The cost is a few minutes a week. The benefit is a context layer a team still trusts two years from now.
Review queues are the actual product surface. For most of our customers, the review queue is where the team lead and the ops lead spend the ten minutes a day that make the rest of the system work. It is not glamorous. It is not the part we demo first. But it is the part that keeps the context clean, and clean context is what the agents read from. The queue is the mechanism by which the team’s judgement compounds into the context over time.
There is a version of this company that does not have a review queue. It is faster to demo. It is easier to get pilots signed. It is also, I think, a product that quietly breaks inside six months at every customer who takes it seriously — the same way every unsupervised auto-note-taker and auto-CRM-enricher I have seen has broken. The governance has to be the first-class citizen. Everything else is downstream of it.
If you take one thing from this post, take this: the question to ask any context product is not “how smart is the model that writes to your context,” it is “who approves what, and where is the audit trail.” The answer should be a human, and the answer should be visible.
The context page has a walkthrough of a review queue in action. Founding-customer applications are open.
