How a task gets executed
Two containers run permanently in your infrastructure: Engine and Command Center. Every task spawns short-lived containers - one for the agent, one for the executor that matches the target’s protocol - and tears them down when the task ends. (MCP plugins add one container each, only if configured.) The same flow runs whether the task came from the Command Center UI or a gateway ticket. Engine doesn’t care.The two-engine agent
Every agent uses two LLMs in tandem, each with a distinct job.Main engine - the executor
Does the work: plans the approach, navigates the filesystem, reads and modifies files, executes commands, interacts with CLIs and MCPs. This is the model that consumes most tokens because it carries the operational context required to act reliably.Secondary engine - the copilot
Watches the main engine. It reviews every command before it runs to answer:- Does this comply with the active operational rules? If not, redirect.
- Is the agent trying to alter the system while running in read-only mode? If yes, block.
- Is the agent drifting away from the task? If yes, refocus.
The tenant engines
Engines aren’t just per-agent. Two more sit at the tenant level - the defaults used everywhere an agent isn’t running:
Tenant defaults are picked in Settings → Tenant from the model catalog. A 70–300b model is usually plenty here - routing is lighter work than executing.