Repository navigation
Provide framework to alter Squad response format and frequency #1769
Description
I'm not sure if this is already provided and I just have stumbled upon it yet.
I'm looking for an ability to provide requirements to Squad about how it responds to work and what that looks like. For example.
- End each turn's output with the originating prompt (first 50-100 char) so that I know what the eventually response is from
- When a response is more than a few minutes, periodically (every 4 mintues or 10 tool calls) provide a checklist of tasks and status
- Provide a few standard templates: terse, noisy, mid
Activity
bradygaster commentedon Aug 20, 2026
Thanks for the detailed write-up, Dina — this is exactly the kind of ergonomics gap worth closing, and we're taking it on. A few notes up front, then answers to each of your three asks, then some questions back to you.
First, a clarification that may have made this look already-solved: we have a setting whose name sounds like what you're describing, but it governs internal ceremony — which agent gets dispatched, how much prompt it receives, how many it spawns. It has nothing to do with user-facing output. The name collision is genuinely confusing, and it's probably why this looked half-built. It isn't. What you're asking for doesn't exist today, and we're adopting it as its own thing.
Naming and shape. We're going with a closed three-value setting:
quiet,normal,verbose. We moved off terse/noisy/mid —midisn't an adjective and reads like a rating — and we deliberately avoideddefaultfor the middle value, sinceVerbosity: defaultin a status line looks like a bug rather than a setting. It's a single flat key in project config, sitting next to the model, reasoning-effort, and context-tier settings you already have. Set it once per project, or say so mid-session to change it for that session. We're keeping it a fixed three-way enum on purpose — we don't want to grow a general output-formatting language.quietnormalverboseAsk #1 — echo the originating prompt. Shipping as a dim, truncated line at the top of a turn — roughly the 50–100 characters you asked for, since the job is "which prompt is this answer attached to," not full recovery. One deviation, stated plainly: under a flat config, the header rides along with
verboserather than being independently toggleable. Turning it on also opts you into progress boards, per-agent annotations, and routing rationale. We chose the flat config because it matches the existing keys and stays simple, and we chose not to make anything verbose-by-default. Those two choices together produce this gap. We thinkverboseis fine for a single-agent task; the real noise risk is multi-agent fan-out, where that detail is meant to be diagnostic. A dedicated toggle remains possible later without breaking anything.Ask #2 — periodic progress checklist. This one changed shape, and the reason is the interesting part. A model has no clock and no reliable count of its own tool calls, so "every 4 minutes or 10 tool calls" can't be honestly promised by an instruction in a prompt — you'd get output that looks like a timer but isn't one. So we're driving it from real tool-call events in the runtime instead. Interactive terminals get a live board that updates in place; logs, pipes, and CI get an append-only checkpoint ledger that never rewrites earlier output.
Ask #3 — response templates. Ships essentially as you asked, just under the renamed levels above.
One dependency: the piece that injects verbosity rules into our generated coordinator instructions overlaps with separate in-flight work on that same generated file, so that slice waits. Everything else is independent.
One thing we haven't settled: with the header confined to
verbose, the practical gap betweenquietandnormalnarrows to how much launch detail and raw agent output shows. We're still deciding where that line sits, so I won't pretend it's finished.Three questions back to you:
diberry commentedon Aug 20, 2026
diberry commentedon Aug 24, 2026
This is from copilot app