How a StudioX Mission Calls a Wrapped Arcane API

Let me show you what actually happens when a StudioX Mission calls a legacy API you wrapped this morning — because the interesting engineering is not in the wrapping. Wrapping is the easy part now. The interesting part is what the platform does with that wrapper once it exists: how an agent discovers it, decides to use it, and how a state-changing call gets gated behind a human before it fires. I build the Missions layer, so this is the view from inside the orchestrator.

The wrapper is an HTTP-shaped contract

Start with the thing you build. An instant MCP server takes one arcane API and exposes it as a set of named tools over MCP — the Model Context Protocol, the "USB-C for AI" plug. Each tool maps to exactly one endpoint: a name the AI reads, a description it reasons over, an HTTP method, a URL template, and typed parameters. You can generate the whole set from an OpenAPI or Postman spec, or hand-author the operations for the genuinely strange APIs. For a SOAP service, the body-template engine renders the XML envelope and conditional fragments so absent fields vanish cleanly; response handling catches a <faultstring> hiding inside an HTTP 200 and extracts just the records the model needs instead of handing it 8KB of envelope. Credentials are AES-256-GCM encrypted and injected as headers server-side — they never cross the conversation.

What you get out is a single URL and a JSON-RPC contract: tools/list to discover, tools/call to execute. That contract is the seam the whole Mission architecture bolts onto.

Two tiers of reasoning sit above the seam

A Mission is a small org chart of specialist agents, and when a user message arrives it runs a two-tier reasoning system. I'll trace one turn.

Tier 1 is the Reasoning Core — the router. It reads the request, the roster of agents, and a one-line index of every knowledge base, then makes an LLM call to pick a single agent to act next. It re-reads every prior result each round and decides, semantically, whether the request is answered yet. If the Mission has exactly one enabled agent it skips routing entirely and chats that agent's bot directly — the cheap fast path.

Tier 2 is the agent planner. Once the Core hands a goal to an agent that has a bot, planAndExecuteAgent runs. First it discovers what that agent can actually do — and this is where your wrapper enters the picture. Discovery asks the bot for its MCP tools, knowledge bases, and vibes. Your instant MCP server shows up here as a set of discovered tools with their descriptions. If the catalog is large, a reranker trims what the planner sees while a per-server floor keeps every server represented. Then the planner decomposes the goal into an ordered list of steps — each with a capability like tool:create_lease_charge, a plain-language subtask, and a scoped return ask — and the plan always ends with a reason step that produces the user-facing answer.

Where your wrapped API actually gets called

Most steps run on the agent's bot, not on the Mission's own LLM. When the planner executes a tool step, IRIS writes a natural-language message to the bot and the bot runs its own pipeline: a vibe/MCP gate picks one handler, and if it matches an MCP tool the bot enters its MCP agent loop — identify (server, tool), call it, shape the response down to the relevant fields, feed the result back. That loop is the only place external MCP tools execute. The arcane API you wrapped is called right there, with your encrypted credentials injected server-side, and the bot streams back a text answer plus explainability events. IRIS reads the text; every tool call it made is a line on the Explain rail, so you can watch the reasoning stream in real time — which agent, which tool, what came back. I described why that transparency is a business asset, not just a debugging aid, back in Why It Matters.

The part that makes it safe: the decision queue

Here is the mechanic I care about most. When the synthesis step assembles the final answer, it operates under a human-in-the-loop instruction: for destructive, irreversible, or high-blast-radius actions, the model does not claim the action was taken. It emits a [REQUEST_APPROVAL] block instead. After reasoning returns, the route layer scans for that marker and turns it into an iris_decisions row, emails each reviewer a magic-link approve/reject URL, and rewrites the marker into an "Awaiting approval" status the user sees in chat. The state-changing call against your legacy API does not fire until a human clicks approve. A [REQUEST_PORTAL] marker works the same way, materializing a branded portal — the UI surface — as a clickable builder link.

That is the whole point of wrapping the arcane API through this stack rather than letting some script hit it directly. The wrapper gives you a governed tool; the Mission gives you reasoning, an audit trail on the Explain rail, and an approval gate in front of anything that changes state. For a concrete run with real numbers, Harry's In Practice walks one end to end.

Why the seam holds

The elegance is that none of these tiers know anything about your API's quirks. The Reasoning Core routes on agent descriptions. The planner plans on discovered capabilities. The bot's MCP loop speaks plain JSON-RPC. Your arcane API's SOAP envelopes and RESTCONF weirdness are absorbed entirely at the wrapper — body templates, response handling, encrypted secrets — and everything above the seam just sees clean tools. Register a new wrapped API and the Generic Agent discovers it at runtime, no redeploy. That is what makes an afternoon's wrapping instantly reusable across every Mission you run. If you want the platform-level picture of how these pieces compose, the enterprise AI platform overview and the integrations guide are the two docs I point every architect to first.