How the Release Notes & Email Composer Mission Works

Harry's companion piece makes the case for why the release note is the last mile of everything your team built. I own the other half of that sentence: how the thing is actually built. I lead the Missions engineering team at StudioX, and the Release Notes & Email Composer is a Mission that runs in production. So let me open the hood — not with marketing abstractions, but with the actual mechanics: which agents run, how you watch them reason, where a human gates the one action that matters, and how we wired GitHub into the whole thing in an afternoon.

The mental model: a small org chart, not a script

A StudioX Mission is not a workflow with boxes and arrows you drew in advance. It's a small org chart of specialist agents plus a reasoning layer that decides, one round at a time, who acts next. The reasoning layer — we call it the Reasoning Core — knows nothing about release notes. All the domain knowledge lives in the agents. That separation is the whole design: the Core is a project manager that plans and synthesizes; each agent is a worker that does the actual tool work and hands back only the slice the Core asked for.

For this Mission the roster is four agents:

• PR Harvester — pulls the merged PRs for the release range from GitHub: titles, bodies, labels, diffs, authors.
• Change Classifier — sorts each PR into internal-only, customer-facing, or breaking, using a knowledge base of your team's labeling conventions and past releases.
• Notes Composer — drafts the three artifacts: internal changelog, external release notes, customer email.
• Delivery Agent — the only agent that can send anything outward, and the only place a human gate lives.

Each agent is backed by its own StudioX bot with its own knowledge base — knowledge isolation by design, so the Classifier only ever searches your release conventions and never accidentally reasons over, say, billing policy.

Round by round: how the Core routes

When a release manager sends the intent — "Draft the notes and customer email for release 4.12" — the Mission chat route authenticates, loads the enabled agents and their knowledge bases, and calls the Reasoning Core. Because there's more than one agent, the Core runs its multi-round routing loop. Each round is a single LLM call that reads the roster, the knowledge-base directory, and every prior agent result accumulated so far, then picks exactly one agent to act next — or decides the work is done and returns id 0.

Round one, it routes to the PR Harvester. Round two, with the PRs in hand, it routes to the Change Classifier. Round three, to the Notes Composer. Round four, to the Delivery Agent. The Core isn't following a hardcoded sequence — it re-reads the accumulated results each round and reasons about what's still missing. If the Harvester came back with zero PRs, the Core would recognize that as a complete (if empty) answer and stop, rather than blindly marching to the Composer. Knowledge drives behavior; change the roster and the routing changes.

Inside an agent: the planner and the tools

When the Core selects an agent that has a bot, Tier 2 kicks in — the agent planner. It first discovers what that agent can actually do: its MCP tools, its knowledge bases, its vibes. For the PR Harvester, discovery finds the GitHub tools. The planner then decomposes the goal into an ordered list of steps, each with a scoped return ask — "hand me back the merged PRs in range 4.11..4.12, each with title, body, labels, and files changed." The agent runs its tools over the full result internally but returns only that slice, so the Core isn't drowning in raw diff. Every plan ends with a reason step that produces the clean, user-facing output.

This is where instant MCP servers earn their name. GitHub isn't hardcoded into the Mission. We registered a GitHub MCP server, and the PR Harvester's Generic-style discovery picked up its tools at runtime — list-pull-requests, get-pull-request, compare-commits. No integration project, no redeploy. When we later wanted to pull from a second repo, we registered another server and the agent used it immediately. That runtime capability injection is what "no code" means at the architectural level: a new tool registers, and the Mission can use it on the next run.

Observations: watching it reason, not trusting a black box

Here's the part that matters most to me as an engineer, and the reason release managers actually trust the output. The whole run is observable. Every phase — each routing decision, the capability discovery, the plan, each step and its validation, the final answer check — is recorded as a trace event and streamed live to the Explain rail over Server-Sent Events. You don't get a finished draft dropped on your desk with no lineage. You watch "Routing to PR Harvester…", then "Classifier: PR #2226 → breaking (matched rate-limit convention)", then the Composer drafting, as it happens.

When the Classifier tags that rate-limit PR as breaking, the trace shows why — which knowledge-base convention it matched. If it ever mis-tags something, you don't guess; you read the trace, find the step, and fix the knowledge or the agent description that caused it. That's the difference between an automation you audit and one you pray over.

The one gate: read-only until the human says send

Let me be precise about where a human is required, because honesty here is the whole point. Harvesting PRs, classifying them, and drafting the three artifacts are all read-only — nothing leaves the perimeter, so nothing is gated. The Mission produces all three drafts autonomously.

Sending the customer email is different. It's an outward, irreversible action, so the Delivery Agent doesn't send it — it ends its turn with a [REQUEST_APPROVAL] marker. The chat route's post-processing catches that marker, writes a row into the decision queue, and emails the release manager a magic-link approve/reject URL. The email does not go out until a human clicks approve. That's the human-in-the-loop gate: full autonomy on the reading and drafting, an explicit stop on the one action a wrong call can't take back. If the manager wants to tweak the draft first, the Composer's output can be opened as a portal — a [REQUEST_PORTAL] marker rewrites into an editable builder link.

That's the Mission end to end: four agents, a reasoning loop you can watch, tools wired by MCP in an afternoon, and exactly one human gate on exactly the right step. If you want to see it earn its keep on a real release, Harry's field write-up has the numbers. And if you're mapping this pattern onto your own release process, StudioX's AI workflow automation and business applications are where these Missions live.