Skip to main content

Knowledge

Every agent has a knowledge folder — its reference library. Drop in the documents the agent should be able to consult (specs, guidelines, price lists, procedures, any file type), and it reads them on demand when a job calls for them. Knowledge is curated by the agent's managers, is never auto-loaded wholesale into conversations, and is the same for everyone who uses the agent.

Knowledge sits alongside the agent's other folders — the shared workspace it works in, each person's private space, and the manager-only config that shapes its behavior. See Agents for the full folder model.

Shared knowledge libraries​

Knowledge doesn't have to stay with one agent. An agent's knowledge folder, or any subfolder of it, can be promoted to a shared library with a name of its own ("Brand Guidelines", "Product Catalog") and attached to other agents across the installation:

  • Share from the source agent's Configuration page, under Shared Knowledge. Pick the whole knowledge folder or browse to a subfolder, give the library a name, and it's available installation-wide. One agent can share several subfolders as independent libraries. Renaming is just re-sharing under a different name.
  • Attach a library to any other agent from the same card. Attached agents see the library at knowledge/shared/<source-agent>/… (on remote machines too) and read it exactly like their own knowledge.
  • Read-only or writable, per attachment. By default a mirror is read-only: the library is edited on its source agent, and every layer of the platform enforces it. If a read-only mirror's file does get changed on the attached side, the platform restores the source version and keeps the changed copy in the Recover bin, so nothing is lost. Attach a library as writable and the consuming agent's edits flow back to the source — one team library, maintained from anywhere it's attached. Deletes flow too: a file a writable agent removes (in its session, with a script, or on a remote machine) disappears from the source and every other copy at the end of that turn, with the source copy kept in the source agent's Recover bin; a file deleted at the source disappears from every copy. A copy that was never in sync, or a whole folder that goes missing at once, is restored rather than treated as a delete, so a broken machine can't empty a library.

Sharing and attaching libraries is for platform admins and creators (a creator also needs manager access on the agents being wired); agent managers see the card read-only. Admins and creators can also manage libraries from chat through the agent's self-configuration tools — each change is confirmed in-chat before it happens.

Bulletins: a standing team briefing​

Each library can carry a bulletin: a markdown file at bulletin/<library name>.md inside the library. Its content is automatically added to the context of every agent attached to the library, and the source agent itself — a standing briefing the library's owner curates. Use it for the short version of what matters right now (current priorities, this week's campaign, an active incident) and keep the reference detail in the library's ordinary files.

The bulletin is kept current by the library's writers — the source agent's own team, and any agent attached with write access (their edits flow back to the library like other shared content). Read-only attachments can read it, not edit it. Renaming the library renames the bulletin file with it.

Who can write knowledge​

  • People: an agent's managers edit knowledge from the dashboard's file view (and from paired machines); editors, contributors and viewers read it.
  • Agents in chat: sessions read knowledge; manager sessions can update it.
  • Agents on a schedule: agent-scoped scheduled tasks and delegated workers created by a manager or admin can write knowledge and the agent's writable library mirrors, so a nightly job can curate the library or sync it to a git repository. Tasks created by editors keep knowledge read-only, and contributors can't create shared tasks at all.

The agent's config/ folder (persona, auto-loaded context) stays manager-only everywhere.

The Recover bin​

Deleted files, files replaced by a newer version in a sync conflict, and stray edits to read-only mirrors all land in the workspace's Recover bin, kept for 7 days. Restore or discard them from the bin button in the file view. Restores go through the same permission checks as any other write: restoring a file into a read-only library is refused, per file, and the rest of a multi-file restore still proceeds.

Next steps​

  • Agents → — the full folder model and per-agent roles.
  • Memory → — what agents remember on their own, vs. what you curate here.
  • Remote Machines → — knowledge and libraries sync there too.