For two years the interesting question about company knowledge and AI was retrieval: can the agent find the answer? That question is largely solved. The one replacing it is harder, because agents have started to write. They file the research, update the playbook, record the decision. Once a process can write into the place your company keeps what it knows, you stop asking whether it can find the answer. You start asking whether you can trust what's in there now, and whether you can tell who put it there.
That is a governance problem, and almost nobody in this category is treating it as one.
Tatara is a governed document store: a company brain of plain Markdown documents that people read and edit, and that agents read and write over the Model Context Protocol (MCP). We built the governance first, before the editor and before the formats. This post explains why.
What is a governed context layer?
A governed context layer is a shared store of company knowledge where every write is constrained and attributed at the moment it happens, instead of being inspected afterwards. Three properties separate it from a store that is only shared:
- Required fields. A write missing the metadata that makes it findable and classifiable is rejected outright, not accepted and flagged.
- A curated vocabulary. Properties come from a registry the company controls, and tags are steered toward one, so anything written can be filtered later.
- Provenance stamped by the system. Every save records who or what made it. The system takes that from the authenticated credential, never from what the writer says about itself.
An ungoverned context layer is a shared drive with an API on the front. That worked while the only writers were people, because people write slowly and are socially accountable for what they write. Your colleague knows their name is on it. It stops working when the writer is a process that can produce two hundred documents overnight, has no name, and feels no embarrassment.
The industry has spent its energy on the read path: embeddings, rerankers, bigger context windows. The write path got a POST endpoint and a shrug.
What goes wrong when agents write freely into shared knowledge?
Four things go wrong, roughly in this order: documents nobody can find, vocabulary drift, changes nobody reviews, and self-citation.
Documents nobody can find. An agent that writes a body with no title, no type and no description has stored a file, not knowledge. It won't rank in a search or show up usefully in a list, and the next agent looking for the same thing won't find it, so it writes it again. Now there are two, and neither is the one to trust.
Vocabulary drift. Left alone, a fleet of agents will coin pricing, price, pricing-strategy and pricing-2026 inside a fortnight. Each near-synonym halves the value of the filter. A taxonomy nobody steers turns into a word cloud, and it takes a person a day to unpick.
Change nobody reviews. If an agent's write looks byte for byte like a colleague's, no query can tell them apart. The team is left choosing between reviewing every change and reviewing none. It reviews none, out of arithmetic rather than negligence.
Self-citation. This is the one that compounds, and the reason the rest matters. A model asserts something plausible, and the assertion gets written into the brain. On the next run, retrieval returns it, now carrying the authority of a company document. It sits next to the pricing page a human wrote and looks exactly like it. Storing the model's guess has promoted it to a company fact. It then grounds the next answer, which gets written down too.
Storage is not verification. Without provenance, writing a guess down is how it becomes a fact.
Why must an agent not pass as a person?
An agent must not pass as a person because every way a team keeps knowledge honest (review, accountability, rollback, plain human trust) depends on knowing who wrote something. Erase that, and all four stop working at once.
Accountability needs a person at the end of it. "Who decided this?" has to resolve to someone you can ask. An agent's write is a proposal that a human may never have read. If the record can't tell the two apart, it is asserting an approval that never happened. That's why Tatara never gives an agent write a human owner: the MCP write path sets the document's owner to null instead of borrowing the identity of whoever's token the agent is holding.
Review only works if you can filter. With attribution, "show me what the agents wrote since Tuesday" is a single filter. Without it, the same question returns every edit anyone made to anything, and the review doesn't happen.
Blast radius is bounded by identity. A wrong human edit is one person's mistake at human speed. A wrong agent edit is a loop: the same faulty instruction applied to forty documents in an hour, each one confidently formatted. Undoing it means selecting exactly the writes one credential made, so the credential has to be on the record at write time. You can't reconstruct it later from timestamps and guesswork.
And the self-citation loop only breaks on a label. The one thing standing between a model's output and its laundering into company knowledge is a durable mark saying a model produced it. A person reads a document stamped agent:claude-desktop more sceptically than one their colleague signed, which is correct, and a retrieval layer that can filter on the stamp does the same.
None of this argues against agents writing. Agents writing into the brain is the point. A brain nobody fills is a brain nobody uses, and company knowledge bases have always failed in the ordinary way: writing them is a chore. The argument is narrower and firmer than that. Agent writes are welcome; anonymous ones are not.
What is provenance, and what must a provenance record contain?
Provenance is the record of who made a change, when, to what, and under which credential, written by the system rather than supplied by the writer. That last part carries the weight. If the writer supplies its own identity, you don't have a record. You have a claim.
| A provenance record must answer | Why it matters |
|---|---|
| Who or what made the change | Separates an agent write from a person's, which is the whole point |
| Which class of actor it was | A human, an external agent token and a background process each warrant different scrutiny |
| Which document, and when | Scopes a rollback to the damage rather than the day |
| Under which credential | Bounds the blast radius of one misconfigured or compromised agent |
| Whether the record can be altered later | A log the application can rewrite proves nothing about the application |
Here is how Tatara handles each one.
Every document row carries a source string stamped from the authenticated token: agent:<slug>, where the slug comes from the token's own name. The agent can't set it. It isn't an input to the write tool, and a source key smuggled into the frontmatter blob is stripped before the write is composed. Human and agent writes can be told apart at the row level, permanently, without consulting a log.
Every document and folder mutation also writes one row to an append-only audit_events table, inside the same database transaction as the mutation. That detail is what makes the record trustworthy and not decorative. A committed mutation always has its audit record, and a failed audit write rolls the mutation back with it. Nothing in the system can change a document and forget to say so.
Each row records the actor type, which is one of five values in a Postgres enum (human, agent_token, platform_agent, maintenance_agent, system), plus the actor's id and name, the event type, the target document or folder, a details blob specific to the event, and a timestamp.
The table is append-only, and the database enforces that, not convention: a trigger raises an exception on UPDATE and DELETE. Our own service role bypasses row-level security, as service roles do, but the trigger still fires for it, so an ordinary update or delete from our own code fails too. Someone holding our database credentials could still switch the trigger off, so it protects the record from mistakes rather than from a stolen credential.
It also has no foreign keys, on purpose. An audit event has to outlive the row it describes: delete the document, and the record of who deleted it stays.
Why do required fields belong at write time, not in a cleanup pass?
Required fields belong at write time because the cleanup pass never happens, and because every future read pays for a missing field, not the writer who skipped it.
Creating a document over MCP requires a type, a destination folder, a title, a description, a body, and one to five tags. None of them are optional, and none are quietly inferred. The description is one plain sentence stating what the document is, and listing and search work from it, so a document without one is close to invisible however good its body.
A rejection isn't a dead end. It says what's wrong and how to fix it, phrased for the agent rather than for you, so the agent corrects and re-sends inside its own loop. An ambiguous folder name comes back with the candidate paths so the agent can re-send the exact one. A property nobody has defined comes back with the list of properties that do exist. A rejected write is a normal step in a working agent loop, not a fault. Watch an agent work in Tatara and you'll see them. They are the system doing its job.
Not every part of the vocabulary is governed the same way, though, and the difference is the interesting part:
- Custom properties are closed. Only keys in the company's registry are accepted. An unregistered key, or a value of the wrong type, rejects the whole write, with the list of defined properties attached so the next attempt succeeds.
- Tags are steered, not gated. The tag registry has three tiers: the first names the area, the second the topic, the third the goal. Agents are told how many of each to apply. If nothing in the registry fits, the agent may coin a short new tag, which is accepted and flagged for curation, never rejected.
The reason for the split is a rule worth stealing. A property is schema. Views, filters and typed tables are built on it, so a wrong type corrupts everything computed downstream, and nobody notices until someone reads a wrong number off a table and acts on it. A tag is a label. A wrong one costs a single curation pass by a person who can see it in a list. Govern strictly where mistakes are silent and compound. Steer where they're visible and cheap. Maximum strictness everywhere just teaches agents to route around you.
Does governance slow the agents down?
No. Governance moves the cost to the point where it is cheapest to pay.
A rejected write costs one round trip inside the agent's own session. The agent is still there, holding the full context of what it was trying to do, and it fixes and re-sends in seconds. An ungoverned write costs a person an afternoon three weeks later. Usually nobody spends that afternoon. They just get slightly worse answers from their agents, indefinitely, and never connect the two.
Governance also improves the read path, which teams tend to underestimate. Required titles, descriptions and types are exactly the fields retrieval ranks on. When every document in a brain is described in one honest sentence, agents search it well. The discipline that makes writes trustworthy is the same discipline that makes reads work, so retrieval isn't a consolation prize for paying for governance.
What should you demand of any tool that lets agents write?
Any tool that lets agents write should pass seven tests, and none of them need a compliance certificate to check. You can verify all seven in an afternoon with a test token and a throwaway agent.
- Attribution the writer cannot forge. The identity must be stamped from the authenticated credential and never accepted as a parameter. Ask what happens when the client sends its own author field. If the answer is "we store it", there is no provenance.
- Attribution on the record, not only in the log. A log answers "what happened last month". A field on the document answers "what am I reading right now", which is the question a person actually has.
- An append-only trail the database enforces. The database should enforce it, not good intentions in the service layer. Ask what it would take for the vendor's own service account to delete rows.
- Validation at write time, with instructive rejections. A gate that only says "invalid" produces agents that retry blindly, then give up and write somewhere ungoverned instead. The error has to teach.
- A way to freeze a document. Some documents shouldn't change without a human in the room. A locked Tatara document refuses every mutation, from agents and humans alike, until someone explicitly unlocks it, and both the lock and the unlock land in the audit trail.
- Recoverable deletes. Deletion is the mutation you're most likely to want reversed and least likely to notice. Agents in Tatara delete recoverably and can restore both documents and folders. An agent asked to delete a folder that isn't empty is told how much would go and told to confirm with a person first.
- A portable format. If the record exists only inside a proprietary schema, the governance belongs to the vendor, not to you. Tatara documents are plain Markdown with YAML frontmatter, readable in any editor and yours to take elsewhere.
All of it rests on one sentence: humans own the brain, agents help fill it, and the record always says which of the two happened. Every design decision above follows from that commitment, including the awkward ones.
If you want to see it work, the free tier is 500 documents and takes no card. Connect an agent over MCP, give it something real to write, then open what it left behind. Its owner reads Unassigned, because no person wrote it.
Related reading: The governed document: one source, two audiences on how one artifact can serve a person and a model at once, and Why your AI agents keep forgetting what your company knows on the problem a company brain exists to solve.
