Orchestration & context

FixControl runs a fixed set of ten specialist agents, coordinated by an orchestrator. Orchestration & context is where you see which agents exist, why the orchestrator picks one, what each of them is given to work with, and which settings are yours to tune. Core security and execution boundaries are deliberately not adjustable — the page lists them, so you can see they are intentional rather than missing.

Open it from Orchestration in the sidebar (/orchestration). It is an admin-level surface, scoped to your own organization, with five tabs: Overview, Agents, Routing, Context & search and Simulator. The console is read-only: it shows the configuration. Changes are made on each agent's own page — AI Team → the agent → Orchestration — so there is exactly one place that writes each value.

Agent names are shown in English in both languages of the product; they are names, not descriptions.

You can ask for this instead of navigating to it. Command Center can report how the agents are configured (which does what, which model, what it may spend, how often it retries, how much context it reads), change one agent's configuration through this same versioned write path, predict how a piece of work would be handled before anyone asks for it, and answer "which agent did this, and under which configuration?" — reading the configuration that was in force at the time, not today's.

The ten agents

The set is fixed. Agents cannot be created or removed, because every agent has real code behind it — a name without an executor would be an agent that could never do anything.

Five of the ten run a language model. The other five run deterministic code — they follow rules over evidence that already exists, and produce a verdict rather than a generated answer. The page shows those five without a model, with the reason, instead of showing one they never use. This matters for two reasons: a deterministic agent has no model cost, and its behaviour does not vary between runs.

How the orchestrator picks an agent

Work is planned as an ordered set of stages. Stages run one after another; the tasks inside one stage run in parallel. The orchestrator produces exactly one of three plans, and the checks run in this order:

1. UI/UX assessment — checked first. When the request or the linked issue reads as a UI/UX change, the Workflow UX Architect assesses it. A UI/UX request is a different kind of work, not a variant of the fix pipeline.
2. Support reply — when the issue is a support question, the Support Reply Agent drafts a reply.
3. Fix pipeline — everything else: bugs, features and free-form instructions.

Fix pipeline

stage 0   Codebase Agent                    context brief
stage 1   Developer Agent                   proposed change + tests + sandbox run
stage 2   QA Agent  +  Security Reviewer    both review, in parallel
stage 3   CTO Review Agent                  technical gate
stage 4   Release Manager                   delivery — only where your organization
                                            has enabled the delivery stage (off by default)

The three plans are mutually exclusive: a mission gets one of them, never a mixture.

Risk flags on an issue put the implementation task behind a human decision before any code is written. Your approval policy decides separately whether the whole plan needs sign-off before work starts.

An admin can Pause an agent, and Resume it later, from the agent's page under AI Team. If you pause an agent, its tasks are dropped from the plan — there is no substitute agent to reroute to, and the page tells you when a change would leave a later stage with nothing to act on. Pausing the Security Reviewer or the Release Manager, for example, removes the security review or the delivery stage from new plans. Two agents cannot be paused at all, and their page says Load-bearing — cannot be deactivated: the CTO Review Agent owns the technical gate and the QA Agent owns the closure gate, and the rest of the pipeline depends on both.

What an agent sees

The page lists, per agent, only the context sources its code actually reads — nothing is listed to make the picture look richer, and each source names where in the runtime the read happens.

Retrieval combines three kinds of search — semantic (vector), full-text and fuzzy text matching — into a single ranking, with an optional re-ranking pass over the best candidates. Depth is set per source: the context brief takes a fixed number of top knowledge hits, and the reply agent a fixed number of recently resolved tickets.

Two boundaries apply to every agent:

• The project boundary. An agent answering about an issue sees that issue's project sources plus organization-wide sources — never another project's. This is enforced both in the query and in the database, and it is not a setting.
• Retrieved content is data, not instructions. Text pulled from a repository or a knowledge source can never grant an agent a capability or lift an approval requirement. Permissions come from policy; nothing a retrieved document says can change that.

Each agent also lists what it may and may not do, in plain language and with the reason. The refusals are listed too: the Codebase Agent produces a brief and never a change, the reviewer never edits, the Support Reply Agent drafts but cannot send, and no agent can push to a default or production branch.

What you can adjust

