From 80b3bf33943c708f9f526366c3355161a740d941 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 13:05:38 -0700 Subject: [PATCH 01/30] W-23450489 Agent Fabric Use Case: MCP Bridge --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 327 ++++++++++++++++++ 1 file changed, 327 insertions(+) create mode 100644 modules/ROOT/pages/af-use-case-mcp-bridge.adoc diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc new file mode 100644 index 000000000..478858082 --- /dev/null +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -0,0 +1,327 @@ += Make APIs Agent-Ready with MCP Bridge + +Agent Fabric's MCP Bridge converts your existing API instances into MCP servers through configuration, exposing their operations as MCP tools that agents can discover and call without modifying the underlying API. +Choose which operations to expose and apply optional read-only filtering to limit what agents can do, giving you control over agent access without rewriting anything. +Use this approach to make your existing Mule or API management investment immediately available to agents, with governance policies applied from the same portfolio. + +== The Problem + +You have invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: + +* **API complexity**: Existing APIs weren't designed for agent consumption. +* **Security concerns**: APIs often include write and delete operations that are too risky for agents. +* **Integration overhead**: Building custom integrations for each agent platform is time-consuming. +* **Inconsistent access**: Different agents access the same APIs in different ways. +* **Governance gaps**: It's hard to track and control how agents use existing APIs. + +Bridge your existing API infrastructure to agents safely and efficiently with MCP Bridge. + +== The Solution + +Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: + +* **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. +* **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. +* **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. +* **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. +* **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. +* **Existing tool compatibility**: Integrates with Mule and other API management platforms without rebuilding existing assets. + +== Who This Is For + +MCP Bridge is ideal for: + +* **Organizations with existing API infrastructure** (especially Mule users) +* **Security teams** who are concerned about agent access to sensitive operations +* **Integration teams** looking to enable agents quickly without custom development +* **Architects** who are designing safe agent access to enterprise systems +* **Teams** who want to leverage existing investments in API management + +== Selecting Operations to Expose as Tools + +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering — without modifying the underlying API. + +=== Full API (All Operations Available) + +[source,text] +---- +Customer API: +- GET /customers/{id} (read) +- POST /customers (create) +- PUT /customers/{id} (update) +- DELETE /customers/{id} (delete) +- GET /customers/{id}/orders (read) +- POST /customers/{id}/orders (create) +---- + +=== Configured Tool Surface (Read Operations Only) + +When you configure MCP Bridge to expose only read operations, agents see a reduced tool surface drawn from the same Customer API. + +[source,text] +---- +Customer API (Agent Tool Surface): +- GET /customers/{id} (read - exposed as tool) +- GET /customers/{id}/orders (read - exposed as tool) +---- + +The agent can read customer and order data but can't create, modify, or delete anything. The write operations exist in the underlying API but are not exposed as MCP tools. + +== How MCP Bridge Works + +[source,text] +---- +Agent → MCP Bridge → Tool Selection Layer → Backend API +---- + +Each agent request follows this path: + +. The AI agent makes a request using the Model Context Protocol. +. MCP Bridge receives the request and maps it to the underlying API. +. Only operations you exposed as MCP tools are reachable. +. The call reaches the backend API. +. Responses flow back through the bridge to the agent. + +== Example Scenarios + +=== Scenario 1: Customer Service Agent with Read-Only Access + +*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. + +*Without MCP Bridge:* + +* Custom integration for each agent platform +* Risk of exposing write operations +* Inconsistent behavior across agent platforms + +*With MCP Bridge:* + +. Configure MCP Bridge to connect to the customer API instance +. Select only GET operations to expose as MCP tools +. Give agents safe, read-only access +. Serve all agent platforms from a single MCP server + +*Result:* Rapid deployment with built-in safety. + +=== Scenario 2: Inventory Check Agent + +*Challenge:* Multiple agents across different applications need to check inventory levels but can't adjust inventory. + +*Without MCP Bridge:* + +* Separate inventory API integration for each agent +* Risk of accidentally exposing inventory write operations +* Inconsistent data access patterns + +*With MCP Bridge:* + +. Create an MCP server from the inventory API instance +. Select only inventory query operations to expose as tools +. Connect all agents to the same configured tool surface +. Monitor all agent access centrally + +*Result:* Consistent, safe inventory access across all agents. + +=== Scenario 3: Financial Data Agent with Layered Tool Selection + +*Challenge:* Different agents need different levels of access to financial APIs. + +*Solution with MCP Bridge:* + +. Create multiple MCP servers from the financial API, each with a different tool selection: + * **Basic server**: Read-only tools for account balances + * **Analytics server**: Read-only tools for transaction history and reports + * **Approval server**: Read-only tools, plus a tool to create approval requests (but no direct change operations) +. Connect agents to the appropriate MCP server based on their access needs +. Apply governance policies from the same portfolio + +*Result:* Fine-grained access control with safety guarantees. + +=== Scenario 4: Mule Integration Platform + +*Challenge:* Organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. + +*Solution:* + +. Deploy MCP Bridge for key Mule APIs. +. Use Mule's existing API management capabilities. +. Select which Mule API operations to expose as tools for agent access. +. Use existing monitoring and governance. + +*Result:* Extend existing Mule investment to agentic use cases. + +== Implementation Steps + +=== Step 1: Identify APIs for Agent Access + +. List APIs that agents access. +. Document current operations (GET, POST, PUT, DELETE). +. Identify which operations are safe for agents. +. Prioritize APIs by business value and risk. + +=== Step 2: Plan Your Tool Selection + +For each API instance, decide: + +* Which operations can agents access? +* Are read-only operations sufficient? +* If agents require write access, which specific write operations do they use? +* What Omni Gateway policies apply to the resulting MCP server? + +=== Step 3: Deploy MCP Bridge + +. Configure MCP Bridge for your target API instances. +. Select which operations to expose as MCP tools and apply optional read-only filtering. +. Test with sample requests. + +=== Step 4: Apply Omni Gateway Policies + +MCP Bridge controls which API operations are available as tools. Omni Gateway controls how agents are allowed to use them at runtime. After deploying MCP Bridge, apply Omni Gateway policies to the resulting MCP server to enforce authentication, rate limiting, audit logging, and alerting. + +See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. + +=== Step 5: Connect Agents + +. Update agents to use MCP Bridge. +. Test with realistic scenarios. +. Verify that tool selection is working (agents can only call the operations you exposed). +. Monitor initial usage. + +=== Step 6: Monitor and Refine + +. Identify any operations that were not exposed but that agents need. +. Watch for attempts to call unexposed operations. +. Refine your tool selection based on real usage. + +== Key Benefits + +* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. +* **Security by default**: Exposes only the operations agents use, with optional read-only filtering. +* **Consistency**: Gives all agents access to APIs through the same controlled interface. +* **Leverage existing investments**: Works with Mule and other API platforms. +* **Centralized governance**: Provides a single point of control for agent API access. + +== Tool Selection Strategies + +=== Read-Only Filtering + +Start by exposing only GET/read operations as tools. Explicitly add write operations only when a use case requires them. + +=== Operation Allowlisting + +Select specific operations to expose rather than trying to identify operations to block. Allowlisting is safer and easier to maintain. + +=== Data Scoping + +Combine tool selection with data filters (for example, expose only operations that access certain data categories). + +For runtime controls such as rate limiting and time-based access restrictions, see xref:use-case-policy-enforcement.adoc[Policy Enforcement]. + +== Common Tool Selection Patterns + +=== Read-Only Tool Surface + +Use this pattern when agents only retrieve data. Expose all GET/read operations as tools; exclude all write operations. + +[source,text] +---- +(exposed) GET /resource/{id} +(exposed) GET /resource +(not exposed) POST /resource +(not exposed) PUT /resource/{id} +(not exposed) DELETE /resource/{id} +---- + +=== Read and Create Tool Surface + +Use this pattern when agents look up records and create new ones but do not modify or delete existing data. + +[source,text] +---- +(exposed) GET /resource/{id} +(exposed) POST /resource +(not exposed) PUT /resource/{id} +(not exposed) DELETE /resource/{id} +---- + +=== Read and Request-Only Tool Surface + +Use this pattern when agents initiate a workflow (for example, submitting an approval request) without directly modifying records. + +[source,text] +---- +(exposed) GET /resource/{id} +(exposed) POST /resource/request +(not exposed) PUT /resource/{id} +(not exposed) DELETE /resource/{id} +---- + +=== Granular Tool Surface + +Use this pattern for fine-grained control — exposing specific safe operations and blocking others based on individual business risk assessments. + +[source,text] +---- +(exposed) GET /orders/{id} +(exposed) POST /orders/{id}/notes (add note - safe) +(not exposed) PUT /orders/{id}/status (change status - risky) +(not exposed) DELETE /orders/{id} (delete order - risky) +---- + +== Security Considerations + +=== Default Deny + +Start with no access and explicitly enable only what agents use. + +Omni Gateway provides audit logging and anomaly monitoring for the resulting MCP server. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. + +=== Regular Reviews + +Periodically review: + +* Which operations are actually being used +* Whether your tool selection is still appropriate +* Whether additional operations should be removed from the agent tool list + +== Integration with Existing Tools + +=== Mule Integration + +MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you can expose existing Mule API instances as MCP servers without rebuilding them. + +* Use MCP Bridge with existing Mule APIs. +* Leverage Anypoint Platform governance. +* Extend Mule monitoring to agent access. +* Reuse existing API policies. + +=== API Gateways + +MCP Bridge can run alongside existing API gateways. Omni Gateway policies apply to the resulting MCP server in the same way they apply to other agent traffic. + +* Deploy MCP Bridge alongside existing gateways. +* Coordinate policies between gateway and bridge. +* Use unified monitoring and alerting across gateways and MCP servers. + +=== Identity Systems + +MCP Bridge can work with existing identity infrastructure so that agent access to APIs respects the same authentication and authorization rules already in place. + +* Integrate with existing authentication. +* Use existing authorization rules where applicable. +* Extend identity-based access control to agents. + +== Related Documentation + +// TODO: Update these links when Agent Fabric documentation is published. +* link:https://docs.mulesoft.com/agent-fabric/mcp-bridge[MCP Bridge Documentation] +* link:https://docs.mulesoft.com/agent-fabric/api-pruning[Selecting Operations to Expose as Tools] +* link:https://docs.mulesoft.com/agent-fabric/mule-integration[Integrating with Mule] + +== Next Steps + +With MCP Bridge providing safe API access, you're ready to: + +* xref:use-case-policy-enforcement.adoc[Add additional policy enforcement] +* xref:use-case-identity.adoc[Implement user-scoped API access] +* xref:use-case-orchestration.adoc[Build workflows using bridged APIs] From 7d8ec6215524b79c705ed14e28c9f746d2f56509 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 14:27:42 -0700 Subject: [PATCH 02/30] Updated short description --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 478858082..51e0365fc 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -1,8 +1,6 @@ = Make APIs Agent-Ready with MCP Bridge -Agent Fabric's MCP Bridge converts your existing API instances into MCP servers through configuration, exposing their operations as MCP tools that agents can discover and call without modifying the underlying API. -Choose which operations to expose and apply optional read-only filtering to limit what agents can do, giving you control over agent access without rewriting anything. -Use this approach to make your existing Mule or API management investment immediately available to agents, with governance policies applied from the same portfolio. +Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. == The Problem From de86eb387e48c2cde3dc7e352fc9e8952719f0d3 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 15 Jul 2026 16:48:12 -0700 Subject: [PATCH 03/30] Reorg --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 82 +++++++++---------- 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 51e0365fc..d6d9d133f 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -23,47 +23,7 @@ Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API i * **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. * **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. * **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Existing tool compatibility**: Integrates with Mule and other API management platforms without rebuilding existing assets. - -== Who This Is For - -MCP Bridge is ideal for: - -* **Organizations with existing API infrastructure** (especially Mule users) -* **Security teams** who are concerned about agent access to sensitive operations -* **Integration teams** looking to enable agents quickly without custom development -* **Architects** who are designing safe agent access to enterprise systems -* **Teams** who want to leverage existing investments in API management - -== Selecting Operations to Expose as Tools - -MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering — without modifying the underlying API. - -=== Full API (All Operations Available) - -[source,text] ----- -Customer API: -- GET /customers/{id} (read) -- POST /customers (create) -- PUT /customers/{id} (update) -- DELETE /customers/{id} (delete) -- GET /customers/{id}/orders (read) -- POST /customers/{id}/orders (create) ----- - -=== Configured Tool Surface (Read Operations Only) - -When you configure MCP Bridge to expose only read operations, agents see a reduced tool surface drawn from the same Customer API. - -[source,text] ----- -Customer API (Agent Tool Surface): -- GET /customers/{id} (read - exposed as tool) -- GET /customers/{id}/orders (read - exposed as tool) ----- - -The agent can read customer and order data but can't create, modify, or delete anything. The write operations exist in the underlying API but are not exposed as MCP tools. +* **Existing tool compatibility**: Integrates with MuleSoft and other API management platforms without rebuilding existing assets. == How MCP Bridge Works @@ -80,6 +40,16 @@ Each agent request follows this path: . The call reaches the backend API. . Responses flow back through the bridge to the agent. +== Who This Is For + +MCP Bridge is ideal for: + +* Organizations with existing API infrastructure +* Security teams who are concerned about agent access to sensitive operations +* Integration teams looking to enable agents quickly without custom development +* Architects who are designing safe agent access to enterprise systems +* Teams who want to leverage existing investments in API management and governance + == Example Scenarios === Scenario 1: Customer Service Agent with Read-Only Access @@ -148,6 +118,36 @@ Each agent request follows this path: *Result:* Extend existing Mule investment to agentic use cases. +== Selecting Operations to Expose as Tools + +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering, without modifying the underlying API. + +=== Example: Limiting Agent Access to Read Operations + +Consider a Customer API with both read and write operations: + +[source,text] +---- +Customer API: +- GET /customers/{id} (read) +- POST /customers (create) +- PUT /customers/{id} (update) +- DELETE /customers/{id} (delete) +- GET /customers/{id}/orders (read) +- POST /customers/{id}/orders (create) +---- + +After you configure MCP Bridge to expose only read operations, agents see a reduced tool surface: + +[source,text] +---- +Customer API (Agent Tool Surface): +- GET /customers/{id} (read - exposed as an MCP tool) +- GET /customers/{id}/orders (read - exposed as an MCP tool) +---- + +The agent can read customer and order data but can't create, modify, or delete anything. The write operations exist in the underlying API but aren't exposed as MCP tools. + == Implementation Steps === Step 1: Identify APIs for Agent Access From 4681bd0ac508cfaf8afa0daa2d02debbaf463624 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 11:16:16 -0700 Subject: [PATCH 04/30] Adding use case overview --- modules/ROOT/nav.adoc | 2 + .../ROOT/pages/agent-fabric-use-cases.adoc | 104 ++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 modules/ROOT/pages/agent-fabric-use-cases.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 96f9abae4..12e42ca08 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -32,6 +32,8 @@ * xref:learning-map-mulesoft-ai.adoc[] * xref:agent-fabric-overview.adoc[Agent Fabric] ** xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] + ** xref:agent-fabric-use-cases.adoc[] + *** xref:af-use-case-mcp-bridge.adoc[] ** xref:agent-fabric-release-notes.adoc[] ** xref:agent-networks-get-started.adoc[] * xref:learning-map-api-management.adoc[API Management] diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc new file mode 100644 index 000000000..7d9cb0e1e --- /dev/null +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -0,0 +1,104 @@ += Agent Fabric Use Cases + +Agent Fabric helps you design and orchestrate a network of agents, brokers, and MCP servers across your enterprise. Use Agent Fabric to manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. + +Solve common challenges when you deploy agentic systems at scale. + +== Find your use case + +[cols="1,2,1"] +|=== +|If you want to... |Use Case |Go to + +|Catalog and manage agents across multiple platforms +|Registry and Visibility +|xref:use-case-registry.adoc[Registry and Visibility] + +|Apply consistent business rules and guardrails across all agents +|Policy Enforcement +|xref:use-case-policy-enforcement.adoc[Policy Enforcement] + +|Control token usage and optimize model selection +|Cost Control and Semantic Routing +|xref:use-case-cost-control.adoc[Cost Control] + +|Move agents from proof-of-concept to production with proper identity management +|Identity and Production Readiness +|xref:use-case-identity.adoc[Identity and Production Readiness] + +|Build complex, deterministic workflows with error handling +|Workflow Orchestration +|xref:use-case-orchestration.adoc[Workflow Orchestration] + +|Make existing APIs agent-ready without modifying code +|MCP Bridge +|xref:af-use-case-mcp-bridge.adoc[MCP Bridge] +|=== + + +== Registry and Visibility + +If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. + +*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms + +xref:use-case-registry.adoc[Learn more →] + +== Policy Enforcement + +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies once through a gateway rather than reimplementing them for each platform. + +*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments + +xref:use-case-policy-enforcement.adoc[Learn more →] + +== Cost Control and Semantic Routing + +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. + +*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements + +xref:use-case-cost-control.adoc[Learn more →] + +== Identity and Production Readiness + +Move from proof-of-concept to production by implementing proper identity verification and data scoping. Make sure agents operate in user context, not system context. + +*Best for:* Teams that are ready to move from POC to production deployments with proper access controls + +xref:use-case-identity.adoc[Learn more →] + +== Workflow Orchestration + +Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. + +*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows + +xref:use-case-orchestration.adoc[Learn more →] + +== MCP Bridge + +Transform your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. + +*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely + +xref:use-case-mcp-bridge.adoc[Learn more →] + +== Get started + +New to Agent Fabric? Start with the learning map to understand the fundamentals: + +* https://help.mulesoft.com/s/article/Get-Started-with-Agent-Fabric[Get Started with Agent Fabric] +* Watch a video to learn about Agent Fabric. +* Watch an interactive demo of Agent Fabric. + +After you understand the basics, return to this guide to implement your use cases. + +== See also + +* xref:use-case-cost-control.adoc[] +* xref:use-case-identity.adoc[] +* xref:use-case-mcp-bridge.adoc[] +* xref:use-case-orchestration.adoc[] +* xref:use-case-policy-enforcement.adoc[] +* xref:use-case-registry.adoc[] From fbb42a06a2f42be1e1490005640b4e3527fccbe3 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 11:37:30 -0700 Subject: [PATCH 05/30] Human edits --- .../ROOT/pages/agent-fabric-use-cases.adoc | 68 ++++++++----------- 1 file changed, 27 insertions(+), 41 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 7d9cb0e1e..4179958df 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -1,18 +1,20 @@ = Agent Fabric Use Cases -Agent Fabric helps you design and orchestrate a network of agents, brokers, and MCP servers across your enterprise. Use Agent Fabric to manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. +Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP servers. Manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. -Solve common challenges when you deploy agentic systems at scale. - -== Find your use case +== Find Your Use Case [cols="1,2,1"] |=== -|If you want to... |Use Case |Go to +|If you want to... |Use case |Go to |Catalog and manage agents across multiple platforms |Registry and Visibility -|xref:use-case-registry.adoc[Registry and Visibility] +|xref:use-case-registry.adoc[] + +|Make existing APIs agent-ready without modifying code +|MCP Bridge +|xref:af-use-case-mcp-bridge.adoc[] |Apply consistent business rules and guardrails across all agents |Policy Enforcement @@ -22,79 +24,63 @@ Solve common challenges when you deploy agentic systems at scale. |Cost Control and Semantic Routing |xref:use-case-cost-control.adoc[Cost Control] -|Move agents from proof-of-concept to production with proper identity management -|Identity and Production Readiness -|xref:use-case-identity.adoc[Identity and Production Readiness] - |Build complex, deterministic workflows with error handling |Workflow Orchestration |xref:use-case-orchestration.adoc[Workflow Orchestration] -|Make existing APIs agent-ready without modifying code -|MCP Bridge -|xref:af-use-case-mcp-bridge.adoc[MCP Bridge] |=== - == Registry and Visibility If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. -*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms +*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms. -xref:use-case-registry.adoc[Learn more →] +xref:use-case-registry.adoc[Registry and Visibility] -== Policy Enforcement +== MCP Bridge -Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies once through a gateway rather than reimplementing them for each platform. +Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. -*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments +*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely. -xref:use-case-policy-enforcement.adoc[Learn more →] +xref:af-use-case-mcp-bridge.adoc[] -== Cost Control and Semantic Routing +== Policy Enforcement -Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. -*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements +*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments. -xref:use-case-cost-control.adoc[Learn more →] +xref:use-case-policy-enforcement.adoc[Policy Enforcement] -== Identity and Production Readiness +== Cost Control and Semantic Routing -Move from proof-of-concept to production by implementing proper identity verification and data scoping. Make sure agents operate in user context, not system context. +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. -*Best for:* Teams that are ready to move from POC to production deployments with proper access controls +*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements. -xref:use-case-identity.adoc[Learn more →] +xref:use-case-cost-control.adoc[Cost Control] == Workflow Orchestration Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. -*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows - -xref:use-case-orchestration.adoc[Learn more →] - -== MCP Bridge +*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows. -Transform your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. +xref:use-case-orchestration.adoc[Workflow Orchestration] -*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely -xref:use-case-mcp-bridge.adoc[Learn more →] -== Get started +== Get Started New to Agent Fabric? Start with the learning map to understand the fundamentals: * https://help.mulesoft.com/s/article/Get-Started-with-Agent-Fabric[Get Started with Agent Fabric] -* Watch a video to learn about Agent Fabric. -* Watch an interactive demo of Agent Fabric. -After you understand the basics, return to this guide to implement your use cases. +After you understand the basics, choose a use case to implement. -== See also +== See Also * xref:use-case-cost-control.adoc[] * xref:use-case-identity.adoc[] From eb8e5437775fa5b109015e965ebed76d2f5f96c6 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 16 Jul 2026 15:21:10 -0700 Subject: [PATCH 06/30] Human in the loop edits --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 206 +++++++++--------- 1 file changed, 97 insertions(+), 109 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index d6d9d133f..3ffec1662 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -1,6 +1,14 @@ = Make APIs Agent-Ready with MCP Bridge -Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose, apply read-only filtering where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. +Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose as tools, limit agents to read operations where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. + +Key benefits of MCP Bridge include: + +* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. +* **Security by default**: Exposes only the operations you explicitly map as tools. +* **Consistency**: Gives all agents access to APIs through the same controlled interface. +* **Leverage existing investments**: Works with APIs managed through Anypoint Platform. +* **Centralized governance**: Provides a single point of control for agent API access. == The Problem @@ -20,32 +28,30 @@ Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API i * **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. * **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. -* **Optional read-only filtering**: Limits agent access to read-only operations when needed, without modifying the underlying API. +* **Selective operation mapping**: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. * **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. * **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Existing tool compatibility**: Integrates with MuleSoft and other API management platforms without rebuilding existing assets. +* **Leverage existing assets**: Works with your existing MuleSoft API infrastructure without rebuilding assets. == How MCP Bridge Works -[source,text] ----- -Agent → MCP Bridge → Tool Selection Layer → Backend API ----- +MCP Bridge operates at the Omni Gateway layer as a set of automated policies. You configure it through API Manager, and it deploys to the same gateway infrastructure you already use to manage API traffic. Each agent request follows this path: -. The AI agent makes a request using the Model Context Protocol. -. MCP Bridge receives the request and maps it to the underlying API. +. The AI agent makes a request using MCP. +. The request flows through Omni Gateway, where MCP Bridge policies execute. +. MCP Bridge maps the request to the underlying API operation. . Only operations you exposed as MCP tools are reachable. . The call reaches the backend API. -. Responses flow back through the bridge to the agent. +. Responses flow back through the gateway to the agent. == Who This Is For MCP Bridge is ideal for: * Organizations with existing API infrastructure -* Security teams who are concerned about agent access to sensitive operations +* Security teams concerned about agent access to sensitive operations * Integration teams looking to enable agents quickly without custom development * Architects who are designing safe agent access to enterprise systems * Teams who want to leverage existing investments in API management and governance @@ -54,106 +60,62 @@ MCP Bridge is ideal for: === Scenario 1: Customer Service Agent with Read-Only Access -*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. - -*Without MCP Bridge:* +*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you would need to build custom integrations for each agent platform. This risks exposure of write operations and creates inconsistent behavior across platforms. -* Custom integration for each agent platform -* Risk of exposing write operations -* Inconsistent behavior across agent platforms +With MCP Bridge you get rapid deployment with built-in safety: -*With MCP Bridge:* - -. Configure MCP Bridge to connect to the customer API instance -. Select only GET operations to expose as MCP tools -. Give agents safe, read-only access -. Serve all agent platforms from a single MCP server - -*Result:* Rapid deployment with built-in safety. +. In API Manager, create an MCP Bridge instance for your customer API. +. Map only GET operations to MCP tools. +. Deploy the instance (policies execute on Omni Gateway). +. Connect all agent platforms to the MCP server endpoint. === Scenario 2: Inventory Check Agent -*Challenge:* Multiple agents across different applications need to check inventory levels but can't adjust inventory. - -*Without MCP Bridge:* +*Challenge:* Your inventory API includes operations to check stock levels, reserve items, adjust quantities, and process transfers. Sales agents, warehouse agents, and customer service agents all need to check current stock, but only warehouse systems should adjust it. -* Separate inventory API integration for each agent -* Risk of accidentally exposing inventory write operations -* Inconsistent data access patterns +Without MCP Bridge, you would either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. -*With MCP Bridge:* +With MCP Bridge you give all agents read-only inventory access from a single configuration: -. Create an MCP server from the inventory API instance -. Select only inventory query operations to expose as tools -. Connect all agents to the same configured tool surface -. Monitor all agent access centrally - -*Result:* Consistent, safe inventory access across all agents. +. In API Manager, create an MCP Bridge instance from the inventory API. +. Map only GET operations for stock queries to MCP tools. +. Connect all agent types to the MCP server endpoint. +. Monitor agent usage in the enhanced MuleSoft experience. === Scenario 3: Financial Data Agent with Layered Tool Selection -*Challenge:* Different agents need different levels of access to financial APIs. +*Challenge:* Different agents need different levels of access to financial APIs. -*Solution with MCP Bridge:* +Without MCP Bridge, you would need to build separate custom integrations for each agent access level, creating duplication and increasing the risk that a high-privilege operation gets exposed to the wrong agent. -. Create multiple MCP servers from the financial API, each with a different tool selection: - * **Basic server**: Read-only tools for account balances - * **Analytics server**: Read-only tools for transaction history and reports - * **Approval server**: Read-only tools, plus a tool to create approval requests (but no direct change operations) -. Connect agents to the appropriate MCP server based on their access needs -. Apply governance policies from the same portfolio +With MCP Bridge you get fine-grained access control with safety guarantees: -*Result:* Fine-grained access control with safety guarantees. +. In API Manager, create multiple MCP Bridge instances from your financial API, each with different operation mappings: + * **Basic server**: Map only GET operations for account balances. + * **Analytics server**: Map GET operations for transaction history and reports. + * **Approval server**: Map GET operations plus POST for creating approval requests. +. Connect each agent to the appropriate MCP server endpoint based on access requirements. +. In API Manager, apply policies to each MCP server instance. === Scenario 4: Mule Integration Platform -*Challenge:* Organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. - -*Solution:* +*Challenge:* Your organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. -. Deploy MCP Bridge for key Mule APIs. -. Use Mule's existing API management capabilities. -. Select which Mule API operations to expose as tools for agent access. -. Use existing monitoring and governance. +Without MCP Bridge, you would need to build agent-specific adapters on top of each Mule API, duplicating logic and bypassing existing Anypoint Platform governance. -*Result:* Extend existing Mule investment to agentic use cases. +With MCP Bridge you extend your existing Mule investment to agentic use cases: -== Selecting Operations to Expose as Tools - -MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. Expose all operations, a subset, or apply optional read-only filtering, without modifying the underlying API. - -=== Example: Limiting Agent Access to Read Operations - -Consider a Customer API with both read and write operations: - -[source,text] ----- -Customer API: -- GET /customers/{id} (read) -- POST /customers (create) -- PUT /customers/{id} (update) -- DELETE /customers/{id} (delete) -- GET /customers/{id}/orders (read) -- POST /customers/{id}/orders (create) ----- - -After you configure MCP Bridge to expose only read operations, agents see a reduced tool surface: - -[source,text] ----- -Customer API (Agent Tool Surface): -- GET /customers/{id} (read - exposed as an MCP tool) -- GET /customers/{id}/orders (read - exposed as an MCP tool) ----- - -The agent can read customer and order data but can't create, modify, or delete anything. The write operations exist in the underlying API but aren't exposed as MCP tools. +. In API Manager, create MCP Bridge instances for key Mule APIs. +. Map the API operations you want to expose to MCP tools. +. Deploy the instances (policies execute on your existing Omni Gateway infrastructure). +. Monitor through the enhanced MuleSoft experience and apply policies in API Manager. == Implementation Steps === Step 1: Identify APIs for Agent Access . List APIs that agents access. -. Document current operations (GET, POST, PUT, DELETE). +. Document the current API operations (GET, POST, PUT, DELETE). . Identify which operations are safe for agents. . Prioritize APIs by business value and risk. @@ -168,13 +130,17 @@ For each API instance, decide: === Step 3: Deploy MCP Bridge -. Configure MCP Bridge for your target API instances. -. Select which operations to expose as MCP tools and apply optional read-only filtering. -. Test with sample requests. +. In API Manager, create an MCP Bridge instance for your target API. +. Configure downstream settings (base path, protocol, port) and upstream settings (route label, upstream URL). +. Map specific API operations to MCP tools by selecting the HTTP method and resource for each tool. +. Define tool names, descriptions, and input schemas for each mapped operation. +. Test the MCP server endpoint with sample requests. + +For more information, see xref:api-manager::create-instance-task-mcp-bridge.adoc[]. === Step 4: Apply Omni Gateway Policies -MCP Bridge controls which API operations are available as tools. Omni Gateway controls how agents are allowed to use them at runtime. After deploying MCP Bridge, apply Omni Gateway policies to the resulting MCP server to enforce authentication, rate limiting, audit logging, and alerting. +MCP Bridge controls which API operations are available as tools. Omni Gateway policies control how agents are allowed to use them at runtime. After deploying MCP Bridge, apply policies in API Manager to the MCP server instance to enforce authentication, rate limiting, audit logging, and alerting. See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. @@ -187,23 +153,45 @@ See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation === Step 6: Monitor and Refine -. Identify any operations that were not exposed but that agents need. -. Watch for attempts to call unexposed operations. -. Refine your tool selection based on real usage. +. In the enhanced MuleSoft experience, review latency, error rates, and request volume for your MCP server. +. Analyze which tools agents are calling and identify missing operations. +. Check gateway logs for attempts to call unexposed operations. +. If you need to change tool mappings, create a new MCP Bridge instance with the updated configuration in API Manager. MCP Bridge instances are immutable after deployment. -== Key Benefits +For information about monitoring MCP servers and other services, see xref:exp-services-monitoring.adoc[]. -* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. -* **Security by default**: Exposes only the operations agents use, with optional read-only filtering. -* **Consistency**: Gives all agents access to APIs through the same controlled interface. -* **Leverage existing investments**: Works with Mule and other API platforms. -* **Centralized governance**: Provides a single point of control for agent API access. == Tool Selection Strategies -=== Read-Only Filtering +MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. During configuration, you map specific operations (HTTP method and resource) to tools. Expose all operations, only read operations, or any subset you choose, without modifying the underlying API. + +Consider a Customer API with both read and write operations: + +[source,text] +---- +Customer API: +- GET /customers/{id} (read) +- POST /customers (create) +- PUT /customers/{id} (update) +- DELETE /customers/{id} (delete) +- GET /customers/{id}/orders (read) +- POST /customers/{id}/orders (create) +---- + +After you configure MCP Bridge to expose only read operations, agents see a reduced tool surface: + +[source,text] +---- +Customer API (Agent Tool Surface): +- GET /customers/{id} (read - exposed as an MCP tool) +- GET /customers/{id}/orders (read - exposed as an MCP tool) +---- + +The agent can read customer and order data but can't create, modify, or delete anything. The write operations exist in the underlying API but aren't exposed as MCP tools. + +=== Read-Only Operation Mapping -Start by exposing only GET/read operations as tools. Explicitly add write operations only when a use case requires them. +Start by mapping only GET/read operations to tools. Explicitly map write operations only when a use case requires them. === Operation Allowlisting @@ -219,7 +207,7 @@ For runtime controls such as rate limiting and time-based access restrictions, s === Read-Only Tool Surface -Use this pattern when agents only retrieve data. Expose all GET/read operations as tools; exclude all write operations. +Use this pattern when agents only retrieve data. Expose all GET/read operations as tools and exclude all write (POST, PUT, DELETE) operations. [source,text] ---- @@ -232,7 +220,7 @@ Use this pattern when agents only retrieve data. Expose all GET/read operations === Read and Create Tool Surface -Use this pattern when agents look up records and create new ones but do not modify or delete existing data. +Use this pattern when agents look up records and create new ones but don't modify or delete existing data. [source,text] ---- @@ -256,7 +244,7 @@ Use this pattern when agents initiate a workflow (for example, submitting an app === Granular Tool Surface -Use this pattern for fine-grained control — exposing specific safe operations and blocking others based on individual business risk assessments. +Use this pattern for fine-grained control, exposing specific safe operations and blocking others based on individual business risk assessments. For example, expose GET /orders/{id} to allow agents to view order details, but block PUT /orders/{id}/status to prevent agents from changing order status. This gives agents access to the information they need while protecting sensitive operations. [source,text] ---- @@ -272,7 +260,7 @@ Use this pattern for fine-grained control — exposing specific safe operations Start with no access and explicitly enable only what agents use. -Omni Gateway provides audit logging and anomaly monitoring for the resulting MCP server. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. +Apply Omni Gateway policies to enable audit logging and monitor MCP server usage through Anypoint Monitoring. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. === Regular Reviews @@ -293,13 +281,13 @@ MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you ca * Extend Mule monitoring to agent access. * Reuse existing API policies. -=== API Gateways +=== Omni Gateway Integration -MCP Bridge can run alongside existing API gateways. Omni Gateway policies apply to the resulting MCP server in the same way they apply to other agent traffic. +MCP Bridge runs on Omni Gateway infrastructure. MCP server instances are managed through API Manager and protected by Omni Gateway policies, just like API instances. -* Deploy MCP Bridge alongside existing gateways. -* Coordinate policies between gateway and bridge. -* Use unified monitoring and alerting across gateways and MCP servers. +* Deploy MCP Bridge instances on the same Omni Gateway that manages your APIs. +* Apply policies to MCP servers the same way you apply them to APIs. +* Use unified monitoring and alerting across APIs and MCP servers. === Identity Systems From 6e5c51f29749cc01317c969de0485915667f57fa Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 17 Jul 2026 11:38:45 -0700 Subject: [PATCH 07/30] Adding short descriptions to sections --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 3ffec1662..fb5de7b0b 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -58,6 +58,8 @@ MCP Bridge is ideal for: == Example Scenarios +These scenarios demonstrate how different organizations use MCP Bridge to solve specific agent access challenges. + === Scenario 1: Customer Service Agent with Read-Only Access *Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you would need to build custom integrations for each agent platform. This risks exposure of write operations and creates inconsistent behavior across platforms. @@ -112,6 +114,8 @@ With MCP Bridge you extend your existing Mule investment to agentic use cases: == Implementation Steps +Follow these steps to deploy MCP Bridge and make your APIs available to agents. + === Step 1: Identify APIs for Agent Access . List APIs that agents access. @@ -128,7 +132,7 @@ For each API instance, decide: * If agents require write access, which specific write operations do they use? * What Omni Gateway policies apply to the resulting MCP server? -=== Step 3: Deploy MCP Bridge +=== Step 3: Create and Deploy MCP Bridge Instance . In API Manager, create an MCP Bridge instance for your target API. . Configure downstream settings (base path, protocol, port) and upstream settings (route label, upstream URL). @@ -205,6 +209,8 @@ For runtime controls such as rate limiting and time-based access restrictions, s == Common Tool Selection Patterns +These patterns represent typical approaches to selecting which operations to expose as tools based on your security requirements and use cases. + === Read-Only Tool Surface Use this pattern when agents only retrieve data. Expose all GET/read operations as tools and exclude all write (POST, PUT, DELETE) operations. @@ -256,6 +262,8 @@ Use this pattern for fine-grained control, exposing specific safe operations and == Security Considerations +When deploying MCP Bridge, follow security best practices to minimize risk and maintain control over agent access to your APIs. + === Default Deny Start with no access and explicitly enable only what agents use. @@ -272,6 +280,8 @@ Periodically review: == Integration with Existing Tools +MCP Bridge integrates with your existing MuleSoft infrastructure, identity systems, and gateway deployment to leverage investments you have already made. + === Mule Integration MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you can expose existing Mule API instances as MCP servers without rebuilding them. @@ -285,7 +295,7 @@ MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you ca MCP Bridge runs on Omni Gateway infrastructure. MCP server instances are managed through API Manager and protected by Omni Gateway policies, just like API instances. -* Deploy MCP Bridge instances on the same Omni Gateway that manages your APIs. +* Create and deploy MCP Bridge instances on the same Omni Gateway that manages your APIs. * Apply policies to MCP servers the same way you apply them to APIs. * Use unified monitoring and alerting across APIs and MCP servers. From 9cde3846967f0975e2a4469bfc5f485b60c3e194 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 20 Jul 2026 12:16:17 -0700 Subject: [PATCH 08/30] wording tweak --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index fb5de7b0b..6aad626df 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -114,7 +114,7 @@ With MCP Bridge you extend your existing Mule investment to agentic use cases: == Implementation Steps -Follow these steps to deploy MCP Bridge and make your APIs available to agents. +Follow these steps to create MCP Bridge instances and make your APIs available to agents. === Step 1: Identify APIs for Agent Access From c63d279c876ecd2571652b6cd2ff5670bb17fe01 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 21 Jul 2026 14:08:58 -0700 Subject: [PATCH 09/30] Adding content --- .../ROOT/pages/agent-fabric-use-cases.adoc | 48 ++++++++----------- 1 file changed, 19 insertions(+), 29 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 4179958df..f61ded5d1 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -1,6 +1,6 @@ = Agent Fabric Use Cases -Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP servers. Manage agents across multiple platforms, enforce consistent policies, control costs, and build workflows. +Agent Fabric addresses the most common challenges in enterprise AI agent management, from discovering and governing agents across platforms, to making existing APIs agent-ready without custom development, and keeping token costs under control. Each use case maps a specific business problem to a set of Agent Fabric capabilities so you can identify where to start and build incrementally. Use the quick-reference table to match your immediate goal to the right capability. == Find Your Use Case @@ -9,66 +9,56 @@ Use Agent Fabric to design and orchestrate a network of agents, brokers, and MCP |If you want to... |Use case |Go to |Catalog and manage agents across multiple platforms -|Registry and Visibility +|Discover and register agents from a centralized catalog. Know what exists and where before you apply governance. |xref:use-case-registry.adoc[] |Make existing APIs agent-ready without modifying code -|MCP Bridge +|Select which API operations to expose as MCP tools, apply read-only filtering, and control agent access to your APIs. |xref:af-use-case-mcp-bridge.adoc[] |Apply consistent business rules and guardrails across all agents -|Policy Enforcement +|Enforce PII policies, rate limits, and compliance rules across all agents through a single gateway rather than reimplementing them per platform. |xref:use-case-policy-enforcement.adoc[Policy Enforcement] |Control token usage and optimize model selection -|Cost Control and Semantic Routing +|Monitor token usage across agents and applications, then route queries to cost-effective models based on complexity. |xref:use-case-cost-control.adoc[Cost Control] |Build complex, deterministic workflows with error handling -|Workflow Orchestration -|xref:use-case-orchestration.adoc[Workflow Orchestration] +|Handle multi-step business logic, error scenarios, and unhappy paths that simple agent loops can't reliably address. +|xref:use-case-orchestration.adoc[Agentic Orchestration] |=== -== Registry and Visibility +== Discover and Govern Agents Across Your Organization -If you have multiplatform agent deployments, use a centralized way to discover, catalog, and manage your agent estate. Know what exists and where before you apply governance. +Use a centralized registry and automated scanners to discover, catalog, and manage agents across your organization. Know what exists and where before you apply governance. For example, a business process outsourcer managing agents across multiple client platforms, or an enterprise security team asked to audit every agent in production, can use Registry and Scanners to get a complete, current picture without manually tracking deployments. -*Best for:* BPOs, holding companies, large system integrators, and enterprises with agents across multiple platforms. +xref:use-case-registry.adoc[Centralizing Agent Discovery with Agent Registry and Scanners] -xref:use-case-registry.adoc[Registry and Visibility] +== Make APIs Agent-Ready with MCP Bridge -== MCP Bridge - -Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. - -*Best for:* Organizations with existing API infrastructure (like Mule) that want to enable agentic access safely. +Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. For example, an organization with hundreds of existing Mule APIs can make them callable by agents in minutes through configuration alone, without touching the underlying implementations. xref:af-use-case-mcp-bridge.adoc[] -== Policy Enforcement - -Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. +== Enforce Consistent Policies Across Agent Platforms -*Best for:* Enterprises that require uniform compliance, security, and governance across different agent environments. +Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. For example, a regulated industry deploying agents across Agentforce, Bedrock, and custom Mule implementations can enforce the same data privacy and rate limiting rules everywhere through a single Omni Gateway policy. xref:use-case-policy-enforcement.adoc[Policy Enforcement] -== Cost Control and Semantic Routing +== Monitor Costs and Optimizing Model Selection -Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. - -*Best for:* Organizations that manage large-scale agent deployments with budget constraints and efficiency requirements. +Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. For example, a team running hundreds of daily agent interactions can route routine lookups to a smaller, cheaper model and reserve a frontier model only for tasks that require complex reasoning. xref:use-case-cost-control.adoc[Cost Control] -== Workflow Orchestration - -Build multi-step workflows with deterministic outcomes. Handle complex business logic, error scenarios, and unhappy paths that simple agent loops cannot address. +== Coordinate Multi-Agent Processes with Brokers -*Best for:* Advanced use cases that require reliable, predictable multi-agent workflows. +Use agent brokers and agent networks to coordinate task delegation across A2A-compliant agents with guided determinism. Define broker routing logic in Agent Script to handle complex business processes, error scenarios, and unhappy paths that require multiple specialized agents working in sequence. For example, an order management process that involves a research agent, a pricing agent, and an approval agent can be wired together in a single agent network with a broker that routes each step to the right specialist. -xref:use-case-orchestration.adoc[Workflow Orchestration] +xref:use-case-orchestration.adoc[Agent Orchestration] From bfdc418579934e0dd9e72ee117477f96d4d24739 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 21 Jul 2026 17:30:14 -0700 Subject: [PATCH 10/30] Removed excessive bold --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 38 +++++++++---------- .../ROOT/pages/agent-fabric-use-cases.adoc | 2 +- 2 files changed, 20 insertions(+), 20 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 6aad626df..2004b4532 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -4,21 +4,21 @@ Agent Fabric's MCP Bridge transforms your existing API instances into agent-read Key benefits of MCP Bridge include: -* **Rapid enablement**: Gets agents connected to APIs quickly, without custom development. -* **Security by default**: Exposes only the operations you explicitly map as tools. -* **Consistency**: Gives all agents access to APIs through the same controlled interface. -* **Leverage existing investments**: Works with APIs managed through Anypoint Platform. -* **Centralized governance**: Provides a single point of control for agent API access. +* Rapid enablement: Gets agents connected to APIs quickly, without custom development. +* Security by default: Exposes only the operations you explicitly map as tools. +* Consistency: Gives all agents access to APIs through the same controlled interface. +* Leverage existing investments: Works with APIs managed through Anypoint Platform. +* Centralized governance: Provides a single point of control for agent API access. == The Problem You have invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: -* **API complexity**: Existing APIs weren't designed for agent consumption. -* **Security concerns**: APIs often include write and delete operations that are too risky for agents. -* **Integration overhead**: Building custom integrations for each agent platform is time-consuming. -* **Inconsistent access**: Different agents access the same APIs in different ways. -* **Governance gaps**: It's hard to track and control how agents use existing APIs. +* API complexity: Existing APIs weren't designed for agent consumption. +* Security concerns: APIs often include write and delete operations that are too risky for agents. +* Integration overhead: Building custom integrations for each agent platform is time-consuming. +* Inconsistent access: Different agents access the same APIs in different ways. +* Governance gaps: It's hard to track and control how agents use existing APIs. Bridge your existing API infrastructure to agents safely and efficiently with MCP Bridge. @@ -26,12 +26,12 @@ Bridge your existing API infrastructure to agents safely and efficiently with MC Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: -* **Rapid integration**: Connects existing API instances to agents through simple configuration, with no rewriting required. -* **Selective exposure**: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. -* **Selective operation mapping**: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. -* **Centralized management**: Provides a single point of control for API access, with governance policies applied from the same portfolio. -* **Agent-facing abstraction**: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* **Leverage existing assets**: Works with your existing MuleSoft API infrastructure without rebuilding assets. +* Rapid integration: Connects existing API instances to agents through simple configuration, with no rewriting required. +* Selective exposure: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. +* Selective operation mapping: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. +* Centralized management: Provides a single point of control for API access, with governance policies applied from the same portfolio. +* Agent-facing abstraction: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. +* Leverage existing assets: Works with your existing MuleSoft API infrastructure without rebuilding assets. == How MCP Bridge Works @@ -93,9 +93,9 @@ Without MCP Bridge, you would need to build separate custom integrations for eac With MCP Bridge you get fine-grained access control with safety guarantees: . In API Manager, create multiple MCP Bridge instances from your financial API, each with different operation mappings: - * **Basic server**: Map only GET operations for account balances. - * **Analytics server**: Map GET operations for transaction history and reports. - * **Approval server**: Map GET operations plus POST for creating approval requests. + * Basic server: Map only GET operations for account balances. + * Analytics server: Map GET operations for transaction history and reports. + * Approval server: Map GET operations plus POST for creating approval requests. . Connect each agent to the appropriate MCP server endpoint based on access requirements. . In API Manager, apply policies to each MCP server instance. diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index f61ded5d1..ca0bbd9cb 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -74,7 +74,7 @@ After you understand the basics, choose a use case to implement. * xref:use-case-cost-control.adoc[] * xref:use-case-identity.adoc[] -* xref:use-case-mcp-bridge.adoc[] +* xref:af-use-case-mcp-bridge.adoc[] * xref:use-case-orchestration.adoc[] * xref:use-case-policy-enforcement.adoc[] * xref:use-case-registry.adoc[] From 433c82690f3268c158eeff11b40ac0065797dfa8 Mon Sep 17 00:00:00 2001 From: Isaac Date: Tue, 4 Aug 2026 12:34:24 -0700 Subject: [PATCH 11/30] Add Agent Fabric orchestration use case --- modules/ROOT/nav.adoc | 1 + .../ROOT/pages/af-use-case-orchestration.adoc | 196 ++++++++++++++++++ 2 files changed, 197 insertions(+) create mode 100644 modules/ROOT/pages/af-use-case-orchestration.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 12e42ca08..a990bb012 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -34,6 +34,7 @@ ** xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] ** xref:agent-fabric-use-cases.adoc[] *** xref:af-use-case-mcp-bridge.adoc[] + *** xref:af-use-case-orchestration.adoc[] ** xref:agent-fabric-release-notes.adoc[] ** xref:agent-networks-get-started.adoc[] * xref:learning-map-api-management.adoc[API Management] diff --git a/modules/ROOT/pages/af-use-case-orchestration.adoc b/modules/ROOT/pages/af-use-case-orchestration.adoc new file mode 100644 index 000000000..b951a7986 --- /dev/null +++ b/modules/ROOT/pages/af-use-case-orchestration.adoc @@ -0,0 +1,196 @@ += Orchestrate Multi-Agent Processes with Agent Broker + +Agent brokers and agent networks coordinate task delegation across specialized agents with guided determinism, so complex business processes produce reliable, predictable outcomes. You define broker routing logic in Agent Script and configure the network composition in `agent-network.yaml`, bringing agents, LLMs, and MCP servers together in a single coordinated system. Use this approach when a single agent isn't enough — when a business process requires multiple specialized agents working in sequence or in parallel. + +Key benefits of agent networks and brokers include: + +* *Guided determinism*: Graph-based routing ensures specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. +* *Specialized coordination*: Route each task to the agent best suited to handle it, rather than building one agent that tries to do everything. +* *Reusable components*: Publish brokers and agent networks to your portfolio so other teams can discover and compose them into their own networks. +* *End-to-end observability*: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer. +* *Incremental composition*: Start with a simple agent network and add brokers as complexity grows. You don't need a broker to get started. + +== The Problem + +A single agent can handle straightforward tasks, but complex business processes expose the limits of working with one agent in isolation: + +* *Specialization gaps*: One agent can't excel at research, financial analysis, regulatory review, and customer communication simultaneously. +* *No intelligent routing*: Without a broker, there's no component to match an incoming request to the right specialist agent based on context. +* *Process reliability*: Multi-step processes that involve multiple agents and systems are difficult to make reliable and predictable without explicit coordination. +* *Opaque execution*: When something goes wrong in a multi-agent process, it's hard to know which agent failed, why, and what state the process was in. +* *Duplication*: Teams building similar multi-agent processes independently leads to inconsistent behavior and wasted effort. + +These challenges aren't solved by making a single agent smarter. They require a coordination layer — an agent network with a broker. + +== The Solution + +Agent Fabric's agent brokers and agent networks provide a coordination layer for multi-agent processes: + +* *Agent networks*: A YAML-configured composition of agents, brokers, LLMs, and MCP servers that defines the structure of your agentic solution. +* *Agent brokers*: Intelligent routing services, defined in Agent Script, that delegate tasks to the right A2A-compliant agent based on context. +* *Guided determinism*: Graph-based broker logic ensures tasks follow defined paths, handling both expected outcomes and error conditions. +* *Portfolio integration*: Published agent networks and brokers appear in your portfolio for discovery and reuse across your organization. +* *Integrated observability*: Agent Visualizer displays the network topology, real-time request flows, and performance metrics for the entire network. + +== How Agent Brokers Work + +When a request arrives at a broker, it follows this path: + +. A request arrives at the broker, either from an external caller or from another broker higher in the network. +. The broker evaluates the request against its routing logic, defined as a graph of nodes in Agent Script. +. The broker generates a context ID and task ID to track state across the interaction. +. The broker delegates the task to the A2A-compliant agent or sub-broker best suited to handle it. +. The assigned agent processes the task, calling LLMs and MCP servers as needed. +. Results return to the broker, which continues routing through the graph until the process is complete. +. The broker returns the final result to the original caller. + +== Who This Is For + +Agent brokers and agent networks are for: + +* Teams building multi-agent solutions where tasks must be routed across specialized agents based on context +* Organizations that need reliable, predictable outcomes from complex processes spanning multiple agents and systems +* Architects designing reusable agentic components that other teams can discover and compose +* Teams that need end-to-end visibility into how multi-agent processes execute and where failures occur + +== Example Scenarios + +=== Scenario 1: Order Processing + +*Challenge:* Processing customer orders involves checking inventory, routing to fulfillment, handling payment, and sending confirmation — each step handled by a specialized agent. Without coordination, the process is fragile and hard to monitor. + +With agent brokers and agent networks, you get reliable coordination with clear routing logic: + +. Define an agent network in `agent-network.yaml` that registers a broker, an inventory agent, a payment agent, and a fulfillment agent. +. Define the broker in Agent Script with nodes for each step and explicit routing logic for inventory shortfalls, payment failures, and partial fulfillment. +. Deploy the agent network to CloudHub 2.0. +. Monitor execution in Agent Visualizer to trace each step and identify where issues occur. + +=== Scenario 2: Multi-Discipline Research + +*Challenge:* Answering a strategic research question requires market analysis, competitive intelligence, technical feasibility assessment, and financial modeling — capabilities that belong in separate specialized agents. + +With an agent network, a broker decomposes the request and coordinates the specialists: + +. Define an agent network that registers market, competitive, technical, and financial analysis agents alongside a synthesis agent. +. Define a broker in Agent Script that routes each sub-question to the appropriate specialist agent, then routes all results to the synthesis agent. +. The synthesis agent produces the final report from the aggregated specialist outputs. +. Agent Visualizer shows the routing path, which agents were called, and where time was spent. + +=== Scenario 3: Document Processing Pipeline + +*Challenge:* Processing incoming documents requires classification, data extraction, quality validation, and routing for human review — in sequence, with defined rules for what happens when quality thresholds aren't met. + +With guided determinism in Agent Script: + +. Define an agent network that includes a classification agent, an extraction agent, and a review routing agent. +. Define a broker with nodes for each processing stage and explicit paths for low-confidence extractions that require human review. +. Deploy the network and monitor processing quality and throughput in Agent Visualizer. + +=== Scenario 4: Customer Support Triage + +*Challenge:* Incoming support requests range from simple account questions to complex technical issues and billing disputes. Each type requires a different specialized agent, and misrouting wastes time. + +With a broker handling intelligent triage: + +. Define a broker in Agent Script that classifies the incoming request and routes it to the appropriate specialist: account agent, technical agent, or billing agent. +. Each specialist agent calls the relevant MCP servers to retrieve customer data, account history, or billing records. +. The broker consolidates the specialist's response and returns it to the caller. +. Publish the agent network to your portfolio so other teams can reuse the triage broker. + +== Implementation Steps + +=== Step 1: Map the Process + +. List the steps in the process and identify which require specialized capabilities. +. Document decision points — where the process branches based on outcomes or data. +. Identify which steps can run in parallel and which must be sequential. +. Determine what backend systems each agent needs to call, and whether MCP servers already expose those systems. + +=== Step 2: Design the Agent Network + +. Decide which agents exist already and which need to be built. +. Determine whether a broker is needed. If the process involves multiple specialists that must be routed dynamically, add a broker. +. Sketch the broker graph: nodes represent steps, edges represent routing logic between them. +. Identify which LLMs agents use for reasoning and which MCP servers provide backend access. + +=== Step 3: Configure agent-network.yaml + +. In Anypoint Code Builder, create a new agent network project. +. Configure `agent-network.yaml` to declare the registry (agents and MCP servers), context (connections), and brokers. +. For each broker, create an Agent Script file (`.agent`) that defines the routing graph and node behavior. + +For more information, see xref:agent-network::af-define-your-agent-network-specification.adoc[Define Your Agent Network Specification]. + +=== Step 4: Deploy and Test + +. Deploy the agent network to CloudHub 2.0. +. Send test requests that exercise each routing path in the broker graph. +. Verify that each agent receives the tasks it is responsible for. +. Test failure paths — what happens when a backend system is unavailable or an agent returns an unexpected result. + +=== Step 5: Monitor with Agent Visualizer + +. Open Agent Visualizer to view the network topology and confirm that agents, brokers, and MCP servers are connected as expected. +. Send live requests and watch routing decisions in real time. +. Use performance metrics to identify latency, error rates, and bottlenecks. +. Review historical analysis to identify patterns and optimize routing logic. + +For more information, see xref:agent-visualizer::index.adoc[Agent Visualizer]. + +=== Step 6: Publish for Reuse + +. After validating the agent network, publish it to your portfolio. +. Other teams can discover the published broker and reuse it as a component in their own agent networks. +. Apply Omni Gateway policies to the broker endpoint to enforce authentication, rate limiting, and audit logging. + +See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. + +== Broker Design Patterns + +These patterns represent common approaches to structuring broker routing logic in Agent Script. + +[cols="1,2,2"] +|=== +| Pattern | Description | When to Use + +| Sequential Routing +| Route a request through a fixed sequence of specialist agents, where each agent's output is the input for the next. +| Steps must run in order and each step depends on the previous result. + +| Parallel Dispatch +| Dispatch a request to multiple specialist agents simultaneously and aggregate the results. +| Sub-tasks are independent and can run concurrently for faster completion. + +| Conditional Routing +| Route a request to different agents based on the content or classification of the request. +| The right specialist depends on context that isn't known until the request arrives. + +| Hierarchical Delegation +| A broker delegates to another broker, which in turn delegates to specialist agents. +| Complex processes can be decomposed into distinct sub-processes, each managed by its own broker. +|=== + +== Security Considerations + +When deploying agent networks and brokers in production: + +* Apply Omni Gateway policies to broker endpoints to enforce authentication, rate limiting, and audit logging. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. +* Ensure each specialist agent's MCP server connections use appropriate authentication. +* Review which agents have access to which backend systems and apply the principle of least privilege to MCP tool selection. +* Use Agent Visualizer to monitor for unexpected routing paths or anomalous agent behavior. + +== Related Documentation + +* xref:agent-network::af-agent-networks.adoc[Building Agent Networks for Agent Fabric] +* xref:agent-network::af-define-your-agent-network-specification.adoc[Define Your Agent Network Specification] +* xref:agent-visualizer::index.adoc[Agent Visualizer] +* xref:anypoint-code-builder::index.adoc[Anypoint Code Builder] + +== Next Steps + +With agent networks and brokers coordinating your multi-agent processes, you're ready to: + +* xref:use-case-policy-enforcement.adoc[Enforce consistent policies across all agents in the network] +* xref:use-case-identity.adoc[Add user identity context to agent interactions] +* xref:use-case-cost-control.adoc[Optimize LLM costs across the network with semantic routing] From f212598d60002407fe5066bd677b9262a5481125 Mon Sep 17 00:00:00 2001 From: Isaac Date: Tue, 4 Aug 2026 12:57:06 -0700 Subject: [PATCH 12/30] post-review edits --- .../ROOT/pages/af-use-case-orchestration.adoc | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-orchestration.adoc b/modules/ROOT/pages/af-use-case-orchestration.adoc index b951a7986..1c51d2de4 100644 --- a/modules/ROOT/pages/af-use-case-orchestration.adoc +++ b/modules/ROOT/pages/af-use-case-orchestration.adoc @@ -1,10 +1,10 @@ = Orchestrate Multi-Agent Processes with Agent Broker -Agent brokers and agent networks coordinate task delegation across specialized agents with guided determinism, so complex business processes produce reliable, predictable outcomes. You define broker routing logic in Agent Script and configure the network composition in `agent-network.yaml`, bringing agents, LLMs, and MCP servers together in a single coordinated system. Use this approach when a single agent isn't enough — when a business process requires multiple specialized agents working in sequence or in parallel. +Agent brokers and agent networks coordinate task delegation across specialized agents with guided determinism. This coordination produces reliable, predictable outcomes from complex business processes. You define broker routing logic in Agent Script and configure the network composition in agent-network.yaml. This file brings agents, LLMs, and MCP servers together in a single coordinated system. Use this approach hen a single agent can't handle the process and your business process requires multiple specialized agents working in sequence or in parallel. Key benefits of agent networks and brokers include: -* *Guided determinism*: Graph-based routing ensures specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. +* *Guided determinism*: Graph-based routing makes sure that specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. * *Specialized coordination*: Route each task to the agent best suited to handle it, rather than building one agent that tries to do everything. * *Reusable components*: Publish brokers and agent networks to your portfolio so other teams can discover and compose them into their own networks. * *End-to-end observability*: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer. @@ -18,9 +18,9 @@ A single agent can handle straightforward tasks, but complex business processes * *No intelligent routing*: Without a broker, there's no component to match an incoming request to the right specialist agent based on context. * *Process reliability*: Multi-step processes that involve multiple agents and systems are difficult to make reliable and predictable without explicit coordination. * *Opaque execution*: When something goes wrong in a multi-agent process, it's hard to know which agent failed, why, and what state the process was in. -* *Duplication*: Teams building similar multi-agent processes independently leads to inconsistent behavior and wasted effort. +* *Duplication*: Teams that build similar multi-agent processes independently create inconsistent behavior and duplicated effort. -These challenges aren't solved by making a single agent smarter. They require a coordination layer — an agent network with a broker. +Making a single agent smarter doesn't solve these challenges. They require a coordination layer—an agent network with a broker. == The Solution @@ -28,7 +28,7 @@ Agent Fabric's agent brokers and agent networks provide a coordination layer for * *Agent networks*: A YAML-configured composition of agents, brokers, LLMs, and MCP servers that defines the structure of your agentic solution. * *Agent brokers*: Intelligent routing services, defined in Agent Script, that delegate tasks to the right A2A-compliant agent based on context. -* *Guided determinism*: Graph-based broker logic ensures tasks follow defined paths, handling both expected outcomes and error conditions. +* *Guided determinism*: Graph-based broker logic makes sure that tasks follow defined paths, handling both expected outcomes and error conditions. * *Portfolio integration*: Published agent networks and brokers appear in your portfolio for discovery and reuse across your organization. * *Integrated observability*: Agent Visualizer displays the network topology, real-time request flows, and performance metrics for the entire network. @@ -48,8 +48,8 @@ When a request arrives at a broker, it follows this path: Agent brokers and agent networks are for: -* Teams building multi-agent solutions where tasks must be routed across specialized agents based on context -* Organizations that need reliable, predictable outcomes from complex processes spanning multiple agents and systems +* Teams building multi-agent solutions where tasks are routed across specialized agents based on context +* Companies that need reliable, predictable outcomes from complex processes spanning multiple agents and systems * Architects designing reusable agentic components that other teams can discover and compose * Teams that need end-to-end visibility into how multi-agent processes execute and where failures occur @@ -59,7 +59,7 @@ Agent brokers and agent networks are for: *Challenge:* Processing customer orders involves checking inventory, routing to fulfillment, handling payment, and sending confirmation — each step handled by a specialized agent. Without coordination, the process is fragile and hard to monitor. -With agent brokers and agent networks, you get reliable coordination with clear routing logic: +Agent brokers and agent networks provide reliable coordination with clear routing logic: . Define an agent network in `agent-network.yaml` that registers a broker, an inventory agent, a payment agent, and a fulfillment agent. . Define the broker in Agent Script with nodes for each step and explicit routing logic for inventory shortfalls, payment failures, and partial fulfillment. @@ -110,7 +110,7 @@ With a broker handling intelligent triage: === Step 2: Design the Agent Network . Decide which agents exist already and which need to be built. -. Determine whether a broker is needed. If the process involves multiple specialists that must be routed dynamically, add a broker. +. Determine whether a broker is needed. If the process involves multiple specialists that are routed dynamically, add a broker. . Sketch the broker graph: nodes represent steps, edges represent routing logic between them. . Identify which LLMs agents use for reasoning and which MCP servers provide backend access. @@ -127,7 +127,7 @@ For more information, see xref:agent-network::af-define-your-agent-network-speci . Deploy the agent network to CloudHub 2.0. . Send test requests that exercise each routing path in the broker graph. . Verify that each agent receives the tasks it is responsible for. -. Test failure paths — what happens when a backend system is unavailable or an agent returns an unexpected result. +. Test failure paths. === Step 5: Monitor with Agent Visualizer @@ -176,7 +176,7 @@ These patterns represent common approaches to structuring broker routing logic i When deploying agent networks and brokers in production: * Apply Omni Gateway policies to broker endpoints to enforce authentication, rate limiting, and audit logging. See xref:use-case-policy-enforcement.adoc[Policy Enforcement]. -* Ensure each specialist agent's MCP server connections use appropriate authentication. +* Make sure that each specialist agent's MCP server connections use appropriate authentication. * Review which agents have access to which backend systems and apply the principle of least privilege to MCP tool selection. * Use Agent Visualizer to monitor for unexpected routing paths or anomalous agent behavior. From 0abbeb69928b719cb60972f1961db14eedb7b2f9 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Wed, 5 Aug 2026 10:49:23 -0700 Subject: [PATCH 13/30] CX style review --- .../ROOT/pages/af-use-case-mcp-bridge.adoc | 59 +++++++++---------- 1 file changed, 28 insertions(+), 31 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 2004b4532..03ae79b1f 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -1,20 +1,20 @@ = Make APIs Agent-Ready with MCP Bridge -Agent Fabric's MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose as tools, limit agents to read operations where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. +Agent Fabric MCP Bridge transforms your existing API instances into agent-ready tools without touching code. Choose which operations to expose as tools, limit agents to read operations where needed, and make your Mule or API management investment immediately available to agents with the same governance policies you already use. Key benefits of MCP Bridge include: * Rapid enablement: Gets agents connected to APIs quickly, without custom development. * Security by default: Exposes only the operations you explicitly map as tools. * Consistency: Gives all agents access to APIs through the same controlled interface. -* Leverage existing investments: Works with APIs managed through Anypoint Platform. +* Reuse existing investments: Works with APIs managed through Anypoint Platform. * Centralized governance: Provides a single point of control for agent API access. == The Problem -You have invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: +You've invested heavily in API infrastructure, but adapting these APIs for agentic use is challenging: -* API complexity: Existing APIs weren't designed for agent consumption. +* API complexity: Existing APIs aren't designed for agent consumption. * Security concerns: APIs often include write and delete operations that are too risky for agents. * Integration overhead: Building custom integrations for each agent platform is time-consuming. * Inconsistent access: Different agents access the same APIs in different ways. @@ -24,14 +24,13 @@ Bridge your existing API infrastructure to agents safely and efficiently with MC == The Solution -Agent Fabric's Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: +Agent Fabric Model Context Protocol (MCP) Bridge enables safe, efficient API integration for agents: * Rapid integration: Connects existing API instances to agents through simple configuration, with no rewriting required. -* Selective exposure: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. -* Selective operation mapping: Map only the operations you choose as tools. Limit agent access to read-only operations when needed, without modifying the underlying API. +* Selective exposure: Exposes only the API operations you choose as discrete MCP tools that agents can discover and call. Limit agent access to read-only operations when needed, without modifying the underlying API. * Centralized management: Provides a single point of control for API access, with governance policies applied from the same portfolio. * Agent-facing abstraction: Exposes existing REST API operations as MCP tools so agents can call them without needing API-specific details. -* Leverage existing assets: Works with your existing MuleSoft API infrastructure without rebuilding assets. +* Reuse existing assets: Works with your existing MuleSoft API infrastructure without rebuilding assets. == How MCP Bridge Works @@ -42,7 +41,7 @@ Each agent request follows this path: . The AI agent makes a request using MCP. . The request flows through Omni Gateway, where MCP Bridge policies execute. . MCP Bridge maps the request to the underlying API operation. -. Only operations you exposed as MCP tools are reachable. +. Only operations you expose as MCP tools are reachable. . The call reaches the backend API. . Responses flow back through the gateway to the agent. @@ -54,7 +53,7 @@ MCP Bridge is ideal for: * Security teams concerned about agent access to sensitive operations * Integration teams looking to enable agents quickly without custom development * Architects who are designing safe agent access to enterprise systems -* Teams who want to leverage existing investments in API management and governance +* Teams who want to build on existing investments in API management and governance == Example Scenarios @@ -62,9 +61,9 @@ These scenarios demonstrate how different organizations use MCP Bridge to solve === Scenario 1: Customer Service Agent with Read-Only Access -*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you would need to build custom integrations for each agent platform. This risks exposure of write operations and creates inconsistent behavior across platforms. +*Challenge:* Customer service agents need to answer questions about customer accounts and orders but can't modify data. Without MCP Bridge, you build custom integrations for each agent platform. This approach risks exposing write operations and creates inconsistent behavior across platforms. -With MCP Bridge you get rapid deployment with built-in safety: +With MCP Bridge, you get rapid deployment with built-in safety: . In API Manager, create an MCP Bridge instance for your customer API. . Map only GET operations to MCP tools. @@ -75,9 +74,9 @@ With MCP Bridge you get rapid deployment with built-in safety: *Challenge:* Your inventory API includes operations to check stock levels, reserve items, adjust quantities, and process transfers. Sales agents, warehouse agents, and customer service agents all need to check current stock, but only warehouse systems should adjust it. -Without MCP Bridge, you would either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. +Without MCP Bridge, you either expose the full API (risking accidental adjustments) or build filtered endpoints for each agent type. -With MCP Bridge you give all agents read-only inventory access from a single configuration: +With MCP Bridge, you give all agents read-only inventory access from a single configuration: . In API Manager, create an MCP Bridge instance from the inventory API. . Map only GET operations for stock queries to MCP tools. @@ -88,9 +87,9 @@ With MCP Bridge you give all agents read-only inventory access from a single con *Challenge:* Different agents need different levels of access to financial APIs. -Without MCP Bridge, you would need to build separate custom integrations for each agent access level, creating duplication and increasing the risk that a high-privilege operation gets exposed to the wrong agent. +Without MCP Bridge, you build separate custom integrations for each agent access level. This duplication increases the risk that a high-privilege operation reaches the wrong agent. -With MCP Bridge you get fine-grained access control with safety guarantees: +With MCP Bridge, you get fine-grained access control with safety guarantees: . In API Manager, create multiple MCP Bridge instances from your financial API, each with different operation mappings: * Basic server: Map only GET operations for account balances. @@ -105,7 +104,7 @@ With MCP Bridge you get fine-grained access control with safety guarantees: Without MCP Bridge, you would need to build agent-specific adapters on top of each Mule API, duplicating logic and bypassing existing Anypoint Platform governance. -With MCP Bridge you extend your existing Mule investment to agentic use cases: +With MCP Bridge, you extend your existing Mule investment to agentic use cases: . In API Manager, create MCP Bridge instances for key Mule APIs. . Map the API operations you want to expose to MCP tools. @@ -114,8 +113,6 @@ With MCP Bridge you extend your existing Mule investment to agentic use cases: == Implementation Steps -Follow these steps to create MCP Bridge instances and make your APIs available to agents. - === Step 1: Identify APIs for Agent Access . List APIs that agents access. @@ -132,7 +129,7 @@ For each API instance, decide: * If agents require write access, which specific write operations do they use? * What Omni Gateway policies apply to the resulting MCP server? -=== Step 3: Create and Deploy MCP Bridge Instance +=== Step 3: Create and Deploy an MCP Bridge Instance . In API Manager, create an MCP Bridge instance for your target API. . Configure downstream settings (base path, protocol, port) and upstream settings (route label, upstream URL). @@ -144,7 +141,7 @@ For more information, see xref:api-manager::create-instance-task-mcp-bridge.adoc === Step 4: Apply Omni Gateway Policies -MCP Bridge controls which API operations are available as tools. Omni Gateway policies control how agents are allowed to use them at runtime. After deploying MCP Bridge, apply policies in API Manager to the MCP server instance to enforce authentication, rate limiting, audit logging, and alerting. +MCP Bridge controls which API operations are available as tools. Omni Gateway policies control how agents can use them at runtime. After deploying MCP Bridge, apply policies in API Manager to the MCP server instance to enforce authentication, rate limiting, audit logging, and alerting. See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation steps. @@ -152,22 +149,22 @@ See xref:use-case-policy-enforcement.adoc[Policy Enforcement] for implementation . Update agents to use MCP Bridge. . Test with realistic scenarios. -. Verify that tool selection is working (agents can only call the operations you exposed). +. Verify that tool selection works (agents can only call the operations you expose). . Monitor initial usage. === Step 6: Monitor and Refine . In the enhanced MuleSoft experience, review latency, error rates, and request volume for your MCP server. -. Analyze which tools agents are calling and identify missing operations. +. Analyze which tools agents call and identify missing operations. . Check gateway logs for attempts to call unexposed operations. -. If you need to change tool mappings, create a new MCP Bridge instance with the updated configuration in API Manager. MCP Bridge instances are immutable after deployment. +. To change tool mappings, create a new MCP Bridge instance with the updated configuration in API Manager. MCP Bridge instances are immutable after deployment. For information about monitoring MCP servers and other services, see xref:exp-services-monitoring.adoc[]. == Tool Selection Strategies -MCP Bridge lets you choose which API operations to expose as discrete MCP tools that agents can discover and call. During configuration, you map specific operations (HTTP method and resource) to tools. Expose all operations, only read operations, or any subset you choose, without modifying the underlying API. +Choose which API operations to expose as discrete MCP tools that agents can discover and call. During configuration, you map specific operations (HTTP method and resource) to tools. Expose all operations, only read operations, or any subset you choose, without modifying the underlying API. Consider a Customer API with both read and write operations: @@ -195,7 +192,7 @@ The agent can read customer and order data but can't create, modify, or delete a === Read-Only Operation Mapping -Start by mapping only GET/read operations to tools. Explicitly map write operations only when a use case requires them. +Map only GET/read operations to tools first. Explicitly map write operations only when a use case requires them. === Operation Allowlisting @@ -250,7 +247,7 @@ Use this pattern when agents initiate a workflow (for example, submitting an app === Granular Tool Surface -Use this pattern for fine-grained control, exposing specific safe operations and blocking others based on individual business risk assessments. For example, expose GET /orders/{id} to allow agents to view order details, but block PUT /orders/{id}/status to prevent agents from changing order status. This gives agents access to the information they need while protecting sensitive operations. +Use this pattern for fine-grained control, exposing specific safe operations and blocking others based on individual business risk assessments. For example, expose GET /orders/{id} so agents can view order details, but block PUT /orders/{id}/status to prevent agents from changing order status. This pattern gives agents access to the information they need while protecting sensitive operations. [source,text] ---- @@ -274,20 +271,20 @@ Apply Omni Gateway policies to enable audit logging and monitor MCP server usage Periodically review: -* Which operations are actually being used +* Which operations are in use * Whether your tool selection is still appropriate -* Whether additional operations should be removed from the agent tool list +* Whether to remove additional operations from the agent tool list == Integration with Existing Tools -MCP Bridge integrates with your existing MuleSoft infrastructure, identity systems, and gateway deployment to leverage investments you have already made. +MCP Bridge integrates with your existing MuleSoft infrastructure, identity systems, and gateway deployment to build on investments you've already made. === Mule Integration MCP Bridge works directly with Mule APIs managed in Anypoint Platform, so you can expose existing Mule API instances as MCP servers without rebuilding them. * Use MCP Bridge with existing Mule APIs. -* Leverage Anypoint Platform governance. +* Use Anypoint Platform governance. * Extend Mule monitoring to agent access. * Reuse existing API policies. From 0d419c209e672a2a3113b038ff06b7f8e1679d37 Mon Sep 17 00:00:00 2001 From: Isaac Eldridge Date: Fri, 7 Aug 2026 09:39:48 -0700 Subject: [PATCH 14/30] Apply suggestions from peer review Co-authored-by: Valkyrie Hunter --- modules/ROOT/pages/af-use-case-orchestration.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-orchestration.adoc b/modules/ROOT/pages/af-use-case-orchestration.adoc index 1c51d2de4..6a1e60098 100644 --- a/modules/ROOT/pages/af-use-case-orchestration.adoc +++ b/modules/ROOT/pages/af-use-case-orchestration.adoc @@ -1,6 +1,6 @@ = Orchestrate Multi-Agent Processes with Agent Broker -Agent brokers and agent networks coordinate task delegation across specialized agents with guided determinism. This coordination produces reliable, predictable outcomes from complex business processes. You define broker routing logic in Agent Script and configure the network composition in agent-network.yaml. This file brings agents, LLMs, and MCP servers together in a single coordinated system. Use this approach hen a single agent can't handle the process and your business process requires multiple specialized agents working in sequence or in parallel. +Agent brokers and agent networks coordinate task delegation across specialized agents with guided determinism. This coordination produces reliable, predictable outcomes from complex business processes. You define broker routing logic in Agent Script and configure the network composition in `agent-network.yaml`. This file brings agents, LLMs, and MCP servers together in a single coordinated system. Use this approach when a single agent can't handle the process and your business process requires multiple specialized agents working in sequence or in parallel. Key benefits of agent networks and brokers include: @@ -57,7 +57,7 @@ Agent brokers and agent networks are for: === Scenario 1: Order Processing -*Challenge:* Processing customer orders involves checking inventory, routing to fulfillment, handling payment, and sending confirmation — each step handled by a specialized agent. Without coordination, the process is fragile and hard to monitor. +*Challenge:* Processing customer orders involves checking inventory, routing to fulfillment, handling payment, and sending confirmation. Each step is handled by a specialized agent. Without coordination, the process is fragile and hard to monitor. Agent brokers and agent networks provide reliable coordination with clear routing logic: @@ -103,13 +103,13 @@ With a broker handling intelligent triage: === Step 1: Map the Process . List the steps in the process and identify which require specialized capabilities. -. Document decision points — where the process branches based on outcomes or data. +. Document decision points such as where the process branches based on outcomes or data. . Identify which steps can run in parallel and which must be sequential. . Determine what backend systems each agent needs to call, and whether MCP servers already expose those systems. === Step 2: Design the Agent Network -. Decide which agents exist already and which need to be built. +. Identify which agents exist and which to build. . Determine whether a broker is needed. If the process involves multiple specialists that are routed dynamically, add a broker. . Sketch the broker graph: nodes represent steps, edges represent routing logic between them. . Identify which LLMs agents use for reasoning and which MCP servers provide backend access. @@ -191,6 +191,6 @@ When deploying agent networks and brokers in production: With agent networks and brokers coordinating your multi-agent processes, you're ready to: -* xref:use-case-policy-enforcement.adoc[Enforce consistent policies across all agents in the network] +* xref:af-use-case-policy-enforcement.adoc[Enforce consistent policies across all agents in the network] * xref:use-case-identity.adoc[Add user identity context to agent interactions] * xref:use-case-cost-control.adoc[Optimize LLM costs across the network with semantic routing] From acd4eefb46df221b317f89f153f2e9a154cd3aae Mon Sep 17 00:00:00 2001 From: Isaac Date: Fri, 7 Aug 2026 09:50:50 -0700 Subject: [PATCH 15/30] peer review edits --- .../ROOT/pages/af-use-case-orchestration.adoc | 36 +++++++++---------- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-orchestration.adoc b/modules/ROOT/pages/af-use-case-orchestration.adoc index 6a1e60098..3f93c6799 100644 --- a/modules/ROOT/pages/af-use-case-orchestration.adoc +++ b/modules/ROOT/pages/af-use-case-orchestration.adoc @@ -4,21 +4,21 @@ Agent brokers and agent networks coordinate task delegation across specialized a Key benefits of agent networks and brokers include: -* *Guided determinism*: Graph-based routing makes sure that specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. -* *Specialized coordination*: Route each task to the agent best suited to handle it, rather than building one agent that tries to do everything. -* *Reusable components*: Publish brokers and agent networks to your portfolio so other teams can discover and compose them into their own networks. -* *End-to-end observability*: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer. -* *Incremental composition*: Start with a simple agent network and add brokers as complexity grows. You don't need a broker to get started. +* Guided determinism: Graph-based routing makes sure that specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. +* Specialized coordination: Route each task to the agent best suited to handle it, rather than building one agent that tries to do everything. +* Reusable components: Publish brokers and agent networks to your portfolio so other teams can discover and compose them into their own networks. +* End-to-end observability: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer. +* Incremental composition: Start with a simple agent network and add brokers as complexity grows. You don't need a broker to get started. == The Problem A single agent can handle straightforward tasks, but complex business processes expose the limits of working with one agent in isolation: -* *Specialization gaps*: One agent can't excel at research, financial analysis, regulatory review, and customer communication simultaneously. -* *No intelligent routing*: Without a broker, there's no component to match an incoming request to the right specialist agent based on context. -* *Process reliability*: Multi-step processes that involve multiple agents and systems are difficult to make reliable and predictable without explicit coordination. -* *Opaque execution*: When something goes wrong in a multi-agent process, it's hard to know which agent failed, why, and what state the process was in. -* *Duplication*: Teams that build similar multi-agent processes independently create inconsistent behavior and duplicated effort. +* Specialization gaps: One agent can't excel at research, financial analysis, regulatory review, and customer communication simultaneously. +* No intelligent routing: Without a broker, there's no component to match an incoming request to the right specialist agent based on context. +* Process reliability: Multi-step processes that involve multiple agents and systems are difficult to make reliable and predictable without explicit coordination. +* Opaque execution: When something goes wrong in a multi-agent process, it's hard to know which agent failed, why, and what state the process was in. +* Duplication: Teams that build similar multi-agent processes independently create inconsistent behavior and duplicated effort. Making a single agent smarter doesn't solve these challenges. They require a coordination layer—an agent network with a broker. @@ -26,11 +26,11 @@ Making a single agent smarter doesn't solve these challenges. They require a coo Agent Fabric's agent brokers and agent networks provide a coordination layer for multi-agent processes: -* *Agent networks*: A YAML-configured composition of agents, brokers, LLMs, and MCP servers that defines the structure of your agentic solution. -* *Agent brokers*: Intelligent routing services, defined in Agent Script, that delegate tasks to the right A2A-compliant agent based on context. -* *Guided determinism*: Graph-based broker logic makes sure that tasks follow defined paths, handling both expected outcomes and error conditions. -* *Portfolio integration*: Published agent networks and brokers appear in your portfolio for discovery and reuse across your organization. -* *Integrated observability*: Agent Visualizer displays the network topology, real-time request flows, and performance metrics for the entire network. +* Agent networks: A YAML-configured composition of agents, brokers, LLMs, and MCP servers that defines the structure of your agentic solution. +* Agent brokers: Intelligent routing services, defined in Agent Script, that delegate tasks to the right A2A-compliant agent based on context. +* Guided determinism: Graph-based broker logic makes sure that tasks follow defined paths, handling both expected outcomes and error conditions. +* Anypoint Exchange integration: Published agent networks and brokers appear in Exchange for discovery and reuse across your organization. +* Integrated observability: Agent Visualizer displays the network topology, real-time request flows, and performance metrics for the entire network. == How Agent Brokers Work @@ -73,7 +73,7 @@ Agent brokers and agent networks provide reliable coordination with clear routin With an agent network, a broker decomposes the request and coordinates the specialists: . Define an agent network that registers market, competitive, technical, and financial analysis agents alongside a synthesis agent. -. Define a broker in Agent Script that routes each sub-question to the appropriate specialist agent, then routes all results to the synthesis agent. +. Define a broker in Agent Script that routes each research sub-task to the appropriate specialist agent, then routes all results to the synthesis agent. . The synthesis agent produces the final report from the aggregated specialist outputs. . Agent Visualizer shows the routing path, which agents were called, and where time was spent. @@ -96,7 +96,7 @@ With a broker handling intelligent triage: . Define a broker in Agent Script that classifies the incoming request and routes it to the appropriate specialist: account agent, technical agent, or billing agent. . Each specialist agent calls the relevant MCP servers to retrieve customer data, account history, or billing records. . The broker consolidates the specialist's response and returns it to the caller. -. Publish the agent network to your portfolio so other teams can reuse the triage broker. +. Publish the agent network to Exchange so other teams can reuse the triage broker. == Implementation Steps @@ -140,7 +140,7 @@ For more information, see xref:agent-visualizer::index.adoc[Agent Visualizer]. === Step 6: Publish for Reuse -. After validating the agent network, publish it to your portfolio. +. After validating the agent network, publish it to Exchange. . Other teams can discover the published broker and reuse it as a component in their own agent networks. . Apply Omni Gateway policies to the broker endpoint to enforce authentication, rate limiting, and audit logging. From ed0784677651033e527bb55f9204546e871ded95 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 7 Aug 2026 11:22:31 -0700 Subject: [PATCH 16/30] Updating xrefs --- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index 03ae79b1f..c6e8a32b4 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -306,15 +306,11 @@ MCP Bridge can work with existing identity infrastructure so that agent access t == Related Documentation -// TODO: Update these links when Agent Fabric documentation is published. -* link:https://docs.mulesoft.com/agent-fabric/mcp-bridge[MCP Bridge Documentation] -* link:https://docs.mulesoft.com/agent-fabric/api-pruning[Selecting Operations to Expose as Tools] -* link:https://docs.mulesoft.com/agent-fabric/mule-integration[Integrating with Mule] +* xref:agent-fabric-use-cases.adoc[] == Next Steps With MCP Bridge providing safe API access, you're ready to: -* xref:use-case-policy-enforcement.adoc[Add additional policy enforcement] -* xref:use-case-identity.adoc[Implement user-scoped API access] -* xref:use-case-orchestration.adoc[Build workflows using bridged APIs] +* xref:af-use-case-policy-enforcement.adoc[Apply Omni Gateway policies to broker endpoints] +* xref:af-use-case-orchestration.adoc[Build agent networks] From 267be62a3df9a9dda738aae9f69420854dfc9bf8 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 14 Aug 2026 15:47:19 -0700 Subject: [PATCH 17/30] W-23533642 Cost Management Use Case --- .../pages/af-use-case-cost-management.adoc | 212 ++++++++++++++++++ 1 file changed, 212 insertions(+) create mode 100644 modules/ROOT/pages/af-use-case-cost-management.adoc diff --git a/modules/ROOT/pages/af-use-case-cost-management.adoc b/modules/ROOT/pages/af-use-case-cost-management.adoc new file mode 100644 index 000000000..7d8acf704 --- /dev/null +++ b/modules/ROOT/pages/af-use-case-cost-management.adoc @@ -0,0 +1,212 @@ += Control LLM Costs in Agent Fabric + +Agent Fabric gives you full visibility into token consumption and spend across every model call, and the controls to enforce limits before usage compounds. Use Model Wallets to set hard limits in tokens or dollars that agents can't exceed, and attribute every token and dollar to the team, application, or agent that generated them. + +Key benefits include: + +* Full cost visibility: See token consumption and spend by application, agent, user, and model in one place. +* Cost-optimized routing: Route each request to the right model at the right cost with semantic routing. +* Enforced budgets: Cap token or spend usage with Model Wallets that block requests when a budget limit is reached. +* Consistent governance: Apply the same policies, prompt protection, and automatic fallback across every provider. +* Cost attribution: Trace every token and dollar to the team, application, or agent that drove them. + +== The Problem + +As agentic systems scale, LLM costs can quickly spiral out of control without proper visibility and enforcement: + +* Unpredictable costs: Token usage varies widely based on agent behavior and queries. +* No visibility: Costs can't be attributed to specific applications, agents, or users. +* Inefficient model usage: Expensive models handle simple queries that cheaper models could address. +* Budget overruns: Nothing enforces the budget, so a number in the plan isn't a real limit. +* No optimization path: Without data on usage patterns, optimization is guesswork. + +Gain visibility into what's driving costs and the controls to optimize spending without sacrificing quality. + +== The Solution + +Agent Fabric provides comprehensive cost management for agentic AI through the Model Proxy: + +* Usage visibility: Tracks token consumption by application, agent, user, and model. +* Semantic routing: Routes each query to the appropriate model based on complexity, automatically. +* Budget enforcement: Caps token or spend usage with Model Wallets that block requests when a budget limit is reached. +* Model optimization: Provides data-driven insight into which models are used for which tasks. +* Cost attribution: Shows exactly what's driving your spend, down to the team, app, or agent. + +== How Semantic Routing Works + +Not all queries require the most powerful (and most expensive) AI models. Semantic routing analyzes query complexity and routes each request appropriately: + +[source,text] +---- +Simple query: "What's the status of order #12345?" +→ Route to: Fast, cost-effective model + +Complex query: "Analyze this quarter's sales trends, identify anomalies, and recommend strategic adjustments" +→ Route to: Powerful, higher-cost model +---- + +The Model Proxy makes these routing decisions automatically based on configurable rules, maintaining quality while minimizing cost. + +== How Model Wallets Enforce Usage Limits + +Budget alerts tell you when you've overrun a limit. They don't stop it. By the time an alert fires at 90 percent of budget, an agent running unattended can push token or spend usage far past the limit before anyone reads the notification. + +A Model Wallet closes that gap by turning a budget from a number in a plan into a financial control that agents can't overrun: + +* Hard limits: Set enforced token or spend limits per provider so that when a budget reaches its limit, requests are blocked rather than flagged. +* Periodic caps: Set a daily, weekly, or monthly limit that resets automatically on a schedule, so token or spend usage stays bounded each period. +* Flexible metrics: Set limits in dollars (USD) or tokens, so budgets reflect the metric that matters most to your team. +* Identity-scoped controls: Tie usage controls to a Model Proxy's client identity so that each application or agent routes through its own governed access point with dedicated budget limits. + +Model Wallets build on the Model Proxy. The proxy provides one governed access point for every provider, making token consumption and spend visible; Model Wallets add the enforcement layer on top, so the usage you can see is also usage you can cap. + +== Who This Is For + +These cost management capabilities are ideal for: + +* FinOps teams managing cloud and AI spending +* Engineering leaders optimizing infrastructure costs +* Product teams building cost-effective agentic features +* Enterprises scaling agent deployments beyond proof of concept +* Any organization where LLM costs are a significant budget item + +== Example Scenarios + +These scenarios demonstrate how different organizations use Agent Fabric to bring LLM costs under control. + +=== Scenario 1: Enterprise-Wide Cost Visibility + +*Challenge:* A large organization has agents deployed across multiple business units but no visibility into which ones are driving LLM costs. + +With Agent Fabric you get complete cost visibility: + +. Route all LLM traffic through the Model Proxy. +. Tag requests by business unit, application, and agent. +. Generate cost dashboards showing usage patterns. +. Identify high-cost agents and opportunities for optimization. + +=== Scenario 2: Semantic Routing for Customer Support + +*Challenge:* A customer support agent system uses expensive models for all queries, including simple lookups. + +With semantic routing you cut cost without sacrificing quality: + +. Configure semantic routing rules: + * Simple queries (order status, account lookups) route to a cost-effective model. + * Complex queries (troubleshooting, technical issues) route to an advanced model. +. The Model Proxy analyzes each request and routes it appropriately. +. Monitor quality metrics to ensure the customer experience isn't impacted. + +=== Scenario 3: Budget Controls for Development Teams + +*Challenge:* Development teams experimenting with agents have no spending limits, leading to budget surprises. + +With Model Wallets you get budgets agents can't overrun: + +. Create a separate Model Proxy for each team, with budget limits configured per provider. +. Set a daily, weekly, or monthly limit in dollars (USD) or tokens depending on how the team tracks spend. +. Enable hard limits so requests are blocked when a budget is reached rather than allowed to overrun. +. Give teams visibility into budget consumption through the Model Proxy dashboard. + +=== Scenario 4: Multi-Model Optimization + +*Challenge:* An organization uses multiple LLM providers but doesn't know which models are most cost-effective for its use cases. + +With Agent Fabric you get evidence-based model selection: + +. Deploy agents with flexible model configuration. +. Agent Fabric tracks cost and quality metrics per model. +. Analyze which models deliver the best cost/quality ratio for each use case. +. Adjust routing rules based on the data. + +== Implementation Steps + +Follow these steps to set up cost management in Agent Fabric. + +=== Step 1: Deploy the Model Proxy + +. Set up the Model Proxy as part of your Omni Gateway deployment. +. Configure integration with your LLM providers. +. Route agent traffic through the Model Proxy. + +=== Step 2: Implement Usage Tracking + +. Tag all requests with relevant metadata: + * Business unit or cost center + * Application name + * Agent identifier + * User or session ID +. Configure logging and metrics collection. +. Set up dashboards for cost visibility. + +=== Step 3: Establish Baseline Costs + +. Monitor usage patterns for one to two weeks without optimization. +. Identify current cost drivers. +. Categorize query types by complexity and frequency. +. Calculate baseline cost metrics. + +=== Step 4: Configure Semantic Routing + +. Define query complexity categories. +. Assign an appropriate model to each category. +. Create routing rules in the Model Proxy. +. Test routing with sample queries to ensure quality. + +=== Step 5: Set Budget Controls with Model Wallets + +. Create a Model Proxy per team, application, or agent to scope budget controls to a client identity. +. Add a budget for each provider the Model Proxy routes to, choosing a daily, weekly, or monthly period. +. Set the limit in dollars (USD) or tokens, and enable hard limits where overruns are unacceptable so requests are blocked when a limit is reached. +. Share the Model Proxy dashboard with teams so they can track budget consumption per provider. + +=== Step 6: Monitor and Optimize + +. Track cost trends after optimization. +. Monitor quality metrics to ensure no degradation. +. Refine routing rules based on results. +. Share cost savings and optimization wins. + +== Metrics to Track + +Track these metrics to measure and improve the impact of cost control. + +=== Cost Metrics + +* Total token usage by time period +* Cost per application, agent, and user +* Cost per model and provider +* Average cost per query + +=== Usage Metrics + +* Queries per time period +* Model distribution (which models handle what percentage of queries) +* Token usage distribution by query complexity +* Peak usage times and patterns + +=== Quality Metrics + +* Response quality scores +* User satisfaction ratings +* Error rates by model +* Average response time by model + +=== Optimization Metrics + +* Cost savings from semantic routing +* Percentage of queries routed to cost-effective models +* Budget adherence by team and application +* ROI of optimization efforts + +== Related Documentation + +* xref:agent-fabric-use-cases.adoc[] + +== Next Steps + +With cost controls in place, you're ready to: + +* xref:af-use-case-policy-enforcement.adoc[Add policy enforcement for governance] +* xref:use-case-orchestration.adoc[Build complex workflows with cost awareness] +* xref:use-case-identity.adoc[Move to production with identity and cost controls] From dc574e5355e7386fa15b0def9d94cfe71020f6a4 Mon Sep 17 00:00:00 2001 From: Valkyrie Hunter Date: Fri, 14 Aug 2026 15:48:57 -0700 Subject: [PATCH 18/30] Delete modules/ROOT/pages/af-use-case-cost-management.adoc --- .../pages/af-use-case-cost-management.adoc | 212 ------------------ 1 file changed, 212 deletions(-) delete mode 100644 modules/ROOT/pages/af-use-case-cost-management.adoc diff --git a/modules/ROOT/pages/af-use-case-cost-management.adoc b/modules/ROOT/pages/af-use-case-cost-management.adoc deleted file mode 100644 index 7d8acf704..000000000 --- a/modules/ROOT/pages/af-use-case-cost-management.adoc +++ /dev/null @@ -1,212 +0,0 @@ -= Control LLM Costs in Agent Fabric - -Agent Fabric gives you full visibility into token consumption and spend across every model call, and the controls to enforce limits before usage compounds. Use Model Wallets to set hard limits in tokens or dollars that agents can't exceed, and attribute every token and dollar to the team, application, or agent that generated them. - -Key benefits include: - -* Full cost visibility: See token consumption and spend by application, agent, user, and model in one place. -* Cost-optimized routing: Route each request to the right model at the right cost with semantic routing. -* Enforced budgets: Cap token or spend usage with Model Wallets that block requests when a budget limit is reached. -* Consistent governance: Apply the same policies, prompt protection, and automatic fallback across every provider. -* Cost attribution: Trace every token and dollar to the team, application, or agent that drove them. - -== The Problem - -As agentic systems scale, LLM costs can quickly spiral out of control without proper visibility and enforcement: - -* Unpredictable costs: Token usage varies widely based on agent behavior and queries. -* No visibility: Costs can't be attributed to specific applications, agents, or users. -* Inefficient model usage: Expensive models handle simple queries that cheaper models could address. -* Budget overruns: Nothing enforces the budget, so a number in the plan isn't a real limit. -* No optimization path: Without data on usage patterns, optimization is guesswork. - -Gain visibility into what's driving costs and the controls to optimize spending without sacrificing quality. - -== The Solution - -Agent Fabric provides comprehensive cost management for agentic AI through the Model Proxy: - -* Usage visibility: Tracks token consumption by application, agent, user, and model. -* Semantic routing: Routes each query to the appropriate model based on complexity, automatically. -* Budget enforcement: Caps token or spend usage with Model Wallets that block requests when a budget limit is reached. -* Model optimization: Provides data-driven insight into which models are used for which tasks. -* Cost attribution: Shows exactly what's driving your spend, down to the team, app, or agent. - -== How Semantic Routing Works - -Not all queries require the most powerful (and most expensive) AI models. Semantic routing analyzes query complexity and routes each request appropriately: - -[source,text] ----- -Simple query: "What's the status of order #12345?" -→ Route to: Fast, cost-effective model - -Complex query: "Analyze this quarter's sales trends, identify anomalies, and recommend strategic adjustments" -→ Route to: Powerful, higher-cost model ----- - -The Model Proxy makes these routing decisions automatically based on configurable rules, maintaining quality while minimizing cost. - -== How Model Wallets Enforce Usage Limits - -Budget alerts tell you when you've overrun a limit. They don't stop it. By the time an alert fires at 90 percent of budget, an agent running unattended can push token or spend usage far past the limit before anyone reads the notification. - -A Model Wallet closes that gap by turning a budget from a number in a plan into a financial control that agents can't overrun: - -* Hard limits: Set enforced token or spend limits per provider so that when a budget reaches its limit, requests are blocked rather than flagged. -* Periodic caps: Set a daily, weekly, or monthly limit that resets automatically on a schedule, so token or spend usage stays bounded each period. -* Flexible metrics: Set limits in dollars (USD) or tokens, so budgets reflect the metric that matters most to your team. -* Identity-scoped controls: Tie usage controls to a Model Proxy's client identity so that each application or agent routes through its own governed access point with dedicated budget limits. - -Model Wallets build on the Model Proxy. The proxy provides one governed access point for every provider, making token consumption and spend visible; Model Wallets add the enforcement layer on top, so the usage you can see is also usage you can cap. - -== Who This Is For - -These cost management capabilities are ideal for: - -* FinOps teams managing cloud and AI spending -* Engineering leaders optimizing infrastructure costs -* Product teams building cost-effective agentic features -* Enterprises scaling agent deployments beyond proof of concept -* Any organization where LLM costs are a significant budget item - -== Example Scenarios - -These scenarios demonstrate how different organizations use Agent Fabric to bring LLM costs under control. - -=== Scenario 1: Enterprise-Wide Cost Visibility - -*Challenge:* A large organization has agents deployed across multiple business units but no visibility into which ones are driving LLM costs. - -With Agent Fabric you get complete cost visibility: - -. Route all LLM traffic through the Model Proxy. -. Tag requests by business unit, application, and agent. -. Generate cost dashboards showing usage patterns. -. Identify high-cost agents and opportunities for optimization. - -=== Scenario 2: Semantic Routing for Customer Support - -*Challenge:* A customer support agent system uses expensive models for all queries, including simple lookups. - -With semantic routing you cut cost without sacrificing quality: - -. Configure semantic routing rules: - * Simple queries (order status, account lookups) route to a cost-effective model. - * Complex queries (troubleshooting, technical issues) route to an advanced model. -. The Model Proxy analyzes each request and routes it appropriately. -. Monitor quality metrics to ensure the customer experience isn't impacted. - -=== Scenario 3: Budget Controls for Development Teams - -*Challenge:* Development teams experimenting with agents have no spending limits, leading to budget surprises. - -With Model Wallets you get budgets agents can't overrun: - -. Create a separate Model Proxy for each team, with budget limits configured per provider. -. Set a daily, weekly, or monthly limit in dollars (USD) or tokens depending on how the team tracks spend. -. Enable hard limits so requests are blocked when a budget is reached rather than allowed to overrun. -. Give teams visibility into budget consumption through the Model Proxy dashboard. - -=== Scenario 4: Multi-Model Optimization - -*Challenge:* An organization uses multiple LLM providers but doesn't know which models are most cost-effective for its use cases. - -With Agent Fabric you get evidence-based model selection: - -. Deploy agents with flexible model configuration. -. Agent Fabric tracks cost and quality metrics per model. -. Analyze which models deliver the best cost/quality ratio for each use case. -. Adjust routing rules based on the data. - -== Implementation Steps - -Follow these steps to set up cost management in Agent Fabric. - -=== Step 1: Deploy the Model Proxy - -. Set up the Model Proxy as part of your Omni Gateway deployment. -. Configure integration with your LLM providers. -. Route agent traffic through the Model Proxy. - -=== Step 2: Implement Usage Tracking - -. Tag all requests with relevant metadata: - * Business unit or cost center - * Application name - * Agent identifier - * User or session ID -. Configure logging and metrics collection. -. Set up dashboards for cost visibility. - -=== Step 3: Establish Baseline Costs - -. Monitor usage patterns for one to two weeks without optimization. -. Identify current cost drivers. -. Categorize query types by complexity and frequency. -. Calculate baseline cost metrics. - -=== Step 4: Configure Semantic Routing - -. Define query complexity categories. -. Assign an appropriate model to each category. -. Create routing rules in the Model Proxy. -. Test routing with sample queries to ensure quality. - -=== Step 5: Set Budget Controls with Model Wallets - -. Create a Model Proxy per team, application, or agent to scope budget controls to a client identity. -. Add a budget for each provider the Model Proxy routes to, choosing a daily, weekly, or monthly period. -. Set the limit in dollars (USD) or tokens, and enable hard limits where overruns are unacceptable so requests are blocked when a limit is reached. -. Share the Model Proxy dashboard with teams so they can track budget consumption per provider. - -=== Step 6: Monitor and Optimize - -. Track cost trends after optimization. -. Monitor quality metrics to ensure no degradation. -. Refine routing rules based on results. -. Share cost savings and optimization wins. - -== Metrics to Track - -Track these metrics to measure and improve the impact of cost control. - -=== Cost Metrics - -* Total token usage by time period -* Cost per application, agent, and user -* Cost per model and provider -* Average cost per query - -=== Usage Metrics - -* Queries per time period -* Model distribution (which models handle what percentage of queries) -* Token usage distribution by query complexity -* Peak usage times and patterns - -=== Quality Metrics - -* Response quality scores -* User satisfaction ratings -* Error rates by model -* Average response time by model - -=== Optimization Metrics - -* Cost savings from semantic routing -* Percentage of queries routed to cost-effective models -* Budget adherence by team and application -* ROI of optimization efforts - -== Related Documentation - -* xref:agent-fabric-use-cases.adoc[] - -== Next Steps - -With cost controls in place, you're ready to: - -* xref:af-use-case-policy-enforcement.adoc[Add policy enforcement for governance] -* xref:use-case-orchestration.adoc[Build complex workflows with cost awareness] -* xref:use-case-identity.adoc[Move to production with identity and cost controls] From 7f5fb104da40376ae60c090c6cdc1663cd1372b4 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 14 Aug 2026 15:49:55 -0700 Subject: [PATCH 19/30] W-23533642 Kill Switch Feature 8/31 Release --- .../pages/af-use-case-cost-management.adoc | 212 ------------------ .../detect-and-contain-rogue-agents.adoc | 130 +++++++++++ 2 files changed, 130 insertions(+), 212 deletions(-) delete mode 100644 modules/ROOT/pages/af-use-case-cost-management.adoc create mode 100644 modules/ROOT/pages/detect-and-contain-rogue-agents.adoc diff --git a/modules/ROOT/pages/af-use-case-cost-management.adoc b/modules/ROOT/pages/af-use-case-cost-management.adoc deleted file mode 100644 index 7d8acf704..000000000 --- a/modules/ROOT/pages/af-use-case-cost-management.adoc +++ /dev/null @@ -1,212 +0,0 @@ -= Control LLM Costs in Agent Fabric - -Agent Fabric gives you full visibility into token consumption and spend across every model call, and the controls to enforce limits before usage compounds. Use Model Wallets to set hard limits in tokens or dollars that agents can't exceed, and attribute every token and dollar to the team, application, or agent that generated them. - -Key benefits include: - -* Full cost visibility: See token consumption and spend by application, agent, user, and model in one place. -* Cost-optimized routing: Route each request to the right model at the right cost with semantic routing. -* Enforced budgets: Cap token or spend usage with Model Wallets that block requests when a budget limit is reached. -* Consistent governance: Apply the same policies, prompt protection, and automatic fallback across every provider. -* Cost attribution: Trace every token and dollar to the team, application, or agent that drove them. - -== The Problem - -As agentic systems scale, LLM costs can quickly spiral out of control without proper visibility and enforcement: - -* Unpredictable costs: Token usage varies widely based on agent behavior and queries. -* No visibility: Costs can't be attributed to specific applications, agents, or users. -* Inefficient model usage: Expensive models handle simple queries that cheaper models could address. -* Budget overruns: Nothing enforces the budget, so a number in the plan isn't a real limit. -* No optimization path: Without data on usage patterns, optimization is guesswork. - -Gain visibility into what's driving costs and the controls to optimize spending without sacrificing quality. - -== The Solution - -Agent Fabric provides comprehensive cost management for agentic AI through the Model Proxy: - -* Usage visibility: Tracks token consumption by application, agent, user, and model. -* Semantic routing: Routes each query to the appropriate model based on complexity, automatically. -* Budget enforcement: Caps token or spend usage with Model Wallets that block requests when a budget limit is reached. -* Model optimization: Provides data-driven insight into which models are used for which tasks. -* Cost attribution: Shows exactly what's driving your spend, down to the team, app, or agent. - -== How Semantic Routing Works - -Not all queries require the most powerful (and most expensive) AI models. Semantic routing analyzes query complexity and routes each request appropriately: - -[source,text] ----- -Simple query: "What's the status of order #12345?" -→ Route to: Fast, cost-effective model - -Complex query: "Analyze this quarter's sales trends, identify anomalies, and recommend strategic adjustments" -→ Route to: Powerful, higher-cost model ----- - -The Model Proxy makes these routing decisions automatically based on configurable rules, maintaining quality while minimizing cost. - -== How Model Wallets Enforce Usage Limits - -Budget alerts tell you when you've overrun a limit. They don't stop it. By the time an alert fires at 90 percent of budget, an agent running unattended can push token or spend usage far past the limit before anyone reads the notification. - -A Model Wallet closes that gap by turning a budget from a number in a plan into a financial control that agents can't overrun: - -* Hard limits: Set enforced token or spend limits per provider so that when a budget reaches its limit, requests are blocked rather than flagged. -* Periodic caps: Set a daily, weekly, or monthly limit that resets automatically on a schedule, so token or spend usage stays bounded each period. -* Flexible metrics: Set limits in dollars (USD) or tokens, so budgets reflect the metric that matters most to your team. -* Identity-scoped controls: Tie usage controls to a Model Proxy's client identity so that each application or agent routes through its own governed access point with dedicated budget limits. - -Model Wallets build on the Model Proxy. The proxy provides one governed access point for every provider, making token consumption and spend visible; Model Wallets add the enforcement layer on top, so the usage you can see is also usage you can cap. - -== Who This Is For - -These cost management capabilities are ideal for: - -* FinOps teams managing cloud and AI spending -* Engineering leaders optimizing infrastructure costs -* Product teams building cost-effective agentic features -* Enterprises scaling agent deployments beyond proof of concept -* Any organization where LLM costs are a significant budget item - -== Example Scenarios - -These scenarios demonstrate how different organizations use Agent Fabric to bring LLM costs under control. - -=== Scenario 1: Enterprise-Wide Cost Visibility - -*Challenge:* A large organization has agents deployed across multiple business units but no visibility into which ones are driving LLM costs. - -With Agent Fabric you get complete cost visibility: - -. Route all LLM traffic through the Model Proxy. -. Tag requests by business unit, application, and agent. -. Generate cost dashboards showing usage patterns. -. Identify high-cost agents and opportunities for optimization. - -=== Scenario 2: Semantic Routing for Customer Support - -*Challenge:* A customer support agent system uses expensive models for all queries, including simple lookups. - -With semantic routing you cut cost without sacrificing quality: - -. Configure semantic routing rules: - * Simple queries (order status, account lookups) route to a cost-effective model. - * Complex queries (troubleshooting, technical issues) route to an advanced model. -. The Model Proxy analyzes each request and routes it appropriately. -. Monitor quality metrics to ensure the customer experience isn't impacted. - -=== Scenario 3: Budget Controls for Development Teams - -*Challenge:* Development teams experimenting with agents have no spending limits, leading to budget surprises. - -With Model Wallets you get budgets agents can't overrun: - -. Create a separate Model Proxy for each team, with budget limits configured per provider. -. Set a daily, weekly, or monthly limit in dollars (USD) or tokens depending on how the team tracks spend. -. Enable hard limits so requests are blocked when a budget is reached rather than allowed to overrun. -. Give teams visibility into budget consumption through the Model Proxy dashboard. - -=== Scenario 4: Multi-Model Optimization - -*Challenge:* An organization uses multiple LLM providers but doesn't know which models are most cost-effective for its use cases. - -With Agent Fabric you get evidence-based model selection: - -. Deploy agents with flexible model configuration. -. Agent Fabric tracks cost and quality metrics per model. -. Analyze which models deliver the best cost/quality ratio for each use case. -. Adjust routing rules based on the data. - -== Implementation Steps - -Follow these steps to set up cost management in Agent Fabric. - -=== Step 1: Deploy the Model Proxy - -. Set up the Model Proxy as part of your Omni Gateway deployment. -. Configure integration with your LLM providers. -. Route agent traffic through the Model Proxy. - -=== Step 2: Implement Usage Tracking - -. Tag all requests with relevant metadata: - * Business unit or cost center - * Application name - * Agent identifier - * User or session ID -. Configure logging and metrics collection. -. Set up dashboards for cost visibility. - -=== Step 3: Establish Baseline Costs - -. Monitor usage patterns for one to two weeks without optimization. -. Identify current cost drivers. -. Categorize query types by complexity and frequency. -. Calculate baseline cost metrics. - -=== Step 4: Configure Semantic Routing - -. Define query complexity categories. -. Assign an appropriate model to each category. -. Create routing rules in the Model Proxy. -. Test routing with sample queries to ensure quality. - -=== Step 5: Set Budget Controls with Model Wallets - -. Create a Model Proxy per team, application, or agent to scope budget controls to a client identity. -. Add a budget for each provider the Model Proxy routes to, choosing a daily, weekly, or monthly period. -. Set the limit in dollars (USD) or tokens, and enable hard limits where overruns are unacceptable so requests are blocked when a limit is reached. -. Share the Model Proxy dashboard with teams so they can track budget consumption per provider. - -=== Step 6: Monitor and Optimize - -. Track cost trends after optimization. -. Monitor quality metrics to ensure no degradation. -. Refine routing rules based on results. -. Share cost savings and optimization wins. - -== Metrics to Track - -Track these metrics to measure and improve the impact of cost control. - -=== Cost Metrics - -* Total token usage by time period -* Cost per application, agent, and user -* Cost per model and provider -* Average cost per query - -=== Usage Metrics - -* Queries per time period -* Model distribution (which models handle what percentage of queries) -* Token usage distribution by query complexity -* Peak usage times and patterns - -=== Quality Metrics - -* Response quality scores -* User satisfaction ratings -* Error rates by model -* Average response time by model - -=== Optimization Metrics - -* Cost savings from semantic routing -* Percentage of queries routed to cost-effective models -* Budget adherence by team and application -* ROI of optimization efforts - -== Related Documentation - -* xref:agent-fabric-use-cases.adoc[] - -== Next Steps - -With cost controls in place, you're ready to: - -* xref:af-use-case-policy-enforcement.adoc[Add policy enforcement for governance] -* xref:use-case-orchestration.adoc[Build complex workflows with cost awareness] -* xref:use-case-identity.adoc[Move to production with identity and cost controls] diff --git a/modules/ROOT/pages/detect-and-contain-rogue-agents.adoc b/modules/ROOT/pages/detect-and-contain-rogue-agents.adoc new file mode 100644 index 000000000..124704980 --- /dev/null +++ b/modules/ROOT/pages/detect-and-contain-rogue-agents.adoc @@ -0,0 +1,130 @@ += Detect and Contain Rogue Agents +:keywords: quarantine agent, contain rogue agent, agent behavioral drift, tool-call abuse detection, token spend anomaly, flag history, reactivate quarantined agent, unauthorized agent actions, agent security monitoring, model proxy policies, mulesoft + +As AI agents take on more autonomous work across your organization, a single compromised, misconfigured, or malfunctioning agent can quickly leak sensitive data, take unauthorized actions, or run up costs before anyone notices. Monitor agent traffic from a single location in the enhanced MuleSoft experience to detect anomalous behavior and contain a rogue agent before it causes damage. + +Key benefits: + +* Detect anomalous or unauthorized behavior in real time, using built-in detectors and your own custom rules. +* Get notified the moment the platform flags an agent, through email or Slack. +* Review flagged activity before you act. Nothing quarantines automatically without your review. +* Quarantine a rogue agent instantly to stop data leakage, harmful actions, or runaway costs. Quarantine is fully reversible, so you can undo a false positive in seconds. +* Meet compliance requirements. The platform logs every action with full attribution. + +== Before You Begin + +Confirm these prerequisites are in place. + +* You need these API Manager permissions: +** API Creator: Create instances +** View APIs Configuration: View instances +** Edit APIs Configuration: Edit and manage instances +** View API Alerts: View API alerts in a specific environment +** Manage API Alerts: Manage API alerts in a specific environment + +* Register each agent you want to monitor with a unique instance name and ID, and link it to its model proxies. This lets flags, logs, and containment actions target the correct agent. + +* Set up your agents as service identities in your enterprise IdP, and configure the IdP to include each agent's identifier and team claims in the tokens it issues. + +*Apply these policies to your agent tools and model proxy instances: +** xref:gateway::policies-included-jwt-validation.adoc[JWT Token Policy]: validates the agent's identity. +** xref:gateway::policies-outbound-oauth-obo.adoc[OBO (On-Behalf-Of) Token Validation Policy]: identifies both the agent and the end user it's acting for. + +== Enable Agent Monitoring for a Model Proxy + +Enable monitoring on each model proxy whose agent traffic you want to track. + +. Log in to the MuleSoft enhanced experience with an account that has the required permissions. +. In *Portfolio*, select *Model Proxies*. +. Select the model proxy you want to monitor. +. Select the *Policies* tab and then select *+Apply Policy*. +. Select the *Rogue Agent Detection* policy and click *Next*. +. Configure the policy settings by selecting the criteria monitor: ++ +* *Token-spend anomaly* ++ +Flags when an LLM virtual key's token-spend rate over a rolling window is statistically anomalous against the baseline. +* *Tool-call loop* ++ +Flags when an agent repeats near-identical tool calls inside a short window past the configured threshold. +* *Behavioral drift* ++ +Flags when an agent's behavioral fingerprint (tool selection, response shape) drifts persistently from its baseline. +* *Custom detection criteria* ++ +Flags activity that matches a rule you define in plain language, for example, `flag any agent that asks a user for a password`. +. Select *Apply Policy*. + +Repeat these steps for each model proxy to protect. + +== Set Up Notifications for Flagged Agents + +Configure alerts so you're notified as soon as an agent is flagged. + +. Navigate to *Notifications* and select *New Notification*. +. Under *Select Alert Target*, complete the fields: +.. *Environment* ++ +Select the environment to monitor, for example, *Production* or *Sandbox*. +.. *Service Type* ++ +Select *Model Proxy*. +.. *Target Service* ++ +Search for and select the model proxy to receive alerts about. +. Under *Specify Alert Configuration*, select the *Alert Metric* for quarantine activity _(label to be confirmed)_, then set the comparison operator, threshold value, and time window. +.. *Alert Metric* ++ +Select *Policy Violation* and then select the policy. +.. *Alert When* ++ +Select the operator to use in the alert condition, for example, the policy violation occurs greater than 10 times in 5 minutes. +. Under *Set Alert Delivery*: +.. For *Severity*, select *Critical*, *Warning*, or *Info*. +.. In *Alert Name*, enter a descriptive name (four or more characters). +.. In *Delivery Channels*, select *Email*, *Slack*, or both. +. Select *Create Alert*. + +== Review and Quarantine a Flagged Agent + +When an agent is flagged, review its activity and quarantine it if needed. Quarantine stops the agent from acting. + +. Navigate to *Security*. +. On the *Needs Review* tab, find the flagged agent. ++ +The *Security* page shows flagged and reviewed agents from the last 90 days. +. Select *Review* to open the agent's flag history. +. Review the timeline of detection events, then select an action: ++ +* *Quarantine agent* ++ Stops the agent from acting. Confirm at the prompt to complete this action. +* *Clear flags* ++ +Dismisses the flags if the activity was legitimate. Confirm at the prompt to complete this action. +* *Cancel* ++ +Closes the view with no changes. The agent stays in the review queue. + +The audit log records the action with the agent instance ID, the user who performed it, and details such as the timestamp and environment. + +== Reactivate a Quarantined Agent + +After you confirm a quarantined agent is safe to return to service, reactivate it. + +. Navigate to *Security*. +. On the *Reviewed* tab, find the quarantined agent. +. Select *Review* to review the agent's details. +. Select *Restore Model Access*. +. In the confirmation prompt, select *Restore Model Access* to return the agent to service. +. Select *Close* to close the view with no changes. ++ +After reactivation the audit log records the action. + +== See Also + +* xref:exp-alerts-configure-notifications.adoc[] +* xref:exp-instances-add.adoc[] +* xref:exp-home-start.adoc[] +* xref:exp-services-monitoring.adoc[] +* xref:gateway::policies-included-jwt-validation.adoc[] +* xref:gateway::policies-outbound-oauth-obo.adoc[] \ No newline at end of file From c5ddb66487328346fa323f9c9b218a2c7f2a0170 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 14 Aug 2026 15:53:59 -0700 Subject: [PATCH 20/30] W-23533533 Agent Fabric Cost Management --- .../pages/af-use-case-cost-management.adoc | 212 ++++++++++++++++++ 1 file changed, 212 insertions(+) create mode 100644 modules/ROOT/pages/af-use-case-cost-management.adoc diff --git a/modules/ROOT/pages/af-use-case-cost-management.adoc b/modules/ROOT/pages/af-use-case-cost-management.adoc new file mode 100644 index 000000000..7d8acf704 --- /dev/null +++ b/modules/ROOT/pages/af-use-case-cost-management.adoc @@ -0,0 +1,212 @@ += Control LLM Costs in Agent Fabric + +Agent Fabric gives you full visibility into token consumption and spend across every model call, and the controls to enforce limits before usage compounds. Use Model Wallets to set hard limits in tokens or dollars that agents can't exceed, and attribute every token and dollar to the team, application, or agent that generated them. + +Key benefits include: + +* Full cost visibility: See token consumption and spend by application, agent, user, and model in one place. +* Cost-optimized routing: Route each request to the right model at the right cost with semantic routing. +* Enforced budgets: Cap token or spend usage with Model Wallets that block requests when a budget limit is reached. +* Consistent governance: Apply the same policies, prompt protection, and automatic fallback across every provider. +* Cost attribution: Trace every token and dollar to the team, application, or agent that drove them. + +== The Problem + +As agentic systems scale, LLM costs can quickly spiral out of control without proper visibility and enforcement: + +* Unpredictable costs: Token usage varies widely based on agent behavior and queries. +* No visibility: Costs can't be attributed to specific applications, agents, or users. +* Inefficient model usage: Expensive models handle simple queries that cheaper models could address. +* Budget overruns: Nothing enforces the budget, so a number in the plan isn't a real limit. +* No optimization path: Without data on usage patterns, optimization is guesswork. + +Gain visibility into what's driving costs and the controls to optimize spending without sacrificing quality. + +== The Solution + +Agent Fabric provides comprehensive cost management for agentic AI through the Model Proxy: + +* Usage visibility: Tracks token consumption by application, agent, user, and model. +* Semantic routing: Routes each query to the appropriate model based on complexity, automatically. +* Budget enforcement: Caps token or spend usage with Model Wallets that block requests when a budget limit is reached. +* Model optimization: Provides data-driven insight into which models are used for which tasks. +* Cost attribution: Shows exactly what's driving your spend, down to the team, app, or agent. + +== How Semantic Routing Works + +Not all queries require the most powerful (and most expensive) AI models. Semantic routing analyzes query complexity and routes each request appropriately: + +[source,text] +---- +Simple query: "What's the status of order #12345?" +→ Route to: Fast, cost-effective model + +Complex query: "Analyze this quarter's sales trends, identify anomalies, and recommend strategic adjustments" +→ Route to: Powerful, higher-cost model +---- + +The Model Proxy makes these routing decisions automatically based on configurable rules, maintaining quality while minimizing cost. + +== How Model Wallets Enforce Usage Limits + +Budget alerts tell you when you've overrun a limit. They don't stop it. By the time an alert fires at 90 percent of budget, an agent running unattended can push token or spend usage far past the limit before anyone reads the notification. + +A Model Wallet closes that gap by turning a budget from a number in a plan into a financial control that agents can't overrun: + +* Hard limits: Set enforced token or spend limits per provider so that when a budget reaches its limit, requests are blocked rather than flagged. +* Periodic caps: Set a daily, weekly, or monthly limit that resets automatically on a schedule, so token or spend usage stays bounded each period. +* Flexible metrics: Set limits in dollars (USD) or tokens, so budgets reflect the metric that matters most to your team. +* Identity-scoped controls: Tie usage controls to a Model Proxy's client identity so that each application or agent routes through its own governed access point with dedicated budget limits. + +Model Wallets build on the Model Proxy. The proxy provides one governed access point for every provider, making token consumption and spend visible; Model Wallets add the enforcement layer on top, so the usage you can see is also usage you can cap. + +== Who This Is For + +These cost management capabilities are ideal for: + +* FinOps teams managing cloud and AI spending +* Engineering leaders optimizing infrastructure costs +* Product teams building cost-effective agentic features +* Enterprises scaling agent deployments beyond proof of concept +* Any organization where LLM costs are a significant budget item + +== Example Scenarios + +These scenarios demonstrate how different organizations use Agent Fabric to bring LLM costs under control. + +=== Scenario 1: Enterprise-Wide Cost Visibility + +*Challenge:* A large organization has agents deployed across multiple business units but no visibility into which ones are driving LLM costs. + +With Agent Fabric you get complete cost visibility: + +. Route all LLM traffic through the Model Proxy. +. Tag requests by business unit, application, and agent. +. Generate cost dashboards showing usage patterns. +. Identify high-cost agents and opportunities for optimization. + +=== Scenario 2: Semantic Routing for Customer Support + +*Challenge:* A customer support agent system uses expensive models for all queries, including simple lookups. + +With semantic routing you cut cost without sacrificing quality: + +. Configure semantic routing rules: + * Simple queries (order status, account lookups) route to a cost-effective model. + * Complex queries (troubleshooting, technical issues) route to an advanced model. +. The Model Proxy analyzes each request and routes it appropriately. +. Monitor quality metrics to ensure the customer experience isn't impacted. + +=== Scenario 3: Budget Controls for Development Teams + +*Challenge:* Development teams experimenting with agents have no spending limits, leading to budget surprises. + +With Model Wallets you get budgets agents can't overrun: + +. Create a separate Model Proxy for each team, with budget limits configured per provider. +. Set a daily, weekly, or monthly limit in dollars (USD) or tokens depending on how the team tracks spend. +. Enable hard limits so requests are blocked when a budget is reached rather than allowed to overrun. +. Give teams visibility into budget consumption through the Model Proxy dashboard. + +=== Scenario 4: Multi-Model Optimization + +*Challenge:* An organization uses multiple LLM providers but doesn't know which models are most cost-effective for its use cases. + +With Agent Fabric you get evidence-based model selection: + +. Deploy agents with flexible model configuration. +. Agent Fabric tracks cost and quality metrics per model. +. Analyze which models deliver the best cost/quality ratio for each use case. +. Adjust routing rules based on the data. + +== Implementation Steps + +Follow these steps to set up cost management in Agent Fabric. + +=== Step 1: Deploy the Model Proxy + +. Set up the Model Proxy as part of your Omni Gateway deployment. +. Configure integration with your LLM providers. +. Route agent traffic through the Model Proxy. + +=== Step 2: Implement Usage Tracking + +. Tag all requests with relevant metadata: + * Business unit or cost center + * Application name + * Agent identifier + * User or session ID +. Configure logging and metrics collection. +. Set up dashboards for cost visibility. + +=== Step 3: Establish Baseline Costs + +. Monitor usage patterns for one to two weeks without optimization. +. Identify current cost drivers. +. Categorize query types by complexity and frequency. +. Calculate baseline cost metrics. + +=== Step 4: Configure Semantic Routing + +. Define query complexity categories. +. Assign an appropriate model to each category. +. Create routing rules in the Model Proxy. +. Test routing with sample queries to ensure quality. + +=== Step 5: Set Budget Controls with Model Wallets + +. Create a Model Proxy per team, application, or agent to scope budget controls to a client identity. +. Add a budget for each provider the Model Proxy routes to, choosing a daily, weekly, or monthly period. +. Set the limit in dollars (USD) or tokens, and enable hard limits where overruns are unacceptable so requests are blocked when a limit is reached. +. Share the Model Proxy dashboard with teams so they can track budget consumption per provider. + +=== Step 6: Monitor and Optimize + +. Track cost trends after optimization. +. Monitor quality metrics to ensure no degradation. +. Refine routing rules based on results. +. Share cost savings and optimization wins. + +== Metrics to Track + +Track these metrics to measure and improve the impact of cost control. + +=== Cost Metrics + +* Total token usage by time period +* Cost per application, agent, and user +* Cost per model and provider +* Average cost per query + +=== Usage Metrics + +* Queries per time period +* Model distribution (which models handle what percentage of queries) +* Token usage distribution by query complexity +* Peak usage times and patterns + +=== Quality Metrics + +* Response quality scores +* User satisfaction ratings +* Error rates by model +* Average response time by model + +=== Optimization Metrics + +* Cost savings from semantic routing +* Percentage of queries routed to cost-effective models +* Budget adherence by team and application +* ROI of optimization efforts + +== Related Documentation + +* xref:agent-fabric-use-cases.adoc[] + +== Next Steps + +With cost controls in place, you're ready to: + +* xref:af-use-case-policy-enforcement.adoc[Add policy enforcement for governance] +* xref:use-case-orchestration.adoc[Build complex workflows with cost awareness] +* xref:use-case-identity.adoc[Move to production with identity and cost controls] From 10c0ba62aadd39fdb8e998ebaefba2c68ae4198b Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Fri, 14 Aug 2026 16:00:02 -0700 Subject: [PATCH 21/30] Added cost management to nav --- modules/ROOT/nav.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 90911bd23..1cc34285b 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -50,6 +50,7 @@ ** xref:learning-map-agent-fabric.adoc[Get Started with Agent Fabric] ** xref:agent-fabric-use-cases.adoc[] *** xref:af-use-case-mcp-bridge.adoc[] + *** xref:af-use-case-cost-management.adoc[] *** xref:af-use-case-orchestration.adoc[] ** xref:agent-fabric-release-notes.adoc[] ** xref:agent-networks-get-started.adoc[] From 36495cbe3017f9dde8c795591511498827f601ab Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 17 Aug 2026 08:15:14 -0700 Subject: [PATCH 22/30] Updating xrefs --- .../ROOT/pages/agent-fabric-use-cases.adoc | 33 +++++++++---------- 1 file changed, 16 insertions(+), 17 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index ca0bbd9cb..7f21ff457 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -10,7 +10,7 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem |Catalog and manage agents across multiple platforms |Discover and register agents from a centralized catalog. Know what exists and where before you apply governance. -|xref:use-case-registry.adoc[] +|xref:af-use-case-registry.adoc[] |Make existing APIs agent-ready without modifying code |Select which API operations to expose as MCP tools, apply read-only filtering, and control agent access to your APIs. @@ -18,15 +18,15 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem |Apply consistent business rules and guardrails across all agents |Enforce PII policies, rate limits, and compliance rules across all agents through a single gateway rather than reimplementing them per platform. -|xref:use-case-policy-enforcement.adoc[Policy Enforcement] +|xref:af-use-case-policy-enforcement.adoc[Policy Enforcement] |Control token usage and optimize model selection |Monitor token usage across agents and applications, then route queries to cost-effective models based on complexity. -|xref:use-case-cost-control.adoc[Cost Control] +|xref:af-use-case-cost-management.adoc[Cost Control] |Build complex, deterministic workflows with error handling |Handle multi-step business logic, error scenarios, and unhappy paths that simple agent loops can't reliably address. -|xref:use-case-orchestration.adoc[Agentic Orchestration] +|xref:af-use-case-orchestration.adoc[Agentic Orchestration] |=== @@ -34,47 +34,46 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem Use a centralized registry and automated scanners to discover, catalog, and manage agents across your organization. Know what exists and where before you apply governance. For example, a business process outsourcer managing agents across multiple client platforms, or an enterprise security team asked to audit every agent in production, can use Registry and Scanners to get a complete, current picture without manually tracking deployments. -xref:use-case-registry.adoc[Centralizing Agent Discovery with Agent Registry and Scanners] +For more information, see xref:af-use-case-registry.adoc[]. == Make APIs Agent-Ready with MCP Bridge Transform your existing API instances into agent-ready tools without modifying code. Select which operations to expose, apply read-only filtering where needed, and control agent access to your APIs. For example, an organization with hundreds of existing Mule APIs can make them callable by agents in minutes through configuration alone, without touching the underlying implementations. -xref:af-use-case-mcp-bridge.adoc[] +For more information, see xref:af-use-case-mcp-bridge.adoc[]. == Enforce Consistent Policies Across Agent Platforms Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. For example, a regulated industry deploying agents across Agentforce, Bedrock, and custom Mule implementations can enforce the same data privacy and rate limiting rules everywhere through a single Omni Gateway policy. -xref:use-case-policy-enforcement.adoc[Policy Enforcement] +For more information, see xref:af-use-case-policy-enforcement.adoc[]. == Monitor Costs and Optimizing Model Selection Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. For example, a team running hundreds of daily agent interactions can route routine lookups to a smaller, cheaper model and reserve a frontier model only for tasks that require complex reasoning. -xref:use-case-cost-control.adoc[Cost Control] +xref:af-use-case-cost-management.adoc[]. == Coordinate Multi-Agent Processes with Brokers Use agent brokers and agent networks to coordinate task delegation across A2A-compliant agents with guided determinism. Define broker routing logic in Agent Script to handle complex business processes, error scenarios, and unhappy paths that require multiple specialized agents working in sequence. For example, an order management process that involves a research agent, a pricing agent, and an approval agent can be wired together in a single agent network with a broker that routes each step to the right specialist. -xref:use-case-orchestration.adoc[Agent Orchestration] +For more information, see xref:af-use-case-orchestration.adoc[]. == Get Started -New to Agent Fabric? Start with the learning map to understand the fundamentals: - -* https://help.mulesoft.com/s/article/Get-Started-with-Agent-Fabric[Get Started with Agent Fabric] +New to Agent Fabric? Start with the xref:agent-fabric-overview.adoc[Agent Fabric Overview] and xref:learning-map-agent-fabric.adoc[Agent Fabric learning map] to understand the fundamentals. After you understand the basics, choose a use case to implement. == See Also -* xref:use-case-cost-control.adoc[] -* xref:use-case-identity.adoc[] +* xref:agent-fabric-overview.adoc[] +* xref:learning-map-agent-fabric.adoc[] +* xref:af-use-case-cost-management.adoc[] * xref:af-use-case-mcp-bridge.adoc[] -* xref:use-case-orchestration.adoc[] -* xref:use-case-policy-enforcement.adoc[] -* xref:use-case-registry.adoc[] +* xref:af-use-case-orchestration.adoc[] +* xref:af-use-case-policy-enforcement.adoc[] +* xref:af-use-case-registry.adoc[] From d8d062070a4f412979cca0c0d580d78a2d646d19 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Mon, 17 Aug 2026 13:43:49 -0700 Subject: [PATCH 23/30] commenting out use cases that don't exist yet --- modules/ROOT/pages/agent-fabric-use-cases.adoc | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 7f21ff457..36c99775c 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -10,7 +10,7 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem |Catalog and manage agents across multiple platforms |Discover and register agents from a centralized catalog. Know what exists and where before you apply governance. -|xref:af-use-case-registry.adoc[] +|//xref:af-use-case-registry.adoc[] |Make existing APIs agent-ready without modifying code |Select which API operations to expose as MCP tools, apply read-only filtering, and control agent access to your APIs. @@ -18,7 +18,7 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem |Apply consistent business rules and guardrails across all agents |Enforce PII policies, rate limits, and compliance rules across all agents through a single gateway rather than reimplementing them per platform. -|xref:af-use-case-policy-enforcement.adoc[Policy Enforcement] +|//xref:af-use-case-policy-enforcement.adoc[Policy Enforcement] |Control token usage and optimize model selection |Monitor token usage across agents and applications, then route queries to cost-effective models based on complexity. @@ -34,7 +34,7 @@ Agent Fabric addresses the most common challenges in enterprise AI agent managem Use a centralized registry and automated scanners to discover, catalog, and manage agents across your organization. Know what exists and where before you apply governance. For example, a business process outsourcer managing agents across multiple client platforms, or an enterprise security team asked to audit every agent in production, can use Registry and Scanners to get a complete, current picture without manually tracking deployments. -For more information, see xref:af-use-case-registry.adoc[]. +//For more information, see xref:af-use-case-registry.adoc[]. == Make APIs Agent-Ready with MCP Bridge @@ -46,7 +46,7 @@ For more information, see xref:af-use-case-mcp-bridge.adoc[]. Consistently enforce business rules, PII policies, and guardrails across all agents regardless of platform. Apply policies one time through a gateway rather than reimplementing them for each platform. For example, a regulated industry deploying agents across Agentforce, Bedrock, and custom Mule implementations can enforce the same data privacy and rate limiting rules everywhere through a single Omni Gateway policy. -For more information, see xref:af-use-case-policy-enforcement.adoc[]. +//For more information, see xref:af-use-case-policy-enforcement.adoc[]. == Monitor Costs and Optimizing Model Selection @@ -75,5 +75,5 @@ After you understand the basics, choose a use case to implement. * xref:af-use-case-cost-management.adoc[] * xref:af-use-case-mcp-bridge.adoc[] * xref:af-use-case-orchestration.adoc[] -* xref:af-use-case-policy-enforcement.adoc[] -* xref:af-use-case-registry.adoc[] +* //xref:af-use-case-policy-enforcement.adoc[] +* //xref:af-use-case-registry.adoc[] From cfe11febf8c73afe45c185b60136c598236f5914 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 18 Aug 2026 08:40:49 -0700 Subject: [PATCH 24/30] Added Kill switch feature to nav --- modules/ROOT/nav.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 39ec1cab6..ca207f8aa 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -31,6 +31,7 @@ ** xref:exp-governance-view-cost-and-token-usage.adoc[] *** xref:model-proxy-token-reports.adoc[] ** xref:exp-akamai-risk-correlation.adoc[] + ** xref:exp-detect-and-contain-rogue-agents.adoc[] ** xref:exp-governance-work-with-strategies.adoc[] *** xref:exp-governance-create-strategy.adoc[] *** xref:exp-governance-manage-strategies.adoc[] From ecefc817947326e18f918d1627891898c3294263 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 18 Aug 2026 08:46:56 -0700 Subject: [PATCH 25/30] Renamed file --- ...rogue-agents.adoc => exp-detect-and-contain-rogue-agents.adoc} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename modules/ROOT/pages/{detect-and-contain-rogue-agents.adoc => exp-detect-and-contain-rogue-agents.adoc} (100%) diff --git a/modules/ROOT/pages/detect-and-contain-rogue-agents.adoc b/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc similarity index 100% rename from modules/ROOT/pages/detect-and-contain-rogue-agents.adoc rename to modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc From a574bdafaa03aade54e562746c6c31dd5c395c19 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 18 Aug 2026 08:49:26 -0700 Subject: [PATCH 26/30] Fixing list item --- modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc b/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc index 124704980..5a853099f 100644 --- a/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc +++ b/modules/ROOT/pages/exp-detect-and-contain-rogue-agents.adoc @@ -26,7 +26,7 @@ Confirm these prerequisites are in place. * Set up your agents as service identities in your enterprise IdP, and configure the IdP to include each agent's identifier and team claims in the tokens it issues. -*Apply these policies to your agent tools and model proxy instances: +* Apply these policies to your agent tools and model proxy instances: ** xref:gateway::policies-included-jwt-validation.adoc[JWT Token Policy]: validates the agent's identity. ** xref:gateway::policies-outbound-oauth-obo.adoc[OBO (On-Behalf-Of) Token Validation Policy]: identifies both the agent and the end user it's acting for. From d85c11c91ab8afcbe4084eb59fcf27ae8fd06d0b Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 18 Aug 2026 11:30:17 -0700 Subject: [PATCH 27/30] Adding Models and Model Wallets --- modules/ROOT/nav.adoc | 2 + .../ROOT/pages/exp-model-wallets-manage.adoc | 99 +++++++++++++++++++ .../ROOT/pages/exp-models-manage-costs.adoc | 46 +++++++++ 3 files changed, 147 insertions(+) create mode 100644 modules/ROOT/pages/exp-model-wallets-manage.adoc create mode 100644 modules/ROOT/pages/exp-models-manage-costs.adoc diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 1a3d4a37b..6f630d0a8 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -30,6 +30,8 @@ *** xref:exp-providers-manage.adoc[] ** xref:exp-governance-view-cost-and-token-usage.adoc[] *** xref:model-proxy-token-reports.adoc[] + *** xref:exp-models-manage-costs.adoc[] + *** xref:exp-model-wallets-manage.adoc[] ** xref:exp-akamai-risk-correlation.adoc[] ** xref:exp-detect-and-contain-rogue-agents.adoc[] ** xref:exp-governance-work-with-strategies.adoc[] diff --git a/modules/ROOT/pages/exp-model-wallets-manage.adoc b/modules/ROOT/pages/exp-model-wallets-manage.adoc new file mode 100644 index 000000000..f0aead320 --- /dev/null +++ b/modules/ROOT/pages/exp-model-wallets-manage.adoc @@ -0,0 +1,99 @@ += Managing Model Wallets +:keywords: model wallets, model wallet, budgets, token budget, spend limit, model proxies, access control, jwt claims, cost management, anypoint platform + +A model wallet controls who can use your model proxies and how much they can spend. It combines the authentication credentials that callers present with the budget limits that you set on that access. Use model wallets to grant controlled access to a team, user, or agent, and to cap their token or dollar spend against a provider over a set time window. + +Each wallet has a system-generated client ID and required JWT claims that you define. When a caller connects to a model proxy, the proxy checks the client ID and JWT claims in the request against the wallet's configuration. If the claims match, the proxy authorizes the request and counts the request against the wallet's budgets. + +[[before-you-begin]] +== Before You Begin + +To manage model wallets, you need: + +* An Anypoint Platform account +* A configured identity provider (IdP), with a JWT validation policy applied to the model proxies that the wallet authorizes +* Any of these permissions: ++ +-- +** API Manager: API Creator +** API Manager: View APIs Configuration +** API Manager: Edit APIs Configuration +-- ++ +For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. + +Organizations without an IdP configured can't use model wallets. Those organizations continue to use existing access methods. + +[[create-a-model-wallet]] +== Create a Model Wallet + +. From *Portfolio* > *Model Proxies* > *Model Wallets*, select *New Model Wallet*. +. In *Name*, enter a name for the wallet, for example, `Finance Analytics Bot`. +. (Optional) Enter a *Description* explaining what the wallet is used for. +. Under *Authentication*, copy the system-generated *Client ID*. ++ +This value is read-only. Callers send it as the `X-Client-Id` request header to select the wallet. +. Select *Add Claim* and enter at least one required claim: ++ +-- +** In *Required Claims*, enter one or more claim keys, for example, `group`. +** Enter one or more comma-separated values. +** To add more claims, select *Add Claim* again. +-- ++ +NOTE: Model wallets use the JWT validation policy configured across agent tools and instances. +. (Optional) Add one or more budgets to cap spend or token usage. See <>. +. Select *Create Model Wallet*. + +[[view-model-wallets]] +== View Model Wallets + +From *Portfolio* > *Model Proxies*, select *Model Wallets*. The wallet list shows: + +* *Name*: The wallet's display name. +* *Description*: What the wallet is used for. +* *Budgets*: How many budgets are attached to the wallet. +* *Last Updated*: When the wallet was last changed. + +To find a specific wallet, use the search box to filter by name or description. + +[[edit-a-model-wallet]] +== Edit a Model Wallet + +. From *Portfolio* > *Model Proxies* > *Model Wallets*, open the wallet and select *Edit*. +. Change the *Name*, *Description*, or *Required Claims*. ++ +The *Client ID* can't be changed. +. Select *Save*. + +Manage budgets separately from the wallet's core details. + +[[add-a-budget-to-a-wallet]] +== Add a Budget to a Wallet + +A budget caps usage for a wallet against a provider over a recurring period. Add a budget when you create or edit a model wallet, or add one from the budgets view in *Governance* > *Cost Management*. + +Add multiple budget limits to a wallet. Assign each model to only one budget limit. + +. In the *Budgets* section, select *Add Budget*. +. Enter the budget details: ++ +-- +** *Provider*: The provider the budget tracks. +** *Period*: *Daily*, *Weekly*, or *Monthly*. +** *Resets on Day of Month*: The day each period the usage counter returns to zero. +** *Metric*: Whether the limit is measured in dollars (*Spend*) or *Tokens*. +** *Spend Limit (USD)*: The limit amount for the selected metric. +-- +. Select *Add Budget*. + +Budgets depend on model costs. For a budget to track usage accurately, configure the cost per token for each model on the *Models* page. Models without configured costs default to zero and don't count against the budget. See xref:exp-models-manage-costs.adoc[]. + +When a wallet reaches its budget, the proxy blocks requests to that provider's models. If a fallback route exists, the request routes to the next model in the proxy's route. + +Budgets are approximate rather than a real-time hard cutoff. The system tracks total token consumption across routes as a governance and cost-awareness tool. Usage can briefly exceed a limit before the system blocks requests. + +== See Also + +* xref:exp-governance-view-cost-and-token-usage.adoc[] +* xref:exp-services-register-manually.adoc[] \ No newline at end of file diff --git a/modules/ROOT/pages/exp-models-manage-costs.adoc b/modules/ROOT/pages/exp-models-manage-costs.adoc new file mode 100644 index 000000000..e60fe55e1 --- /dev/null +++ b/modules/ROOT/pages/exp-models-manage-costs.adoc @@ -0,0 +1,46 @@ += Managing Models and Model Costs +:keywords: models, model costs, cost per token, input tokens, output tokens, spend tracking, budgets, model proxies, cost management, anypoint platform + + +The *Models* page lists the AI models available in your organization. Set the cost per token for each model so that token usage translates into accurate spend and budget tracking across model proxies and wallet budgets. + +== Before You Begin + +To manage model costs, you need: + +* An Anypoint Platform account. +* Any of these permissions: ++ +-- +** API Manager: API Creator to create instances +** API Manager: View APIs Configuration to view instances +** API Manager: Edit APIs Configuration to edit instances +-- ++ +For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. + +== View Models + +. From *Portfolio* > *Model Proxies* > *Model Wallets*, select *Models*. +. Review the list of available models. +. To see details for a model, select its name. ++ +The model detail page shows the model proxies that surface the model and its configured costs. + +[[edit-model-costs]] +== Edit Model Costs + +Model costs drive spend and budget calculations. Configure them for each model you use. + +. On the *Models* page, select a model — for example, `Claude 3.5 Haiku`. +. Select *Edit model costs*. +. Enter the *Cost per 1K input tokens* — for example, `0.001`. +. Enter the *Cost per 1K output tokens* — for example, `0.005`. +. Select *Save changes*. + +Models without configured costs default to zero and don't factor into spend tracking or budget calculations. If a model's costs aren't configured, wallet budgets don't reflect actual usage for that model. See xref:exp-model-wallets-manage.adoc[]. + +== See Also + +* xref:exp-model-wallets-manage.adoc[] +* xref:exp-governance-view-cost-and-token-usage.adoc[] \ No newline at end of file From 9de9c131411e50e51249d3d83e2eadc731b4b16e Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Tue, 18 Aug 2026 16:53:29 -0700 Subject: [PATCH 28/30] Adding business outcomes --- .../pages/af-use-case-cost-management.adoc | 18 +++++++++++++----- modules/ROOT/pages/af-use-case-mcp-bridge.adoc | 18 +++++++++++++----- .../ROOT/pages/af-use-case-orchestration.adoc | 18 +++++++++++++----- modules/ROOT/pages/agent-fabric-use-cases.adoc | 12 +++++++++--- 4 files changed, 48 insertions(+), 18 deletions(-) diff --git a/modules/ROOT/pages/af-use-case-cost-management.adoc b/modules/ROOT/pages/af-use-case-cost-management.adoc index 7d8acf704..afc64d19d 100644 --- a/modules/ROOT/pages/af-use-case-cost-management.adoc +++ b/modules/ROOT/pages/af-use-case-cost-management.adoc @@ -4,11 +4,11 @@ Agent Fabric gives you full visibility into token consumption and spend across e Key benefits include: -* Full cost visibility: See token consumption and spend by application, agent, user, and model in one place. -* Cost-optimized routing: Route each request to the right model at the right cost with semantic routing. -* Enforced budgets: Cap token or spend usage with Model Wallets that block requests when a budget limit is reached. -* Consistent governance: Apply the same policies, prompt protection, and automatic fallback across every provider. -* Cost attribution: Trace every token and dollar to the team, application, or agent that drove them. +* Stop budget overruns before they happen: Model Wallets block requests when a budget limit is reached, so an unattended agent can't run spend past the cap. The limit is enforced, not just flagged. +* Cut cost without cutting quality: Semantic routing sends routine queries to a cheaper, faster model and reserves higher-cost models for complex work, lowering average cost per query while holding response quality. +* Turn spend into decisions: See token consumption and cost by application, agent, user, and model in one place, so you can act on what's driving cost instead of guessing. +* End cost surprises: Trace every token and dollar to the team, application, or agent that drove it, so overruns have an owner and a root cause. +* Govern once, everywhere: Apply the same policies, prompt protection, and automatic fallback across every provider, so adding a model or team doesn't mean rebuilding controls. * Govern once, everywhere: Apply the same policies, prompt protection, and automatic fallback across every provider, so adding a model or team doesn't mean rebuilding controls. == The Problem @@ -85,6 +85,8 @@ With Agent Fabric you get complete cost visibility: . Generate cost dashboards showing usage patterns. . Identify high-cost agents and opportunities for optimization. +*Result:* Every dollar of LLM spend maps to the business unit, application, and agent that drove it. Leaders can see which deployments cost the most and target optimization where it pays off, instead of splitting an unattributed bill across teams. + === Scenario 2: Semantic Routing for Customer Support *Challenge:* A customer support agent system uses expensive models for all queries, including simple lookups. @@ -97,6 +99,8 @@ With semantic routing you cut cost without sacrificing quality: . The Model Proxy analyzes each request and routes it appropriately. . Monitor quality metrics to ensure the customer experience isn't impacted. +*Result:* Routine lookups, which are often the majority of support traffic, move to a model that can cost roughly an order of magnitude less per query, while complex cases still reach a more advanced, higher-cost model. Average cost per query drops with no measurable change in resolution quality. + === Scenario 3: Budget Controls for Development Teams *Challenge:* Development teams experimenting with agents have no spending limits, leading to budget surprises. @@ -108,6 +112,8 @@ With Model Wallets you get budgets agents can't overrun: . Enable hard limits so requests are blocked when a budget is reached rather than allowed to overrun. . Give teams visibility into budget consumption through the Model Proxy dashboard. +*Result:* A runaway experiment stops at its cap instead of surfacing as a month-end invoice. Finance gets predictable per-team spend, and teams keep the autonomy to experiment within a limit they can see. + === Scenario 4: Multi-Model Optimization *Challenge:* An organization uses multiple LLM providers but doesn't know which models are most cost-effective for its use cases. @@ -119,6 +125,8 @@ With Agent Fabric you get evidence-based model selection: . Analyze which models deliver the best cost/quality ratio for each use case. . Adjust routing rules based on the data. +*Result:* Model selection becomes an evidence-based decision instead of a default. Each use case runs on the provider that delivers the best cost and quality ratio for it, and routing keeps pace as providers change pricing or release new models. + == Implementation Steps Follow these steps to set up cost management in Agent Fabric. diff --git a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc index c6e8a32b4..12fe2ce44 100644 --- a/modules/ROOT/pages/af-use-case-mcp-bridge.adoc +++ b/modules/ROOT/pages/af-use-case-mcp-bridge.adoc @@ -4,11 +4,11 @@ Agent Fabric MCP Bridge transforms your existing API instances into agent-ready Key benefits of MCP Bridge include: -* Rapid enablement: Gets agents connected to APIs quickly, without custom development. -* Security by default: Exposes only the operations you explicitly map as tools. -* Consistency: Gives all agents access to APIs through the same controlled interface. -* Reuse existing investments: Works with APIs managed through Anypoint Platform. -* Centralized governance: Provides a single point of control for agent API access. +* Connect agents in minutes, not weeks: Turn an existing API into agent-ready tools through configuration alone, skipping the custom integration each agent platform would otherwise require. +* Never expose an operation by accident: Agents can call only the operations you explicitly map as tools, so write and delete stay off-limits unless you choose to expose them. +* One controlled interface for every agent: All agents reach your APIs the same way, eliminating the inconsistent, per-platform access that's hard to audit. +* Get more from what you already built: Reuse APIs managed through Anypoint Platform without rebuilding them for agentic use. +* Govern agent API access from one place: A single point of control means access, policy, and monitoring don't fragment as you add agents. == The Problem @@ -70,6 +70,8 @@ With MCP Bridge, you get rapid deployment with built-in safety: . Deploy the instance (policies execute on Omni Gateway). . Connect all agent platforms to the MCP server endpoint. +*Result:* Agents answer account and order questions with zero write access exposed, from a single configuration. There is no per-platform integration to build or maintain, and no path for an agent to modify customer data. + === Scenario 2: Inventory Check Agent *Challenge:* Your inventory API includes operations to check stock levels, reserve items, adjust quantities, and process transfers. Sales agents, warehouse agents, and customer service agents all need to check current stock, but only warehouse systems should adjust it. @@ -83,6 +85,8 @@ With MCP Bridge, you give all agents read-only inventory access from a single co . Connect all agent types to the MCP server endpoint. . Monitor agent usage in the enhanced MuleSoft experience. +*Result:* Sales, warehouse, and customer service agents all read live stock levels from one read-only tool surface, while stock adjustments stay restricted to warehouse systems, without building or maintaining a filtered endpoint per agent type. + === Scenario 3: Financial Data Agent with Layered Tool Selection *Challenge:* Different agents need different levels of access to financial APIs. @@ -98,6 +102,8 @@ With MCP Bridge, you get fine-grained access control with safety guarantees: . Connect each agent to the appropriate MCP server endpoint based on access requirements. . In API Manager, apply policies to each MCP server instance. +*Result:* Each agent gets exactly the access its role requires. Agents balances only, analytics or approval requests from one financial API, with no duplicated integrations and no path for a high-privilege operation to reach the wrong agent. + === Scenario 4: Mule Integration Platform *Challenge:* Your organization has extensive Mule infrastructure and wants to enable agentic access without rebuilding integrations. @@ -111,6 +117,8 @@ With MCP Bridge, you extend your existing Mule investment to agentic use cases: . Deploy the instances (policies execute on your existing Omni Gateway infrastructure). . Monitor through the enhanced MuleSoft experience and apply policies in API Manager. +*Result:* Existing Mule APIs become agent-callable without new adapters or duplicated logic, and agent traffic inherits the same Anypoint Platform governance already protecting those APIs. + == Implementation Steps === Step 1: Identify APIs for Agent Access diff --git a/modules/ROOT/pages/af-use-case-orchestration.adoc b/modules/ROOT/pages/af-use-case-orchestration.adoc index 3f93c6799..48974d33e 100644 --- a/modules/ROOT/pages/af-use-case-orchestration.adoc +++ b/modules/ROOT/pages/af-use-case-orchestration.adoc @@ -4,11 +4,11 @@ Agent brokers and agent networks coordinate task delegation across specialized a Key benefits of agent networks and brokers include: -* Guided determinism: Graph-based routing makes sure that specific operations run in the correct order, with defined paths for both expected outcomes and error conditions. -* Specialized coordination: Route each task to the agent best suited to handle it, rather than building one agent that tries to do everything. -* Reusable components: Publish brokers and agent networks to your portfolio so other teams can discover and compose them into their own networks. -* End-to-end observability: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer. -* Incremental composition: Start with a simple agent network and add brokers as complexity grows. You don't need a broker to get started. +* Reliable outcomes from complex processes: Graph-based routing runs operations in the correct order with defined paths for both expected outcomes and error conditions, so multi-step processes behave predictably instead of drifting. +* Better results by using the right specialist: Route each task to the agent best suited to handle it, instead of stretching one agent to do everything and accepting weaker output on every task. +* Build once, reuse across teams: Publish brokers and agent networks to your portfolio so other teams compose them into their own networks rather than rebuilding the same process. +* Know exactly where a process failed: Monitor broker routing decisions, agent performance, and request flows with Agent Visualizer, so a failure points to the agent and step that caused it. +* Start small, scale when ready: Begin with a simple agent network and add brokers as complexity grows. You don't need a broker to get started, so there's no upfront coordination cost. == The Problem @@ -66,6 +66,8 @@ Agent brokers and agent networks provide reliable coordination with clear routin . Deploy the agent network to CloudHub 2.0. . Monitor execution in Agent Visualizer to trace each step and identify where issues occur. +*Result:* Orders move through inventory, payment, and fulfillment on defined paths, with explicit handling for shortfalls and payment failures instead of silent breakage. When a step fails, Agent Visualizer shows which agent and which state, so recovery is fast rather than a guessing game. + === Scenario 2: Multi-Discipline Research *Challenge:* Answering a strategic research question requires market analysis, competitive intelligence, technical feasibility assessment, and financial modeling — capabilities that belong in separate specialized agents. @@ -77,6 +79,8 @@ With an agent network, a broker decomposes the request and coordinates the speci . The synthesis agent produces the final report from the aggregated specialist outputs. . Agent Visualizer shows the routing path, which agents were called, and where time was spent. +*Result:* A strategic question is answered by four specialists working in parallel and synthesized into one report. The report is faster and higher-quality than a single general-purpose agent, with a visible trail of which analysis contributed what. + === Scenario 3: Document Processing Pipeline *Challenge:* Processing incoming documents requires classification, data extraction, quality validation, and routing for human review — in sequence, with defined rules for what happens when quality thresholds aren't met. @@ -87,6 +91,8 @@ With guided determinism in Agent Script: . Define a broker with nodes for each processing stage and explicit paths for low-confidence extractions that require human review. . Deploy the network and monitor processing quality and throughput in Agent Visualizer. +*Result:* Documents flow through classification, extraction, and validation automatically, and only low-confidence cases route to a human. Staff review the exceptions instead of every document, and quality thresholds are enforced by the graph rather than left to chance. + === Scenario 4: Customer Support Triage *Challenge:* Incoming support requests range from simple account questions to complex technical issues and billing disputes. Each type requires a different specialized agent, and misrouting wastes time. @@ -98,6 +104,8 @@ With a broker handling intelligent triage: . The broker consolidates the specialist's response and returns it to the caller. . Publish the agent network to Exchange so other teams can reuse the triage broker. +*Result:* Requests reach the right specialist on the first hop, so account, technical, and billing issues stop bouncing between the wrong agents. Publishing the triage broker to Exchange lets other teams adopt the same routing instead of rebuilding it. + == Implementation Steps === Step 1: Map the Process diff --git a/modules/ROOT/pages/agent-fabric-use-cases.adoc b/modules/ROOT/pages/agent-fabric-use-cases.adoc index 36c99775c..5f20abe51 100644 --- a/modules/ROOT/pages/agent-fabric-use-cases.adoc +++ b/modules/ROOT/pages/agent-fabric-use-cases.adoc @@ -1,6 +1,12 @@ = Agent Fabric Use Cases -Agent Fabric addresses the most common challenges in enterprise AI agent management, from discovering and governing agents across platforms, to making existing APIs agent-ready without custom development, and keeping token costs under control. Each use case maps a specific business problem to a set of Agent Fabric capabilities so you can identify where to start and build incrementally. Use the quick-reference table to match your immediate goal to the right capability. +== Why Agent Fabric + +Enterprises don't struggle to build one agent. They struggle to run many — across Agentforce, Bedrock, custom Mule implementations, and vendor platforms — without losing control of cost, security, and consistency. The usual response is to solve each problem per platform: custom API adapters here, a spend dashboard there, guardrails reimplemented for every team. That work duplicates effort, drifts out of sync, and leaves gaps no one owns. + +Agent Fabric replaces that per-platform sprawl with one governed layer that every agent, API, model, and provider routes through. Expose APIs as agent tools without touching code, enforce the same policies and budgets everywhere, attribute every token to the team that spent it, and contain a rogue agent before it causes damage — all from a single point of control. The result is faster time-to-agent, predictable spend, and governance that holds as you scale from proof of concept to production. + +Each use case below maps a specific business problem to the Agent Fabric capabilities that solve it, so you can start where the pain is and build incrementally. Use the quick-reference table to match your immediate goal to the right capability. == Find Your Use Case @@ -48,11 +54,11 @@ Consistently enforce business rules, PII policies, and guardrails across all age //For more information, see xref:af-use-case-policy-enforcement.adoc[]. -== Monitor Costs and Optimizing Model Selection +== Monitor Costs and Optimize Model Selection Monitor token usage across applications and agents, then optimize costs by routing simple queries to cost-effective models while reserving powerful models for complex tasks. For example, a team running hundreds of daily agent interactions can route routine lookups to a smaller, cheaper model and reserve a frontier model only for tasks that require complex reasoning. -xref:af-use-case-cost-management.adoc[]. +For more information, see xref:af-use-case-cost-management.adoc[]. == Coordinate Multi-Agent Processes with Brokers From ef569285a5fc5700d09581fa44a8b34be0c7eb13 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 20 Aug 2026 08:23:41 -0700 Subject: [PATCH 29/30] Moving kill switch in nav --- modules/ROOT/nav.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/modules/ROOT/nav.adoc b/modules/ROOT/nav.adoc index 6f630d0a8..78e27f949 100644 --- a/modules/ROOT/nav.adoc +++ b/modules/ROOT/nav.adoc @@ -23,6 +23,7 @@ *** xref:model-proxy-request.adoc[] *** xref:model-proxy-semantic-service.adoc[] *** xref:model-proxy-try-out.adoc[] + *** xref:exp-detect-and-contain-rogue-agents.adoc[] ** xref:exp-scanners-add-from-providers.adoc[] *** xref:exp-scanners-prerequisites-reference.adoc[] *** xref:exp-scanners-view-details.adoc[] @@ -33,7 +34,6 @@ *** xref:exp-models-manage-costs.adoc[] *** xref:exp-model-wallets-manage.adoc[] ** xref:exp-akamai-risk-correlation.adoc[] - ** xref:exp-detect-and-contain-rogue-agents.adoc[] ** xref:exp-governance-work-with-strategies.adoc[] *** xref:exp-governance-create-strategy.adoc[] *** xref:exp-governance-manage-strategies.adoc[] From b2d2d939019995af0c6bb83791ba7a2797d79c75 Mon Sep 17 00:00:00 2001 From: valkyrie69 Date: Thu, 20 Aug 2026 16:54:53 -0700 Subject: [PATCH 30/30] Updated Model Wallets prereqs --- .../ROOT/pages/exp-model-wallets-manage.adoc | 24 ++++++++++++++++--- 1 file changed, 21 insertions(+), 3 deletions(-) diff --git a/modules/ROOT/pages/exp-model-wallets-manage.adoc b/modules/ROOT/pages/exp-model-wallets-manage.adoc index f0aead320..06a577b28 100644 --- a/modules/ROOT/pages/exp-model-wallets-manage.adoc +++ b/modules/ROOT/pages/exp-model-wallets-manage.adoc @@ -11,19 +11,35 @@ Each wallet has a system-generated client ID and required JWT claims that you de To manage model wallets, you need: * An Anypoint Platform account -* A configured identity provider (IdP), with a JWT validation policy applied to the model proxies that the wallet authorizes -* Any of these permissions: +* At least one configured model proxy. See xref:model-proxy-create-model-proxy.adoc[]. +* A configured identity provider (IdP) that issues JWTs for callers +* A xref:gateway::policies-included-jwt-validation.adoc[JWT Validation] policy applied to each model proxy that the wallet authorizes. Apply this policy on the model proxy in the enhanced experience. See <>. +* These permissions: + -- ** API Manager: API Creator ** API Manager: View APIs Configuration ** API Manager: Edit APIs Configuration +** API Manager: Manage Policies, to apply the JWT Validation policy -- + For more information, see xref:exp-home-start.adoc#permissions[Enhanced Experience Permissions]. Organizations without an IdP configured can't use model wallets. Those organizations continue to use existing access methods. +[[apply-jwt-validation-to-a-model-proxy]] +== Apply a JWT Validation Policy to a Model Proxy + +A model wallet matches the client ID and JWT claims in a request. The JWT Validation policy on the model proxy validates the token from your IdP first. Apply the policy on each model proxy that callers reach through the wallet. You apply it from the model proxy, not from *Model Wallets*. + +. From *Portfolio* > *Model Proxies*, open the model proxy. +. Select the *Policies* tab, then select *+Apply Policy*. +. Select *JWT Validation* and select *Next*. +. Configure the policy to validate tokens from your IdP, including the JWT origin and the JWKS URL or signing key. For configuration parameters, see xref:gateway::policies-included-jwt-validation.adoc[]. +. Select *Apply Policy*. + +Repeat these steps for each model proxy the wallet authorizes. + [[create-a-model-wallet]] == Create a Model Wallet @@ -41,7 +57,7 @@ This value is read-only. Callers send it as the `X-Client-Id` request header to ** To add more claims, select *Add Claim* again. -- + -NOTE: Model wallets use the JWT validation policy configured across agent tools and instances. +The required claims must match claims in the JWT after the JWT Validation policy on the model proxy validates the token. . (Optional) Add one or more budgets to cap spend or token usage. See <>. . Select *Create Model Wallet*. @@ -95,5 +111,7 @@ Budgets are approximate rather than a real-time hard cutoff. The system tracks t == See Also +* xref:model-proxy-create-model-proxy.adoc[] +* xref:gateway::policies-included-jwt-validation.adoc[] * xref:exp-governance-view-cost-and-token-usage.adoc[] * xref:exp-services-register-manually.adoc[] \ No newline at end of file