Let's Build Azure!

Anatomy of an Agentic Platform

Before any serious discussion of an agent platform, you need to agree on what an agent platform is. Without that definition, conversations talk past themselves: one person means the chatbot, another means the model, a third means the whole governed fleet. This article is that definition.

This map is not theoretical. I am a practice leader at IBM Consulting, where my work covers AI adoption and transformation broadly: the foundational pieces, data, governance, security, and the organizational change around them. Agentic platforms are one part of that work, and a growing one. In the past five years I have been involved in 10+ agentic platform implementations at large enterprises, in highly regulated industries like healthcare, energy, and utilities, and in less regulated ones like food and automotive manufacturing. Those platforms supported as many as 250 types of agents, from simple chat-with-your-documents assistants to semi-autonomous agents that retrieve data, analyze trends, update purchase orders, and process claims, with a human approving the consequential steps until confidence grows. The work was hands-on, from high-level design to code written to mentor my own teams and the client’s technology staff, and it was also conceptual: long sessions with business executives, security teams, finance, and data teams, whose timelines and priorities rarely matched.

The lessons were consistent. Clear objectives, honest measurement, and quality information matter more than any model choice. Monitoring and steady iteration, following a “crawl, walk, run, fly” maturity path, mattered more than any launch plan. The failures were rarely about the models or the technology; they came from expectations that advanced implementations could succeed without strong fundamentals. This article covers one slice of that foundation, the platform itself. The wider work of AI adoption and transformation is a larger subject than one article, and this one does not try to cover it.

An agent platform is the set of capabilities that lets an organization design agents, run them safely, connect them to its systems and data, and keep them reliable and accountable in production. It is not a single product. No single vendor product covers all of it well, and no open source project covers all of it either. A platform is assembled from parts, and the point of defining it first is to give every later discussion a shared vocabulary.

The capabilities fall into eight groups. Three of them wrap everything else:

• governance and security,
• lifecycle,
• and operations.

Five of them form the path an agent takes from idea to user:

• interaction channels,
• authoring,
• runtime and orchestration,
• integration and interoperability,
• models, data and memory.

Thirty-eight capabilities in total. Not every organization needs all thirty-eight on day one, but most organizations running agents in production will need an answer for most of them, even if the answer for now is “not yet.”

Interaction channels: where people and systems engage with agents

This is the front door. It is every surface through which a person or another system reaches an agent, and it is the group most teams think of first, because it is the only group users ever see.

• Chat with agent: chat clients such as Copilot, Teams, and Slack, plus web and mobile apps. The agent meets people where they already work.
• Talk with agent: voice assistants, telephony, and contact center. The same agent logic, reached by voice instead of text.
• Event and scheduled triggers: webhooks, queues, and batch invocation. Agents that act without a person starting them, on a schedule or when something happens.
• Programmatic inbound: APIs (exposed in many ways, REST, MCP, etc.) and SDKs for inbound calls from external services and applications. Other software/agents invoking your agents as a service.

Authoring: where agents are designed, assembled and tested

This is the workshop. It is where an agent goes from an idea to something testable, and it is where most of the domain work lives, whether teams realize it or not.

• Agent studio: design, build and test agents. The workspace where prompts, tools, and behavior are assembled and tried out.
• Context and knowledge: data, retrieval, grounding and documented procedures. The material the agent draws on to answer correctly, and the procedures it is supposed to follow, written down where the agent can use them. This is agent-specific grounding material; the machinery that indexes it lives under knowledge and retrieval, and the prepared corporate data itself lives under enterprise data.
• Tools and skills: define, describe and bind agent tools. The explicit list of what the agent is allowed to do, described clearly enough that the agent can choose correctly and a reviewer can audit the choice. Defining a tool is not governing it; enforcement of which agents may call it, and under what identity, lives at the tool gateway.
• Guardrails and testing: design-time safety controls and offline evaluations. The rules set before release, and the tests that prove the agent behaves within them on cases you already know about.

Runtime and orchestration: where agent logic runs, holds state and coordinates across agents

This is the engine room. It is what executes the agent, remembers where a conversation or a task stands, and coordinates when more than one agent is involved.

