> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Knowledge > Your agents' shared brain — the metrics, definitions, skills, and learnings they build once and reuse everywhere. **Knowledge** (the **Brain** in the app) is what your agents know about your business. Instead of re-deriving the same things every thread, agents read from a shared, structured memory and add to it as they learn — so the workforce gets sharper over time and stays consistent across people and threads. It's one connected store, not a pile of notes: definitions link to the data they come from, learnings link to the work that produced them, and everything is typed so agents (and you) can reason over it. ## What's in it Business measures with definitions and formulas — revenue, CAC, ROAS — so everyone (and every agent) computes them the same way. The business objects you work with — campaigns, products, customers — and how they map to the tables in your data sources. The exact SQL behind a metric, how you segment "active users", and mandatory filters (like "exclude refunded orders") agents must always apply. Reusable procedures an agent can call to perform a task the same way each time. Pin them to an [agent](/agents) to give it a capability. Findings, limitations, and optimizations an agent picks up while working, kept so it doesn't relearn them. Caveats about a dataset or an API — its grain, freshness, known gaps, and quirks — so agents read it correctly. Erdo ships with a starting **ontology** — common entities and metrics so agents aren't working from a blank slate — and a library of built-in **skills** for things like data analysis, charting, and reporting. You add your own on top. ## Tied to your data Knowledge isn't free-floating prose. A metric or entity is **bound** to the datasets it comes from — which table, at what grain, keyed on which columns, with which filters. That binding is what lets an agent move from "revenue is defined as…" to actually running the right query against the right table. One definition is marked the **source of truth** when several could apply, so agents don't pick the wrong one. Already have this modelled elsewhere? Import it from **dbt**, **LookML**, **Power BI**, or **Tableau** and Erdo turns your metrics, entities, relationships, and access rules into knowledge. See [Bring your semantic layer](/data#bring-your-semantic-layer). ## Shared values with collections Some facts are exact values that show up in many places at once — your monthly price, this quarter's targets, brand tokens. Hardcoding them into each definition, skill, and page means they drift the moment one changes. Instead, store the value once in a **KV store** (a named collection — Erdo's shared key/value store) and reference it from Knowledge prose as `{{slug.key}}`: ```text theme={null} Our Pro plan is {{pricing.monthly}} per seat, billed monthly. Annual billing works out to {{pricing.annual}}. ``` When an agent reads that record, Erdo resolves each reference to the live value of that KV item — so `{{pricing.monthly}}` becomes `$29` everywhere, and updating the store updates every record and page that references it. The same KV stores are read by [pages](/apps/build-apps#per-page-state-kv) and managed over the [CLI](/cli#kv-collections) and [MCP/REST API](/mcp/overview#kv-collection-tools). References are permission-aware and **fail closed**: if a reference can't be resolved — unknown store, missing key, or no access — it renders as a visible `⟦unresolved: slug.key⟧` marker rather than a silent blank or raw braces, so a broken reference is obvious instead of quietly wrong. References resolve when the record is read, against the *live* KV value — so editing the store updates every record at once. ## Use it from your apps and tools Knowledge isn't only for agents in a thread. A [page](/apps/build-apps) can read a knowledge object directly as structured app data — `window.erdo.getKnowledgeObject(id)` returns the object plus its links, backlinks, and related objects, so an app can render a brand profile, a metric definition, or a glossary straight from the Brain instead of hardcoding it. And the same records are reachable over the [CLI](/cli#knowledge) (`erdo knowledge list` / `search`) and the [MCP/REST API](/mcp/overview#knowledge-tools) (`erdo_create_knowledge`, `erdo_search_knowledge`, …) — so coding agents and scripts read and write the same shared brain your in-app agents use. ## How agents use it As agents work, they lean on Knowledge in two directions: * **Search before acting** — before answering or running code, an agent searches Knowledge for your definitions, skills, and prior learnings, so it uses *your* meaning of a term instead of guessing. * **Propose after learning** — when an agent learns something durable ("this column is the revenue metric", "this API caps page size at 100"), it proposes adding it to Knowledge so the next thread benefits. Because the store is shared, a definition you approve once is used consistently by every agent and every person — and the workforce compounds what it knows instead of starting cold each time. ## Visibility — workspace vs. public Every Knowledge entry has a visibility that controls who it can be shown to: * **Workspace** (the default) — visible to people and agents inside your organization only. Nothing you add is exposed externally unless you say so. * **Public** — the entry is opted into **anonymous external surfaces**, such as the [website voice widget](/voice-widget) answering visitors on your site. Making an entry public **is** the publish decision: a draft is approved in the same step and goes live immediately, so only flip it when you mean it. If your widget can't answer something you've already added, check the entry's visibility — an approved entry that's still *Workspace* is invisible to it. You can change visibility on an entry in the Knowledge browser, or ask Erdo in chat to publish a set of entries for you. To see exactly what's public right now, set the Knowledge browser's visibility filter to **Public**, or list it programmatically: `erdo knowledge list --public` from the CLI, or `GET /v1/knowledge?visibility=public` from the API. Each agent's Knowledge tab also shows the same public set, since that's what its website deployments answer from. Reserve **Public** for customer-facing facts you'd happily tell any visitor: products, pricing, opening hours, locations, policies, FAQs, galleries. Internal processes, personal data, and financials stay *Workspace*. ## Keeping facts fresh Some knowledge goes stale — an API version changes, an enum is renamed, a rate limit moves. Erdo tags volatile facts with when they were last verified and when they should be re-checked, and marks them deprecated or superseded when they're replaced. Agents treat stale or unverified facts as a hint to confirm, and always prefer current tool definitions and live docs over an old note. ## Review what agents propose New knowledge an agent wants to add to the workspace shows up in the [review queue](/review-queue) before it becomes shared truth. Each proposal comes with the evidence behind it and the change it suggests, so you can accept what's right and reject what isn't — and the Brain stays trustworthy rather than filling with guesses. This is the same human-in-the-loop principle behind [approvals](/concepts#review-and-approvals) for actions, and the same queue is readable and answerable over the CLI and API.