Curate Knowledge
Admin guide
Knowledge is the customer-specific prose that agents read when they work. As an IT admin, you author org-scope Knowledge entries, review agent proposals to org and integration scope, and keep the corpus accurate as the organization evolves.
The conceptual model is in Knowledge. This page covers the IT-side workflow.
What lives in org Knowledge
Section titled “What lives in org Knowledge”Org-scope Knowledge is the small set of “how we work here” documents that apply to every agent session in the organization, regardless of which app they’re working on. Typical entries:
- The design system in use, with usage rules (“never disable a button with
disabled={true}; useloading”). - Compliance summaries (“PII must not appear in app logs; use the
gl-redacthelper”). - Coding conventions (“we use TypeScript strict; avoid
any; prefer named exports”). - Internal infrastructure notes (“our Snowflake warehouse is
ANALYTICS_PROD; query themartschema notraw”). - The “what is this org” context — names, product surface, audience.
Org entries are small and stable. They should not change weekly. Agents read them at the start of every session.
Authoring
Section titled “Authoring”The dashboard’s Knowledge tab lists every org entry. Click New entry, give it a topic slug (design-system, compliance-summary), title, and Markdown body. Save. The entry is immediately readable by agents over MCP.
Edits are versioned and audited. The history view shows every change with the diff and the editor.
Reviewing agent proposals
Section titled “Reviewing agent proposals”Agents propose entries when they learn something during a build. A proposal appears in the dashboard with:
- The agent’s rationale (why this is worth keeping).
- The bound user (who the agent was working for).
- The full diff against the live entry (if it’s an update) or the full body (if it’s new).
Three actions:
- Accept as proposed — the entry is upserted as-is.
- Accept with edits — your edits land along with the agent’s content; the audit log captures
accepted_with_edits=true. - Reject — the entry is not changed; the proposal is closed; your reason is captured.
Stale proposals (where the entry has moved on since the agent read it) are flagged automatically. The agent is asked to re-read and re-propose; you don’t have to do anything.
Integration Knowledge starts empty — unless you write the first entry
Section titled “Integration Knowledge starts empty — unless you write the first entry”Catalog and Custom integrations both start with no integration-scope entries unless you fill in the registration wizard’s optional “First Knowledge entry” field — registration is often the moment you know most about why the integration is being added. Left blank, the integration’s detail page shows an “Add the first entry” state instead; you, app owners, and builder agents build the corpus from what the team learns about the real source. Live connection mechanics such as the base URL and delivery mode come from the integration record, so Knowledge stays focused on customer-specific schema, idiomatic queries, and gotchas.
Visibility and scope
Section titled “Visibility and scope”Knowledge entries can be marked dashboard_only if they should not be visible to agents — typically when an entry is in draft, or when the content is human-only operational guidance. dashboard_only entries never appear in MCP responses regardless of agent role.
Making an integration inactive hides all of its integration-scope Knowledge from agent MCP tools, also regardless of agent role, without deleting the entries or changing their individual visibility. You can continue editing them in the dashboard and make them agent-visible again by reactivating the integration.
Integration-scope entries (what’s in this Snowflake account, the warehouses an app may use, idiomatic queries, gotchas) belong on the integration’s own detail page. App-scope entries belong on the app’s detail page. Org-scope entries are reviewed here.
Cleanup
Section titled “Cleanup”Knowledge that’s gone stale (e.g., a deprecated design system, a now-irrelevant integration) should be deleted — the audit log retains the deletion event. To keep an entry for humans but hide it from agents, set its visibility to dashboard_only instead of deleting it; dashboard_only entries never appear in MCP responses.
There is no automatic expiration field today — staleness is a human judgment, not an automatic policy.