• Managed runtime: isolated, region-scoped scalable execution. The place agent code runs, separated from other tenants, in the right geography, able to scale up and down. That isolation includes sandboxed execution for untrusted code, such as code an agent itself generates, so it cannot reach data or systems outside its allowance.
• Agent framework: consistent SDK for agent logic. The shared toolkit every agent is written against, so agents behave consistently and engineers do not reinvent the loop that calls tools, reads results, and decides what to do next.
• Orchestration: multi-agent coordination. When a task needs several agents, this decides who does what, in what order, and how results combine.
• State and durability: sessions, checkpointing and resumable runs. The memory of a run in progress: what has been done, what is pending, and the ability to pick up again after an interruption instead of starting over.

Integration and interoperability: where agents reach tools, content and systems of record

This is the plumbing to the rest of the enterprise. An agent that cannot reach your systems is a demo; an agent that reaches them without control is a risk. This group is both at once.

• Tool and MCP gateway: registry, discovery and governed tool access. A single catalog of the tools agents may call, with access governed centrally instead of each agent carrying its own credentials. MCP, the Model Context Protocol, is the open standard many tools now use to describe themselves to agents.
• Enterprise system connectors: SAP, ServiceNow, GIS and systems of record. The prebuilt bridges to the systems where your business data actually lives.
• Identity propagation: delegated authorization and on-behalf-of access. The mechanism that lets an agent act as a specific user, with that user’s permissions, rather than with a shared super-user credential. When an agent reads a record, it should be because the person it serves is allowed to read it. Delegation is not impersonation: the record must show both identities, the agent and the user, at the gateway, the connectors, and the system of record, never the user alone. When one agent calls another, both identities travel with the call, and the receiving agent’s own scope still applies.
• Agent-to-agent (A2A): discovery and interoperability with other agents (first-party or third-party). The ability for your agents to find and work with agents inside or outside your organization, using shared protocols instead of custom wiring per partner. Trust in an external agent is itself a capability: verify the external agent’s identity and allow-list it before delegating work to it.

Models, data and memory: where agents draw models, grounded content and durable memory

This is the fuel and the recall. It covers which models agents use, what enterprise data they can draw on, what they remember across conversations, and how they find grounded content instead of guessing.

• Model management: frontier and tuned model catalog, with model routing rules for optimized token use. The list of approved models, including fine-tuned ones, and the rules that send each request to the right model based on cost, latency, and quality. Routing is where tokenomics, the value you get for money spent on tokens, is decided in practice.
• Enterprise data: data and workplace intelligence. Your corporate data, prepared so agents can use it: searchable, access-controlled, and current.
• Agent memory: long-term and shared context. What an agent remembers about a user, a team, or a task across sessions, and what it shares with other agents.
• Knowledge and retrieval: indexes, embeddings and freshness. The machinery that turns documents into searchable form, keeps those indexes up to date as documents change, and returns the right passages when an agent needs grounding.

Governance and security: where identity, guardrails and data protection are enforced

This is the group that decides whether the platform is allowed to exist in a regulated enterprise. It is not a feature added at the end; it is the frame the other groups operate inside.

• Agent identity: non-human identity and credential lifecycle. Every agent gets its own identity, like an employee badge, with credentials that are issued, rotated, and revoked. While an agent often acts on behalf of end-users, it should always have its own identity for clear auditing purposes (“Agent X performed action Y for human Z”). That identity answers which agent acted; it does not by itself grant access to data. When no user is present, as with a scheduled or event-triggered run, the agent acts solely under its own identity, so its scope must be explicit and narrow.
• Access management: scoped entitlements and least-privilege access. Each agent gets only the permissions its job requires, nothing broader, and those permissions are reviewed. Coupled with on-behalf-of identities, this creates two layers of protection, and they work by intersection, not addition: an agent acting for a user can do only what both the agent’s scope and the user’s permissions allow, so the narrower of the two wins. An agent never expands a user’s rights; it can only narrow them. A user acting directly, without an agent, is bounded only by their own permissions, but also gains none of the agent’s speed, scale, or tooling.
• 
  

Data governance: classification, retention, residency and compliance. Knowing what kind of data an agent touches, how long it is kept, where it is allowed to live, and which regulations apply.

Human oversight: approval gates and action boundaries by risk. Low-risk actions proceed; higher-risk actions pause for a human approval, with the boundary set by the risk of the action, not by the convenience of the workflow. An approval authorizes that action; it does not widen the agent’s entitlements or the user’s permissions. The approved action still runs under both identities.

