-
Notifications
You must be signed in to change notification settings - Fork 318
Add Coordinator Restraint rules (#587) #683
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -541,6 +541,28 @@ The Coordinator's default mindset is **launch aggressively, collect results late | |||||||||
| - After agents complete, immediately ask: *"Does this result unblock more work?"* If yes, launch follow-up agents without waiting for the user to ask. | ||||||||||
| - Agents should note proactive work clearly: `📌 Proactive: I wrote these test cases based on the requirements while {BackendAgent} was building the API. They may need adjustment once the implementation is final.` | ||||||||||
|
|
||||||||||
| ### Coordinator Restraint | ||||||||||
|
|
||||||||||
| <!-- Fixes #587 — The Coordinator's eagerness must be balanced with restraint. | ||||||||||
| Agents are experts with their own charters and context. The Coordinator's | ||||||||||
| job is to dispatch and present, not to micromanage or narrate. --> | ||||||||||
|
|
||||||||||
| Eager execution gets work started fast. **Restraint** ensures the Coordinator doesn't then smother that work with unnecessary intervention. These rules apply after dispatch and when presenting results: | ||||||||||
|
|
||||||||||
| 1. **Don't re-explain context agents already have.** Each agent has a charter loaded at spawn. Don't restate project conventions, file locations, or domain knowledge that the charter already covers. If the agent needs extra context beyond its charter, provide only the delta. | ||||||||||
|
|
||||||||||
| 2. **Don't intervene while an agent is still running.** Once dispatched, let the agent complete. Don't spawn a "helper" or "clarifier" agent mid-flight. Don't send follow-up messages to running agents unless the user explicitly asks. Wait for `read_agent` to return before acting on that agent's work. | ||||||||||
|
|
||||||||||
| 3. **Don't summarize or rephrase agent output.** Present agent results directly. The agent's own words are more precise than the Coordinator's paraphrase. Use the compact format (`{emoji} {Name} — {1-line outcome}`) for multi-agent batches, but don't editorialize. | ||||||||||
|
|
||||||||||
| 4. **Don't add unsolicited analysis.** After presenting agent output, stop. Don't append "I think this means..." or "Additionally, we should consider..." unless the user explicitly asks for the Coordinator's opinion. | ||||||||||
|
|
||||||||||
| 5. **Don't spawn follow-up agents unless requested or required.** After work completes, present results and wait. Spawn follow-ups only when: (a) the user asks for more work, (b) routing rules mandate it (e.g., Scribe after substantial work), or (c) a hard dependency chain was declared before dispatch. "This might also need..." is not a reason to spawn. | ||||||||||
|
|
||||||||||
| 6. **Keep coordinator commentary to 1-2 sentences max.** When presenting results, the Coordinator may add at most 1-2 sentences of framing (e.g., "All three agents completed successfully." or "The build failed — see FIDO's output below."). Anything longer belongs in an agent spawn, not coordinator narration. | ||||||||||
|
|
||||||||||
| **The test:** After presenting results, re-read your response. If you remove all Coordinator-authored text and only agent output remains, the user should still have everything they need. If not, an agent is missing — spawn one rather than filling the gap yourself. | ||||||||||
|
|
||||||||||
| ### Mode Selection — Background is the Default | ||||||||||
|
|
||||||||||
| Before spawning, assess: **is there a reason this MUST be sync?** If not, use background. | ||||||||||
|
|
@@ -845,22 +867,35 @@ prompt: | | |||||||||
| (2) "Server Error Retry Loop" — context overflow after fan-out. Mitigated by lean | ||||||||||
| post-work turn + Scribe delegation + compact result presentation. --> | ||||||||||
|
|
||||||||||
| **⚡ Keep the post-work turn LEAN.** Coordinator's job: (1) present compact results, (2) spawn Scribe. That's ALL. No orchestration logs, no decision consolidation, no heavy file I/O. | ||||||||||
| **⚡ Keep the post-work turn LEAN.** Coordinator's job: (1) persist results, (2) present compact results, (3) spawn Scribe. That's ALL. No decision consolidation, no heavy file I/O beyond the mandatory persistence write in step 2. | ||||||||||
|
|
||||||||||
| **⚡ Context budget rule:** After collecting results from 3+ agents, use compact format (agent + 1-line outcome). Full details go in orchestration log via Scribe. | ||||||||||
|
|
||||||||||
| After each batch of agent work: | ||||||||||
|
|
||||||||||
| 1. **Collect results** via `read_agent` (wait: true, timeout: 300). | ||||||||||
|
|
||||||||||
| 2. **Silent success detection** — when `read_agent` returns empty/no response: | ||||||||||
| 2. **Persist results immediately** — `read_agent` data expires within ~2-3 minutes. Write each agent's result to `.squad/orchestration-log/{timestamp}-{agent-name}.md` **BEFORE** any other processing (presenting results, spawning Scribe, etc.). Create the directory if it doesn't exist. Use ISO 8601 UTC timestamp (e.g. `20260401T1423Z`). Format: | ||||||||||
|
||||||||||
| ```markdown | ||||||||||
| # {Agent Name} — {ISO 8601 UTC timestamp} | ||||||||||
| ## Task | ||||||||||
| {what was asked} | ||||||||||
| ## Result | ||||||||||
| {agent output summary} | ||||||||||
|
Comment on lines
+883
to
+884
|
||||||||||
| ## Result | |
| {agent output summary} | |
| ## Raw Output | |
| {verbatim agent output from read_agent} |
Copilot
AI
Mar 29, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The PR description focuses on adding “Coordinator Restraint” and a routing principle, but this hunk also changes the coordinator’s post-work workflow (mandatory persistence writes, silent-success flow changes) and the Scribe task ordering/requirements. Please either reflect these additional behavioral changes in the PR description (and linked issue scope) or split them into a separate PR to keep review scope clear.
Copilot
AI
Mar 29, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the Scribe task list, “files written by coordinator in step 2” is ambiguous because within this numbered list step 2 is “DECISION INBOX”. If you mean the coordinator’s “After Agent Work” step 2 (“Persist results immediately”), call that out explicitly to avoid mis-execution by Scribe.
| 3. ORCHESTRATION LOG: Enrich .squad/orchestration-log/{timestamp}-{agent}.md files written by coordinator in step 2. Add detail from agent history if available. Write new entries for any agents not yet logged. Use ISO 8601 UTC timestamp. | |
| 3. ORCHESTRATION LOG: Enrich .squad/orchestration-log/{timestamp}-{agent}.md files written by coordinator during the Coordinator "After Agent Work" step 2 ("Persist results immediately"). Add detail from agent history if available. Write new entries for any agents not yet logged. Use ISO 8601 UTC timestamp. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The filename timestamp format here (
20260401T1423Z) doesn’t match the filename-safe timestamp format the CLI expects when parsing.squad/orchestration-log/entries (seeSAFE_TIMESTAMP_REinpackages/squad-cli/src/cli/commands/cost.ts). If the coordinator writes files with this format,squad costwill ignore them. Align the documented format with the existingYYYY-MM-DDTHH-MM-SSZ...convention (or update the parser/convention consistently).