BLOG  /  GUEST POST  /  AZURE

AI Maestro on Azure: A Reference Architecture for a Team of Agents

Guest post by Jaime Peláez · November 2, 2026

One AI agent with access to every system can do a lot of work. It also puts all the risk in one place. If it can reach everything, one mistake can reach everything too.

I prefer a team of specialised agents. Each agent has the model, the tools and the access that its job needs, and nothing more. One dashboard coordinates them. In my case that dashboard is AI Maestro, an open-source tool for running many AI coding agents (23blocks, 2026).

This post describes how I would run such a team on a company’s own Azure subscription. My argument is simple. AI Maestro coordinates the agents, but the security comes from Azure and from the way you connect agents to company systems: a private network, model access without keys, and small connector services that hold the credentials instead of the agents.

What AI Maestro Does and Does Not Do

AI Maestro gives each agent its own folder, session and settings. From the dashboard you start and stop agents, watch their terminals and answer their questions. The dashboard also shows the status of each agent: working, needs you, ready or offline.

Agents send messages to each other with AMP, the Agent Messaging Protocol. Each agent has its own inbox. The sender signs every message with an Ed25519 key.

AI Maestro does not lock you to one vendor. Claude Code, Codex and Grok Build have full support: launch, chat history, status and approval cards. GitHub Copilot CLI also launches from AI Maestro, with chat history and approval cards. Any other terminal agent runs in the terminal tab (23blocks, 2026).

AI Maestro does not connect agents to company systems. MCP servers do that job. MCP is the Model Context Protocol, an open standard for giving AI agents tools. I explain them below.

The Overall Design

Everything runs inside one Azure Virtual Network (VNet), Azure’s private network.

• One Linux virtual machine (VM) runs AI Maestro, the dashboard and the agents. Ubuntu 24.04 on a Standard_D4s_v5 (4 virtual CPUs, 16 GiB of memory) is a reasonable start (Microsoft, 2026c). The VM has no public IP address. Azure offers no macOS VMs, so the VM runs Linux.
• The models run in Microsoft Foundry, Azure’s service for AI models, inside the same subscription.
• MCP servers run in their own subnet. Each one has its own identity and a short list of tools.
• Azure Key Vault, Azure’s service for secrets, holds the passwords and keys of the company systems.
• Azure Firewall controls outgoing traffic.

Azure Virtual Network (no public IP)
 ├── snet-aimaestro ......... AI Maestro VM (dashboard + agents)
 ├── snet-privateEndpoints .. Foundry, Key Vault
 ├── snet-mcpServers ........ private MCP servers
 └── AzureFirewallSubnet .... outgoing traffic only to listed domains

The Network Is the Boundary

AI Maestro has no login screen. This is a design choice. It listens on port 23000 and trusts anyone who can reach it (23blocks, 2026). So the network must keep strangers out.

On Azure, people reach the dashboard only through the company network: a VPN (virtual private network) gateway, ExpressRoute or Tailscale. Do not give the VM a public IP address.

Outgoing Traffic

All outgoing traffic passes through Azure Firewall. Firewall rules list the domain names the VM may reach. The firewall blocks everything else. The Basic tier filters web (HTTP and HTTPS) and SQL traffic by domain name. To filter other protocols by name, you need the Standard tier (Microsoft, 2026b).

Models in Microsoft Foundry Without API Keys

Claude Code can use Microsoft Foundry directly. You set CLAUDE_CODE_USE_FOUNDRY=1 and the name of your Foundry resource. If you set no API key, Claude Code signs in through Microsoft Entra ID, Azure’s identity service. On a VM it uses the VM’s managed identity (Anthropic, 2026b). You give that identity the Foundry User or Cognitive Services User role, and no key exists anywhere.

AI Maestro stores a model for each agent and passes it when the agent starts. I choose the model by job:

• Claude Opus for long reasoning and careful writing, such as procedures and analysis.
• Claude Sonnet for most day-to-day agents.
• Claude Haiku for fast, simple work, such as sorting tickets.
• OpenAI models for the Codex or Copilot agents that write scripts and pipelines.

Two Foundry details matter. First, Claude in Foundry has two hosting options. With “hosted on Azure”, prompts and answers stay in Azure. Only usage data and content flagged by safety systems go to Anthropic. With “hosted on Anthropic”, the model runs on Anthropic’s own servers (Anthropic, 2026a). If you use Azure to keep data in one place, choose hosted on Azure.

Second, set a fixed model version for each deployment. Claude Code’s default model names can point to a model that your account does not have (Anthropic, 2026b).

How Agents Reach Company Systems

Agents never connect to a database or an admin API directly. Each system sits behind an MCP server. The MCP server offers a fixed set of tools. The agent calls a tool with some parameters. It never sees a connection string or a password.

In my design, every MCP server follows the same rules. It offers only defined tools, so the agent cannot run its own queries. It has its own managed identity, with rights on one system only. It runs in a private subnet that only the AI Maestro subnet can reach. It reads its credentials from Key Vault when it runs.

For a helpdesk, I use these servers:

• ServiceNow: read and update tickets, search the knowledge base.
• Talkdesk: call queues and service levels.
• Entra ID: check a user, reset a password, read groups.
• Dynatrace: open problems and availability.

For Kubernetes, Microsoft publishes an open-source MCP server for Azure Kubernetes Service (AKS), Microsoft’s managed Kubernetes (Microsoft, n.d.). It has three access levels: read, read-write and admin. The default is read. I would keep it there unless one agent really needs to restart pods.

