Skip to main content
Context is a set of markdown documents that agents read before they work for you, the way Claude Code reads a CLAUDE.md file. It comes in two layers: Good organization context says what the company does, its products and customers, the terms people use, and the conventions and policies an agent should follow. Good personal context says your role, what you are working on and how you like things done.

​
Edit context

Open Dashboard > Context with the organization selected in the workspace switcher. The tab named after the organization holds its documents (in Personal there is no such tab, and no organization context reaches your agent); owners and admins can add, edit, reorder and delete them, and everyone else can read them. The Personal tab holds yours. A layer holds up to 10 documents of up to 32,000 characters each. Agents never write organization context. The organization endpoints answer 403 to any API key, an admin’s included, so a prompt injected into one agent can’t change what every member’s agent reads. Every organization edit is recorded in the audit log (context.create, context.update, context.delete, context.restore).

​
Share a document with your organization

A personal document you want the whole team’s agents to read can be shared with the organization. Share with <organization> on the document (in the Personal tab) copies its text into the organization’s context; your own document stays where it is and stays yours.
  • Owners and admins add it at once. When the organization already has a document with that name, the dashboard asks before replacing it; the old text stays in that document’s history.
  • Members send it to the organization’s owners and admins as a proposal. Sharing the same name again updates the pending proposal.
  • Agents only propose. A share made with an API key, an admin’s included, always becomes a proposal, so no agent writes what every member’s agent reads.
Owners and admins review proposals under Proposals on the organization’s tab (the tab shows how many are waiting): the proposer, the name and the text, raw or rendered, with Approve or Decline. Approving writes the document into the organization’s context, with the same replace question when the name is taken. Members see their own pending proposals there and can Withdraw one. Every step is recorded in the audit log (context.propose, context.proposal_approve, context.proposal_decline).

​
What the agent sees

At the start of a session an agent calls get_context (or reads the MCP resource context://current, or GET /v1/context). It gets one merged text, broad to narrow:
  1. Organization context for the organization the session acts for.
  2. Personal context.
  3. Skills you can load: your organization’s internal skills and your private ones, by name and description. The agent loads one with get_skill when a task calls for it.
  4. Your timezone, when set.
Which organization applies: the one the connection acts for (the danube-org-id header, or an organization API key). If there is none and you belong to exactly one shared organization, that one applies. If you belong to several, no organization layer is included and the answer carries a note asking you to pick one, since guessing could put one company’s context in front of another’s work. The Danube MCP server tells clients to call get_context first, and get_context is in the core tool group, so it is available on every connection. Agents treat context as information about you and your organization, not as instructions that override your own request.

​
How agents remember

When you tell an agent something durable (your role, a preference, what you are working on), it can save it with the update_context MCP tool:
mode is append (a new paragraph at the end) or replace. The document is created when missing. update_context only writes the personal layer, and it is in its own tool group (context), so a connection limited with ?tools=core can read context but not change it. From a script or the CLI:

​
Revisions

Every edit keeps the previous text as a revision: yours, your agent’s and every organization edit. The dashboard shows who changed a document, when and how (dashboard, api or agent), and restores any earlier version in one click. The 50 most recent revisions of each document are kept. To avoid overwriting someone else’s change, a write can carry expected_version; if the document changed since that version, nothing is written and the answer is 409 with the current text.

​
No credentials in context

Everything in context is shown to agents, so a key or token in a document would reach every agent that reads the layer. Content is scanned with the same secret scanner that redacts tool responses; a document that contains a credential is refused with 400. Store keys and tokens as credentials instead.

​
API