Handoff — Not Needed
Pattern: Explicit task handoff between agents, where one agent completes its work and passes control to the next. Why excluded: DAG linear chains already cover sequential task handoff naturally. When step B depends on step A, the executor waits for A to complete, then passes A’s result into B’s context via the dependency mechanism. This is structurally equivalent to a handoff — but without requiring a separate abstraction layer. Adding an explicit handoff protocol would duplicate what step dependencies already provide, with no additional expressiveness.Backflow — Not Needed
Pattern: Downstream steps feeding results back to upstream steps for re-evaluation (also called backpropagation of results). Why excluded: The PlanAnalyzer re-plan loop already covers this use case. After all steps complete, the analyzer evaluates whether the original goal was achieved. If not (and confidence is below the stop threshold), it triggers a full re-plan with context from the previous round’s results — including what went wrong and what was learned. This is a coarser-grained but more robust approach than per-step backflow. Per-step backflow creates complex feedback loops that are hard to debug and can lead to infinite cycles. The re-plan loop achieves the same corrective effect with a cleaner execution model: plan, execute, evaluate, re-plan if needed.Teams (Agent Inter-Communication) — Not Needed
Pattern: Multiple specialized agents communicating with each other during execution, negotiating subtask ownership, or collaborating on shared state. Why excluded: DAG dependency chains are sufficient for data-dependency tasks. When step C needs results from both step A and step B, the dependency edges express this directly. Step C receives the outputs of A and B in its context — no inter-agent messaging protocol required. The DAG model is simpler and more predictable than agent-to-agent communication. Agents don’t need to negotiate; the planner determines the execution structure upfront, and the executor enforces data flow through dependency resolution. This avoids the coordination overhead and non-determinism that multi-agent messaging introduces.agent_hint / role_hint — Not Needed
Pattern: An explicit hint telling the executor which type of agent or persona should handle each step (e.g., “use the researcher agent” or “use the coder agent”). Why excluded: The combination of three existing fields already provides sufficient guidance:task— The natural language description of what the step should accomplish. A well-written task implicitly signals the required expertise.tool_hint— Suggests which tools the step should use (e.g.,web_search,python_exec). This constrains the execution approach more precisely than a vague role label.model_hint— Controls whether the step uses the fast or reasoning model tier, which is the most impactful execution decision.
agent_hint or role_hint would be redundant with these three fields and would introduce another axis of configuration that the planner LLM must get right. Keeping the hint surface small reduces planning errors.