The templates and how to use them

How to use T1

Purpose. Describe the use case on one page, in the client’s words, so everyone agrees what is in and out of scope.

When. Step 1 (frame), updated after discovery.

Who. The engagement lead drafts it with the business owner, and the lead architect adds the stages and systems.

How to fill it

1. Name the use case after its business outcome, for example “Engagement launch: from verbal win to ready-to-charge.”
2. Write the problem today and the target state in two or three sentences each.
3. Fill the trigger, end state, users, systems of record and out-of-scope rows.
4. List five to seven stages. For each, record the human step, the work mode (human-led, AI-assisted or AI-led) and why, the agent and its tier, and the system of record.
5. Write three to five business goals and the control-plane goals, each with the KPI that measures it.
6. Score the use case against the seven selection criteria, with evidence.

Tips

• Keep it to one page and leave the detail to the other templates.
• If you cannot name the end state, the scope is not ready.
• Ask could AI and should AI of every stage (Section 2). A human-led step needs a reason the risk team would accept.

Feeds. Client deck: The use case; At a glance. Client report: sections 1 and 2.

How to use T2

Purpose. State the value at stake as a few levers with formulas that the business owner and finance can check.

When. Step 1 (frame) as a hypothesis, then step 5 (phase) with measured baselines.

Who. The engagement lead, with the business owner and the finance partner.

How to fill it

1. Pick the levers that apply: capacity, revenue, utilization, cost avoided, risk avoided.
2. For each, write how the solution delivers it and the formula with its inputs.
3. Take inputs from the client (volumes, rates, loaded costs) and record their source.
4. Mark each lever’s confidence (high, medium, low) and what would raise it.
5. Total the run rate at full scale, before platform, model and change costs.
6. Record every assumption and who agreed it.
7. Set the total against the published payback benchmarks (Section 6), with separate horizons for generative and agentic slices.

Tips

• Prefer a conservative, checkable figure to a large, vague one.
• Describe risk avoided in words and evidence unless the client has its own number.

Feeds. Client deck: The value at stake, Value arrives at every milestone. Client report: section 4.

How to use T3

Purpose. Record every asset the use case touches, who owns it, how it is controlled today and when the plan needs it.

When. Step 2 (discover), updated through design.

Who. The lead architect, confirmed row by row with each owner.

How to fill it

1. Start from the data request and the process walkthrough, and add one row per asset.
2. Fill T3a to T3h in turn: systems, data, tools, agents, models, identities, policies, infrastructure.
3. For every agent, record an owner, a sponsor, a tier and a status (live, pilot, planned or shadow), its lifecycle stage and next recertification, and any native control plane that already governs it.
4. For every tool and system, record read or write access and whether it exists today or must be built.
5. Add the phase in which each asset is needed.
6. Turn every unknown into an open question in T12.

Tips

• Run Agent Scanners where the client allows. It finds agents and MCP servers people forget.
• “Not enforced today” is a valuable entry, because that is where the control plane adds value first.

Feeds. Client deck: Discovery; Asset inventory. Client report: section 3 and the appendix.

How to use T4

Purpose. Record what the solution must do and the conditions it must meet, each traceable to a KPI and a phase.

When. Step 3 (define), refined in design.

Who. The lead architect, accepted by the business owner and the relevant client owners.

How to fill it

1. Use the prefixes BR, FR, DR, IR, NFR, SR, CR and OR (Section 4).
2. Write each requirement with a measurable acceptance test.
3. Set a priority (Must, Should, Could, Won’t) and the phase in which it must be met.
4. Link each requirement to the KPI it moves or protects.
5. Name an owner who can accept it.
6. Include the operational requirements the control plane needs: evaluation before promotion and on sampled production traces, cost attribution by owner and use case, and a takeover runbook for any agent at tier 3 or above (Section 4).

Tips

• A short register the client owns is more useful than a long one nobody reads. For one use case, 20 to 30 rows is typical.
• Write identity requirements to the vendor-neutral checklist in Section 4: a unique identity per agent, authority that narrows at each hop, no static keys and real-time revocation.
• Fill the control-ID column only when compliance asks for it, from the crosswalk in Section 4 (ISO/IEC 42001, NIST AI RMF, EU AI Act).

Feeds. Client deck: Requirements. Client report: section 5 and the appendix.

How to use T5

Purpose. Set the controls for every layer, the autonomy tier for every agent and the evidence each obligation requires.

When. Step 3 (define), with the requirements and security workshop.

Who. The lead architect with the client’s CISO or security architect and risk and compliance.

How to fill it

1. For each of the nine layers, write the controls the use case needs (Section 4 lists the questions to ask).
2. Record what enforces each control in the realization, and in which phase.
3. Give every agent a tier, a human role, the approvals bound to its actions and its limits.
4. List each regulatory or professional obligation with the evidence it requires and where that evidence is produced.
5. Map the design to the OWASP agentic risks (ASI01 to ASI10) and name an owner for every gap (Section 4).
6. For every agent above tier 1, record the evidence it needs for promotion and the events that demote it automatically.
7. For every agent at tier 3 or above, write the takeover runbook: who takes over, with what information, and how the process continues.
8. If compliance asks, add control IDs from ISO/IEC 42001, the NIST AI RMF or the EU AI Act.

Tips

• Only a few agents should ever write to a system of record, and those writes need bound, time-limited approvals and a drilled kill switch.
• Turn the 2026 protocol changes into controls: the registry verifies signed agent cards (A2A 1.0), and the gateway applies policy on MCP’s standard request headers and joins every call to its trace.^26,27

Feeds. Client deck: Security. Client report: section 6.

How to use T6

Purpose. Define how success is measured: a baseline and a target at every milestone for each KPI, with its source and owner.

When. Step 2 (discover) for baselines and step 5 (phase) for milestone targets.

Who. The engagement lead and the lead architect, with the business owner and finance.

How to fill it

1. Define each KPI precisely: what is counted, from which event to which, in which scope.
2. Record the data source and the owner who reports it.
3. Measure the baseline in the phase 1 scope, and write “not measured” where there is no data yet.
4. Set a target for months 3, 8, 12 and 24 in line with the phasing (T11).
5. Keep the control-plane KPIs: agent quality, governed AI traffic, AI cost per outcome and AI cost visibility.
6. Give each scorecard metric a leading indicator from the library below, defined so that every team computes it the same way, and measure value instead of adoption.

Tips

• Month 3 targets apply to the first slice only. Say “in scope” so no one reads them as enterprise-wide.

Feeds. Client deck: The value at stake, KPIs at every milestone. Client report: sections 4 and 11.

How to use T7

Purpose. Show what good looks like for this use case, layer by layer, before any product is named.

When. Step 4 (design), in the architecture workshop.

Who. The lead architect with the client’s enterprise architect.

How to fill it

1. Start from the north star in Figure 2 (handbook Figure 4) and the asset inventory (T3).
2. Fill each layer with the use case’s channels, agents and tiers, orchestration, models, tools, data governance and systems of record.
3. Record the design decisions and their rationale.
4. Check the design rule: every agent-to-model and agent-to-tool call passes the control plane.
5. Name only the systems of record and keep everything else vendor-neutral.
6. Run the design-review checklist with the enterprise architect, against the framework the client already uses (Section 5).

Feeds. Client deck: Vendor-neutral architecture. Client report: section 7.

How to use T8

Purpose. Make the architecture human: one persona, one realistic case, from trigger to end state.

When. Step 4 (design).

Who. The lead architect, checked with a real user.

How to fill it

1. Choose a persona and a realistic case in the first phase’s scope.
2. Write six to eight timestamped moments from the trigger to the end state.
3. Show every human decision, and one moment where a control changes the outcome.
4. End with the result in business terms.

Feeds. Client deck: A day in the life. Client report: section 8.

How to use T9

Purpose. Trace the day in the life through the architecture: which components act, over which protocol, under which controls.

When. Step 4 (design).

Who. The lead architect.

How to fill it

1. Use the same moments as T8.
2. For each, name the components and protocols (A2A between agents, MCP from agents to tools, APIs to systems of record).
3. Name the controls that apply, including every policy check before a write.
4. For every hand-off between agents, check the four delegation rules: a verifiable unit of work, a right-sized model, permissions narrowed at the hop, and escalation to a person when the request is ambiguous (Section 4).

Feeds. Client deck: Component interaction. Client report: section 8.

How to use T10

Purpose. Map every reference component to the MuleSoft Agent Fabric, MuleSoft or Informatica capability that realizes it.

When. Step 4 (design), after T7.

Who. The lead architect, with MuleSoft and Informatica specialists as needed.

How to fill it

1. Keep the rows the use case needs and delete the others.
2. Write the role each capability plays in this use case.
3. List what stays the client’s choice.
4. Agree how the control plane coexists with any native agent control planes the client runs, and which is authoritative for what.

Tips

• Custom Omni Gateway policies, built with the Policy Development Kit, are not MuleSoft products. Name who builds, tests and supports them.
• Confirm MuleSoft connector coverage for each of the client’s systems, and map each data need to an Informatica MCP server or an API.
• Name the evaluation tool the client will use (any evaluation tool works), and record its results in the registry.

Feeds. Client deck: Realized; Mapping to the AI control plane; Coexistence. Client report: section 9.

How to use T11

Purpose. Show what goes live at each milestone, the KPIs it moves and the value it delivers, quick wins first.

When. Step 5 (phase), in the value and phasing workshop.

Who. The engagement lead and the lead architect, with the business owner and finance.

How to fill it

1. Align the use case’s milestones (months 3, 8, 12 and 24) with the four platform phases.
2. For each milestone, write what goes live, the KPIs at that milestone and the run-rate value with its formula.
3. Record the foundations each milestone leaves behind for the next use case.
4. Test the month-3 slice against the quick-win test and shrink it until it passes.
5. Add the cumulative value and, with the project team, the costs. Then show net value and payback.
6. Set the plan against the payback benchmarks (Section 6), and judge generative and agentic slices on separate horizons.

Tips

• Agents act in systems of record only from phase 3, under bound approvals and limits that hold across sessions.
• Never add values across use cases from different businesses.

Feeds. Client deck: Phased plan, Phased delivery, Value arrives at every milestone. Client report: sections 10 and 11.

How to use T12

Purpose. Record the decisions you will ask for, the risks and open questions, and the first 90 days.

When. Throughout the engagement, finalized for step 6 (decide).

Who. The engagement lead, with the lead architect for technical risks.

How to fill it

1. Start from the four standard decisions and adapt them to the client.
2. Log every risk, assumption, issue and dependency with an owner and an action.
3. Write the 90-day plan in four steps with exit criteria.

Tips

• Before any agent reaches tier 3, add a decision to approve its takeover runbook and drill (T5).
• Present the operating model with the decisions: who owns what once the agents are live (T13).

Feeds. Client deck: Decisions. Client report: section 12.

How to use T13

Purpose. Name who owns what once the agents are live, the decisions each role can take, the skills people need, and how adoption and value will be measured.

When. Step 5 (phase), in the value and phasing workshop, then confirmed in step 6 (decide).

Who. The engagement lead, working with the sponsor, the business owner and HR or the change lead. The lead architect covers the platform roles.

How to fill it

1. Name a person or team for each role, starting with the accountable executive and the AI governance council.
2. Give every agent in T3d a sponsor.
3. Agree the RACI for the control-plane activities below, adapting the defaults to the client.
4. Plan training for each audience before the slice it affects goes live.
5. Choose the adoption measures and their targets, and measure value and acceptance instead of usage.

Tips

• Technology is the smaller part of the work: BCG estimates that becoming AI-first “involves 30% technology and 70% people and organization.”⁸⁵
• Agree which work stays human (T1) before any decision on roles.

Feeds. Client deck: Operating model. Client report: sections 10 and 12.