Workspace context

Every agent on a project reads from the same set of shared documents before it does anything else. These live under the Workspace group in the Agents rail. Each one is a folder of markdown files stored in the project's docs repo: a tree on the left, an editor on the right.

What are the four doc layers?

Layer	Injected into <...>	Scope	What it's for
Project	<project_context>	Every agent, every call	Standing instructions, conventions, and anything all your agents should always know.
Skills	<available_procedures>	Handed to a subagent when spawned, or read on demand	Playbooks the orchestrator can pass down when it spawns sub-agents.
Knowledge	Retrieval / on-demand reads	Only when an agent asks	Your reference library: service docs, runbooks, and the codebase maps Discovery generates automatically under knowledge/apps/ (those are marked as generated and may be overwritten the next time Discovery runs).
Payloads	<payload_rules>	Incident classification & grouping	The rules that decide which incoming operational events count as the same incident, and which must never be grouped together.

(A fifth rail entry, MCP, is not a doc layer; it is the list of connected external tool servers. See MCP servers.)

How do I edit a workspace file?

1. Open the layer from the rail (for example Project).
2. Select a file from the tree, or click New doc to start one. You will be asked for a lowercase filename ending in .md (subfolders are fine, for example jira/flows.md).
3. Edit the content in the editor.
4. Click Save.

A successful save shows Committed — syncing to agents (~1–2 min); the change lands in the repo immediately but takes a couple of minutes to actually reach the agents that read it.

Files under features/apps/ inside Knowledge are flagged generated by discovery; you can still edit them, but a fresh Discovery run may overwrite your edits.

Per-agent guidelines and "What this agent sees"

The four layers above are shared. Each agent also has its own private layer, guidelines, that only it reads, on every call. These do not live in the Workspace rail; they are edited inline on the agent itself, in the Behavior tab, inside a panel called What this agent sees.

That panel lays out the full composition of what gets fed to the agent, in the order it is actually injected:

1. The prompt: the markdown body you are editing directly above the panel (profile.md).
2. <project_context>: the shared Project layer, shown read-through with a shortcut back to Workspace. Editing it there affects every agent, so it is not editable from here.
3. <{agent}_guidelines>: this agent's own layer, editable right there inline. Pick an existing file, click New to add one, edit the content, and Save. Use this to steer one specific agent without touching its prompt or the shared Project context.
4. <available_procedures>: the Skills layer, shown read-through, but only if the agent can spawn sub-agents (that is, it has the spawn_subagent tool). An agent that cannot spawn anything never sees the Skills catalog.

Guidelines are stored per agent: at .config/orchestrator/docs/ for the root orchestrator, or .config/agents/<agent id>/docs/ for everything else.

How this connects to the rest of the platform

• The Knowledge layer is the exact same content described in the Knowledge guide; nothing here duplicates it, it is the same files viewed from the agent side.
• The Payloads layer is what Incidents uses to decide whether a new signal is the same incident as an existing one.