DEV Community: Shakar Bisetty

Bonus: Your MuleSoft APIs are already most of an MCP server

Shakar Bisetty — Mon, 12 Oct 2026 03:33:53 +0000

Bonus · Building an Agentic Change-Approval MVP on MuleSoft

The main series finished with Part 10. This bonus post answers the question I got most often along the way: "We've done API-led on MuleSoft for years. How much work is it to make that usable by agents?"

Less than most teams expect. If you have a healthy API-led estate, you already have most of an MCP server. What's missing is a thin layer and some writing.

What you already have

RAML or OAS specs. Every Process API already has typed inputs and outputs. They translate into the input and output schemas of an MCP tool, so the agent gets the same contract your other consumers use.
Process APIs. This is where your business rules live, such as "no SAP import without an approval". In our MVP, that one check in a Process API is what kept the agents safe, as described in the human-in-the-loop post.
Exchange. A catalogue of what exists, who owns it and which version is current. That's exactly what you need when deciding which APIs become tools.
Gateway policies. Client IDs, rate limits and access control are already in place for every API. Agent traffic sits on top of the same governance.
MUnit. Tests for the behaviour agents will rely on, including the error cases.

What you add

An MCP server app. A Mule app using the MCP Connector, with one Tool Listener per tool, each calling a Process API. Part 4 walks through it.
Descriptions written for an agent. Not the API's summary line. Say when to use the tool, what it needs first and what it returns.
Named errors. APPROVAL_MISSING tells an agent what to do next. A generic 400 makes it guess, or retry.
Agent policies. Tool allow-lists per agent, PII detection and token limits in Omni Gateway, as in Part 5.

Expose Process APIs, never System APIs

This is the one rule worth repeating. A System API is a thin wrapper over a system of record. If an agent can call it directly, every business rule you built in the Process layer is bypassed. In our MVP, a git pre-commit hook rejected any tool that called a System API, so the rule couldn't drift.

Picking your first tool

Good first tools have three things in common:

Read-only. A lookup, such as "get transport status", can't do damage while you learn how agents use it.
Well documented. A clean spec and clear error codes make a good tool description almost write itself.
Used a lot by people today. If analysts look it up twenty times a day, an agent that can do it saves real time.

Write actions come later, behind a Process API that checks approvals.

Three mistakes to avoid

Mapping every endpoint to a tool. Agents choose worse with more tools. Expose the handful a task needs, and give each agent only its own.
Copying the API description. "Retrieves transport details" is written for developers. An agent needs "Use this before importing a transport, to confirm it's released and not locked".
Skipping the error design. Most agent loops we saw came from errors the agent couldn't act on.

A checklist for one API

Pick a Process API, not a System API.
Translate its request and response types into the tool's input and output schemas.
Write the tool description: when to use it, what it needs first, what it returns.
Map each failure to a named error.
Add MUnit tests for the happy path and each named error.
Add the tool to the right agent's allow-list in Omni Gateway.

For a well-specified API, that can be an afternoon, not a project.

Which of your Process APIs would make the best first tool?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 10: Lessons learned and a reusable blueprint for agentic approval flows

Shakar Bisetty — Sun, 11 Oct 2026 08:02:07 +0000

Part 10 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

This is the last part. Over nine posts we took one painful process, promoting an SAP change from development to production, and built an agentic MVP for it on MuleSoft: from the 21-step process and the 2x2 that decides what to automate, through the architecture, the agent network, MCP tools, gateway policies, Vibes, testing, CI/CD and production support.

This part pulls it together: what worked, what we'd change, and a blueprint you can reuse for your own process.

Five things that worked

1. Starting with the process, not the agents. We mapped all 21 steps before writing a single prompt, and sorted each one into rules, agent or person. Most steps didn't need an agent at all. That map is still the most useful artifact in the project.

2. Enforcing human gates in code. Every approval is checked by a Process API before anything touches SAP, as in the human-in-the-loop post. The agent can't skip a gate, however it's prompted, because the gate isn't in the prompt.

3. Exposing Process APIs as tools, never System APIs. The business rules the integration team had already built became the safety layer for the agents. We reused far more than we wrote.

4. Letting deterministic checks decide. The AI proposes a package, a risk class, a transport order. Schemas, Process APIs, gateway policies and people decide whether it goes ahead. The same rule applied to the AI developer: Vibes proposes code, hooks and CI decide.

5. Testing exactly wherever we could. Only the LLM steps get scored. Everything else gets an exact test, which kept the test suite ordinary, fast and trusted.

Five things we'd do differently

1. Write tool descriptions and named errors first. Most of the agent problems we debugged, including loops, came from tools that didn't say when to use them or what to do after an error. Next time we'd write those before any agent prompt.

2. Build the golden set before the first agent. We built it after the first version worked. Having it from day one would have made every early prompt change measurable instead of a judgement call.

3. Set token budgets from the start. We added the LLM rate-limit policy after a prompt change multiplied token use. A budget per agent from day one is cheap and catches that immediately.

4. Keep agents smaller. One of our first agents had too many tools and made poor choices between them. Splitting it into two agents with a few tools each fixed more than any prompt rewrite.

5. Plan support before go-live. The correlation ID, the dashboard, the runbooks and the pause switch from Part 9 all came late. They should be part of the first release, not the first incident.

The blueprint

If you want to apply this to your own process, this is the order we'd follow:

Map the process. List every step and sort each one: rules, agent or person.
Find the gates. Enforce every approval in a Process API, not in a prompt.
Expose tools. MCP tools over Process APIs, with descriptions written for an agent and named errors.
Design the network. Small agents with few tools each, and a broker graph with loop limits and escalation to a person.
Govern traffic. Tool allow-lists, PII detection and token budgets in Omni Gateway.
Build with standards. Skills, rules and workflows for the AI developer in Vibes; hooks and CI to check the result.
Test, ship and run. Exact tests plus a golden set, one versioned release for Mule apps and the agent network, and a runbook for each failure mode.

Steps 1 and 2 are the ones teams want to skip, and they're the ones that make the rest safe.

Where else it fits

Nothing in the blueprint is specific to SAP. The same shape works for any multi-step process where people approve and systems execute: access requests, vendor onboarding, configuration promotion in Salesforce or Workday, or release management in general. If your process has a checklist, a few approvers and a system of record at the end, it's a candidate.

Thank you

Thanks for reading along, and to everyone who commented and asked questions. All ten parts stay together in the series.

What process in your organisation would you put through this blueprint first? And what should the next series cover?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 9: Supporting an agentic flow in production: observability, runbooks and failure modes

Shakar Bisetty — Fri, 09 Oct 2026 17:14:54 +0000

Part 9 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 8 shipped the system. This part is about the day after go-live: what the support team watches, what actually breaks, and what they do about it. An agentic flow fails differently from a normal integration. Most failures don't throw an error. The agent just does something slightly wrong, or nothing at all.

One trace per change request

The first decision paid for itself many times over: the change request number is the correlation ID, end to end. It's set when the ITSM ticket arrives and passed through the broker, every agent, every MCP tool call, the Process APIs and the SAP System API.

That means a support engineer can answer "what happened to CR-1042?" with a single search across the logs, instead of piecing together five applications by timestamp. Every log line is structured JSON with the CR number, the agent name, the tool name and the step in the broker's graph.

Watch four groups of signals

We kept the production dashboard deliberately small. Four groups, one row each:

Flow health. Requests in flight, time spent in each stage of the broker's graph, and the escalation rate to a person. A rising escalation rate is usually the first sign that something upstream changed.
Tool layer. Calls per tool and named errors per tool. A spike in APPROVAL_MISSING is worth a look: it often means approvers are being chased before the approval request was sent.
Gateway. Denials per agent, PII detections and rate-limit responses from the Omni Gateway policies in Part 5.
LLM. Tokens per request per agent, and the trend of the quality scores from the judge LLM introduced in Part 7.

Each alert on this dashboard points to one of the failure modes below, and each one has a runbook.

The six failure modes

1. The agent loops. The same tool is called with the same input three or more times for one request. The broker's graph caps retries at two and escalates to a person, so the request doesn't get stuck. The alert exists so someone finds out why: usually a tool description that doesn't say what to do after an error.

2. A tool isn't found. After a deployment, an agent reports it can't complete a step, and the trace shows zero tool calls for that stage. This is almost always deployment order (agents deployed before their tools, as described in Part 8). We now run a smoke check after every deployment that lists each agent's tools and compares them with the access matrix.

3. The token budget is hit. The LLM rate-limit policy returns 429s for one agent. The request waits and resumes, so nothing is lost. The real question is why: in our case it was a prompt change that pulled the full transport history into every call.

4. An SAP transport is locked. TRANSPORT_LOCKED errors come back from SAP. The Process API retries with backoff. The agent never retries on its own, because an agent retrying a locked import is how you get duplicate imports.

5. Quality drifts. The judge scores fall slowly over a few weeks with no change on our side. This can happen when the model provider updates a model behind the same name. We rerun the golden set, pin a specific model version, and treat any model change as a release, as in Part 8.

6. Policy denials spike. One agent suddenly gets 403s from the gateway. We compare its live tool list with the access matrix and check the most recent policy change. So far it has always been configuration, never an agent misbehaving.

Runbooks with four sections

Every runbook has the same shape, so the person on call doesn't need to learn a new format at 2 a.m.:

Symptom: what the alert or the user report looks like.
Check: the exact log search or dashboard panel, filtered by CR number.
Act: the safe actions, in order. Resubmit the request, reassign it to a person, or pause intake.
Escalate: who owns it. The integration team for tools, the agent team for prompts and evaluations, the platform team for gateways.

The runbook for "the agent loops" is the most used. The fix is almost never in the agent's prompt. It's in the tool description, or in a named error that the agent can't act on.

Pause intake: the kill switch

Every agentic system needs a way to stop safely. Ours is a single switch that stops the broker from accepting new requests. Requests already in flight finish their current step and park. New tickets go to the manual queue.

This only works because the manual process never went away. It's documented, and the change analysts still know it. We tested the switch in production in a planned window before go-live, and again after the first month.

Who supports what

Service desk (L1): request status by CR number, and the pause switch.
Integration team (L2): MCP tools, Process and System APIs, SAP errors.
Agent team (L2): prompts, the broker's graph, golden-set reruns.
Platform team: Omni Gateway, Agent Fabric, credentials and deployments.

Once a week, the agent team reviews ten completed requests by hand, the judge score trend and the token spend per agent. It takes an hour and it has caught every slow drift so far.

Part 10, the last part, covers the lessons learned and a reusable blueprint you can take to your own change process.

What's the first runbook you'd write for an agent in production?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 8: Deploying agent networks: CI/CD with the Anypoint CLI

Shakar Bisetty — Thu, 08 Oct 2026 14:16:08 +0000

Part 8 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 7 built the evidence. This part ships it. An agentic system has more moving parts than a normal integration release: Mule apps, gateway policies, prompts, a model choice and the agent network itself. If they don't move through environments together, you end up testing one combination and running another in production.

Two pipelines, one release

