Skip to main content

​
Graph engineering (2026) and FIM One

Industry discussion often frames a shift from loop engineering (a single agent repeatedly thinking and acting) to graph engineering (making multi-node topology an explicit engineering object). The label is new; the practice is not. LangGraph-style systems and multi-agent orgs have used graphs for years. What matters for FIM One is which kind of graph people mean, and how that maps onto our three execution layers.

​
What graph engineering usually means

Consensus across that framing: graph does not replace loop. Graph designs relationships between processes; each agentic node may still run a full loop. “Graph” is overloaded in practice. Three usages get mixed: This page is about the first two (orchestration).

​
Not “Dify Workflow with a new name”

Dify-style visual workflows and graph engineering share a bloodline (explicit topology) but they are not the same product. Short form: classic Workflow is a deterministic (or semi-deterministic) pipe with occasional LLM steps. Graph engineering is multi-node system topology, where critical posts can still be autonomous agents.

​
How the industry map sits on FIM One

FIM One already spans the control spectrum; chat “Planner mode” is only one slice.

​
Graph engineering vs FIM One DAG (chat Planner)

Same family (explicit multi-step topology). Different species. Implication: industry heat around graph engineering validates keeping a graph/scheduling engine. It does not require a chat default that forces users to pick “Planner” for every turn. Most tasks still want a strong loop; graphs earn their keep on parallel branches, fixed compliance paths, and multi-role orchestration.

​
What FIM One can learn (empower ReAct, DAG, Workflow)

Concrete takeaways, not slogans. Ordered by leverage. Anti-patterns to avoid when “doing graph”:
  • Using a dependency graph to simulate a human state machine (multi-step “wait for answers” with no wait primitive).
  • Equating ReAct update_plan (checklist memory) with graph engineering (scheduling topology).
  • Shipping graph heat as a second chat personality instead of as engine composition (loop outside, schedule inside when needed).
  • Describing FIM One DAG steps as “shallow LLM calls”: that understates the engine and misleads product decisions.

​
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 DAG steps are already full ReAct agents — Layer 3 is not aspirational. Each step runs agent.run() with tools and multi-iteration loops; differences vs a top-level ReAct chat turn are deliberate (no per-step plan board, no chat-level ask_user_question wait, model chosen by model_hint / general default).
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 ReAct steps based on dependency resolution. In practice, both implement dependency-driven parallel execution; the difference is coordination overhead (messages vs edges), isolation (peer agents vs task + dependency results), and token economics. The product gap is less “make nodes into agents” and more when to schedule a graph vs stay in one chat loop, plus human wait edges where the graph cannot pause.

​
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. Relative to graph engineering: Workflow is the design-time graph product; DAGPlanner is a runtime task graph; ReAct is loop engineering (with optional plan-board memory, not a schedule graph). 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, refine, or ask structured questions mid-run? → ReAct.
  • Not sure? → execution_mode: "auto" classifies the query and routes to DAG or ReAct at runtime (prefer ReAct when the goal is primarily clarification or short exploration).
This layering is what separates FIM One from single-paradigm tools:
  • Dify emphasizes the Workflow layer (static or semi-static visual graphs).
  • LangGraph emphasizes a code-level control-flow graph DSL (developer-defined topology, dynamic routing, checkpointing). Structurally related to visual workflows, expressed as software.
  • Manus-class agents emphasize the Agent/loop layer (autonomous execution, little user-defined structure).
FIM One covers all three layers, plus automatic routing between chat engines. The progression user-defined graph → LLM-generated task graph → no schedule graph matches a broader industry honesty: as models improve, explicit topology becomes optional for most turns, not mandatory UI. Graph engineering heat is a reason to invest in engines and composition, not to force every chat through a planner.