Deterministic Zero-LLM Orchestration
A deterministic code orchestrator splits goals, runs parallel coding agents, verifies with tests, and commits, spending LLM tokens only on the one-time goal decomposition
Add to Pack
Saved locally in this browser for now.
Cite This Pattern
Alex Chernysh (@chernistry) (2026). Deterministic Zero-LLM Orchestration. In *Awesome Agentic Patterns*. Retrieved October 14, 2026, from https://agentic-patterns.com/patterns/deterministic-zero-llm-orchestration
@misc{agentic_patterns_deterministic-zero-llm-orchestration,
title = {Deterministic Zero-LLM Orchestration},
author = {Alex Chernysh (@chernistry)},
year = {2026},
howpublished = {\url{https://agentic-patterns.com/patterns/deterministic-zero-llm-orchestration}},
note = {Awesome Agentic Patterns}
} Use when
- Multi-agent coding system spends tokens on routing and coordination
- Project structure is well defined enough for rule-based planning
- You want the same goal to produce the same task breakdown
Avoid when
- Ambiguous goals need LLM judgment to split
- Novel task types need adaptive routing
Problem
Multi-agent coding systems typically spend LLM tokens on coordination — deciding which agent works on what, routing tasks, merging results. This coordination overhead adds cost, latency, and non-determinism where none is needed.
Solution
Keep the orchestrator as deterministic Python code that spends almost no LLM tokens on coordination. Decomposition makes a single LLM call ("One LLM call, then plain Python from there"), and everything after it — assignment, verification, git — is plain code. The LLM budget goes almost entirely to the agents doing actual work.
Goal → Decompose (one LLM call) → Assign to parallel agents → Verify (tests) → Commit
For a fully LLM-free path, write the plan file yourself and run it directly with bernstein run plan.yaml, skipping LLM planning entirely.
The orchestrator handles:
- Task decomposition via one LLM call, then rule-based planning in code
- Agent assignment and parallel spawning (Claude Code, Codex CLI, Gemini CLI)
- Result verification through test execution
- Git operations (branching, merging, committing)
Agents handle:
- Code generation
- Problem solving
- Implementation decisions
How to use it
# Single goal → parallel agents → verified commits
bernstein -g "Add JWT auth with refresh tokens, tests, and API docs"
# Fully LLM-free: execute a plan file directly, skipping LLM planning
bernstein run plan.yaml
# Initialize a project, watch a run, stop it
bernstein init
bernstein live
bernstein stop
Key implementation choices:
- No LLM router — task-to-agent mapping is code, not prompts
- Test-driven verification — a janitor process runs tests after each agent completes
- Git worktree isolation — each agent works in its own worktree, no conflicts
- Circuit breaker — halt on test regression, no silent failures
Trade-offs
Pros:
- Predictable coordination cost (one LLM call at setup, then plain Python; zero with a hand-written plan file)
- Deterministic behavior — same goal produces same task breakdown
- Faster iteration — no waiting for LLM to decide what to do next
- Supports heterogeneous agents (Claude Code, Codex CLI, Gemini CLI, Qwen)
Cons:
- Rigid decomposition — can't handle ambiguous goals that need LLM judgment to split
- Requires well-defined project structure for rule-based planning
- Less adaptive than LLM-routed orchestration for novel task types
References
- Bernstein — reference implementation of this pattern (repo transferred from
chernistry/bernstein, which now redirects). Status per its README: beta, solo-maintained, under active development. - See also: Sub-Agent Spawning for the general multi-agent delegation pattern
- See also: Plan-Then-Execute Pattern for the planning phase approach