You adjust an agent in Orchestration settings on its Orchestration tab under AI Team. Change opens the editable values; Review change shows what would change, from Now to After, with the risk of each field; Apply saves it. Restore FixControl defaults removes your organization's overrides for that agent — it records a new version rather than erasing the ones before it.

Which AI providers FixControl uses, and the API keys and accounts behind them, are not configured by you. They are set by FixControl for the whole platform. What you choose is which of the available models an agent should prefer for your organization.

Every setting is placed in one of four categories, and the label on screen tells you which:

The distinction between Set elsewhere and Protected is deliberate. A fixed retrieval depth and a platform-wide search weighting are not security decisions, and labelling them as though they were would tell you something untrue about your own system.

Typical Adjustable settings: which model an agent uses for your organization, a cost ceiling and answer-length limit per request, how many times work is retried, how long a single attempt may take, and how much surrounding context an agent gathers before acting. A cost ceiling refuses a request that would exceed it rather than truncating it; the agent then falls back to its deterministic path. Not every agent's work runs through the layer that applies these limits — the agent that writes code changes streams its model directly, so its spend is measured after the fact rather than capped before the call. Where that is the case the page says the values are configured, not enforced next to them, instead of implying a guarantee.

Typical Needs confirmation settings: whether the delivery stage is part of your plans at all, whether a plan needs sign-off before work starts, how strict verification is, and what "approve" means on a change the reviewer asked to revise.

Every value shows where it came from: a FixControl default, a setting for your organization, a setting for a project, or a value frozen at a higher level — with who froze it and why.

Project-level and per-agent overrides are stored as soon as you author them, but they only take effect once your organization explicitly enables narrower resolution. That setting is off by default, and until it is on the page labels such an override stored, not yet enforced rather than implying it is live. Enabling it makes every override your organization has ever authored take effect at once, so review them first.

Every change is recorded

A configuration is identified by its content, not by an edit counter. That has one very practical consequence: the untouched default is a configuration too, so a run can always name exactly what it ran under — not only after somebody has edited something.

Because of that, history is kept as two records, and the page shows both:

• which configurations this agent has had — the set of distinct configurations; and
• when it changed, who changed it and why — the timeline, read from the tamper-evident audit trail.

Changes are never rewritten. Restoring the FixControl defaults records a new entry rather than erasing the ones before it, and every past run keeps pointing at the configuration it actually ran under. Two administrators editing the same agent cannot silently overwrite one another: the second is told the configuration moved and shown the current values.

Try it before you run it

The simulator answers what would happen. Describe what you would ask for and it shows the plan the orchestrator would produce: which agents, in which stages, what context each would read, what each would be allowed to do, and which human decisions the work would need. Nothing runs — no work is created, no agent is dispatched, no gate is opened and no external system is touched. It shares the orchestrator's own planning decision rather than re-implementing it, so the prediction cannot drift from the real thing.

It predicts the plan, not the outcome: what each agent produces depends on code and evidence that does not exist yet. Gates can still be raised at runtime by policy — never lowered.

Inspect what actually happened

The run inspection on each run's page (Agent runs → a run) answers what did happen, from what was recorded at the time. Nothing is reconstructed from today's settings, because the question worth answering after a run went wrong is what the agent was configured to do then.

It is deliberate about what it does not know. A missing cost is shown as not known, with the reason — either there is no catalogue price for that model, or the run went through a subscription that reports no token counts. A run without a configuration stamp is shown as not stamped, never as "ran on defaults". Anything that could not be shown is listed with why. Absent is not zero, and absent is not default.

What is never adjustable

These are enforced in code and are not settings at any level:

• Organization isolation — enforced in the database, fails closed.
• The approval chokepoint — every gate decision is frozen with its role, route, evidence, policy version, consequence and channel. There is no side door.
• The lifecycle contract — work moves between states through one transition path, never by a direct write.
• Outbound writes — every effect on an external system goes through the outbox, with an idempotency key, a retry policy and a dead-letter path. Nothing calls an external system directly.
• Code delivery is pull/merge request only — pushing to a default or production branch is not a state the system can reach.
• The technical gate and the closure gate — the CTO Review Agent and the QA Agent cannot be paused.
• The agent set — agents cannot be created or deleted.
• The retrieval project boundary — one project's context never reaches another.

Related: Governance & policy · Approvals · Change validation