Each MCP server has its own identity, so the MCP server is where isolation really happens. A helpdesk agent cannot change the cluster because none of its tools reach the cluster.

Data That the Tools Keep in Azure

AI Maestro keeps its own data on the VM disk: the agent list, one database per agent and the messages. It does not use Azure storage services. The tools that agents call can use them. For example, an MCP server can keep files in Azure Blob Storage or search an Azure AI Search index.

Put each of these services behind a private endpoint. A private endpoint gives the service an address inside your virtual network, so traffic does not go over the public internet (Microsoft, 2026d). Then turn off public access to the service. Give access only to the identity of the MCP server that needs it, not to the VM.

Where Identity Isolates Agents and Where It Does Not

It is tempting to give each agent its own managed identity on the VM. On one VM, this does not separate the agents. Microsoft states that all code on a VM can get tokens for every managed identity attached to that VM (Microsoft, 2025). AI Maestro also does not assign identities per agent.

The same is true for files. All agents on one VM run as the same operating-system user. An agent that goes looking can read the other agents’ secrets and messaging keys on that VM (23blocks, 2026).

So the real boundaries are these:

• Between the VM and Azure, the VM’s identity, with only the rights it needs (for example, to call models).
• Between agents and company systems, the MCP servers and their own identities.
• Between agents, separate VMs, or AI Maestro’s Docker backend. The Docker backend runs an agent in a container that cannot see the VM’s vault, keychain or other agents’ keys.

Some agents need a credential directly. For those, AI Maestro has aim-secret. It keeps the credential in a vault and runs a command with it. The value never appears in the chat, the transcript or the model (23blocks, 2026). This protects against accidents. It does not stop a determined agent on the same VM.

How the Agents Work Together

My helpdesk team has seven agents. There is a coordinator, plus agents for the service desk, user identities, monitoring, the contact center, documentation and automation. They talk through AMP. Messages are asynchronous, so no agent waits idle for a reply. Typical exchanges look like this:

• The coordinator gives a task to an agent. The agent does it and reports back.
• The documentation agent needs ticket details. It asks the service-desk agent, which gets them from ServiceNow through its MCP server.
• The monitoring agent sees a problem in Dynatrace. It tells the coordinator, who decides whether to involve someone for the cluster.
• The documentation agent writes a procedure and sends it to a technical agent. The technical agent checks it before the team publishes it.

Azure SRE Agent is Microsoft’s managed agent for site reliability engineering (SRE), generally available since March 2026 (Microsoft, 2026a). It can sit next to this team for Kubernetes and Azure Monitor work. It is a managed Azure service, not a terminal program. AI Maestro does not start it or send it messages. A person or an MCP server connects the two.

The Dashboard

The team lead works from the AI Maestro dashboard, on a computer or a phone. For each agent, the dashboard shows its status and a live terminal.

Each agent also has a permission level. The levels go from supervised (the agent asks before every file edit and command) through trust edits and smart auto to full autonomy. You choose the level when you create or wake the agent.

When an agent asks for permission, the question appears as a card. One click sends the answer. The dashboard also shows each agent’s messages and chat history, including the tools it called.

Deployment Steps

1. Build the network: the VNet, subnets, network security groups, and Azure Firewall with outgoing rules.
2. Create the VM in the AI Maestro subnet with no public IP. Install AI Maestro from the 23blocks repository.
3. Create the Foundry resource and deploy the models (fixed versions, hosted on Azure). Add a private endpoint. Give the VM’s identity the user role.
4. Create Key Vault with a private endpoint and store the company systems’ secrets.
5. Deploy the MCP servers in their subnet, each with its own managed identity and roles.
6. Create the agents in AI Maestro. Set each agent’s role, program, model, permission level and MCP servers.
7. Give the team lead access to the dashboard through the VPN.
8. Plan backups. AI Maestro keeps its state (agent list, messages, memory) on the VM’s disk, so take regular disk snapshots.

The Same Design on Google Cloud

The same pattern works on Google Cloud. AI Maestro already ran as a test deployment there, described in AI Maestro on Google Cloud. Each Azure piece has a Google Cloud match:

• A VM in a VNet becomes Compute Engine in a private VPC.
• Microsoft Foundry becomes Vertex AI.
• Managed identities become service accounts.
• Key Vault becomes Secret Manager.
• Azure Firewall becomes Cloud NAT with firewall rules.
• Private endpoints become Private Service Connect.

The decisions stay the same: a private network, no stored keys, and MCP servers between agents and data.

Conclusions

A team of specialised agents is safer and easier to grow than one agent that can do everything. AI Maestro makes such a team practical, because it coordinates the agents. It does not secure them by itself. On Azure, the security comes from the design around it.

• Keep AI Maestro on a private network. It has no login, so the network is the boundary.
• Use Microsoft Foundry with Entra ID sign-in, so no model keys exist. Choose “hosted on Azure” if data location matters.
• Put every company system behind an MCP server with its own identity and a short list of tools.
• Do not count on per-agent identities on one VM. To separate agents from each other, use separate VMs or containers.
• Back up the VM’s disk, because AI Maestro keeps its state there.

For how I govern this same team (permissions, layers of control and audit), see Governing AI Agents in a Company.

References

Claude is a trademark of Anthropic. Azure, Microsoft Foundry, Entra ID and GitHub Copilot are trademarks of Microsoft. AI Maestro is not affiliated with or endorsed by them.