Skip to main content

​
Five kinds of “planning” in the AI tooling landscape

The word “planning” is overloaded. At least five distinct approaches exist today, and they solve different problems: The first two are design-time planning — they produce a plan before work begins, and a human (or the model itself) follows it step by step. The last three introduce runtime planning — execution graphs are generated and scheduled programmatically, with independent branches running in parallel. The difference is who executes: Claude Code Teams spawns autonomous agents; FIM One DAG dispatches steps within a single orchestrator. These approaches are not competitors; they are complementary layers. A Kiro-style spec can define what to build, while a FIM One DAG can schedule how to execute the subtasks concurrently. Claude Code’s plan mode ensures a human agrees with the approach; FIM One’s PlanAnalyzer verifies the outcome automatically.

​
Three-Layer Nesting: The Full-Power Architecture

Both Claude Code Teams and FIM One DAG, at full capacity, exhibit a three-layer nested architecture:
  • Layer 1 — Human gate: User reviews the plan and approves before execution begins.
  • Layer 2 — DAG orchestration: The approved plan is decomposed into tasks with dependency edges. Independent tasks run in parallel; downstream tasks wait for their blockers to resolve.
  • Layer 3 — ReAct inner loop: Each task is executed by an agent running a full ReAct cycle (Perceive → Reason → Act → Observe), capable of multi-step reasoning, tool use, and autonomous retry.
The key insight: Claude Code Teams and FIM One DAG implement the same three layers, just with different Layer 2 mechanics — message-passing vs dependency-edge resolution.

​
Full-Power Runtime: FIM One vs Claude Code Teams

Both are genuine Agents — the core loop is identical: Perceive → Reason → Act → Feedback. The difference lies in how they orchestrate parallel work at full capacity.

​
Real-World Benchmark: v0.5 RAG System

Claude Code Teams built FIM One’s entire v0.5 RAG subsystem in a single session:
  • 8 phases: Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
  • 46 tests passing, frontend build clean
  • Wall time: ~5 minutes
  • Token cost: ~100k tokens per agent task × 8+ tasks ≈ 800k+ total tokens
  • Dependency edges: Phase 5 depends on Phase 4 + 1b; Phase 6 depends on Phase 5 + 2 + 3 — a genuine DAG
This demonstrates the core trade-off: time parallelism at the cost of token multiplication. Claude Code Teams trades compute dollars for developer hours.

​
Converging, Not Competing

The boundary between “team collaboration” and “pipeline scheduling” is blurring:
  • Claude Code Teams’ blockedBy/blocks IS a DAG — tasks have explicit dependency edges, and the leader dispatches newly-unblocked tasks as predecessors complete. This is topological scheduling with extra steps (messages).
  • FIM One’s DAG could benefit from agent autonomy — instead of single LLM calls per step, letting each step run a full ReAct loop would handle complex sub-tasks better.
Takeaway: Same Agent essence, converging parallel philosophies. Claude Code follows a team collaboration model — a Leader delegates to Workers who communicate via messages. FIM One follows a pipeline scheduling model — a DAG Executor dispatches steps based on dependency resolution. In practice, both implement dependency-driven parallel execution; the difference is coordination overhead (messages vs edges) and token economics (isolated contexts vs shared memory). The optimal architecture likely combines both: DAG scheduling for structured pipelines, agent pools for tasks that need autonomous multi-step reasoning.

​
Structured Output Degradation

All structured LLM call sites in the DAG pipeline (Planner, Analyzer, Tool Selection) use a unified structured_llm_call() utility that implements a 3-level degradation chain: Each text-based level retries once with a reformat prompt before falling to the next. The result is a StructuredCallResult containing the parsed value, which extraction level succeeded, and accumulated token usage. This design means the same prompt works reliably across GPT-4 (native FC), Claude (JSON mode), and local models (plain text), with consistent error handling and retry logic in one place instead of scattered across four call sites.

​
Three Execution Layers: Control Spectrum

The five planning approaches above describe the landscape. Within FIM One itself, three execution layers offer a control spectrum — from full human control to full AI autonomy: The design principle: give users exactly as much control as they want.
  • Need to prove every loan approval passes five specific steps? → Workflow.
  • Need to research three topics in parallel then synthesize? → DAG.
  • Need to draft and refine until satisfied? → Agent.
  • Not sure? → execution_mode: "auto" lets the LLM classify the query and route to DAG or ReAct at runtime.
This layering is what separates FIM One from single-paradigm tools:
  • Dify offers only the Workflow layer (static visual DAGs).
  • LangGraph offers only a code-level graph DSL (developer-defined topology, dynamic routing — structurally equivalent to visual workflows but requiring Python).
  • Manus offers only the Agent layer (autonomous execution, no user-defined structure).
FIM One covers all three layers, plus automatic routing between them. The abstraction progression — user-defined graph → LLM-generated graph → no graph at all — mirrors a broader industry trend: as models grow more capable, explicit orchestration structures become optional rather than mandatory.