business_context.md are injected into every briefing and outrank anything the agent infers from store data. So the agent is not allowed to write them.
Instead it files a patch: here is the field, here is what it says now, here is what I think it should say, and here’s why. You apply it, edit it first, or dismiss it. That asymmetry is the whole design — an agent that could edit its own ground truth would turn one wrong inference into a permanent fact and then keep confirming it.
Review them in Settings → Business, above the profile forms.
What a patch looks like
business_context.md › How we make money), so applying it is surgery on that heading and not a rewrite of your prose.
Patches are fingerprinted on target plus proposed value, so a weekly job can’t grow the queue a near-duplicate row every Monday.
Where they come from
Proposing works in read mode — it isn’t a mutation, and a failed proposal never fails the briefing that produced it.
Why drift and promotion run weekly
Nothing else ages your context out. Without the drift audit, a repositioning you made in March quietly poisons every briefing after it. And facts are retrieved while profiles are injected — so a rule that lives only as a fact is a rule the agent forgets the moment the retriever ranks it below something newer. Promotion moves standing rules where they belong. When an app-scoped source ends up needing changes, it raises the sameknowledge_drift signal as anomalies, so it lands in your “needs attention” queue instead of waiting to be discovered.
Reviewing
Three outcomes per patch:- Apply — writes the value. The row becomes
source: user, because you decided; a document patch records a revision under your name. - Edit, then apply — the common case. A proposal is usually directionally right and phrased slightly wrong, so you fix the wording and apply that instead.
- Dismiss — rejected, and it won’t come back with the same fingerprint.
Two rules that are easy to get wrong
Promote the rule, not the evidence. Most facts are written as findings — “adding a paywall dropped downloads 63%”. The standing truth is “don’t gate downloads behind a paywall”; the number will be stale within a quarter and would sit in every future briefing as if it were current. Append is not replace. An append adds a line and can’t destroy an edit, so it isn’t blocked by a conflict. Otherwise every queued constraint would conflict the moment you touched that field — which is exactly what these proposals are asking you to go do.Deriving fields from your prose
The Update fields button on Settings → Business readsbusiness_context.md and maps it onto the profile fields. It runs when you ask, not while you’re typing, because it can both write and queue.
- Empty fields are filled directly. There is nothing to lose and no conflict to review.
- Fields that disagree become patches. You see your value against the proposed one.
- Low-confidence findings are dropped below a 0.55 floor.
- Rewordings are rejected. A proposal that restates your value with less detail in it is thrown away rather than queued — except for factual fields (company name, website, stage, business model, monetization, pricing) where replacing the old value is the point.
teamSize and primaryMarkets are deliberately never extracted: a document that mentions “we’re a team of three” or names a country is far more likely describing a customer than a fact about your company.
Related docs
- Company Knowledge Base — the layers a patch can target
- Library — where document patches land
- Memory — facts and episodes, the layer promotion draws from
- Knowledge Patches API — REST surface