Threat protection: detection, SIEM and runtime defense. Watching for attacks on and through agents, feeding events into the security information and event management system, and defending the runtime while agents are running. That defense includes policy enforcement at runtime: screening tool calls and outputs as they happen, including screening for injected instructions in tool results and retrieved content.

Responsible AI: policies, controls and audit trail around the agent’s decision making and tool calls. The written policies, the controls that enforce them, and the record that proves what happened, so the organization can answer for its agents’ actions.

Lifecycle: where agents are onboarded, versioned, promoted and released

This is the conveyor belt from an idea to production and, eventually, to retirement. It is the group that turns one agent built by one team into a fleet the organization can manage.

• Intake and ownership: request, approve and assign an accountable owner. Before an agent is built, someone asks for it, someone approves it, and one named person owns it. An agent without an owner is an agent nobody maintains.
• Agent registry: catalog of agents, versions and owners. The inventory: every agent, every version, who owns it, what it does. Without a registry, you cannot answer the simplest governance question, which is how many agents you have.
• Deployment pipelines: build, promote, version and roll back. The automated path from a change to production, with versions recorded and rollback available when a release misbehaves.
• Environments: isolated dev, test and production. Separate places to build, test, and run, so an experiment cannot touch production data and a production incident cannot be confused with a test.
• Release gates: evaluation and approval before promotion. The checkpoint before a new version reaches users: evaluations pass, approvals are recorded, then promotion happens.
• Retirement: decommission, revoke credentials and archive. The end of an agent’s life: shut it down, revoke its credentials, archive its record. Retired agents with live credentials are a quiet security hole.

Operations: where agents are monitored, kept reliable and held accountable

This is the group that keeps the fleet running after launch, and it is the group most often underestimated, because it is invisible until something breaks.

• Observability: tracing, monitoring and root cause. Following an agent’s run step by step, watching its health, and finding why it failed when it does.
• Scorecards: in-production quality and safety evaluation. Ongoing measurement of whether agents are still doing good work and staying within safety bounds, not just on release day but every day.
• SLOs: reliability and availability targets. The service level objectives, the promised reliability and availability, that the platform and each agent are held to.
• Incident response: triage, rollback and on-call. When an agent misbehaves in production, someone is paged, the problem is triaged, and the bad version is rolled back.
• Performance and adoption: business outcomes, usage and engagement. Whether agents are actually delivering the business result they were built for, and whether people are using them.
• Cost allocation: token spend, chargeback and optimization. Tracking what each agent and each team spends on tokens, charging it back to the right budget, and finding where spend can be cut without losing quality.

How the groups fit together

Follow one agent through the groups and the platform stops looking like a list. An idea enters through intake, with an owner assigned. It is designed in the studio, grounded in context and knowledge, given tools, and bounded by guardrails. It passes release gates, travels a deployment pipeline through isolated environments, and lands in the managed runtime. People reach it through a chat client, a voice assistant, a scheduled trigger, or an API. It draws on models, enterprise data, and memory, reaches systems of record through the gateway, and acts with its own identity, on behalf of a named user. Governance wraps the whole path: its own identity, scoped access, data rules, human approval where risk demands it. Operations watches it from then on: traces, scorecards, SLOs, incidents, adoption, cost. One day it is retired, credentials revoked, record archived.

That walkthrough is the point of defining the platform this way. Once every capability has a name and a place, teams can discuss a specific agent, a specific gap, or a specific risk without talking past each other. The definition is the shared map. What to do with each part of it is a separate discussion.

Further reading

The definitions above stand on their own, but these public standards and frameworks cover the same ground and are worth reading alongside them:

• Model Context Protocol (MCP): Anthropic’s open specification for connecting AI applications to external systems and tools, published November 2024 and now governed under the Linux Foundation’s Agentic AI Foundation. spec.modelcontextprotocol.io
• Agent-to-Agent (A2A) protocol: Google’s open specification for discovery, delegation, and coordination between agents, announced April 2025, now at version 1.0 under Linux Foundation governance. a2a-protocol.org
• NIST AI Risk Management Framework 1.0: the voluntary framework organized around Govern, Map, Measure, and Manage, published January 2023, with a Generative AI Profile added in 2024. nist.gov/itl/ai-risk-management-framework
• OWASP Top 10 for Agentic Applications (2026): the ten risk categories for agents that plan and act, from agent goal hijack (ASI01) through rogue agents (ASI10). genai.owasp.org Top 10 for Agentic Applications