Agent progress updates: surface periodic status during long-running work

Community feedback: Users report feeling uncertain whether agents are still working during longer tasks. The UI goes quiet and the user wonders 'is anything happening?'

Request: Investigate ways for agents to surface summary-level progress updates at intervals during their work — not just a final result dump. Ideally:

Periodic status signals so the user knows work is in progress
Updates that reflect each agent's personality/voice (not generic 'still working...')
Lightweight enough to not slow down actual work

Considerations:

Platform constraints: background agents communicate via
ead_agent\ — can the coordinator poll and relay?
Could agents write to a shared progress file that the coordinator checks on intervals?
What's the right cadence? Every 30s? Per-milestone? Per-file-written?
Balance between 'the user feels informed' and 'the output is noisy'

@verbal

✅ GO for v0.4.0 — Agent Progress Updates

This is a quality-of-life win. When an agent is working for 2+ minutes, the user should feel confident work is happening. We'll ship lightweight, personality-flavored progress signals without slowing down execution.

Architecture Decision: Option C + Lightweight File Fallback

Recommendation: Agents emit progress markers in their output stream that the coordinator parses via
ead_agent polling.

Why Option C wins:

✅ No new I/O overhead — agents already produce output; we just structure it
✅ Works with existing read_agent — coordinator already polls background agents
✅ Agent-side is trivial — agents just write [PROGRESS: {message}] markers
✅ Backward compatible — old agents work fine, no progress just means no updates

Format:

Agents include progress markers in their output:
\
[PROGRESS: Reading authentication logic across 12 files...]
[PROGRESS: Found 3 potential issues, analyzing severity...]
[PROGRESS: Writing fixes to src/auth/jwt.js...]
\\

Coordinator polls
ead_agent every 30 seconds (configurable), extracts [PROGRESS: ...] lines, and relays them to the user with agent personality intact.

Fallback for complex coordination:

If multi-agent orchestration needs richer state, agents can optionally write to .ai-team/progress/{agent-session-id}.md. Coordinator checks this during polling. Start without this; add only if needed.

Work Items

WI-1: Progress Reporting Spec — @verbal

Acceptance Criteria:

Define progress marker format: [PROGRESS: {message}]
Define polling interval (default: 30s, configurable via env var SQUAD_PROGRESS_INTERVAL)
Specify when agents should emit progress (e.g., after reading files, before major actions, per-file-written)
Document in .ai-team/decisions/

WI-2: Coordinator Polling Loop — @verbal

Acceptance Criteria:

After spawning background agent via ask tool, start progress polling loop
Every 30s, call
ead_agent and extract [PROGRESS: ...] lines
Relay progress to user via coordinator output (preserve agent personality)
Stop polling when agent completes
Update emplates/squad.agent.md with polling logic

WI-3: Agent Progress Template — @verbal

Acceptance Criteria:

Update agent spawn templates to include progress guidance:
- "Emit [PROGRESS: ...] markers during long operations"
- Suggested intervals: after reading N files, before writing files, per major milestone
Add examples to emplates/ for explore, task, and custom agents
Keep it lightweight — agents decide when to emit, not forced cadence

WI-4: User Documentation — @mcmanus

Acceptance Criteria:

Add "Agent Progress Updates" section to docs/features.md
Explain what users should expect: periodic updates, no action required
Document SQUAD_PROGRESS_INTERVAL env var
Add troubleshooting: "If progress stops, agent may be blocked — check logs"

WI-5: Progress Reporting Tests — @Hockney

Acceptance Criteria:

Test scenario: Long-running agent emits 3+ progress updates
Test scenario: Agent completes without progress markers (backward compat)
Test scenario: Coordinator relays progress to user with correct formatting
Test scenario: Polling stops after agent completion
Add to est/progress.test.js

What We're NOT Doing

❌ Real-time streaming — polling every 30s is enough; no WebSocket complexity
❌ Progress bars — too much UI complexity for v0.4.0
❌ Automatic progress — agents decide when to emit, no forced instrumentation
❌ Multi-agent progress aggregation — v0.4.0 is single-agent progress only

Sprint Readiness

Dependencies: None — all work can start immediately
Risk: Low. If polling adds latency, we tune the interval or make it opt-in.
Timeline: 3-4 days. WI-1 → WI-2/WI-3 in parallel → WI-4/WI-5 in parallel.

Let's ship this. Users shouldn't wonder if their AI team is still working.

— 🏗️ Keaton (Lead) · Posted by Squad

