Team0 · Agentic understanding
Thirty-one things you have to solve before an agent can understand you.
Almost everything sold as "AI that knows you" is retrieval. You write things down, it embeds them, it finds them again. But remembering a sentence is not the same as knowing whether it is still true.
This is the engineering recipe inside the Team0 World Model: the maintained understanding that powers your Team0 Chief. It keeps track of what is current, what changed, what conflicts, what remains unknown, and who is allowed to see it. These are the 31 problems that make that possible.
A second brain remembers. Understanding decides what is still true.
The build out
Part one · Getting it in
Email, calendar, chat, meetings, documents, tools, other agents. Every one arrives in a different format with different guarantees, and every one has to end up as the same kind of object or nothing downstream can reason across them.
Fails like this
The agent answers well about your inbox and badly about the same person’s meetings, because those two live in different shapes and never met.
Every claim needs an author, a time, and a source you can walk back to. Not for compliance — for arithmetic. You cannot resolve a contradiction between two claims without knowing which one is newer and who stands behind each.
If you do not know where a fact came from, you cannot prove it wrong.
When something is true and when you learned it are different timestamps, and you need both. A document from March describing a decision from January is January evidence. Systems with one clock also break on out-of-order arrival: a backfill that runs oldest-last will cheerfully overwrite current truth with history.
The hardest ordinary problem in the stack. Two messages say "Dana." One is your accountant, one is a customer’s PM. A calendar invite has an email address; a chat transcript has a display name; a meeting recording has neither. The line that matters is which keys may auto-merge and which may only suggest. An email address is an identity claim. A phone number is not — signature phones are shared company mainlines, and matching on one is a false-merge generator.
Fails like this
Someone’s first name is also a substring of a common word, so "tomorrow" matches "Tom" and the agent files a commitment against a person who was never mentioned. Fix it with a keyword exception list and you have started a list that never ends.
Part two · Holding it
Storing something and believing it are different operations. A notes app has exactly one tier: if it is in there, it is true. That is why these systems repeat stale and wrong things back to you with total confidence — there was never a place to put "I saw this claim but I do not vouch for it." You need at least three states: evidence, candidate, and trusted. And nothing may promote itself.
It can hold something without believing it.
Having three states is not enough if deduplication can quietly merge across them. If a trusted belief can absorb a candidate because the text is similar, you built one tier with extra steps.
When someone says "no, that is wrong," it has to beat every inference, every source, and every confident restatement — not until the next ingest run overwrites it. The mechanism is unglamorous and load-bearing: a corrected fact is pinned, and pinned rows are exempt from deduplication, retirement and supersession.
If you close something and the source that created it gets re-read next cycle, it comes straight back. Every closure needs to leave a marker the writer checks before inserting.
Fails like this
Your resolver works perfectly and silently undoes itself every night.
Part three · Keeping it true
This is the part almost nobody builds, and it is most of the work.
A retired fact keeps its row and gets marked, with a pointer to whatever replaced it. Deletion destroys your ability to answer "why did you think that?" and makes every mistake permanent instead of reversible.
Not just that something was retired, but by whom and why: a deadline expired, a user corrected it, a newer value superseded it, an action closed it. An untagged invalidation is unauditable and un-revertable.
If you cannot say who retired a fact and why, you cannot undo it — and one day you will need to.
If two subsystems can both close an obligation, they will fight, they will disagree, and you will never be sure which one won. Decide who owns each lifecycle and make everyone else mirror it.
"These two sentences are 70% similar" is a deduplication hint. It is not grounds for declaring one of them obsolete. Supersession must key on a typed field — same person, same attribute — or you get false retirements that are almost impossible to trace.
Fails like this
Two payments to the same supplier, a month apart. The receipts are worded identically apart from the amount, so the second one reads as an update of the first — and one of your payments quietly stops existing.
Let the model classify into a closed taxonomy — same thing, update, unrelated, cannot tell — with "cannot tell" as the default. Then let deterministic code decide what each verdict is allowed to do. And do not build a threshold on the model’s confidence score until you have looked at the distribution. We did.
The confidence scores clustered at 0.80 and discriminated nothing.
Some contradictions cannot be resolved from evidence. The right move is to ask the human, and the discipline is to ask rarely — one question a day, not one per conflict. Otherwise the honest design becomes an interrogation, people stop answering, and you lose the ground truth you were collecting. Until the human answers, both facts stay live. Pretending you resolved it is worse.
Every stage that retires or rewrites belief should ship with its computation on and its writes off, and soak that way. Half-on is a deliberate state, not an unfinished one.
If you record a new signal, name the thing that consumes it in the same change. Otherwise you get a beautifully maintained column that nothing has ever read. Ask me how I know.
Part four · Finding it
If retrieval, the brief, the proactive nudge and the meeting prep each run their own lookup with their own scoring, you do not have one understanding — you have four, and they will disagree in front of the user.
Semantic similarity alone under-serves nearly every real question. "What is open with Dana?" is not a similarity query, it is a structural one. You need several distinct lanes over one corpus: direct matches, open obligations, connected evidence, recent context, and the original receipts behind each. And whatever you do not embed is invisible to meaning-search permanently and silently — embedding coverage is a correctness property, not an optimisation.
Deduplicate before you reason, and carry why each item is here into the reasoning. A fact retrieved because it is an open promise means something different from the same fact retrieved because it is recent.
Part five · Judging it
Who owns this claim, when was it true, was it ever corrected, and what part is still unfinished. Four separate questions with four separate answers.
The single most under-built piece in the category. "The proposal," "the pricing thing," "what we discussed Tuesday," and a calendar event may all be one matter — or four. Get this wrong and everything downstream double-counts.
Not "was it marked done" — did it finish, according to whatever authority is highest. A structured record saying completed must outrank a paragraph of narrative that still describes it as open.
Fails like this
A task is completed, the record says completed, the user has said out loud "I already sent that" — and the evening summary tells them to send it. Every layer was internally consistent. None of them was current.
Consistent and wrong is a state your quality gate passes.
Two sources disagree. The answer is not to pick the confident one, and not to average them. It is to notice, and to say so.
You cannot say "there is nothing else," "no one has replied," or "you have no history with this person" unless you know exactly what you searched and what you could not reach. Absence is a claim and needs the same authority as any other claim.
You cannot say "there is nothing else" unless you know what you looked at.
Part six · Knowing what matters
Being right is not the same as being useful. Everything above gets you a system that is correct and exhausting.
Which things matter to this person comes from what they actually do: pinning, editing, acting, asking again — and dismissing, deleting, skipping. Fold those into a weight that decays, so a correction fades rather than scarring the record forever. Recency is not importance. Frequency is not importance. Neither is your ranking function’s opinion.
A spouse and a vendor you emailed once are not the same kind of contact, and a contact who mattered last year may not now. But dormancy has to have exemptions — family does not stop being family because you did not email them this quarter.
Picking up where you left off is what makes a system feel like it has been paying attention, and grouping related facts into a running thread is how you get it. The trap is treating that thread as evidence. It is a way of talking about what happened, not a new source of facts — and an agent that confuses the two will speak confidently about things it cannot actually see.
A storyline lets the agent sound like it is tracking an arc without giving it anything new to reason over.
The hardest behaviour in the whole product, and the one nobody lists. An agent that is correct and constant is worse than one that is correct and occasional. That means a real model of whether this has already been raised, whether the moment is right, and whether it earns an interruption at all. It also means some things you deliberately never store — how someone seemed to be feeling can shape timing in the moment and should never become a durable belief about a person.
Part seven · Who is allowed to see it
If your agent ever faces anyone other than its owner — a website visitor, a cold emailer, a meeting attendee, another person’s agent — this section is not optional, and it is where the serious mistakes live.
A public conversation must be served from a publicly-scoped read: the private graph is filtered out before retrieval, so the model never receives what it must not reveal. Prompt instructions and output scrubbing are not defences. If a refusal is the mechanism, you did not build a boundary — you got obedience, and obedience is one clever message away from failing.
Do not tell the model not to say it. Do not give it to the model.
Every entry point must declare who is talking — never infer it, never default it. The original sin in our own system was that the absence of a contract meant full owner access: "owner" was what you got when nobody said anything. Exposure, by contrast, may default — always to the most restrictive thing. And a related trap: an internal run may legitimately see owner data without that making its output owner-authored. What a run may see and who said something are different questions.
A stranger becomes known because you emailed them or you accepted a meeting with them — never because they emailed you repeatedly, never because they are in a group thread, and never because your own agent replied to them. Receipt, membership, attendance, volume and recency prove contact. They do not prove relationship.
The hierarchy
| Question | Answered by |
|---|---|
| May this conversation see the row? | the channel’s contract |
| May the system assert it as true? | the trust lane |
| Where did it come from? | exact provenance |
| Is it related to the owner? | structural relationship evidence |
| Did the owner actually see this item? | exact-item attention evidence |
| May we bring it up unprompted? | that surface’s own policy |
Six different questions. Most systems answer all six with "it is in the database."
What we got wrong
We first controlled public exposure with a blocklist — the sources that must never be shown outside. That works right up until someone adds a new source and does not think about the list, because anything unlisted defaults to visible. The fix is to invert it: nothing is publicly readable unless it has been explicitly named. A new source is now private by default, and forgetting is safe rather than expensive.
We audited the trust layer thoroughly and it passed. There was still a live leak, because a component assembled part of its own prompt outside the layer we were auditing. Enumerate everything concatenated into the final prompt, not the parts you designed to be safe.
Our contract module had passing tests while the real path wrote nothing at all. Require positive evidence from the production path and a durable round-trip, or you have tested your mocks.
And one more, because negative results deserve publishing: we built a safety gate, tested it across four independent blinded rounds, and the population it could safely act on was zero every single time. The right move was to surface that as an open architecture decision — not to ship it because it was already written.
Inside the Team0 World Model
These 31 ingredients are the machinery inside the Team0 World Model. Almost every one is a question about state: what is current, what changed, what conflicts, what remains unknown, according to whom, and who may see it. A better language model does not solve those questions. It can only make the wrong answer more persuasive.
That is why a larger context window was never enough. The problem is not how much an agent can see at once. It is what the system is entitled to believe, how that belief changes, and whether the agent asking has permission to use it.
The Team0 Chief is the application you work with. The Team0 World Model is the maintained understanding underneath it. Correct Team0 once and it stops carrying that mistake forward; connect another permitted agent and it can consult the same current understanding without rebuilding your business from scratch.
Meet the Team0 World Model