From conductor-design.md §5 (landed in #275). Pairs with #245, which makes fleet mountable; this is what makes the prompt follow the mounts.
Why
CONDUCTOR_SYSTEM_PROMPT_APPEND lives in fleet.ts:163, with a comment saying the fleet tools "define the conductor's whole contract." Under the reframe that is backwards: fleet is one capability, alongside memory, notes, web, routines, and any mounted MCP server. The prompt should be an identity preamble plus one section contributed per mounted capability.
Composed also means absent when unmounted — this is not tidiness
A model told about tools it does not have will hallucinate calls to them. A 20–30B open-weight backend does so far more readily than a frontier model, and config.conductor.provider exists precisely so an open-weight backend can drive the conductor. A monolithic prompt that describes routines and notes on a daemon where neither is mounted is a correctness bug for exactly the deployment we are building toward.
Scope
The mount contract this enables (design §5)
Declaring prompt sections is half of a two-way exchange worth landing together with #245:
A capability declares its read-only verbs and its side-effecting verbs at mount time. In return the daemon stamps every call it makes with identity attribution, an audit row, the correct approval classification, and episodic capture.
Mandatory in both directions: a capability that declines to declare gets no auto-approval (fail safe), and a capability that declares gets governance it did not have to build.
Declared-but-validated, never declared-and-trusted — the registry supplies the list, tool-safety.ts still matches exact names, because an over-broad match is a prompt bypass regardless of author. See open question #11 in the design doc.
That exchange is the part competitors' plugin systems cannot offer. Every peer has a plugin system; a plugin mounted elsewhere inherits nothing, while a capability mounted here inherits the whole substrate. The registry is not the moat — it is how the moat reaches third-party code. Worth designing deliberately rather than discovering after the third capability.
Related
From conductor-design.md §5 (landed in #275). Pairs with #245, which makes fleet mountable; this is what makes the prompt follow the mounts.
Why
CONDUCTOR_SYSTEM_PROMPT_APPENDlives in fleet.ts:163, with a comment saying the fleet tools "define the conductor's whole contract." Under the reframe that is backwards: fleet is one capability, alongside memory, notes, web, routines, and any mounted MCP server. The prompt should be an identity preamble plus one section contributed per mounted capability.Composed also means absent when unmounted — this is not tidiness
A model told about tools it does not have will hallucinate calls to them. A 20–30B open-weight backend does so far more readily than a frontier model, and
config.conductor.providerexists precisely so an open-weight backend can drive the conductor. A monolithic prompt that describes routines and notes on a daemon where neither is mounted is a correctness bug for exactly the deployment we are building toward.Scope
fleet.tsinto the conductor's own moduleThe mount contract this enables (design §5)
Declaring prompt sections is half of a two-way exchange worth landing together with #245:
A capability declares its read-only verbs and its side-effecting verbs at mount time. In return the daemon stamps every call it makes with identity attribution, an audit row, the correct approval classification, and episodic capture.
Mandatory in both directions: a capability that declines to declare gets no auto-approval (fail safe), and a capability that declares gets governance it did not have to build.
Declared-but-validated, never declared-and-trusted — the registry supplies the list,
tool-safety.tsstill matches exact names, because an over-broad match is a prompt bypass regardless of author. See open question #11 in the design doc.That exchange is the part competitors' plugin systems cannot offer. Every peer has a plugin system; a plugin mounted elsewhere inherits nothing, while a capability mounted here inherits the whole substrate. The registry is not the moat — it is how the moat reaches third-party code. Worth designing deliberately rather than discovering after the third capability.
Related