We run two pipelines, released together under one version number:

The Mule pipeline builds and deploys the MCP server app and the Process and System APIs. It's the same Maven-based pipeline the integration team already used, publishing to Exchange and deploying to CloudHub 2.0.
The agent network pipeline builds and deploys the agents and the broker, using the Anypoint CLI Agent Fabric plugin.

The agent network pipeline

The Agent Fabric plugin for the Anypoint CLI covers the whole lifecycle with a handful of commands. A project created with agent-network:project:create contains an agent-network.yaml that describes the network. In CI, the steps are:

# once per target space, before the first deployment
anypoint-cli-agent-fabric-plugin agent-network:setup:gateways

# every release
anypoint-cli-agent-fabric-plugin agent-network:project:build    # validate, generate artifacts
anypoint-cli-agent-fabric-plugin agent-network:project:publish  # assets to Exchange
anypoint-cli-agent-fabric-plugin agent-network:project:deploy   # to the target environment

Credentials come from the CI secret store as ANYPOINT_CLIENT_ID and ANYPOINT_CLIENT_SECRET, never from the repo. The environment is chosen with --environment, and values that differ per environment are passed at deploy time with --property name:value. The plugin needs Node 20+ and Java 17+ on the build agent.

Deploy in dependency order

Agents depend on tools, and tools depend on gateway policies. So the order inside each environment is fixed:

Mule apps first. The Process and System APIs, then the MCP server with its tools.
Gateway policies next. The allow-list and ABAC rules from Part 5, applied from configuration in the same repo.
The agent network last. Only once every tool it expects is reachable and governed.

Deploying agents before their tools exist doesn't fail loudly. The agents simply can't find the tools, and the first symptom is a confused answer in testing.

Promote the same thing, not a rebuild

Every release has one version, set as the asset version (the GAV coordinates) in the agent network project and matched in the Mule apps. Sandbox, test and production all get the same built artifacts; only the environment and its properties change.

The gates between environments are the layers from Part 7:

Into test: MUnit and gateway policy tests pass in sandbox.
Into production: graph scenarios pass, the golden-set scores are no worse than the current production version, and the business owners have signed the UAT record.

A prompt change or a model change is a new version, with the same gates as a code change. That rule caught more regressions for us than any other.

The system approves its own changes

This is a change-approval system, so its own production releases go through change approval. The production deploy job waits for an approved change record, the same way an SAP import waits for an approval_id. It's a small thing to build, and it's the first question an auditor asks.

Rolling back an agent

Rollback is a redeploy of the previous version, not an edit in production:

Agent network: check out the previous release tag and run build and deploy again. Keep the previous version published in Exchange until the new one has been stable for a while.
Mule apps: redeploy the previous application version.
Teardown order matters. If you ever remove a version, run undeploy before unpublish, so nothing running still points at a deleted Exchange asset.

We rehearse a rollback in the test environment before every production release. If the rehearsal takes more than a few minutes, the release waits.

Who owns what

Integration team: the Mule pipeline and the tool deployment.
Agent team: the agent network project, its version and the golden-set gate.
Platform team: target spaces, gateways, CI credentials and the policy deployment.
Change board: the production approval, like any other change.

Part 9 covers running it in production: observability, runbooks and the failure modes we actually saw.

How do you version prompts in your team today?

This series describes a reference model built on a fictional company. CLI commands are from the Anypoint CLI Agent Fabric plugin documentation as of October 2026; check current docs before you build.

Part 7: Testing an agentic flow: MUnit, evaluations and the evidence auditors ask for

Shakar Bisetty — Wed, 07 Oct 2026 13:28:31 +0000

Part 7 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 6 covered how the team builds the tools. This part covers how we test them, and how we test the agents that call them. In a regulated change process, "it worked in the demo" isn't evidence. The quality team will ask what was tested, how, against which version, and who signed off.

Test deterministic things deterministically

The single most useful rule we followed: anything that should always give the same answer gets an exact test, and only the LLM steps get scored. That splits the system cleanly, and it means most of the test suite is ordinary integration testing.

Layer 1: MUnit for the tool layer

Every MCP tool flow from Part 4 gets MUnit tests, generated by the /new-mcp-tool workflow and finished by hand:

The happy path, with the Process API mocked.
One test per named error, such as APPROVAL_MISSING and TRANSPORT_LOCKED, checking the error code the agent will see.
Schema tests: malformed input is rejected before any call goes out.

