Custom agents now have a "First Run Setup" section that defines what
the agent must do the very first time it is invoked: what questions
to ask the user, what config files or folders to create, and how to
detect that it has already been set up.
agent-template.md:
- New "First Run Setup" section between Core Responsibilities and
Operational Rules, with subsections for detection, questions to
ask, what to create, and post-setup behavior
architect.md:
- New Phase 4 "First Run Setup" in the conversational flow where
the Architect asks the user what the agent should do on first run
- Previous Phase 4 (Advanced) becomes Phase 5
- Previous Phase 5 (Confirmation) becomes Phase 6
- Updated blocking rules to reference Phase 6
agents-registry.md:
- Added "Custom Agents" section with rules for how custom agents
are added to the registry (naming, priority, creation flow)
- Custom agents always have lower priority than core 8
- Names must be lowercase with hyphens, no conflicts with core names
agents.md:
- Added "Custom Agents" section explaining what they are, how they
coordinate with core agents, and how to create/edit/remove them
agent-orchestration.md:
- Added "Suggested new agent" signal format so agents can flag when
the user needs functionality that no existing agent provides
- Added step in Dispatcher Decision Logic to check for this signal
- Added "Custom Agent Lifecycle" section covering creation, discovery,
routing, chaining, maintenance, and deletion
New file: references/agent-template.md
This is a reference document that the Architect reads when generating
custom agents. It defines the exact structure every agent must follow:
YAML frontmatter format, required sections (Language, User Profile,
Inter-Agent Coordination, Core Responsibilities, Operational Rules),
placeholder tokens, and inline conventions (naming rules, tool
permissions, multilingual triggers).
The template is not an agent itself. It is a structural guide that
ensures custom agents are generated with the same quality and
consistency as the core 8.
- Remove "message board archival" from Librarian responsibilities
- Rename "Who to Message for What" → "When to Suggest Another Agent"
- Replace "Message to" column with "Suggest"
- Move coordination explanation above the table
- Update intro line to reflect dispatcher model
- Fix call-chain example consistency in CLAUDE.md and agent-orchestration.md
(chain lists already-invoked agents, "step N" matches chain length + 1)
- Renumber architect.md Task Checklist (was skipping 3) and replace
"Leave messages" step with dispatcher-driven "Suggested next agent"
- Replace "Leave a message to the Sorter" with signal via Suggested next agent
- Clarify "Do NOT write to other agents' files" → only prompt/config files
(.claude/agents/*.md), normal vault edits still allowed
- Fix agent count 10→8 in docs/getting-started.md
- Initialize SKILL_COUNT before conditional block in launchme.sh
Before this change, agents communicated directly with each other by
writing to a shared file (Meta/agent-messages.md), following the
protocol in references/inter-agent-messaging.md. This was fragile
and hard to control.
Now the dispatcher (CLAUDE.md) is the only coordinator. Agents do
not talk to each other. Instead, when an agent detects work for
another agent (e.g. missing vault structure, orphan notes), it
outputs a "Suggested next agent" section. The dispatcher reads it,
validates it against the agents-registry, and decides whether to
chain the next agent.
New files added:
- references/agent-orchestration.md: the new coordination protocol,
including call chain tracking, anti-recursion rules, and a max
depth of 3 agents per user request
- references/agents-registry.md: a capability registry that maps
each agent to its inputs, outputs, and chaining suggestions
Deleted:
- references/inter-agent-messaging.md: the old peer-to-peer protocol
