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

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}; use loading”).
Compliance summaries (“PII must not appear in app logs; use the gl-redact helper”).
Coding conventions (“we use TypeScript strict; avoid any; prefer named exports”).
Internal infrastructure notes (“our Snowflake warehouse is ANALYTICS_PROD; query the mart schema not raw”).
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

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.

Attaching brand assets

The entry editor has an Assets section for image files attached to that entry. Upload your logo, icon mark, wordmark, and favicon to the design-system entry and agents will use them instead of generating something that looks approximately right.

For each file, set:

Role — logo-primary, logo-mark, logo-wordmark, icon, favicon, illustration, diagram, or other. This is how an agent finds the right file without guessing at names.
Theme — light, dark, or any, meaning the background the file is drawn for. Upload both variants when a mark disappears on one of them; the editor previews each thumbnail on both backgrounds so you can check.
Description — required. It is the alt text in the dashboard and the agent’s hint for when to use this file rather than another.

Use Copy reference to paste ![Primary logo](gl-asset:logo-primary) into the entry body, so the document shows the mark it is describing.

SVG, PNG, JPEG, and WebP up to 2 MB, 25 files per entry. SVGs containing scripts or references to remote resources are refused; export a static file and re-upload. Files are stored exactly as you uploaded them — never re-compressed — so what agents receive is the artifact you approved.

Uploading an asset needs the same permission as editing that entry’s body, and doesn’t create a new version of the entry. Each asset change is recorded in the audit log as its own event; the entry’s History tab shows body revisions only.

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

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

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

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. Deleting an entry also deletes the files attached to it, so a retired logo does not linger where an agent can still fetch it. 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.

KnowledgeThe concept page covering scopes, authorship, and the proposal flow.

MCP tools referenceThe knowledge.* tools agents call.

Manage integrationsWhere integration-scope Knowledge lives.