How it works
The orchestrator, Task Documents, and the plan-confirm-fan-out flow
How it works
Every Foxl Code account has one orchestrator - a per-user agent that turns a conversation into shipped pull requests. It decides whether to just reply, ask you something, file a GitHub Issue, or plan and spawn coding agents, and it keeps an eye on the agents it spawns. At code.foxl.ai it runs in Foxl's cloud using managed Bedrock models and Relay credits. Foxl Desktop also runs the shared orchestrator locally with your own configured providers (BYOK/BYOA). These are separate model-access paths.
The orchestrator
The orchestrator is a single reasoning agent per user (not a fixed pipeline). When you chat - whether at code.foxl.ai or inside the Foxl app - it routes your message to one of a few actions:
- Reply - answer a question, no work needed.
- Ask you - put a question in your Needs you queue (and a notification on your phone) before planning. Your answer settles it everywhere it is shown.
- Plan - write a Task Document for multi-step work.
- Spawn - launch one or more coding agents to do the work.
It runs on a model you choose for replies, separate from the model your coding agents use, so you can keep orchestration cheap and let the heavy model do the coding. On code.foxl.ai, the picker offers Foxl's managed catalog without requiring a Desktop connection or personal key. It includes Claude, GPT, GLM, Kimi, Grok, and chat-only Gemma. On Desktop, the local picker retains your connected providers and subscriptions. See Model access.
Task Documents
A Task Document is the orchestrator's plan, written in markdown. Each top-level checkbox is one unit of work that maps to one pull request:
- The plan carries a title, the checkbox list, an execution status, and an estimated budget.
- Each checkbox can open a GitHub Issue and is tracked as a subtask.
- As agents land PRs, the orchestrator ticks the matching checkboxes.
A Task Document moves through draft -> awaiting_confirmation -> confirmed -> in_progress -> completed (or archived if you drop it).
Confirm once, then fan out
With the default autonomy level (Work on its own, ask me to merge) a coding request in chat starts agents in the same turn - Foxl tells you what it started instead of asking permission, and still stops to ask when a guess could waste the whole run or the work is hard to reverse. Two things bring the confirmation back:
- A request that splits into more pull requests than your per-turn cap (3 by default, "Agents per turn without asking" under Advanced on the Autonomy card) gets a Task Document with a cost estimate and one approval button first. You confirm once, and the orchestrator spawns a coding agent for every checkbox in a single step - they run concurrently, each on its own machine.
- The "Only when I ask" level turns instant spawning off, so every request waits for you.
The plan waiting for approval is the one card in Needs you that has no dismiss button, because there is nowhere else in the app to find it.
Single-PR requests never need the plan. With the default level the agent is started in the same turn; with "Only when I ask" the orchestrator asks first and spawns one agent. The Task Document machinery is for work that fans out across multiple PRs or repos. See Autonomous loop.
Watching the agents
Once agents are running, the orchestrator can inspect and steer them:
- Read an agent's screen - see exactly what its terminal is showing right now.
- Send input - type into a running agent's terminal.
- Resize - adjust the terminal dimensions.
- Poll active agents - list which agents are still running.
- Resume, retry or cancel an agent - the same controls you have on a task, so it can unblock a paused agent or give a failed one one more go.
- Read GitHub - CI status, the failing build's log, a pull request or issue - confined to the repository you have selected. On your own computer it signs in the way you already do (
gh auth login, your git credential helper, orFOXL_CODE_GITHUB_TOKEN). - Remember the repo - it keeps a short project memory per repository and hands it to the next task there.
This is what lets one orchestrator coordinate several agents at once - checking on each and unblocking it as needed. To have it do this on a schedule without you in the chat, see the autonomous loop.