Deploying Claude-Powered Agents on Azure: Architecture Patterns

From demo to production

Building an agent that works in a demo takes an afternoon, with a loop, a model call, and a couple of tools. Running one in production inside a UK enterprise raises questions the demo skipped. Where does it run, and what identity does it hold? How is the model endpoint governed, what can the agent touch, and who gets paged when it misbehaves?

None of these questions is exotic. They are the standard questions of any production workload, with a model dependency and a tool surface added. This guide maps the standard Azure answers onto the agent shape, for teams building with the Claude Agent SDK or their own orchestration against the Messages API.

Where should the agent tier run?

We treat the agent as an ordinary service and weight the hosting decision towards security and control. An agent concentrates the things you most want controlled: a model endpoint, credentials, and tools that reach your systems.

• Azure Kubernetes Service (AKS) is our default for agent services. It gives the most control over the concerns specific to agents: network isolation and egress control around the model endpoint and tool connections, workload identity, policy enforcement, and a shared observability stack. Everything in our AKS production support guide applies unchanged, because the agent is one more deployment.
• Azure Functions is the right default for event-driven, short-lived AI work, such as a single enrichment call in a pipeline or a queue-triggered classification step. Long-running agent loops sit better in a container on AKS than inside serverless time limits.
• Azure App Service has a place only for very simple workloads where the client explicitly wants minimal operational complexity, and we do not default to it for agent systems.

Two hosting points are specific to agents. The first is long-running work: agentic tasks can run for minutes rather than milliseconds, so front them with a queue (Service Bus or Storage queues) and report progress instead of holding HTTP connections open. The second is state. Keep the agent tier stateless and externalise conversation and task state to a store (Cosmos DB or SQL), so that scaling and restarts stay routine.

Which route to the model, and how to keep it swappable

There are three legitimate routes, and the Claude on Azure decision guide covers choosing between them:

1. Microsoft Foundry: Claude behind Azure identity and billing (Claude Consumption Units, MACC drawdown), with Global and US data zone options on Azure-hosted models. The endpoint speaks the Messages API via the Anthropic SDKs.
2. The Anthropic API directly: the full first-party feature surface, with keys managed by your team.
3. AWS Bedrock or Google Vertex AI: the current route where EU or UK in-region processing is contractually required, per the residency analysis in our Claude GDPR guide.

The rest of the system should not need to know which route is in use. Isolate the model client behind your own interface and configure endpoint and model identifiers externally. The residency or procurement decision then becomes a deployment setting rather than a code change.

Where should quotas, metering, and logging live?

A production agent system needs a set of operational controls around the model endpoint, wherever they live:

• Quotas and rate limiting per consumer, so one runaway workload cannot exhaust a shared model deployment’s rate limits or budget.
• Metering for the token budget. Usage logging feeds cost attribution per team or feature, which is the foundation of the governance in our token cost guide.
• Request logging where your data classification permits, so ‘what was the AI asked and what did it answer?’ can be answered from records.
• Credential handling and rotation, with model keys never spread across application teams.
• A stable internal abstraction, so model versions, deployments, or providers can change without application changes.

There are three candidate homes for these controls, and the right one depends on scale:

1. A shared client library is the default for a single team or a small number of workloads. Logging, retries, metering, and the model abstraction live in code you own, with no extra infrastructure to run. This is where we usually start.
2. The platform’s own controls carry part of the load. Foundry deployments sit behind Microsoft Entra ID with Azure-native billing and per-deployment quota, which covers identity and coarse metering without any additional component.
3. A gateway (Azure API Management or similar) is worth adding when several teams or applications share model deployments and you need central quotas, key custody, and audit in one enforced location. Below that scale it is unnecessary overhead, adding an extra hop, another component to operate, and one more thing to explain in the architecture review.

We do not default to a gateway. We start with the client library, rely on the platform controls, and add a gateway once several teams need to share model deployments.

Identity: managed identity first, Key Vault for the rest

The agent tier should hold no secrets in code or configuration:

• Managed identity authenticates the agent’s workload to Azure resources (storage, databases, Service Bus, Key Vault) without any credential to leak. Foundry-routed model access can also sit behind Microsoft Entra ID.
• Azure Key Vault holds the API keys that remain (direct Anthropic API keys, third-party service keys), referenced by the platform rather than embedded.
• Scope identity per agent rather than per platform. Each agent workload gets its own identity with the minimum roles its tools need. An agent that reads reference data and files tickets does not hold a role that can write to the ledger.

The same least-privilege thinking limits what the agent can be instructed to do, so it works as a prompt-injection defence as well as an access control. An agent whose identity cannot reach a system cannot be talked into misusing it.

Tools: give agents scoped access rather than credentials

Agent architecture differs most from ordinary services at the tool surface, because tools turn model output into effects on your systems. We document the full pattern set in MCP patterns for production agents, and summarise it at the architecture level here:

• Read-only servers for queries, exposing curated views of the handful of tables the agent needs rather than the whole schema. Our Azure SQL MCP post works through this scoped-context pattern.
• Gated action servers for writes, where consequential operations require explicit approval steps or run in constrained modes.
• Per-call logging on every tool, so that ‘what did the agent do?’ can be answered from logs rather than by reconstruction.
• Tool inventory under governance: versioned, reviewed, and pruned like any dependency surface, per governing the AI agent supply chain.

Treat the internal APIs the agent calls as products with contracts, as you would for any other consumer. Our integration strategy guide applies unchanged.

Monitoring: four layers, instrumented from day one

1. Infrastructure: the ordinary signals (container health, scaling, queue depth) through Application Insights and Azure Monitor, monitored as you would any other service.
2. Model usage: tokens in and out, cache hit rates, cost and latency per request, and error and retry rates against the model endpoint. Finance will ask about this layer, so capture it before they do.
3. Agent behaviour: tool-call frequency and failure patterns, loop lengths, guardrail and refusal triggers, and anomalies. An agent that suddenly calls a tool ten times as often is a signal, whatever the cause.
4. Outcome quality: task success measured against evaluation sets on a regular cadence, because a production agent’s quality can drift with model updates, prompt changes, and data changes. Our AI test quality guide covers evaluation discipline.

Alerting should span the same layers. An agent can be healthy at the infrastructure level while behaving wrongly, and only layers three and four will show it.

Next steps

If you are moving an agent from demo to production, we suggest this sequence:

1. Pick the model route, and keep it swappable.
2. Settle the identity model and where the operational controls live.
3. Build the tool surface as scoped MCP servers with logging.
4. Instrument all four monitoring layers before launch rather than after the first incident.

For the surrounding decisions, see the Claude on Azure decision guide for model routing, MCP patterns for production agents for the tool layer, and the token cost guide for budget governance.

Building an agent for production? Book a free consultation and we will review the architecture with you.