The most important test in the whole suite is a negative one. For import_transport_to_qa, we call the Process API with no valid approval and assert two things: the result is APPROVAL_MISSING, and the SAP System API mock was called zero times (MUnit's verify-call with times set to 0). That one test proves the approval gate from the human-in-the-loop post holds in code.

Layer 2: policy tests at the gateway

The Omni Gateway rules from Part 5 are configuration, and configuration drifts. So we test them in the test environment with a small script:

For each agent identity, list the tools it can see and compare with the access matrix.
For each agent, try one tool it should not have and expect a denial.
Send a prompt with planted test PII and confirm the PII policies catch it.

These run after every gateway change, not just at release.

Layer 3: scenario tests on the broker graph

The broker's graph has branches, loops and gates, and each one gets a scenario with fixed inputs:

An incomplete request loops back to the requester twice, then escalates to a person.
A rejected approval closes the request with a reason and never reaches create_sap_change_doc.
A complete, approved request reaches the stage 4 hand-off with a full record.

We're testing the routing here, not the quality of the agents' reasoning, so the inputs are chosen to make the agents' decisions obvious.

Layer 4: evaluations for the agents

This is the only layer where answers vary. We built a golden set of 40 historical change requests, anonymised, with the answers a senior analyst gave: completeness, risk class and the transport sequence.

Each agent version runs against the full set:

Structured fields are checked exactly. Risk class must match; the transport sequence must respect every dependency.
Free-text output is scored. The A2A Quality Evaluation policy in Omni Gateway sends each response to a judge LLM and returns a yes/no on whether the request was addressed, a 1–3 quality score and an explanation, as response headers and metrics. It doesn't block anything, so we collect the scores and set our own release threshold.

A new prompt or model version only ships if it matches or beats the previous version on the golden set. The scores per version go into the evidence pack.

Layer 5: human sign-off

Before go-live, business owners run a sample of real-shaped requests in the test environment and sign off on the packages the Approval agent builds. This is the same human gate the process has always had, applied to the system itself.

Test data without touching production

All of this runs against a non-production SAP client with synthetic transports, a test ITSM instance and test approvers. Production systems never appear in a test, and the gateway's prompt guard blocks production system names even if someone tries.

The evidence pack

What we hand the quality team for each release:

MUnit results for every tool and Process API, including the zero-call SAP test.
Gateway policy test results against the access matrix.
Graph scenario results.
Golden-set scores for each agent, compared with the previous version.
Signed UAT records from the business owners.

Who owns what

Integration team: MUnit and the Process API tests.
Platform team: gateway policy tests.
Agent team: graph scenarios, the golden set and evaluation thresholds.
Quality and business owners: the sign-off.

Part 8 covers deployment: CI/CD for the Mule apps and the agent network, promoting through environments, and how to roll back an agent.

What would you put in your golden set first?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 6: Building it with MuleSoft Vibes: skills, rules, workflows and hooks

Shakar Bisetty — Tue, 06 Oct 2026 00:53:50 +0000

Part 6 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Parts 4 and 5 covered what the integration team builds: MCP tool flows with strict contracts, behind a governed gateway. This part covers how they build it. We used MuleSoft Vibes in Anypoint Code Builder, and the interesting part wasn't the code it wrote. It was how we taught it our standards so every tool came out the same way.

Three ways to teach Vibes your standards

Vibes gives you three building blocks, and each one solves a different problem:

	What it is	When it applies	What we used it for
Rules	Natural-language constraints	Every message (global or workspace)	Standards that never change
Skills	Instruction packs with optional files	Only when a request matches the skill	How to build one kind of thing
Workflows	Named multi-step tasks	When you run them as a slash command	Repeatable sequences

The difference matters because of context. Rules are always loaded, so they should be short. Skills load only when relevant, so they can carry detail, templates and examples without crowding out everything else.

Rules: the things that are always true

Our workspace rules are a short list. Each one is something we never want to explain twice:

Tool flows never call a System API directly. They call a Process API.
Every flow has an error handler that returns a named error code.
Tool names are snake_case and start with a business verb (create_, read_, request_, import_).
No credentials, hostnames or client names in code. Use properties and secure properties.

If a rule needs a paragraph of explanation, it probably belongs in a skill instead.

Skills: how to build one kind of thing

Workspace skills live in .a4drules/skills/, one folder per skill, committed with the project. Each folder has a SKILL.md and can carry references/, assets/ and scripts/. Vibes loads a skill only when a request matches its description.

We wrote one skill per kind of artifact. The most-used one teaches Vibes how to build an MCP tool flow:

.a4drules/skills/mcp-tool-flow/
├── SKILL.md
└── references/
    ├── tool-listener-template.xml
    ├── input-schema-template.json
    └── description-checklist.md

The top of SKILL.md:

---
name: mcp-tool-flow
description: Use when creating or changing an MCP tool flow with the
  MCP Connector Tool Listener. Covers naming, description, input schema,
  Process API call and error codes.
---

1. Ask for the business action and who will call it, if not given.
2. Name the tool <verb>_<object>, snake_case.
3. Write the description with: what it does, when to use it,
   what it needs first, what it returns.
4. Build the input schema from references/input-schema-template.json.
   Every field typed, constrained and described. No additionalProperties.
5. Call the Process API, never a System API.
6. Map failures to named error codes from the Process API contract.

The description checklist is the same four rules from Part 4. Putting it in a skill means every developer gets it, including the ones who never read the series.

Workflows: the sequence we kept repeating

Adding a tool always took the same steps, so we made it a workflow and run it as /new-mcp-tool:

Collect the business action, caller (which agent) and Process API operation.
Generate the input schema and Tool Listener flow, using the mcp-tool-flow skill.
Generate an MUnit test for the happy path and each named error.
Draft the change request for the platform team: add the tool to the Global Access allow-list and to the right agent's ABAC rule (Part 5).

Step 4 is the one people forgot before the workflow existed. A tool that works locally but isn't on the gateway's allow-list is invisible to every agent.

Guardrails: what the AI doesn't get to decide

Rules and skills make good output likely. They don't make it certain. A developer can ignore a suggestion, and a model can miss an instruction. So the checks that must always pass are deterministic and live outside Vibes:

A git pre-commit hook runs a small script that checks every Tool Listener has a description and an input schema, that tool names match the naming rule, and that no tool flow references a System API.
The CI pipeline runs the MUnit suite and the same checks again, because hooks can be skipped locally.

Vibes itself doesn't have hooks; these are ordinary git hooks and pipeline steps. If your team also uses an AI coding tool that supports hooks, such as Claude Code, you can run the same checks at edit time. The principle is the same as in the runtime design: the AI proposes, deterministic checks decide.

Who owns what

Integration team: workspace rules, the skills and workflows in the repo, and the pre-commit checks.
Integration CoE or platform team: global rules shared across projects.
Every developer: proposes a new rule or skill when they catch themselves correcting the same thing twice.

Part 7 covers testing an agentic flow: MUnit for the deterministic tool layer, evaluations for agent answers, and the evidence a regulated quality team will ask for.

Which of your team's standards would you turn into a skill first?

This series describes a reference model built on a fictional company. Vibes capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 5: Governing agent traffic with Omni Gateway policies

Shakar Bisetty — Mon, 05 Oct 2026 04:22:34 +0000

Part 5 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 4 ended with an uncomfortable point: a tool's description guides the agent, but it doesn't protect anything. This part covers the layer that does: Omni Gateway, sitting in front of every MCP server, every agent-to-agent call and every request to an LLM.

Three kinds of traffic, one gateway

An agent network produces three kinds of traffic, and each one has its own risks:

Agent → MCP tools. Can this agent call this tool? Is the request well formed? Is personal data coming back in the response?
Agent → agent (A2A). Is the request valid, and is personal data being passed between agents?
Agent → LLM. Is personal data going to the model provider? Is anyone trying to talk the model out of its instructions? How many tokens is each agent burning?

Omni Gateway has policy sets for all three. Here's the chain we use in the MVP:

The order shown is the order we apply them, cheapest and most decisive first. A malformed request should fail before anything inspects its content.

MCP traffic: who can see which tool

Two policies decide tool access, and they work at different levels.

MCP Support comes first: it's the required policy that makes the gateway treat the API as an MCP server. Then MCP Global Access sets the baseline. It defines allow and block rules for which tools the MCP server exposes at all. We allow exactly the five tools from Part 4. Anything the integration team adds later stays invisible until someone adds it to the list on purpose.

MCP Attribute-Based Access Control narrows that down per caller. Rules use attributes of the request, such as token claims, headers, IP or tiers. Each agent calls the gateway with its own identity, so the rules can say which agent gets which tool:

Tool	Intake	Planner	Approval
`create_change`	✅
`read_transport`		✅
`request_approval`			✅
`create_sap_change_doc`			✅
`import_transport_to_qa`			✅

The Intake agent never sees import_transport_to_qa. It isn't refused when it tries; the tool simply isn't in its list. A tool an agent can't see is a tool it can't be talked into calling.

Two more MCP policies are worth switching on early:

MCP Schema Validation rejects requests that don't conform to the MCP specification before they reach a flow.
MCP PII Detector blocks responses that contain personal data. ITSM records carry requester names and contact details. The agents don't need them, so they never leave the integration layer.

If your tool list grows, look at MCP Tools Progressive Disclosure, which exposes tools on demand through search instead of sending every description in every prompt. MCP Tool Mapping lets you rename tools and rewrite descriptions at the gateway without redeploying the Mule app.

A2A traffic: agents talking to agents

In our network the broker coordinates the agents, so agent-to-agent calls are fewer than you might expect. They still go through the gateway:

A2A Schema Validation checks requests against the A2A specification.
A2A PII Detector catches personal data passed between agents.
A2A Prompt Decorator adds context to every request, such as "this is a regulated change process; never skip an approval step".

LLM traffic: what leaves the building

Every agent's model calls go out through the gateway too. Three policies matter most:

Regex Prompt Guard blocks requests that match a deny-list. Ours includes common prompt-injection phrasing and any attempt to name a production system.
LLM PII Detection finds personal data in prompts before they reach the model provider.
LLM Token Based Rate Limit caps token use per agent. Part 3 gave every loop a retry limit; this is the budget behind it. An agent stuck in a loop hits the token limit long before it hits the invoice.

Defense in depth, not a single wall

The gateway is one of three layers, and none of them trusts the others:

The tool contract (Part 4) makes the right call easy and rejects malformed input.
The gateway decides who can see which tool and what data crosses the boundary.
The Process API checks the approval ID against the approval record before any import, whoever calls it.

Remove the tool contract or the gateway and the system is weaker, but the approval still holds. Remove the Process API check and it doesn't, which is why that check never moves out of the integration layer.

Who owns what

Platform team: the gateway, every policy on it, the agent identities the ABAC rules depend on, and the token budgets.
Integration team: asks for a tool to be added to the allow-list and explains who needs it.
Agent team: gets a clear error when a policy blocks something, and adjusts the agent instead of asking for the policy to be removed.

Part 6 moves to the developer side: building all of this with MuleSoft Vibes, using skills, rules and workflows, plus hooks as guardrails for the AI developer.

Which policy would you switch on first: tool access, PII or token limits?

This series describes a reference model built on a fictional company. Policy names are from the Omni Gateway agent policies documentation as of October 2026; check current docs before you build.

Part 4: Turning Mule APIs into MCP tools with the MCP Connector

Shakar Bisetty — Sun, 04 Oct 2026 10:11:59 +0000

Part 4 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 3 drew the broker's graph. Four of its nine nodes are MCP tool calls, and that's where the integration team does its work. This part covers how a Mule flow becomes an MCP tool with the MCP Connector, and why the tool's name and description matter more than the code behind it.

The tools in the MVP

The MVP graph uses four tools. We also built a fifth, import_transport_to_qa, which stage 4 will need first. It's the example used below, because it's the one that must never run without an approval.

Tool	What it does	Calls
`create_change`	Opens the change record	ITSM System API
`read_transport`	Reads a transport's objects and status	SAP System API
`request_approval`	Sends the package to the business owner and returns an `approval_id`	Approval Process API
`create_sap_change_doc`	Creates the SAP change document	Change Process API
`import_transport_to_qa`	Imports one approved transport into QA (stage 4)	Change Process API

None of these maps one-to-one to an existing endpoint. Each one is a business action, and its flow calls the APIs it needs.

From Mule flow to MCP tool

The MCP Connector lets a Mule app act as an MCP server (and as a client, which we don't need here). Three pieces do the work.

1. The server configuration

One MCP server configuration per app. It has a server name and version, and a connection type. Use Streamable HTTP: SSE is deprecated in the connector and only supports single-replica deployments. Streamable HTTP serves one endpoint (/mcp by default), and with a distributed object store for sessions it runs across several replicas.

2. One Tool Listener per tool

Each tool is a flow that starts with a Tool Listener source. The listener carries the contract the agent sees:

Name: import_transport_to_qa
Description: what it does, when to use it, and what it needs first
Input schema: the arguments, as JSON Schema
Output schema (optional): a structured result the agent can rely on

The input schema for import_transport_to_qa:

{
  "type": "object",
  "properties": {
    "transport_id": {
      "type": "string",
      "pattern": "^[A-Z0-9]{3}K9[0-9]{5}$",
      "description": "SAP transport request, e.g. DEVK900123"
    },
    "approval_id": {
      "type": "string",
      "description": "Approval ID returned by request_approval"
    }
  },
  "required": ["transport_id", "approval_id"],
  "additionalProperties": false
}

When the agent calls the tool, the flow receives the arguments as its payload.

3. The flow body

The flow is ordinary Mule: validate, call the Process API, shape the response. It doesn't talk to SAP itself. The Process API checks the approval again and calls the SAP System API. If anything fails, the flow returns an error result with a named code, such as APPROVAL_MISSING or TRANSPORT_LOCKED, instead of a stack trace.

That's the whole pattern. If your team already builds API-led integrations, most of the work is already done: the System and Process APIs exist, and the MCP layer is a thin set of flows on top.

The contract is the hard part

The code in a tool flow is short. The name and description take longer, because the agent picks tools by reading them. A recent LinkedIn post in this series showed the before and after:

Four rules we follow:

Name the business action, not the HTTP verb. import_transport_to_qa, not postTransportImport.
Say when to use it, and when not to. Preconditions belong in the description the model reads.
Type and constrain every input. A pattern on transport_id and a required approval_id stop bad calls before they reach SAP.
Name the errors. An agent that gets APPROVAL_MISSING can tell the requester what's wrong. An agent that gets "500 Internal Server Error" retries.

One more: keep the tool list short. Every tool's description goes into the agent's context. Five well-described tools work better than twenty overlapping ones.

Where enforcement actually lives

The description guides the agent. It doesn't protect anything. Enforcement sits in three places:

The input schema rejects malformed calls.
The Process API checks the approval ID against the approval record before any import, whoever calls it.
Omni Gateway decides which agent can see which tool at all. The Intake agent never sees import_transport_to_qa. That's Part 5.

If you remove the description entirely, the system is still safe. It just works worse.

Who owns what

Integration team: the MCP server app, tool flows, schemas, descriptions and error codes, plus the Process and System APIs underneath.
Agent team: reviews tool names and descriptions with the integration team, because they see how agents actually use them.
Platform team: the gateway in front of /mcp and the policies on it.

Part 5 puts Omni Gateway in front of the MCP server: tool allow-lists per agent, attribute-based access control, PII detection and token limits on LLM traffic.

What's the first tool you'd expose from your own APIs?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026 (MCP Connector 1.7); check current docs before you build.

Part 3: Designing the agent network, and what the broker's graph actually looks like

Shakar Bisetty — Sat, 03 Oct 2026 07:45:25 +0000

Part 3 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 2 put the architecture on one page: agents in Agent Fabric, Omni Gateway in front of everything they touch, and MCP tools over Mule APIs. This part goes one level down. How do you decide where each of the 21 steps lives, and what does the broker's graph actually look like?

Step 1: sort every step before drawing anything

We started with a spreadsheet, not a diagram. One row per step, and four questions per row:

Does it follow rules or need judgement? (See the 2x2.)
How bad is a mistake, and can we undo it?
Which system of record does it read or change?
Who has to sign off, if anyone?

The answers put each step in one of four places: an agent (judgement, low risk), an MCP tool (rules), a human gate (judgement, high risk), or a tool behind a gate (rules, high risk).

Once every step is sorted, the agents almost name themselves. Steps that need the same kind of judgement and the same context belong together. In our process that gave four agents:

Intake agent: completeness and risk classification.
Planner agent: transports, dependencies and sequence.
Change agent: documentation, evidence and log analysis.
Approval agent: building packages and requesting gates.

Each agent gets a short list of tools, and no agent gets a tool it doesn't need. The Intake agent can't import anything into SAP, because it never sees that tool.

Step 2: draw the broker's graph

With Agent Network 2.0 in Agent Fabric, the broker coordinates agents using a defined graph ("guided determinism"). The LLM still reasons inside each step, but the order of steps, the branches and the gates are part of the graph, not left to the model.

Here's the graph for the MVP scope, the first three stages of the process:

Reading it top to bottom:

A change request arrives.
The Intake agent checks completeness and classifies risk.
A rule-based branch decides what happens next. If the request is incomplete, it goes back to the requester. That loop runs at most twice before a person takes over.
The create_change tool opens the change record in the ITSM tool. No LLM is involved.
The Planner agent maps transports and dependencies, calling read_transport as it needs to.
The Approval agent builds the package for the business owner.
The business owner approves or rejects. A rejection closes the request with a reason.
Only with a valid approval ID can create_sap_change_doc run.
The request hands off to stage 4, which is outside the MVP.

Three rules the graph enforces

Every loop has a limit

An agent that's allowed to retry forever eventually will. Every loop in the graph has a counter and an exit to a human. "Two tries, then a person" is a good default for anything involving a requester.

Validate between steps

Each agent's output is checked against a schema before the graph moves on. If the Intake agent returns a risk level that isn't one of the allowed values, the step fails loudly instead of passing nonsense to the Planner. This is cheap to build and catches a lot of quiet errors.

Gates are edges, not instructions

The approval isn't a line in a prompt asking the agent to wait. It's the only edge from node 7 to node 8, and the tool on node 8 checks the approval ID again in the integration layer. As covered in the human-in-the-loop post, the model can't skip the gate, and the API wouldn't let it even if it tried.

What the graph doesn't do

It doesn't make the agents smarter. A bad prompt in the Planner agent still produces a bad plan. What the graph gives you is a guarantee about structure: whatever the agents decide, the process still runs in the right order, with the right people involved and a record of what happened. In a regulated environment, that structure is what auditors and quality teams care about first.

Who owns what

Agent team: the four agents, their prompts and output schemas, and the broker graph.
Integration team: the MCP tools behind nodes 4, 5, 7 and 8, and the approval check.
Platform team: the gateway policies that decide which agent can see which tool.

Part 4 gets hands-on with the integration side: turning Mule APIs into MCP tools with the MCP Connector, and why tool names and descriptions matter more than you'd expect.

Where would you put the loop limit, and what would you do when it's hit?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Part 2: The reference architecture for an agentic change-approval MVP on MuleSoft, on one page

Shakar Bisetty — Fri, 02 Oct 2026 15:12:20 +0000

Part 2 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

In Part 1 I set out the use case: automating the approval and promotion of SAP changes in a regulated company, with agents doing the reasoning, integration tools doing the actions and people doing the approving. The two follow-ups covered which steps should be agents at all and how to enforce approval gates.

This part puts the whole thing on one page.

The layers, top to bottom

People. A requester raises the change. Approvers (business, QA, validation and the change advisory board) make the decisions. They work in the tools they already use; the agents come to them, not the other way round.

Agent network (Agent Fabric). Four agents, each with a narrow job:

Intake agent: checks the request is complete and enriches it.
Planner agent: works out transport dependencies and sequence.
Change agent: drafts documentation, collects test evidence and reads import logs.
Approval agent: builds the approval package and requests each gate.

A broker coordinates them. With Agent Network 2.0, the broker's flow is a defined graph: the LLM reasons inside each step, but the order of steps and the gates between them are deterministic. In a regulated process, that's the difference between "the model decided to skip QA" and "it can't".

Governance (Omni Gateway). Omni Gateway, formerly Flex Gateway, sits in front of everything agents touch: MCP servers, other agents over A2A, and the LLM provider. Policies here decide which tools an agent may see, check the caller's claims, detect PII, limit token usage and log every call.

MCP tools. One MCP server, built in Mule with the MCP Connector, exposes a small set of business-level tools: create_change, read_transport, request_approval, import_to_prod. Agents see tools, not APIs.

Process API. change-process-api orchestrates the multi-step work behind each tool, verifies approvals before anything irreversible happens, and writes the audit record.

System APIs. One per back end: SAP (through RFCs), the ITSM tool and test management. They hide connection details and normalise errors.

Systems of record. SAP, the ITSM tool, test management and the LLM provider. None of them is called directly by an agent.

Platform. Agent Registry and Exchange for discovering agents and tools, Agent Visualizer for seeing how agents interact, and CloudHub 2.0 or Runtime Fabric for deployment.

Three design decisions worth explaining

1. Tools are business actions, not API endpoints

It's tempting to expose every System API operation as an MCP tool. Don't. An LLM choosing between 40 low-level operations makes more mistakes and burns more tokens than one choosing between five clear business actions. The MCP tool layer is where we decide what an agent is allowed to want.

2. A Process API between tools and systems

The MCP server could call System APIs directly. We put a Process API in between because that's where cross-system rules live: "an import needs a valid approval for this exact change" spans ITSM and SAP. Keeping that logic in one place means it's tested once and enforced for every caller, agent or human.

3. The gateway covers outbound LLM traffic too

Most teams think of a gateway as inbound protection. Here it also governs what leaves: prompts going to the LLM provider pass through the same policies for PII and token limits. If a change record contains something sensitive, it's caught before it reaches a model.

Who owns what

The colours in the diagram are the team boundaries:

Agent team (purple): agents, prompts, the broker graph and evaluation.
Integration team (teal): the MCP server, Process API and System APIs.
Platform team (dark grey): Omni Gateway policies, registry, observability and environments.

Each team can ship independently as long as the contracts between layers (tool definitions and API specs) stay stable. Those contracts are published in Exchange, which makes them the shared source of truth.

Starting small

The full process has 21 steps. The MVP starts with the first three stages: request intake, change setup and creating the change in SAP, with stubbed back ends so the whole chain can be tested end to end before touching real systems. Later parts show how the remaining stages slot into the same layers without changing the shape of the architecture.

Part 3 goes one level down into design: how we decided where each of the 21 steps lives, and what the broker's graph actually looks like.

Which layer would you push back on? I'd especially like to hear from anyone who exposes System APIs directly as MCP tools.

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026; check current docs before you build.

Human-in-the-loop is a design feature: enforcing approval gates for AI agents on MuleSoft

Shakar Bisetty — Thu, 01 Oct 2026 02:05:31 +0000

Companion to Part 1 · Building an Agentic Change-Approval MVP on MuleSoft

When people demo agentic systems, the human approval step is often treated as an embarrassment: the bit we'll automate away later.

In a regulated process it's the opposite. The approval is the product. Auditors, quality teams and your change advisory board rely on it. The question isn't how to remove it, but how to design it so it's fast, hard to bypass and fully traceable.

This post walks through the pattern we use in our change-approval MVP for promoting SAP changes to production. (Background: Part 1 and the 2x2 for deciding what to automate.)

The flow

The agent builds the approval package. It gathers the change summary, transport contents, test evidence and a risk summary into one place.
It calls a request_approval tool. This is an MCP tool over a Mule API that creates an approval task in the ITSM system. The agent can't approve anything itself.
A person reviews and approves. Their identity and the timestamp are recorded in the ITSM system, which issues an approval_id.
The agent calls import_to_prod with the change ID and the approval ID.
Omni Gateway applies policy first. The MCP tool allow-list decides whether this agent may see the tool at all, and attribute-based access control checks the caller's claims.
The Mule API verifies the approval. Does the approval ID exist, match this change, and is it unexpired and unused? Only then does it call SAP to import the transport.
An audit record is written. It captures who approved, what they saw and what was executed.

If any check fails, the tool refuses with a clear error and nothing touches SAP.

Three design rules

1. Enforce, don't instruct

"Always ask the user before importing to production" in a system prompt is a hope, not a control. Prompts can be ignored, misread or injected around.

The gate belongs where agents can't argue with it: in the API that performs the action, and in gateway policy in front of it. The agent's job is to request; the integration layer decides.

2. Make approving easy

Approval gates slow processes down mostly because approvers get incomplete information. They have to open five screens, read a raw log and chase someone for test evidence.

The agent's most valuable work here is preparing a single, complete package. A fast "yes" from a well-informed approver beats a slow one every time, and so does a confident "no".

3. Leave a trail

Every gate should answer, after the fact: who approved, when, what they were shown, and what was executed as a result. That's what turns an agentic workflow from "interesting" into something a validated environment can actually accept.

Who owns what

This pattern splits cleanly by team:

Agent team: building the package and handling refusals gracefully.
Integration team: the request_approval and import_to_prod tools, approval verification and the audit record.
Platform team: gateway policies, identities and environments.

In Part 2 I'll zoom out to the full reference architecture: Agent Fabric, Omni Gateway, MCP tools and the SAP and ITSM back ends on one page.

How do you enforce approvals in your agentic workflows today? Prompt, API, gateway, or something else?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of September 2026.

Not every step should be an agent: a 2x2 for deciding what to automate

Shakar Bisetty — Wed, 30 Sep 2026 03:30:31 +0000

Companion to Part 1 · Building an Agentic Change-Approval MVP on MuleSoft

The fastest way to over-engineer an agentic system is to make every step an agent.

In Part 1 I introduced the use case for this series: automating the approval and promotion of SAP changes from lower to upper environments in a regulated company. The process has about 21 steps across 11 stages. Before designing anything, we had to decide which of those steps an agent should touch at all.

This is the tool we used. It's simple enough to run on a whiteboard in 30 minutes with the process owners.

Two questions per step

For every step in the process, ask:

Does it follow rules, or does it need judgement? If you can write the logic as an if-statement or a mapping, it follows rules. If a person reads something messy and decides, it needs judgement.
If it goes wrong, how bad is it, and can we undo it? Drafting a document badly is cheap to fix. Importing the wrong transport into production is not.

Plot each step on those two axes and you get four quadrants.

The four answers

Rules, low risk: integration tool, fully automated.
This is an MCP tool over a Mule API, with no LLM in the path. Creating the change record, reading transport objects and fetching import logs all live here. They're deterministic, fast, cheap and easy to audit. An agent can call these tools, but the tool itself doesn't reason.

Judgement, low risk: the agent acts and a human spot-checks.
This is where agents earn their keep. Is the change request complete? Does the description match the transport contents? What do these import logs actually mean for the approver? Mistakes here are visible and easy to correct, so the agent can act and a person reviews samples.

Rules, high risk: still a tool, but only after approval.
Importing to production is a deterministic call, so it shouldn't involve an LLM. But it's hard to undo, so the tool only runs once an approval is on record. In a MuleSoft setup that's enforced in the integration layer and at the gateway, not by asking the agent nicely in a prompt.

Judgement, high risk: a human decides, the agent prepares.
Business approval, validation review and the CAB decision stay with people. The agent's job is to hand them a complete package with a summary, the evidence and the risks, so the decision is fast and well-informed.

What we learned

When we sorted our process, more steps landed in the "tool" quadrants than in the "agent" quadrants. That surprised some of the team, but it's a good sign:

Deterministic steps are cheaper to run and easier to test.
Auditors understand them.
Every step that doesn't need an LLM is one less thing that can hallucinate.

It also split the work cleanly between teams. The integration team owns the tool quadrants: MCP tools, Mule APIs, and SAP and ITSM connectivity. The agent team owns the judgement quadrants. The platform team owns the guardrails that keep the high-risk row behind approvals.

The borderline cases

Some steps don't sort cleanly. "Analyse import logs" is the one we argued about most. You could write rules for known return codes, but real logs are messy and the value is in explaining them to a non-technical approver. We put it with the agent, with the raw return codes still passed through deterministically.

Where would you put it? I'd like to hear the case for a rules engine.

In Part 2 I'll put the whole reference architecture on one page: Agent Fabric, Omni Gateway, MCP tools and the SAP and ITSM back ends, colour-coded by which team owns what.

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of September 2026.