Register the planner
Connect your local planner process to the hosted control plane and publish live task digests.
NFLTR
Orchestrate AI workers in parallel
Hosted control plane for planner and worker fleets — local or distributed. Dispatch explicit task contracts, watch the run, and approve inline on nfltr.xyz.
nfltr mcp --proxy-url https://nfltr.xyz --write-mcp-json .vscode/mcp.json
nfltr worker --labels nfltr.supports_task_mode.implement=true --mcp-command "nfltr copilot-mcp"
nfltr orch status --task my-task-id --events 20 --watchHow a run works
From planner attach to recoverable state
NFLTR carries the task graph, governance, status, and recovery path. Your planner and workers make the domain decisions.
-
1
Attach a planner and workers
Connect
nfltr mcpwith an API key, then register workers by role and capability so the planner can probe and rank them. -
2
Decompose and dispatch
Turn a goal into child tasks, dispatch one task or a batch, and keep lineage so the dashboard can show root, child, and verifier state.
-
3
Steer while it runs
Answer questions, approve gated work, reject unsafe output, or abort — through the same command queue the workers already use.
-
4
Verify, observe, recover
Review and reduce with explicit outcomes. Digests, event tails, artifacts, and recovery metadata stay on the relay when a session drops.
Start targeted workers
Label workers by role and capability so the planner can route implementation, verification, and integration work.
Review live orchestration
Use the dashboard Atlas for approvals, DAGs, task detail, and timing evidence without leaving the run.
Register the planner
nfltr mcp --proxy-url https://nfltr.xyz --write-mcp-json .vscode/mcp.jsonProof
What the orchestrator has already done
Observed end to end in runs NFLTR coordinated — what happened, not what is planned.
- Decomposed, verified, reviewed, merged One objective became phases that were implemented, independently verified, reviewed, and merged without a human authoring the change.
- The plan grew when evidence failed When a phase's result contradicted its own success claim, the coordinator added a verification phase on a different worker.
- Review rejected the fleet's own work A review stage rejected work from the same fleet and withheld merge until the problem was corrected.
- Run state lives on the relay Task digests and recovery metadata stay inspectable after disconnects, so another session can monitor, approve, or cancel in-flight work.
When to use
Where local and distributed orchestration win
Use local nfltr orch when coordination quality matters more than machine count. Use distributed orchestration when the best worker is defined by repo access, hardware, network, secrets, platform, or availability.
Local nfltr orch
Better than a single agentic harness
- Builder and verifier separation One local actor implements; another reviews with a clean context, reruns the tests, and can reject the patch so it is not merged until the problem is corrected.
- Isolated workspace per actor Parallel actors on one machine each get their own workspace, so two of them touching the same files do not overwrite each other and patches come back for review instead of landing in place.
- Parallel investigation of one failure Run separate actors for reproduction, code archaeology, candidate fix, and test coverage, then merge the evidence into one decision.
- Human-gated local work Keep questions, approvals, aborts, and rework requests in-band instead of losing decisions inside one long terminal transcript.
Distributed nfltr orch
Useful when locality matters
- Capability-matched routing Workers advertise task mode, the tooling installed on the host, and whether each task gets an isolated workspace, and the planner routes on that instead of a fixed assignment.
- Private repo or secret-bound work Route tasks to the machine that already has the checkout, credentials, internal network, or customer environment.
- Heavy builds and specialized hardware Keep the planner lightweight while workers on CI, GPU hosts, or beefier desktops run slow builds, tests, traces, or benchmarks.
- Long-running or shared operations A run is owned by the relay, not by the terminal that launched it, so the operator can disconnect while teammates monitor, approve, recover, or resume it from the dashboard.
Where to start