DEV Community

Cover image for Part 8: Deploying agent networks: CI/CD with the Anypoint CLI
Shakar Bisetty
Shakar Bisetty

Posted on

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

#mulesoft #ai #devops #cicd

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:

  1. 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.
  2. The agent network pipeline builds and deploys the agents and the broker, using the Anypoint CLI Agent Fabric plugin.

The release pipeline, from commit to production

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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Mule apps first. The Process and System APIs, then the MCP server with its tools.
  2. Gateway policies next. The allow-list and ABAC rules from Part 5, applied from configuration in the same repo.
  3. 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.

Next

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.

Top comments (0)