Decision #1 — agenKic-orKistrator

Orchestration Pattern

Why Supervisor/Worker + DAG over LangGraph, CrewAI, or AutoGen

The Question

How should we coordinate multiple AI agents working on decomposed tasks? The orchestrator needs to spawn agents, assign work, handle failures, and support both sequential and parallel task execution. The pattern choice shapes every downstream API: from how tasks are represented and queued, to how results are collected and failures are recovered. Choosing a framework means accepting its concurrency model, fault tolerance primitives, and interoperability constraints for the life of the project.

Options Considered

Supervisor/Worker + DAG
Go-native gRPC control plane with LangGraph-style DAG task decomposition
Chosen
Pros
  • Type-safe contracts via protobuf and gRPC across all agent boundaries
  • OTP-style supervision tree with proven fault-tolerance model
  • DAG decomposition enables genuine parallel fork execution, not just sequential chains
  • Scales horizontally to N agents without framework-imposed bottlenecks
Cons
  • More upfront scaffolding than dropping in a Python framework
  • Custom DAG engine requires ongoing maintenance
LangGraph (Python)
Graph-based orchestration with state persistence from the LangChain ecosystem
Rejected
Pros
  • Mature and well-documented with wide community adoption
  • Native access to the Python AI/ML ecosystem
  • Built-in state persistence and checkpointing
Cons
  • Python runtime overhead and GIL concurrency limits
  • No native desktop process integration with Godot
  • Vendor lock-in to LangChain abstractions and release cadence
CrewAI
Role-based agent coordination with high-level process delegation API
Rejected
Pros
  • High-level role abstraction enables rapid prototyping
  • Clean separation of agent responsibilities via role definitions
Cons
  • Limited customization once you leave the happy path
  • Opaque internals make debugging agent interactions difficult
  • Python-only, no cross-language embedding story
AutoGen / MetaGPT
Multi-agent conversation frameworks — AutoGen (Microsoft) and MetaGPT (65.1k stars)
Rejected
Pros
  • MetaGPT has the deepest orchestration patterns in the Python ecosystem
  • AutoGen is Microsoft-backed with strong enterprise documentation
  • Both offer multi-agent conversation primitives out of the box
Cons
  • Conversation-centric, not task-centric — poor fit for structured DAG work
  • Complex debugging when agent conversations diverge from expected flows
  • No visual UI story and no native cross-runtime embedding

The Decision

Go

Go-native for desktop integration

The orchestrator runs as a native process alongside a Godot desktop application. Go compiles to a single binary, shares no runtime with the UI layer, and starts in milliseconds. Python frameworks require a runtime, dependency resolution, and a foreign-function bridge to reach Godot — three additional failure surfaces before the first agent task is dispatched.

OTP

OTP supervision model: 35 years of fault tolerance

The supervisor/worker pattern maps directly to Erlang’s OTP supervision trees, which have underpinned telecom-grade systems since 1987. Each agent is a supervised worker: crash detection, exponential backoff, circuit breakers, and restart policies are first-class primitives rather than application-layer afterthoughts bolted onto a Python event loop.

DAG

DAG decomposition enables real parallelism

Sequential chains (LangGraph, CrewAI) process one step at a time. A directed acyclic graph lets the supervisor identify independent branches and dispatch them to separate agents concurrently. For a task like “research + draft + review,” the research subtasks fan out in parallel, the draft waits for all upstreams, and review unblocks immediately after. This is not achievable by chaining agent calls sequentially.

GAP

The competitive gap this project occupies

The research council identified two capability poles: Pixel Agents for visual programming interfaces, and MetaGPT for deep multi-agent orchestration. No existing project combines a rich desktop visual layer with a production-grade task orchestration engine. This project occupies both poles simultaneously — requiring a Go-native orchestrator that the desktop UI can directly supervise and inspect.

Trade-offs Acknowledged

Implementation effort.  Using LangGraph out of the box would have yielded a working prototype faster. The Go-native approach front-loads the scaffolding cost: gRPC service definitions, a DAG engine, and the supervision loop must be built and tested before any agent work ships.
Go AI ecosystem maturity.  Python’s AI ecosystem is orders of magnitude richer — more client libraries, more model integrations, more community patterns. Go clients for LLM APIs exist but are less battle-tested. Integration work that is a one-liner in Python may require a hand-rolled client in Go.
Custom DAG engine maintenance.  Rather than using an established graph library, the DAG engine is a custom implementation inside the orchestrator package. Topological sort, cycle detection, and fan-out scheduling are implemented and tested here rather than inherited from a dependency.
gRPC latency floor.  gRPC serialization adds approximately 5–20 ms of overhead per call compared to in-process function calls. For long-running LLM tasks this is negligible, but for high-frequency supervisor heartbeat and assignment loops the protocol budget must be managed.
Council verified: 11-agent parallel research team + adversarial council review (2026-03-14). The ARBITER’s recommendation was FOR the Supervisor/Worker + DAG pattern on all four decision axes: runtime fit, fault-tolerance model, parallelism model, and competitive positioning. No unsubstantiated counter-claims remained after QUESTIONER review.