Client deck, Part 1: worked example

This deck is the client-facing companion to the guide Assessing an AI Control Plane Project. Part 1 presents reference use case 1 from The AI Control Plane Handbook (engagement launch at a global audit, tax and advisory firm) as a finished assessment readout. Part 2 is the same storyline as a template.

The design, diagrams and wording match the executive deck The AI Control Plane, so the two can be used together. Superscripts and bracketed numbers refer to the handbook’s endnotes.

Internal slide for the lead architect and the engagement lead. Leave it out of the readout you present.

Part 1 is reference use case 1 from the handbook (professional services engagement launch), presented as a finished client readout. Use it to show a client what the assessment produces, or as the model answer when you fill in Part 2.

Part 2 is the same storyline as a template. The MuleSoft Agent Fabric and Informatica capabilities are pre-filled because they do not change from client to client. Everything that does is a bracketed prompt. The guide explains each template (T1 to T13) and gives the use case 1 answer for every one.

The standards and regulation dates slide in the appendix keeps protocol versions and regulation dates in one place. Check it before every readout.

The last two slides are the notices (the license, the toolkit’s additional permission, the trademarks and the credits) and a note about the author. Keep the credit line, the icon credit and the trademark notice in readouts built from Part 2.

John Fisher works for Salesforce. The views here are his own, not Salesforce’s, and are drawn from public information; this toolkit is not affiliated with or endorsed by Salesforce. Product names are trademarks of their owners. Illustrative figures are not results from any customer.

Part 1 starts here. It is written as the readout you would give the firm’s executive sponsor at the end of a five-week assessment. Everything specific to the firm is illustrative. Product descriptions come from public information.

Engagement lead opens: thank the sponsor, restate the goal of the meeting (agree the plan and the decisions for the next 90 days) and walk the agenda. The lead architect presents parts 3, 5 and 6, the engagement lead presents 1, 4, 7 and 8, and part 2 is shared.

Talk track (two minutes): This is the first of three reference use cases that show the control plane working end to end on a real process. It is written for a global audit, tax and advisory firm, and the architecture is vendor-neutral except for the transactional systems the process already runs on: a CRM, SAP S/4HANA, Workday and Snowflake.

The problem: between a verbal win and the first chargeable hour sits a chain of manual, risk-sensitive steps owned by different functions in different systems. Delays leave people on the bench and let early work go unbilled, and a missed affiliate relationship can become an auditor-independence breach, with regulatory consequences, when the client or its parent is an audit client [89].

In the target state, an Engagement Launch Orchestrator coordinates six specialist agents: Entity Resolution, Conflicts & Independence, Scoping & Letter, Pricing & Budget, Staffing and Engagement Setup. People keep every judgment that carries professional or regulatory accountability (independence decisions, engagement terms, partner approval). Agents do the assembly, checking, drafting and system updates, and the control plane makes every step governed, observable and auditable.

All figures in this use case are illustrative. Replace them with the firm's own baseline during discovery. The companion handbook (Section 11) has the full detail.

Lead architect: explain how the assessment ran, so the client trusts where the numbers and the design came from.

1. Frame: the use case, its goals and scope, and the value hypothesis, agreed with the sponsor. 2) Discover: an inventory of the applications, data, integrations, agents, models, identities, policies and infrastructure the launch touches, and the KPI baselines. 3) Define: requirements and security for every layer, and a tier for every agent. 4) Design: a vendor-neutral north star, a day in the life, how the components work together, and its realization with MuleSoft Agent Fabric and Informatica. 5) Phase: milestones with value at every step, quick wins first. 6) Decide: this readout, with the operating model that keeps the program running.

The workshops are listed along the bottom. Each produced one or more templates in the assessment report.

Lead architect: summarize discovery in one minute, then land the four findings.

The numbers on the left are the assets the launch depends on: six systems of record, seven agents (an orchestrator and six specialists), four models, fifteen MCP tools to publish, four master data domains and nine policies and controls that must be enforced at runtime rather than on paper.

