How the Requirements Traceability Graph Works as a Mission

When Ajay describes the traceability graph as "click any line, see the whole chain both ways," what he's describing is, to me, a textbook StudioX Mission. There's no giant new service to build and no matrix to maintain. There's a small org chart of specialist agents, a reasoning core that routes between them, and a rule that every decision gets written down as it happens. Let me walk through how we actually assemble the chain — ask → decision → code → test → release — the moment someone asks, and where a human stays in the loop.

The mission is an org chart, not a pipeline

A Mission in StudioX takes a goal in plain language and delegates it to specialist agents, each an expert in one domain and each backed by its own bot and knowledge base. The reasoning core — we call it the Reasoning Vibe — knows nothing about traceability itself. All the domain knowledge lives in the agents. That separation is the whole trick: I can add, remove, or re-describe an agent without touching the orchestration.

For the traceability graph, the roster looks like this:

• Requirements Agent — reaches into the requirements manager (Jama, DOORS, Polarion, or a Jira project) to find the requirement and the approval/decision record behind a given ID or code region.
• Code Agent — resolves a line or symbol to its Git history: the commit, the author, the PR, and crucially the commit message and PR discussion that reference a requirement or decision.
• Test Agent — searches the test management system and the test code for cases that exercise the requirement or the code region, and reads their latest results.
• Release Agent — maps a commit to the tags, builds, and release records that carry it to production.
• Report Agent — assembles the traced chain into the user-facing graph and, because its name contains "report," its output is persisted as a first-class record you can cite later.

The user's intent arriving at the mission is as ordinary as "Trace src/alarm/threshold.c line 212 both directions." The reasoning core reads that, reads the agent descriptions, and decides — one round at a time — which single agent acts next.

Two tiers: the router plans, the agents work

Under the hood there are two reasoning tiers, and understanding the split is the key to understanding why this is accurate rather than a hallucinated guess.

Tier 1 is the reasoning core. Each round it makes one LLM routing decision: given the intent, the agent roster, and every prior agent result accumulated so far, which agent should act next — or is the chain complete? It re-reads the accumulated results each round and decides semantically whether we're done. So it might route to the Code Agent first to resolve the line to a commit, feed that commit to the Requirements Agent and the Test Agent, then to the Release Agent, then declare the chain assembled. The router is a project manager: it plans and synthesizes, it doesn't do the tool work itself.

Tier 2 is the agent planner. When the router hands a goal to an agent with a bot, that agent discovers its own capabilities — MCP tools, knowledge bases, vibes — decomposes the goal into ordered steps, and executes each step against its bot. The bot runs its own pipeline: it picks a tool, calls it, shapes the result, and streams back a text answer. The planner's rule is that the plan always ends with a reason step that produces the clean, user-facing slice — and each earlier step is scoped by a "return ask" so the agent hands back only the relevant records, not a raw dump.

Instant MCP servers do the wiring

The reason this is weeks-to-value rather than a quarter-long integration project is MCP. Each agent's bot reaches its system through an MCP server — the requirements manager's API, the Git host, the test suite, the release tooling — registered at runtime. The Generic Agent, and any agent's bot, discovers those tools the moment they're registered; there's no code change and no redeployment to teach the mission about a new system. Point a bot at a DOORS MCP server and a GitHub MCP server, and the Requirements and Code Agents can traverse them immediately. New test platform next quarter? Register its MCP server; the Test Agent uses it that day.

Observations: watch it reason

Every phase is streamed as a trace event — routing decisions, each agent's plan, each step and its validation, the final synthesis — over Server-Sent Events into the Explain rail of the portal. This is non-negotiable in our design, and for traceability it's the point: you don't get a chain and have to trust it. You watch the mission resolve line 212 to commit a3f9, watch the Requirements Agent tie that commit's PR reference to REQ-4471 and its approval, watch the Test Agent find test_threshold_bounds and read its last pass. Every link in the chain shows why it was drawn, in plain language, in execution order — which is exactly the provenance an auditor wants.

Where the human stays in the loop — and where it doesn't

Here's where I want to be precise rather than oversell. Assembling and reading the traceability graph is a read-only operation. It queries requirements, code, tests, and releases; it changes nothing. So the normal flow needs no approval gate at all — you ask, you get the traced chain. The decision queue and human-in-the-loop machinery in Missions exists for when a chain surfaces something that warrants an action — say the graph reveals an orphaned safety requirement with no linked test and someone triggers a follow-up. If the mission's synthesis proposes a destructive or high-blast-radius action, it emits a [REQUEST_APPROVAL] block instead of claiming it did the work; the route turns that into a decision-queue row and emails a reviewer a magic-link approve/reject. For pure tracing, that path simply never fires. Honesty about that boundary matters — a traceability tool that quietly changed your systems would be the opposite of trustworthy.

That's the machine. For why it's worth building at all, read Ajay's why it matters; for a real field run with the numbers, Harry's in practice. And the platform underneath — the reasoning core, the agents, the MCP layer — is the same AI Missions engine, grounded in your own enterprise knowledge, running inside your perimeter.