Part 15: Build 2b — Boomi: Agentstudio, AI Gateway and Control Tower (with scores)

Part 15 · One Agent, Five Platforms

Part 14 hosted the nine tools on Boomi, as an API Control Plane MCP server. This part builds the invoice agent on top of them in Agentstudio, adds the guardrails, checks the approval gate and gives Boomi its provisional scores.

It's documentation-only, like the MuleSoft build in Part 11. Everything below comes from Boomi's official documentation as I read it on 3 November 2026, linked in the text. Where a criterion can only be judged hands-on, the score stays blank, as Part 5 promised.

How the pieces map

Using the five layers from Part 3:

• Channel: the AP exception queue and approver inbox stay where they are. A Boomi integration process picks up each exception.
• Agents: one invoice-exception agent, built in Agent Designer and deployed from Agent Garden.
• Tools: the nine tools from Part 14, imported from the MCP Registry.
• Process APIs: the business rules and the approval check, as Boomi processes behind APIs.
• Systems of record: the ERP and workflow, reached through existing connectors.

Across them sit AI Gateway for model and tool traffic and Agent Control Tower for inventory and monitoring.

1. Building the agent

The creating an agent page describes the parts:

• A goal of up to 2,000 characters, then tasks with instructions. The agent decides the order.
• Tools attached per task. A tool can be marked Requires Approval, so the agent asks before using it.
• Three modes: Conversational, Structured (JSON in, JSON out, single-turn) and Decision Engine (a validated decision that matches your schema).
• Models run through Amazon Bedrock as a managed service. You pick Standard or Fast, with optional Extended Thinking. Bring Your Own Model is in early access.
• A Test Agent window with Show Trace, and immutable packages for deployment.

For the invoice agent, Structured mode fits best. Following Part 2, rules run first: the integration process calls run_three_way_match and check_duplicate_invoice itself, so the six rules-only invoices in the golden set never reach the agent. Only real exceptions go to the agent, through the Agent step, and it returns a structured proposal.

One thing to check: the Agent step page says agents with "complex API tools" aren't compatible with the step. The invoice agent calls several tools per exception. If that counts as complex, the fallback is invoking the deployed agent through the Agent Garden REST APIs instead.

2. Guardrails

Boomi puts guardrails in three places.

In the agent. Agent Designer guardrails have a blocked message, up to 30 denied topics, and word filters and custom regex. Regex is how you'd catch sensitive data in prompts, such as bank account numbers on an invoice. There's no separate PII feature on the page.

In AI Gateway. The AI Gateway overview (updated 31 August 2026) has two parts:

• LLM Gateway for model traffic: quotas, cost controls, inline inspection and data redaction, and routing across model providers.
• MCP Gateway for tool traffic: "Control which tools and methods are accessible to which agents" (MCP Gateway overview).

That second line answers the question from Part 14. The rollout stages from Part 9 could be a gateway policy, not three API Products. The overview pages don't show the rule syntax or say whether the components are generally available, and they deploy on Kubernetes. So this is a design to confirm, not a result.

In Agent Control Tower. Agent Control Tower is an inventory of Boomi and third-party agents (such as Amazon Bedrock), with trust levels, tags and a dashboard of invocations, latency and errors. Agents can be disabled from it for some providers, such as Bedrock. For a Boomi agent, the documented way to stop it is through deployment.

3. The approval gate

Requires Approval is useful, but it isn't the gate. It makes the agent ask before calling a tool. In a chat, that's the person in the chat, not the finance approver from Part 6. In Structured mode there's no one to ask.

So the gate stays where it has always been: in the process API. post_invoice_adjustment and notify_supplier check the approval_id against the workflow record and return APPROVAL_MISSING without a valid one. Requires Approval on the two write tools is a sensible extra in a conversational setup, but the control is the API check.

4. Where it runs

The deploying agents page lists four Boomi-managed runtime clouds: US, UK, Japan and Australia. Each environment is tied to one, so the environment sets the region. Self-hosted deployment on the Flex runtime is in early access, as is Bring Your Own Model. There's no EU runtime cloud on the list, which matters for a European finance team.

5. Easy and hard, from the docs

Easy: a low-code agent with tasks, tools and guardrails in one place; immutable packages; tools from APIs you already govern; session traces that show each tool call with tokens and latency (session logs).

Hard: no A2A or multi-agent orchestration in the pages I read; no evaluation feature beyond testing; no OpenTelemetry export; tokens tracked but not cost per outcome; and the most interesting controls (MCP Gateway, Flex runtime, BYOM) are the least documented or still early access.

Provisional scores

Documentation-only scores are capped at 4. Blank means it needs a hands-on build.

1. Tool exposure (MCP): 4. API Control Plane MCP servers, MCP versions up to 2025-11-25, a registry (Part 14). Check names, schemas and named errors in a build.
2. Agent build experience: blank.
3. Multi-agent and A2A: 2. Control Tower manages third-party agents, and processes can call agents through the Agent step. No A2A support in the pages I read.
4. Human-in-the-loop: 3. Requires Approval per tool, but no approval workflow. The finance gate is built in the process API.
5. Identity and access: 3. Agent keys per subscription, Basic, Token and JWT auth for MCP tools (OAuth coming), OAuth for application tools, secrets in MCP Gateway. No distinct agent identity in the pages I read.
6. Governance and gateway: 3. Agent guardrails, LLM and MCP Gateways, a registry and Control Tower. Policy details and release status aren't on the pages I read.
7. Observability: 3. Session traces with tool calls, tokens, latency and guardrail hits, plus monitoring metrics. No export documented.
8. Evaluation support: 2. Test Agent with traces. Running the golden set needs my own harness.
9. Deployment and CI/CD: 3. Immutable, versioned packages per environment, REST APIs and YAML import/export. No rollback or promotion procedure documented.
10. Cost transparency: 2. Token counts per agent. Cost controls are listed for AI Gateway without details, and there's no cost per invoice.
11. Data residency and on-prem: 3. Four regional clouds and an early-access on-prem runtime. No EU cloud listed.

That's ten scores, averaging 2.8 (MuleSoft averaged 3.3 on the same basis). The average isn't meaningful yet, and both will change after hands-on builds.

What this sets for the other three

Boomi's strengths are its integration roots: tools generated from governed APIs, rules in processes, and an agent you can drop into a process as a step. Its gaps, on paper, are A2A, evaluation and cost. Part 16 puts MuleSoft and Boomi side by side on the same tool. Then SAP, with the same questions: do named errors survive, and how much of the gate do you build yourself?

Boomi users: what would you do differently?

---

This series describes a reference build on a fictional company. This part is based only on Boomi's official documentation as of 3 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.