Potential Issues & Limitations

[jedapaw]

1. Paper ≠ Code. The open-source artifact is significantly simpler than what the paper describes. No feedback channels, no structured diagnosis, no Algorithm 1 loop.
2. No rate limiting. If you fan out to 192 agents (like the Chrome campaign), all 192 launch simultaneously up to your concurrency limit. No queuing, no API rate-limit awareness.
3. Context window management. AgentFlow splits work but doesn't automatically manage context window overflow. If an agent receives too much data via {{ nodes.x.output }}, it will exceed its context limit with no warning.
4. Single event loop per run. Each run gets one background thread with one asyncio event loop. If a node blocks (e.g., waiting for API), it holds up a slot but not the loop (async I/O handles this).
5. No built-in result deduplication in fanout. Multiple fanout members could find the same bug. The merge node handles this only if you write prompt logic for it.
6. Worktree cleanup on failure. If a run is cancelled mid-execution, worktrees may leak (they're removed in _execute_node after completion, but not on cancellation).
7. No cross-node state sharing. Scratchboard is the only shared state. There's no shared database, no RPC between agents, no message passing beyond template variables.
8. All agents share the model identity. The diagnoser and proposer (in optimization) are the same model as inner agents. No separation of concerns between meta-optimizer and task-executor.
9. No streaming for remote runners. LocalRunner streams stdout/stderr line-by-line via asyncio streams. SSH/EC2/ECS runners may not have equivalent streaming — they capture output after execution completes.
10. agent_defaults only supports built-in AgentKind enum values. You can't set defaults for custom agent names used with agent("my-custom-name", ...).
11. node_defaults has a forbidden_fields list. It prevents overriding id, prompt, depends_on, fanout, fanout_group, fanout_member, and fanout_dependencies. This is enforced at the Pydantic level.