Agent Progress Updates — Proposal 022a Published

I've completed the design spike for Issue #22 and published the full proposal at team-docs/proposals/022a-agent-progress-updates.md.

TL;DR — Recommended Approach

Milestone Signals + Coordinator Polling (Hybrid)

Users see periodic status updates without sacrificing agent personality:

Coordinator polls agents via read_agent every 30 seconds (standard cadence, zero additional cost)
Agents opt-in to emit progress signals: ✅ [MILESTONE] Analyzed 150/400 files
Coordinator extracts milestones and relays to user in real-time

Why This Wins

Cost-first: Reuses existing read_agent polling, one API call per 30s per agent (negligible)
Voice-preserving: Agents control what gets highlighted, not the coordinator
No breaking changes: Backward compatible; agents adopt via new skill (.ai-team/skills/progress-signals/SKILL.md)
User experience: Long-running tasks feel alive; users see "Keaton is analyzing files (150/400 done)" instead of silence

What the User Actually Sees

`
Brady: keaton, analyze the codebase

🏗️ Keaton is analyzing the codebase. I'll check in every 30 seconds.

[30s later]
📍 Keaton — ✅ Parsed 150/400 files
📍 Keaton — 📍 Analyzing module dependencies...

[60s later]
📍 Keaton — ✅ Found 47 circular dependencies
📍 Keaton — 📍 Generating report...

✅ Keaton completed analysis. Here's the report:
[full output...]
`

Impact on squad.agent.md

Add progress polling loop to spawn flow (30-line addition)
New skill: progress-signals with examples
No changes to agent spawn templates (backward compatible)
All agent types work immediately (explore, task, general-purpose, code-review)

Proposal Structure

The proposal follows our standard format:

Problem analysis — Why users feel uncertain (UX gap, not a technical blocker)
Platform constraints — What mechanisms exist (read_agent polling is most viable)
Four approaches evaluated — Polling, file writes, milestones, event logs
Recommendation with rationale — Milestones + coordinator relay
Impact on squad.agent.md — Concrete spawn template changes
UX mockups — Three scenarios showing what users see
Success criteria, risks, roadmap

Next Steps

Ready for review and approval. Implementation is straightforward (coordinator addition + skill documentation). Estimated effort: 3-4 hours (Fenster for coordinator, Verbal for skill design).

Status: Proposed (awaiting Brady approval)

Design spike complete. Proposal 022a (agent progress updates) shipped. Recommended approach: milestone signals + coordinator polling — zero extra API cost.

docs(ai-team): merge 3 decisions from inbox and propagate updates

feat: project board + v0.4.0 docs (#6)

blog: Welcome to the New Squad — v0.8.18 launch post (#22)

docs(e2e): record E4 agent-binding verification result

docs(e2e): record E4 agent-binding verification result (PASS, n=1) (#…

Navigation Menu

Repository navigation

Agent progress updates: surface periodic status during long-running work #22

✅ GO for v0.4.0 — Agent Progress Updates

Architecture Decision: Option C + Lightweight File Fallback

Why Option C wins:

Format:

Fallback for complex coordination:

Work Items

WI-1: Progress Reporting Spec — @verbal

WI-2: Coordinator Polling Loop — @verbal

WI-3: Agent Progress Template — @verbal

WI-4: User Documentation — @mcmanus

WI-5: Progress Reporting Tests — @Hockney

What We're NOT Doing

Sprint Readiness

Agent Progress Updates — Proposal 022a Published

TL;DR — Recommended Approach

Why This Wins

What the User Actually Sees

Impact on squad.agent.md

Proposal Structure

Next Steps

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Agent progress updates: surface periodic status during long-running work #22

Description

Activity

bradygaster commented on Feb 13, 2026

✅ GO for v0.4.0 — Agent Progress Updates

Architecture Decision: Option C + Lightweight File Fallback

Why Option C wins:

Format:

Fallback for complex coordination:

Work Items

WI-1: Progress Reporting Spec — @verbal

WI-2: Coordinator Polling Loop — @verbal

WI-3: Agent Progress Template — @verbal

WI-4: User Documentation — @mcmanus

WI-5: Progress Reporting Tests — @Hockney

What We're NOT Doing

Sprint Readiness

bradygaster commented on Feb 13, 2026

Agent Progress Updates — Proposal 022a Published

TL;DR — Recommended Approach

Why This Wins

What the User Actually Sees

Impact on squad.agent.md

Proposal Structure

Next Steps

bradygaster commented on Feb 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions