Most enterprises spent years building a cloud adoption framework: a strategy, a landing zone, governance policies, a migration factory and an operating model. Then generative AI arrived and, in many organizations, bypassed all of it. Teams spun up model endpoints, chat assistants and, increasingly, autonomous agents in sandboxes, SaaS tools and personal subscriptions. In 2026 the stakes are higher because agents do not just answer questions; they call APIs, update records and trigger workflows on behalf of people. The good news is that you do not need a new framework. You need to extend the one you already have. This playbook walks through how, phase by phase, drawing on the AI agent adoption guidance Microsoft added to its Cloud Adoption Framework in December 2025 and on equivalent practices from other providers.
Why Agents Break Assumptions in a Traditional CAF
A classic CAF assumes workloads are deterministic applications with human operators. Agents violate that assumption in three ways.
- They act with delegated authority. An agent may read customer data, create tickets or approve refunds. Its permissions are effectively a new class of privileged identity.
- Their behavior is nondeterministic. Microsoft’s guidance notes that, unlike standard retrieval-augmented generation where retrieval is fixed, agents use the model to choose which knowledge and tools to use at each step. The same request can follow different paths, which changes how you test and govern.
- They proliferate quickly. Low-code agent builders and SaaS copilots let any business team create agents in minutes. Without a registry, nobody knows how many exist or what they can touch.
Each of these maps onto a CAF discipline that already exists: identity and access, governance, testing and operations. The work is to make those disciplines agent-aware.
Phase 1: Plan for Agents With a Business Case, Not a Demo
Classify Use Cases by Autonomy
A practical way to prioritize is to classify candidate agents by how much autonomy they need. Microsoft’s CAF describes three broad types, in increasing order of risk:
- Productivity agents that retrieve and synthesize information, such as internal knowledge assistants.
- Action agents that perform defined tasks such as updating a record or opening a ticket.
- Automation agents that run multi-step processes with minimal human oversight and require the most rigorous governance.
Start with productivity and bounded action agents where value is measurable and failure is recoverable. Leave fully autonomous automation agents until identity, observability and incident response are proven.
Decide Buy, Configure or Build
For each use case, decide whether a SaaS agent (for example, inside your CRM or productivity suite), a low-code agent builder or a custom agent built on a cloud AI platform is the right fit. SaaS agents are fastest but inherit the vendor’s data boundaries; low-code platforms balance speed and control; custom agents give maximum control at maximum engineering cost. The CAF lens is the same as for any workload: favor the least custom option that meets requirements, and record the decision.
Check Data Readiness Early
Agents are only as good as the data and tools they can reach. During planning, confirm that grounding data is curated, classified and owned, and that the systems the agent must act on expose stable APIs. Microsoft’s March 2026 CAF update on a unified data platform for AI and analytics, built around domain ownership and governed data products, reflects how tightly agent success now depends on data architecture.
Define Success Metrics Before You Build
Agent pilots often stall because nobody agreed what success looked like. Before building, define a small set of outcome metrics tied to the business process: average handling time, first-contact resolution, cycle time for an approval, percentage of cases resolved without escalation, or analyst hours saved per week. Pair them with guardrail metrics such as error rate, escalation rate, user satisfaction and cost per completed task. Capture a baseline from the current process so the comparison is honest. These numbers become the evidence that justifies moving an agent from pilot to production, or retiring it.
Phase 2: Govern and Secure Agents Through a Control Plane
This is where most organizations are weakest, and where the CAF extension pays off most. The guidance converges on a centralized, enforceable baseline that reuses existing identity, data governance and security practices rather than creating a parallel AI bureaucracy.
Keep an Agent Registry
The single most important control is an inventory. As Microsoft’s guidance puts it, you cannot govern agents you do not know exist. Every agent should be registered with an owner, purpose, platform, data sources, tools and access scope. Where available, use the platform’s native registry (Microsoft points to Agent 365’s registry or Microsoft Entra Agent ID as the authoritative source); otherwise a CMDB extension works, provided registration is a prerequisite for production access.
Give Every Agent Its Own Identity
Shared service accounts make agent actions unattributable. Assign a unique identity per agent, use managed identities or workload identity federation instead of stored secrets, and apply least privilege. Where an agent acts on behalf of a user, it should inherit that user’s permissions rather than hold broad standing access. This aligns with the OWASP Top 10 for Agentic Applications released in December 2025, which lists identity and privilege abuse among the top risks.
Apply Data Governance Consistently
Agent memory stores, conversation logs and tool outputs are data stores like any other. Apply sensitivity labels and data loss prevention, define retention for logs and memory, know where every runtime and output store lives, and isolate public-facing agents from internal business data. In an Azure landing zone, Microsoft recommends separating these into distinct “corp” and “online” management groups; AWS and Google Cloud equivalents are separate OUs or folders with distinct policies.
Standardize Protocols and Approve Integrations
Agents connect to tools and to each other. Standardizing on open protocols such as the Model Context Protocol (MCP) for tool access and Agent-to-Agent (A2A) for inter-agent communication reduces bespoke integration risk. MCP moved under the Linux Foundation’s Agentic AI Foundation in December 2025, which increases confidence in its long-term neutrality. Equally important: maintain an allowlist of approved MCP servers and external agents, and route calls through a gateway that enforces authentication, policy and logging.
Test Adversarially Before Production
Require red teaming before launch and after significant changes, filter inputs and outputs, and enable AI-specific threat protection where your cloud provides it. Prompt injection through retrieved documents, tool descriptions or email content is a real and recurring attack path.
Phase 3: Prepare the Environment — Landing Zones for Agents
Agents should not live in sandboxes forever, nor should every team build its own AI environment. Extend your landing zone with an AI pattern:
- A shared AI platform landing zone hosting model endpoints, AI gateways, vector stores and evaluation tooling, with private networking and centralized quota management.
- Workload landing zones for individual agent applications, consuming the shared platform through approved interfaces. (Microsoft renamed “application landing zones” to “workload landing zones” in October 2026.)
- SaaS agent governance for agents that run inside vendor platforms, which need identity, access and DLP configuration rather than infrastructure.
- Environment separation for low-code builders, with development, test and production environments and connector policies controlling what agents can reach.
Start with an audit-first posture: monitor behavior and collect evidence, then tighten controls once you understand real usage. Blocking everything on day one drives teams back to shadow AI.
Phase 4: Build Agents With Standard Engineering Practices
Agent development needs the same disciplines as any software, plus a few new ones. Standardize on a small number of frameworks and SDKs so security reviews and observability are repeatable. Decide deliberately between single-agent and multi-agent designs; multi-agent systems are powerful for complex workflows but multiply failure modes, cost and testing effort. Treat prompts, tool definitions and evaluation datasets as versioned artifacts in source control. Build evaluation into CI: groundedness, task success, safety and cost per task should be measured on every change, with thresholds that block deployment.
Keep humans in the loop where the action is consequential or irreversible. A simple rule works well: the agent may propose; a person approves anything that moves money, changes customer commitments or deletes data, until production evidence justifies more autonomy.
Phase 5: Manage and Operate Agents at Scale
Operations is where agent programs succeed or quietly fail. The operational baseline should include:
- End-to-end tracing of each agent run, including model calls, tool invocations and decisions, exported to your observability stack with OpenTelemetry where possible.
- Security operations integration, routing AI threat alerts to your SIEM alongside other cloud signals.
- Cost management with tags by department or product, budgets and real-time alerts; agent loops can consume tokens quickly.
- Quality monitoring for drift in task success and user satisfaction, with periodic re-evaluation as models and data change.
- Incident response runbooks describing how to disable a misbehaving agent, revoke its identity, preserve logs and notify stakeholders.
- Lifecycle management including regular access reviews and offboarding, so retired agents do not leave orphaned credentials.
A Worked Example: Adding Agents to an Existing CAF in 90 Days
Imagine a hypothetical logistics company with a mature Azure and AWS footprint and an established CAF. Business units have already built a dozen agents: two in a CRM, several in a low-code builder and a few custom prototypes. Leadership wants to scale responsibly.
Days 1–30: Discover and decide. The cloud center of excellence runs an agent discovery exercise across SaaS admin consoles, low-code environments and cloud subscriptions, finding more agents than expected. Each is registered with an owner and classified by autonomy. Governance accountability is assigned to the existing cloud governance board rather than a new AI committee. The team selects three priority use cases: a customer-service knowledge agent, a shipment-exception action agent that opens and routes tickets, and an internal procurement assistant.
Days 31–60: Build the control plane and landing zone. The platform team deploys a shared AI landing zone with private model endpoints, an AI gateway and an MCP gateway with an approved-server allowlist. Every agent receives its own managed identity. DLP policies are applied to the low-code environments, and the public-facing customer agent is isolated from internal finance data. Evaluation pipelines are added to CI for the three priority agents.
Days 61–90: Operate and expand. Tracing and cost dashboards go live. A red-team exercise uncovers a prompt-injection path through attached shipping documents, which is mitigated with input filtering and a narrower tool scope. The shipment-exception agent moves to production with human approval for any customer-facing message. Two prototypes that cannot meet the baseline are retired, and their identities are revoked.
At the end of 90 days the company does not have dozens of new agents. It has a repeatable path that lets the next ones reach production safely and quickly.
Readiness Checklist: Is Your CAF Agent-Ready?
- Agent use cases are prioritized by business value and autonomy level.
- Every agent is registered with an owner, purpose, tools and access scope.
- Each agent has a unique identity with least-privilege, short-lived credentials.
- Agent memory and logs fall under existing data classification, DLP and retention.
- MCP servers and external agents are allowlisted and accessed through a gateway.
- Red teaming and automated evaluations are required before production.
- Landing zones include a shared AI platform and governed workload zones.
- Tracing, cost tracking and SIEM integration are in place.
- Runbooks exist to disable an agent and revoke its access within minutes.
Pitfalls to Avoid
- Creating a parallel AI governance body that duplicates cloud governance and slows everything down; extend the existing board instead.
- Granting agents broad standing access for convenience during pilots, then never narrowing it.
- Skipping evaluation datasets, so model or prompt changes ship without evidence that quality held.
- Ignoring SaaS agents because they do not appear in cloud subscriptions; they often touch the most sensitive data.
Agents do not need a new adoption framework. They need the one you already have to treat every agent as a managed resource with an owner, an identity, least privilege, continuous monitoring and an off switch.
Outlook: What Comes Next
Expect agent governance to become a standard CAF chapter across providers, much as security and FinOps did. Regulatory pressure reinforces this: the EU AI Act’s obligations are phasing in, and governance tooling that maps regulations to controls is already appearing in compliance platforms. Protocols will mature, with MCP and A2A gaining enterprise features for authorization and auditing. Agent identity is becoming a distinct category in identity platforms. And as agents take on more operational work, the line between AI adoption and cloud operations will blur; the same platform team will run both.
Conclusion: Extend, Don’t Reinvent
The fastest way to scale AI agents safely is to reuse the adoption machinery you already trust. Plan agents around measurable outcomes and autonomy levels, govern them through a central control plane with a registry and unique identities, extend landing zones with a shared AI platform, build them with standard engineering and evaluation practices, and operate them with tracing, cost control and incident response. Organizations that make these extensions now will find that agents become just another well-governed workload type, and that is exactly what makes them scalable.
How Hanoi Technology Can Help
Hanoi Technology helps teams extend their cloud adoption framework for AI agents, from agent registries and identity design to AI landing zones, evaluation pipelines and day-two operations.
Further Reading
- AI agent adoption in the Cloud Adoption Framework – Microsoft Learn
- Governance and security for AI agents across the organization – Microsoft Learn
- What’s new in the Cloud Adoption Framework – Microsoft Learn
- OWASP Drops First AI Agent Risk List – TechRepublic
- MCP joins the Agentic AI Foundation – Model Context Protocol Blog