Discovery found that a launch crosses six systems and four functions with no shared engagement ID. The client hierarchy is the weak link, because a missed subsidiary is a missed conflict. AI is already in use but ungoverned, with no registry, gateway or measure of cost and quality. And setup lags the work, so early hours go unbilled on about a quarter of launches. All findings are illustrative for this example.

Walk the six columns left to right. Systems of record: what the launch runs on today, and whether agents need read or write access. Master data: the golden records and reference data the agents depend on. The client hierarchy is on the critical path. MCP tools and APIs: the capabilities to expose once, with read or write scopes. Agents and tiers: seven agents, each with an owner and an autonomy tier. Models: four, routed by policy so client-confidential text stays on private models. Policies and controls: the rules that must be enforced at runtime in the gateway path.

Every item has an owner and a phase in the inventory tables.

Walk the six stages left to right. For each, point to the human step (amber), the agent and its autonomy tier (blue), and the governed path underneath: every agent reaches its system of record only through the control plane and a governed MCP tool or API.

• Verbal win: the CRM event starts the Launch Orchestrator, which posts a launch plan to the engagement manager.
• Accept client: the Entity Resolution agent matches the client to its MDM golden record and corporate hierarchy (read-only).
• Risk clearance: the Conflicts & Independence agent assembles findings and precedent. Risk & Quality decides (Tier 1).
• Scope & price: the letter is drafted from approved clauses. The budget comes from SAP rate cards and Snowflake actuals. The manager edits.
• Staff team: a proposal from Workday skills and availability plus a yes/no independence-clearance flag. The manager confirms.
• Approve & set up: partner approval and client signature open the gate. Only then does the Setup agent write to SAP S/4HANA (Tier 3, policy-gated).

The outcome to land: verbal win to ready-to-charge in about two days instead of two weeks (illustrative), with every independence decision made by a person, before work starts, with evidence attached.

Business case, illustrative for a firm launching 10,000 engagements a year:

• Capacity released: manual assembly, checking and data entry falls from about 14 to 5 hours per launch across managers, Risk, resourcing and finance. 10,000 launches × 9 hours × $120 loaded cost is about $10.8M a year.
• Revenue protected: charge codes exist when work starts, so early hours are billed instead of written off. 2,500 affected launches × 20 hours × $200 average rate is about $10.0M.
• Higher utilization: teams are confirmed within days instead of weeks. 0.5 point × 5,000 client-facing staff × 1,800 hours × $200 is about $9.0M.
• Risk avoided: every independence decision is made by a person before work starts, with evidence and lineage. Not quantified.

Roughly $30M a year released or protected before platform, model and change costs, which should be estimated alongside the baseline.

Expected business outcomes: faster time to revenue (about two business days from verbal win to ready-to-charge), lower cost to launch, no known independence exceptions at engagement start, and a better client and staff experience.

KPIs: the baselines are illustrative. The KPIs that speak directly to the control plane are governed AI traffic (target: 100% of model and tool calls through the gateway) and AI cost per launch within target. Agent evaluation pass rate covers letter-clause accuracy and independence-finding recall.

Lead architect: the register has 23 requirements. These 16 are the ones the architecture turns on.

Business: the two KPI targets (2 days, 5 hours), the rule that people make every independence decision, and the AI cost target. Functional: the golden record, Tier 1 independence, cleared staff only, and the gated SAP write. Data and integration: the golden record per legal entity, one engagement ID, data contracts and lineage, and governed APIs and MCP tools. Operations: failover and idempotent writes, one trace per engagement, evaluation before promotion and on sampled live traces, and evidence kept for inspections. The register also makes a drilled takeover runbook a condition of tier 3 (OR-03).

Each requirement links to a KPI and a phase in the register, so the plan and the scorecard trace back to it.

Lead architect: security follows zero-trust principles [90]: every actor is authenticated, every call is authorized for the specific task, and nothing is trusted because of where it sits on the network.

Walk the nine layers. Users get phishing-resistant MFA, with step-up for partners. Agents have a workload identity per instance [91] and no static API keys [46], with least privilege, a kill switch and no self-approval. A2A uses signed agent cards verified by the registry, mTLS plus OAuth [27], and on-behalf-of tokens with narrowed scopes [92]. MCP allows only registered, version-pinned servers behind the gateway, with per-tool scopes, schema validation, and policy on the standard MCP request headers with every call joined to its trace [26]. Pinned tool definitions are firm practice. Then cover APIs, models (gateway only, zero retention, masking, output validation [93]), data at rest and in motion, and tamper-evident audit.

Then the tiers on the right: only the setup agent writes to a system of record, and only when independence is cleared, the partner has approved that exact request and the client has signed. The approval expires at the end of the business day.

Tiers move both ways: an agent moves up only on evidence (evaluations over a sustained period, red-team findings closed, an up-to-date impact assessment) and drops automatically on a security event, a failed binding check or stale data [33]. The controls map to the OWASP Top 10 for Agentic Applications [48]. The report’s security section shows the mapping and the owners of the two gaps no gateway closes alone. And if the setup agent is ever stopped, finance takes over its open launches with the launch trace in hand, under a runbook drilled before tier 3 [64].

This is the vendor-neutral solution architecture, aligned to the north-star reference architecture. Only the systems of record are named products. Everything else is replaceable.

Orchestration model selected: hybrid/federated. The control plane governs identity, policy, cost and audit centrally, while Risk & Quality, Finance and Talent own their agents. Within a launch, a supervisor pattern applies: the orchestrator delegates tasks to specialist agents over A2A [27], and agents reach tools and data only through MCP servers [26]. The regulated sequence is deterministic and does not depend on model reasoning: no letter before independence is cleared, no SAP write before partner approval and client signature.

Models and routing: a frontier model under enterprise terms with zero data retention drafts letters and summarizes findings, with a second provider for failover. A self-hosted open-weight small language model handles extraction, classification and personal-data detection, and embeddings run on a private endpoint. The AI gateway sends client-confidential payloads only to private models or approved regions and sets token budgets per launch.

Data governance covers client and legal-entity, worker and engagement golden records and a semantic layer (glossary, metric definitions and a data contract for each MCP tool). A catalog with lineage lets a reviewer see which records drove an independence finding, and access policies enforce masking and information barriers between engagements.

Security at every level: the design follows zero-trust principles [90] and gives each agent instance a unique workload identity [91]. A2A calls use on-behalf-of token exchange with narrowed scopes [92]. MCP servers are OAuth-protected, with per-tool scopes and no token pass-through [26], and as firm practice their tool definitions are reviewed and pinned. The design also uses prompt-injection screening and output validation [93]. Data at rest uses AES-256 with customer-managed keys, and data in motion uses TLS 1.3 and mTLS.

Observability: every hop emits OpenTelemetry traces using the generative-AI semantic conventions, tied to one engagement correlation ID [94].

Tell Maya's day as a story.

At 08:05 the CRM opportunity for Project Atlas moves to verbal win, and within a minute Maya's chat copilot shows a launch plan targeting ready-to-charge in two days. By 08:12 the entity-resolution agent has matched the client to its golden record and found that it is a subsidiary of a group whose parent is an audit client, so an enhanced independence review starts automatically. At 09:40 a reviewer in Risk & Quality approves the engagement with one condition: no work on financial-reporting systems.

The scoping agent drafts the engagement letter with that carve-out by 10:30, and Maya rewrites two paragraphs. The pricing agent's budget arrives at 11:20 with a 31% margin against a 30% target. At 13:05 the staffing agent proposes a team of five, having already replaced a consultant who is not independence-cleared for this client. Maya sees only that a substitution was required, not why. The partner approves the letter and budget on mobile at 14:30 with step-up authentication, and the letter goes to the client for signature. At 16:10 the client signs, the setup agent creates the SAP project, WBS and billing plan, and the team receives charge codes.

End the story on the result: what used to take two weeks finished the same day, and every accountable decision was still made by a person.

Read the numbered steps top to bottom. They follow Maya's day.

Steps 1–6 (08:05–08:12): the CRM event starts the orchestrator, which delegates entity resolution and the independence check over A2A [27]. The agent's MCP calls carry a delegated, on-behalf-of token [92], and the control plane authorizes read scopes only [26]. The MDM returns the golden record and flags the affiliate of an audit client, and lineage is captured.

Steps 7–9 (09:40): a private small language model summarizes the findings, and a Tier 1 review task goes to Risk & Quality. The decision is made there, never by the agent, and it is signed and logged.

Steps 10–13 (10:30–13:05): the orchestrator delegates drafting, pricing and staffing. Drafting uses the frontier model with personal data masked, and retrieval is filtered by information barriers. Rate cards, actuals and availability are read through MCP under row-access policies. Staffing sees only a yes/no clearance flag, never the underlying personal financial interests.

Steps 14–18 (14:30–16:10): the partner approves with step-up MFA, and the policy decision point confirms that the engagement is cleared, approved and signed. Only then does the gateway allow the SAP write tools, and the setup agent creates the project, WBS and billing plan with idempotent calls. The partner's approval is bound to the exact setup request and expires at the end of the business day.

Every hop emits an OpenTelemetry span and an audit event [94], tokens are metered against the launch budget, evaluations are sampled, and the kill switch is available throughout.

How MuleSoft Agent Fabric and Informatica realize the vendor-neutral design. Colors show which vendor fills each role. Grey boxes remain the firm's choice (collaboration tools, models, agent frameworks and systems of record).

• Registry and discovery: Agent Registry and Agent Scanners register every launch agent, including agents other teams built on other platforms, with owner and autonomy tier [21].
• Orchestration: Agent Broker with guided determinism enforces the fixed gates for independence, approvals and signature. A2A support handles delegation [21].
• Gateway: AI Gateway is the single policy point for LLM and MCP traffic (routing, token limits, masking). Omni Gateway applies authentication, mTLS and rate-limit policies to APIs and A2A [21][78].
• Identity and control: Trusted Agent Identity lets agents act on behalf of Maya or the partner, with mobile approval for high-risk steps [21]. A custom Omni Gateway policy, built with the Policy Development Kit, binds each approval to the executed call [78]. Agent Kill Switch, Agent Visualizer and AI cost controls (token-based rate limits and spend attribution) operate the system [21], and letters and findings are tested before release with the firm's evaluation tool.
• Tools: MCP Bridge turns existing APIs into governed MCP tools, and MuleSoft connectors reach SAP S/4HANA, Workday, Snowflake and the CRM without rewriting integrations [21].
• Data foundation (Informatica): Multidomain MDM provides client, worker and engagement golden records that agents reach through governed APIs, while data quality rules validate entity data at the point of entry and the Address Verification MCP server validates and standardizes addresses. Data Governance and Catalog gives agents and people a shared glossary and lineage, and agents find data assets through the CDGC Metadata Search MCP server [77].
• Deployment: Runtime Fabric keeps gateways and MCP servers inside the firm's VPC where confidentiality requires [21].

Lead architect: this is the requirement-to-capability map for the launch. Every reference component in the vendor-neutral design maps to a MuleSoft Agent Fabric, MuleSoft or Informatica capability, with the role it plays in the launch.

Approval binding is a custom Omni Gateway policy built with the Policy Development Kit, not a MuleSoft product, so agree who builds, tests and supports it [78]. The evaluation suites run with any evaluation tool, such as Amazon Bedrock AgentCore Evaluations or Microsoft’s open-source ASSERT framework, with the results recorded in the registry [62][63]. MDM APIs exposed through MCP Bridge give the agents governed access to the golden records, and the CDGC Metadata Search and Address Verification MCP servers cover catalog search and address checks [77].

Lead architect: a client that runs Microsoft 365 or AWS already has an agent control plane in those estates, so show how the planes divide the work. Microsoft describes Agent 365 as “the control-plane for AI agents”, with Microsoft Entra Agent ID for agent identities [12]. AWS offers Amazon Bedrock AgentCore, with a runtime, memory, a gateway for MCP servers, identity and observability [62]. Google’s Gemini Enterprise Agent Platform includes an agent registry, an agent gateway and agent identities [47].

Each governs its own estate well. The answer is a division of labor agreed up front: each native plane stays authoritative for identity and runtime in its own estate, and MuleSoft Agent Fabric is authoritative for the cross-estate inventory, for policy on every call into enterprise capabilities and data, for orchestration across vendors, and for cost and audit [21]. Microsoft’s own Cloud Adoption Framework asks for consistent policy across every agent platform [14].

