Why dynamic planning is the hard middle ground
The AI agent landscape split into two camps, and both picked the easy path. Traditional workflow engines — Dify, n8n, Coze — chose static orchestration: visual drag-and-drop flowcharts with fixed execution paths. This was not ignorance; enterprise customers demand determinism (same input, stable output), and static graphs deliver that. On the other extreme, fully autonomous agents (AutoGPT and its descendants) promised end-to-end autonomy but proved impractical: unreliable task decomposition, runaway token costs, and behavior nobody could predict or debug. The sweet spot is narrow but real. Simple tasks do not need a planner. Tasks complex enough to require dozens of interdependent steps overwhelm current LLMs. But in between lies a rich class of problems — tasks with clear parallel subtasks that are tedious to hard-code yet tractable for an LLM to decompose. Dynamic DAG planning targets exactly this zone: the model proposes the execution graph at runtime, the framework validates the structure and runs it with maximum concurrency. No drag-and-drop, no YOLO autonomy.The bet on improving models
Every few months the foundation shifts — GPT-4, function calling, Claude 3, the MCP protocol. Building a rigid abstraction on shifting ground is risky; LangChain’s over-abstraction is the cautionary tale everyone in this space has internalized. FIM Agent takes the opposite approach: minimal abstraction, maximum extensibility. The framework owns orchestration, concurrency, and observability. The intelligence comes from the model, and the model keeps getting better. Today, LLM task decomposition accuracy sits around 70-80% for non-trivial goals. When that reaches 90%+, the “sweet spot” for dynamic planning expands dramatically — problems that were too complex yesterday become tractable tomorrow. FIM Agent’s DAG framework is designed to capture that expanding value without rewriting the plumbing.Will ReAct and DAG planning become obsolete?
ReAct will not disappear — it will sink into the model. Consider the analogy: you do not hand-write TCP handshakes, but TCP did not go away; it got absorbed into the operating system. When models are strong enough, the think-act-observe loop becomes implicit behavior inside the model, not explicit framework code. This is already happening: Claude Code is essentially a ReAct agent where the loop is driven by the model itself, not by an external harness. DAG planning’s lasting value is not “helping dumb models decompose tasks” — it is concurrent scheduling. Even with infinitely capable models, physics imposes latency: a serial chain of 10 LLM calls takes 10x longer than 3 parallel waves. DAG is an engineering problem (how to run things fast and reliably), not an intelligence problem (how to decide what to run). Retry logic, cost control, timeout management, observability — these do not go away when models get smarter. The endgame: models own the “what” (planning intelligence internalizes into the model), frameworks own the “how” (concurrency, retry, monitoring, cost governance). A framework’s lasting value is not intelligence — it is governance.Why not mirror Dify’s workflow editor
A natural question: if DAG covers the flexible case, shouldn’t we also build a static workflow editor for the deterministic case? No. The reasoning:- The workflows already exist elsewhere. Government and enterprise clients’ fixed processes live in their OA, ERP, and legacy systems. They don’t want to rebuild those flows in yet another platform — they want AI that can connect to the systems where those flows already run. The Connector Platform (v0.6) solves this directly.
- Existing capabilities compose into fixed pipelines. Scheduled Jobs (v1.0) trigger a DAG agent with a fixed prompt; the DAG dynamically plans the steps; Connectors (v0.6) connect to the target systems. The combination is equivalent to a static pipeline — but more flexible, because the LLM can adjust its plan based on the data it encounters. No separate pipeline DSL needed.
- Investment mismatch. A production-quality visual workflow editor (canvas, node types, variable passing, debug/replay) is months of dedicated effort. The result would be a low-fidelity copy of what Dify’s 120K-star community already maintains. That effort is better spent on the Connector architecture — a capability no competitor offers.
Where FIM Agent stands
FIM Agent is not an “AGI task scheduler” and not a static workflow engine. It occupies the middle ground: planning capability with constraints, concurrency with observability.- Compared to Dify: more flexible — runtime DAG generation vs. design-time flowcharts. You do not need to anticipate every execution path in advance. Does not compete on visual workflow editing; competes on legacy system integration.
- Compared to AutoGPT: more controlled — bounded iterations, re-planning limits, with human-in-the-loop on the roadmap. Autonomy within guardrails.
Where FIM Agent Sits: Planning x Execution Spectrum
The AI execution landscape can be mapped on two axes — how plans are created (static vs dynamic) and how they are executed (rigid vs adaptive): Why Dify/n8n are Static Planning + Static Execution: The DAG is drawn by a human on a visual canvas at design time. Each node executes a fixed operation (an LLM call with a fixed prompt, an HTTP request, a code block). There is no runtime replanning — if a step fails, the workflow fails or follows a pre-wired error branch. This is structurally the same as BPM, just with AI nodes in the graph. FIM Agent’s position: Dynamic Planning + Dynamic Execution- DAG topology is generated by LLM at runtime (dynamic planning) — no human designs the graph
- Each DAG node runs a full ReAct loop (dynamic execution) — nodes reason, use tools, and adapt
- Re-planning mechanism (execute → analyze → re-plan if unsatisfied)
- But bounded: max 3 re-plan rounds, token budgets, human confirmation gates
Concept Glossary
For readers unfamiliar with the terminology used in this document:| Term | One-line explanation | Relation to FIM Agent |
|---|---|---|
| BPM (Business Process Management) | Processes fully fixed at design time, executed rigidly. Camunda, Activiti. | FIM Agent is not BPM. No fixed process engine. |
| FSM (Finite State Machine) | System is in exactly one state at any time; events trigger transitions. Supports loops (reject → resubmit). | Target systems (ERP, contract systems) use FSM internally. FIM Agent doesn’t need its own FSM — it calls the target system’s API. |
| ACM (Adaptive Case Management) | Skeleton static, branches dynamic. Main flow pre-defined, each node adapts at runtime. | FIM Agent’s DAG + ReAct naturally falls in this quadrant. |
| HTN (Hierarchical Task Network) | Recursive task decomposition: high-level → subtasks → atomic operations. | DAG re-planning covers most scenarios; full HTN not needed yet. |
| iPaaS (Integration Platform as a Service) | Cloud integration platform connecting multiple SaaS/on-prem systems. MuleSoft, Zapier. | FIM Agent’s Hub Mode is like AI-native iPaaS — natural language drives cross-system integration. |
Architecture Boundary: FIM Agent Does Not Replicate Workflow Logic
Complex business processes (approval chains, transfers, rejections, escalation, co-signing, countersigning) are the target system’s responsibility. These systems spent years building this logic — ERP, OA, contract management systems all have mature state machines. From the Connector’s perspective:| Operation | What the Connector does |
|---|---|
| Transfer | Call one API, pass target person |
| Reject | Call one API, pass rejection reason |
| Escalate | Call one API, pass escalation person list |
| Co-sign | Call one API, pass co-signer list |
- Create maintenance burden (two state machines to keep in sync)
- Add failure modes (what if they disagree?)
- Provide zero additional value (the target system already does this correctly)