How the Conflict Predictor Works as a StudioX Mission

Harry's companion piece on why colliding branches hurt makes the business case. My job is the other half: showing you exactly how the Conflict Predictor is assembled as a StudioX Mission, so you can judge it as an engineer rather than take it on faith. I'm Trevor Solis, and I lead the Missions team. Nothing below is aspirational — it maps directly onto how a mission actually runs.

A mission is a small org chart, not a script

The first thing to unlearn is the pipeline mental model. The Conflict Predictor is not a cron job that runs seven hard-coded steps. A StudioX Mission is a roster of specialist agents coordinated by a reasoning core. Each agent is a StudioX Vibe backed by its own bot and its own knowledge base — a worker that's expert in exactly one thing and knows nothing about the others. The reasoning core is the project manager: it reads the incoming intent and the roster of agent descriptions, and decides, one round at a time, which single agent should act next. It knows nothing about Git or branches; all of that domain knowledge lives in the agents. Change an agent's description and the routing changes. Add an agent and it gets considered automatically, with no redeploy.

For the Conflict Predictor, the roster looks like this:

• a Branch Watcher agent that reads the current set of active branches and their recent commits;
• a Diff Analysis agent that reasons over what each branch is actually changing — which files, which symbols, which interfaces;
• a Collision Reasoning agent that compares changes pairwise and judges whether two branches are genuinely converging or just coincidentally near each other;
• a History agent, backed by a knowledge base of past merges and post-mortems, that weighs how badly a given pair of areas has bitten the team before;
• a Notify agent that drafts the heads-up and, when an action is warranted, hands it to a human.

How the tools get wired: instant MCP servers

None of those agents can see your repository until you connect it, and this is where StudioX earns its keep. Instead of a bespoke integration project, the Branch Watcher's bot reaches your Git host — GitHub, GitLab, whatever you run — through an instant MCP server. MCP tools are discovered at runtime. You register the server once; the agent's planner discovers the available tools (list branches, list commits, fetch a diff) the moment they exist, and can use them immediately. Swap GitHub for GitLab tomorrow and you register a different MCP server — no agent code changes, because the agents were never coded against a specific API. This is the "new tool means no integration project" promise made concrete.

What actually happens on a run

When the mission fires, the two-tier reasoning system in the docs kicks in. Tier 1 — the reasoning core — routes. It looks at the intent ("check active branches for collisions"), the agent roster, and a one-line index of every knowledge base, then makes an LLM routing decision: pick one agent, or declare the request done. It re-reads every prior agent result each round, so a round that comes back "no active branches touch overlapping code" is a complete answer, and the core exits rather than spinning.

Tier 2 is the chosen agent's planner. When the core routes to, say, the Diff Analysis agent, that agent discovers its own capabilities (MCP tools, KBs, vibes), decomposes its goal into an ordered list of steps — at most six, always ending in a reason step that produces the user-facing slice — and executes each step against its bot. Crucially, the planner hands each step a scoped return ask: it doesn't want a raw dump of every diff line, it wants "the files and symbols each active branch modifies." The agent reasons over the full diffs internally but hands back only that slice. That's what keeps a hundred-branch scan from drowning the top-level reasoning in noise.

Watching it reason: observations

The reason I trust this on a live repo is that it isn't a black box. Every phase — each routing decision, each plan, each step and its validation, the final answer check — is recorded as a trace event and streamed to the Explain rail in true execution order. When the Collision Reasoning agent decides that Priya's and Marcus's branches collide, the observation reads in plain language: both modify BillingAdapter.charge(); the History agent found a prior post-mortem on this exact interface; confidence high. You're never asked to trust a verdict you can't inspect. If it makes a wrong call, you can see the exact step that caused it and fix the knowledge or the agent description behind it — no code change.

Where the human gate lives — and where it doesn't

Let me be honest about a distinction that matters. Most of this mission is read-only. Watching branches, analyzing diffs, cross-referencing history — none of that touches your repository. There is nothing to gate there, and pretending otherwise would just add friction. The mission observes; it does not rewrite anyone's branch.

The gate lives at exactly one place: the action. When the Notify agent concludes a collision is real and wants to do something beyond informing — open a tracking issue, request that one branch pause, ping a specific pair of engineers with an assignment — it doesn't just act. The synthesis step emits a [REQUEST_APPROVAL] block, which the mission turns into a row in the decision queue: a pending action with the full reasoning attached, waiting for a human's approve or reject. A reviewer sees why, not just what, and clicks once. That's the human-in-the-loop principle applied precisely where it earns its cost — on the actions with consequences — and nowhere it would just slow you down.

How people actually touch it

Engineers don't babysit a dashboard. The mission is delivered through portals — the StudioX UI surface — and through whatever channel fits: a Slack message, an email, or the runtime API (POST /missions/run/{slug} with an API key) wired into a merge-check. The heads-up meets people where they already work.

If you want to see all of this play out on a real team over a real sprint — with the hours saved and the escape it caught — read the in-practice walkthrough. The architecture above is the machine; that piece is the machine earning its keep.