For the firm, the band at the bottom is the agreement to confirm with the chief architect: the collaboration platform keeps its own controls, the identity provider stays authoritative for people, and every call the launch agents make into the systems of record passes through Agent Fabric.

This slide shows the north star realized: every layer of the vendor-neutral architecture maps to a MuleSoft or Informatica capability. The control plane (layer 2) sits between consumer workloads and the models and data beneath, and applies identity, policy, routing, cost controls and audit to every agent-to-model and agent-to-tool call.

How the layers map:

1. Consumers and workloads: agents from any platform (Agentforce, Copilot Studio and Foundry, Bedrock AgentCore, Gemini Enterprise Agent Platform), copilots and MCP clients such as Claude, Slack and Teams, and B2B systems, discovered by Agent Scanners and registered in Agent Registry [21].
2. Control plane, MuleSoft Agent Fabric: Agent Registry and Scanners (inventory), Agent Broker (orchestration), AI Gateway (one policy point for LLM and MCP traffic), Trusted Agent Identity, and Agent Visualizer and AI cost controls [21].
3. Models: five model classes, routed per task by AI Gateway's intelligent model routing, with token-based rate limits and spend attribution [1][21].
4. Capabilities and data: MuleSoft system and process APIs, MCP Bridge and connectors with IDP and RPA, plus Informatica for master data, data quality, catalog and lineage (with data services exposed to agents through Informatica's MCP servers) and Salesforce Data 360 for customer data [21][77].
5. Infrastructure and resilience: multi-cloud and edge, CloudHub or customer-managed Runtime Fabric, post-quantum-ready transport, OpenTelemetry and audit logs, and failover.

Across every layer: Omni Gateway policies (including custom ones), Trusted Agent Identity, the Agent Kill Switch, Agent Visualizer and OpenTelemetry traces, and Informatica governance and lineage.

Design rule: nothing in layer 1 calls layer 3 or 4 directly. Every agent-to-model and agent-to-tool call traverses layer 2. In operational technology the rule extends one layer down: no agent reaches a control system except through a governed conduit, and independent safety systems sit beneath everything (reference use case 3 applies this to a gas pipeline operator).

Engagement lead: this slide shows how value arrives while the platform matures. The platform is adopted in four phases, visibility and one policy point first and federation last, which is the sequence published phasing guidance recommends [20]. In the same window, each phase puts a larger slice of engagement launch into production.

Month 3: one service line in one region, read-only entity resolution and independence agents, about $0.5M a year. Month 8: half of all launches, with letters, budgets and staffing proposals, about $8M a year. Month 12: every launch, with SAP setup gated on the partner’s approval bound to that exact request, about $30M a year, the full business case. Month 24: all goals met, about $33M cumulative.

The first slice is a quick win by design. It is read-only, in one scope, on systems that are reachable now, and it leaves reusable foundations behind: the gateway, the registry and the client golden record.

Phased delivery for the engagement-launch use case, aligned with the four phases of the plan. Each milestone widens the scope or raises the autonomy tier only after the previous one has proved its value and its controls.

• Month 3 (phase 1): one service line in one region, about a tenth of launches (1,000 a year). Entity resolution and independence agents work read-only at tiers 1–2, and every model and tool call goes through the gateway from day one. Effort per launch falls from 14 to about 10 hours in scope: 1,000 × 4 hours × $120 is about $0.5M a year.
• Month 8 (phase 2): half of all launches. Agents draft letters and budgets from approved clauses and rate cards, and the staffing agent proposes teams from Workday. Effort falls to about 8 hours (5,000 × 6 hours × $120, about $3.6M) and faster staffing lifts utilization by about a quarter point (about $4.5M): about $8M a year.
• Month 12 (phase 3): every launch. The setup agent writes the SAP project, WBS and billing plan at tier 3 once the partner's approval, bound to that exact request, and the client's signature are in place. All KPI targets are met and the full business case applies: about $30M a year.
• Month 24 (phase 4): run rate and targets sustained, with adjacent processes added on the same controls. Counting each run rate from the milestone at which it was reached, cumulative value by month 24 is about $33M.

All values are illustrative and before platform, model and change costs. The revenue protected by timely charge codes arrives in phase 3, when agents can write to SAP S/4HANA under bound approvals.

Engagement lead and business owner: these are the KPIs the firm’s leadership will judge the program by, with a target at every milestone. Month 3 is measured in the one service line in scope. Month 12 is when all targets are met. Month 24 shows them sustained.

The row along the bottom is the control-plane scorecard, reported monthly to the executive committee and quarterly to the AI governance board: agent coverage, governed traffic, cost per outcome, value realized, oversight effectiveness and time to contain. For this use case, oversight effectiveness means every SAP setup executed exactly as the partner approved it, within the approval’s validity window. AI cost visibility means every model and tool call in scope tagged to its engagement within a day. Only 26% of organizations had full, real-time visibility into AI operating costs in KPMG’s Q2 2026 pulse [8].

Each chip also shows a leading indicator, an early signal that moves within weeks: unregistered agents found, new agents behind the gateway, cost per successful task, spend attributed within a day, acceptance rate, takeover rate and drill time [60]. Evaluate trajectories as well as answers, and measure value rather than adoption [88].

Engagement lead: the value builds in steps from month 3. Run rate at month 3 is about $0.5M a year from one service line, rising to about $8M at month 8 from half of all launches. From month 12 it is about $30M, when every launch is in and the revenue protected by timely charge codes arrives. Counting each run rate only from the milestone at which it is reached, cumulative value by month 24 is about $33M.

For context, 56% of CEOs report no significant financial benefit from AI so far, while strong foundations make meaningful returns three times more likely [79]. High performers build a repeatable capability rather than accumulating pilots [80], and successful deployments start in adjacent processes, prove value, then scale [81].

Net ROI and payback need the cost side: platform, model usage and change. The project team estimates it with the firm, and value is then reported against it at every milestone review. All values are illustrative until the firm’s baseline is measured.

The benchmark in the amber box: in Deloitte’s 2025 survey of 1,854 executives in Europe and the Middle East, a typical AI use case paid back in two to four years, against seven to 12 months for other technology, and only 6% saw payback within a year [82]. In KPMG’s 2025 Global CEO Outlook, 67% of CEOs expected AI returns within one to three years [83]. The first slice releases value within months, which is how phasing beats the benchmark.

Engagement lead: before the decisions, show who owns what once the launch agents are live. BCG estimates that becoming AI-first involves 30% technology and 70% people and organization [85]. In Microsoft’s 2026 Work Trend Index, only one in four people using AI at work said their leadership is clearly aligned on AI [86]. Among the organizations whose AI returns are accelerating, 48% have extremely clear ownership and decision rights [84].

Walk the roles. The managing partner for operations is accountable. The AI governance council owns policy, tiers and no-go zones, and its first no-go zone is written down: no agent decides independence. The head of practice operations owns the value and decides which stages stay human-led. Every launch agent has a named sponsor who recertifies it and makes the first call in an incident. The platform team runs the control plane, the CISO with Risk & Quality can block a release or stop an agent, and finance owns cost attribution and how value is reported.

The work split on the right was agreed stage by stage with the could-AI, should-AI questions. Record it before any decision on roles: 57% of leaders who cut staff because of AI have come to question that decision [87]. Adoption is measured by acceptance and takeover rates [60], not by logins.

Engagement lead closes. Ask for four decisions:

1. Name an owner: one accountable executive and an AI governance council spanning architecture, security, data and the business, with a sponsor for every agent (the previous slide shows who owns what).
2. Fund phase 1: 90 days, one service line in one region, entity resolution and independence agents in read-only mode, every model and tool call through AI Gateway.
3. Adopt the standards: API-led connectivity, MCP and A2A as enterprise policy, with every agent registered and routed through the control plane.
4. Agree how value is reported: baseline the KPIs with finance now.

The right-hand panel is the 90-day plan. Before committing dates, confirm MuleSoft connector coverage for the independence system and document management.