Skip to content

dispatching-parallel-agents: agents freeze on development tasks without explicit autonomy level #473

@vomikodved

Description

@vomikodved

Problem

dispatching-parallel-agents skill works great for debugging (fix failing tests, investigate issues). But when dispatching agents for feature development (write new code, modify existing codebase, compile, deploy), agents frequently freeze — they stop and ask permission before writing significant code.

Root Cause

The skill covers scope, goals, constraints, and expected output — but doesn't address autonomy level. For debugging tasks this isn't an issue (agents naturally investigate and fix). For development tasks, agents default to caution when facing:

  • Writing new files in an existing codebase
  • Modifying production code
  • Compiling and running builds
  • Deploying to hardware/infrastructure

Real-World Example

Two agents dispatched in parallel:

  • Agent A (verification task): "test existing pipeline with WAV samples, collect results" → worked perfectly, no hesitation
  • Agent B (development task): "implement WiFi AP onboarding — shell script + C code + daemon integration" → stopped before compilation, asked for permission

Same briefing structure, same CLAUDE.md permissions. The difference: Agent A had a linear test checklist, Agent B had an architectural description with phases that read like "a plan for discussion" rather than "do this now."

Proposed Addition

A section on briefing structure for development tasks, covering:

1. Explicit Autonomy Level

## Autonomy

Phases 1-3: FULL AUTONOMY. Write code, compile, test — don't ask.
Phase 4 (hardware): ask before destructive operations.

Without this line, agents treat development briefings as proposals rather than mandates.

2. Imperative Framing (not architectural)

# ❌ Architecture description — agent treats as "plan to discuss"
### Phase 2: MQTT auto-register
Add subscription to `tasmota/discovery/+/config` in the daemon.
File: `src/tasmota_discovery.c/.h`

# ✅ Imperative checklist — agent treats as "do this"
### Phase 2: MQTT auto-register
1. Create `src/tasmota_discovery.c` and `.h`
2. Implement subscription to `tasmota/discovery/+/config`
3. Add to Makefile, compile: `make host-test`
4. Write test in `test/test_discovery.sh`
**Don't ask — write and compile.**

3. Task Type Awareness

Task type Framing Without it
Testing existing "verify, run, collect results" Agent may start refactoring
New code "write, compile, test in container" Agent stops before compilation
Modify existing "change X in file Y, rebuild" Agent afraid to break things
Hardware "deploy, verify on device" Agent asks permission

4. Shared Resource Coordination

When multiple agents access shared infrastructure (hardware, services), briefings should include a resource table and coordination protocol. We've found three channels work in practice:

  • File mutex (same machine): lock files in /tmp/
  • Git files (any topology): commit coordination files, like Orchestra's .orchestra/
  • GitHub issue comments (any topology): announce before/after destructive ops

Scope

This could be either:

  • An extension to the existing dispatching-parallel-agents skill
  • A separate companion skill (e.g., dispatching-dev-agents)

Happy to submit a PR with either approach. We have a working local skill we've been using.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions