Skip to main content
The Vault is what the agent learned. The knowledge base is what you told it. Keeping the two separate is the point: a belief the agent inferred from store data should never quietly outrank a fact you stated about your own company. Everything here is optional. An owner who fills in nothing gets exactly the briefing they got before this existed — the renderers return an empty string when there is no content, so nothing is added to the prompt.

Four layers

Below all of this sits the Vault — facts and episodes, scored and evicted. Untouched by this feature and still the learning loop.

Precedence

When a fact contradicts a profile field, the profile wins and a contradicts edge is written in the memory graph. The reverse never happens on its own: the agent can only propose a change to your context, never make one. See Knowledge Patches.

Why company and app are separate

A founder with five apps has one company and five products. Brand voice, business model, and company-wide constraints are shared; ICP, pricing, and “do not touch the app name” are per-product. Merging them would force you to either repeat yourself five times or write a profile too vague to change any recommendation. Runs are per-app, so each one is injected company + this app.

What the fields are for

Two fields are worth more than the rest combined:
  • constraints (company) — “Never recommend removing the free tier.” Rendered as a blocking rule; the agent will not propose an action that breaks one.
  • doNotTouch (app) — “app name”, “the free tier”, “MX pricing”. Turns “please stop suggesting this” from a weekly chat correction into structure.
Both stay switched off while the profile is an unreviewed draft. A hallucinated constraint blocking real work is the worst failure this feature can have, so a rule only becomes binding once you confirm it.

Token budget

Always-on context has to stay bounded or it displaces the store data the briefing is actually about. Truncation always happens at a heading boundary, never mid-sentence — a severed clause reads to the model as a complete thought, which is worse than a missing section. At most 3 documents can be pinned always-on; a fourth would only shrink the other three. To give a single app its own always-on context, pin a document and scope it to that app: pinned documents are read on every briefing for the apps that can see them. business_context.md itself stays account-wide. Every run logs a company_context_injected event with the rendered size, so budget creep is visible before it degrades a briefing.

You don’t start from a blank form

Roughly eight minutes after you connect an app, the Co-founder drafts your profiles and a first business_context.md from evidence it already has: Reading your own workspace beats re-fetching the store: it is richer than a lookup response, works the same for Google Play, and can’t be rate-limited. A live store lookup happens only when the workspace has no description. Three guards keep the draft honest:
  • It never overwrites you. Any profile you already confirmed is skipped, and business_context.md is left alone if it contains a single word of your own prose.
  • Weak evidence writes nothing. The model is told to return null rather than guess. Fewer than two populated fields → no draft, because a review banner over an empty form is worse than no banner.
  • Vault-only evidence writes nothing. Re-deriving a profile from facts the agent already injects just restates them in a second block.
Until you confirm it, the draft is still injected — prefixed “(unconfirmed draft — treat as low confidence)”. A wrong-but-editable draft beats no context, and the marker stops the agent over-committing to it.

Where to edit it

business_context.md is edited in the Library only, deliberately. Two editors over one document means two autosave loops racing on the same body, and the loser silently loses a paragraph.
  • Library — documents, scope, retrieval, and the agent’s document tools
  • Knowledge Patches — how the agent proposes changes to any of this
  • Memory — the full memory model including the Vault
  • Second Brain — ingesting outside content (articles, Notion, files) into the Vault