From AI Proof of Concept to Production Using Foundry and A2A

In this blog post From AI Proof of Concept to Production Using Foundry and A2A we will explain how to turn a promising AI agent demonstration into a secure, measurable and supportable business service.

Many organisations can build an agent that answers questions or completes a simple task. The difficulty starts when that agent needs access to company data, must work with other agents, and is expected to operate reliably every day.

The gap is rarely caused by the AI model. It is usually caused by unclear ownership, weak access controls, missing monitoring and no agreed process for releasing changes. An operating model closes that gap.

What Foundry and A2A do in plain English

Microsoft Foundry is the Azure-based platform used to build, deploy, evaluate and monitor AI applications and agents. Foundry Agent Service provides a managed environment for running agents, connecting them to approved tools and controlling how they access business systems.

A2A, short for Agent-to-Agent, is an open communication protocol. It gives agents built by different teams, frameworks or vendors a standard way to discover one another, exchange messages and coordinate work.

Think of Foundry as the controlled workplace in which an agent operates. A2A is the agreed language agents use when they need help from another specialist agent.

This is different from simply connecting an AI model to more data. A production agent has an identity, permissions, operating costs, logs, service expectations and the ability to take actions. It should therefore be managed more like a business application than a chatbot experiment.

The operating model has five practical layers

1. Start with a measurable business service

A proof of concept often starts with a broad goal such as “help employees find information”. That is too vague for production because nobody can define whether the agent is working well.

Define a narrow service with a clear outcome. For example, an internal support agent could classify Microsoft 365 requests, locate an approved answer and prepare a service ticket when the issue requires human attention.

• Business owner: The person accountable for the result.
• Users: The employees or customers allowed to access the service.
• Success measure: Time saved, requests resolved or errors reduced.
• Risk limit: Actions the agent is never allowed to complete independently.

If the team cannot agree on these four points, the agent is not ready to move beyond experimentation.

2. Separate development, testing and production

A common mistake is continuing to improve the original demonstration until it quietly becomes a production system. Test accounts, broad permissions and sample data then become part of a live business process.

Create separate Foundry environments for development, testing and production. Prompts, tools, model settings, Agent Cards and access policies should be version controlled and released through an approval process.

Each release should pass a defined set of evaluations. These tests should measure whether the agent completes the task, follows instructions, handles unsafe requests and avoids exposing confidential information.

Foundry tracing can record inputs, outputs, tool calls, delays, retries and usage costs through Azure Monitor and Application Insights. In plain English, this gives the support team a timeline of what the agent did and helps explain why a request failed.

3. Give every agent a narrow identity

An agent should never inherit the full access of its developer or service administrator. It needs its own managed identity, which is a secure Azure identity that can access only specifically approved resources.

For example, an accounts-payable agent may need to read invoices and create a draft record. It should not be able to approve a payment, change supplier bank details or browse unrelated employee files.

Use Microsoft Entra ID for authentication, role-based access control for permissions, private network connections where required, and a secrets manager rather than storing passwords in code. These controls also support Essential Eight, the Australian government’s cybersecurity framework that many organisations use to measure security maturity.

Australian organisations should also review whether agent prompts, traces and stored conversations contain personal information. Privacy checks must cover the complete workflow, not only the model.

For a deeper infrastructure view, see our guide to designing secure AI agent infrastructure on Azure.

4. Treat A2A as a controlled business contract

A2A allows one agent to discover and call another without needing to understand its internal code. Each agent publishes an Agent Card, which is a machine-readable description of its skills, location and authentication requirements.

A request can then become a tracked task. The receiving agent can return messages, progress updates or an artifact, meaning the completed output such as a report, structured record or document.

{
 "agent": "supplier-risk-review",
 "approved_callers": ["procurement-agent"],
 "allowed_actions": ["assess_supplier", "draft_report"],
 "human_approval_required": ["reject_supplier"],
 "maximum_task_cost": 2.00,
 "data_classification": "confidential"
}

This example is not just a technical configuration. It describes the operating boundary: who can call the agent, what it may do, when a person must approve the result and how much a task may cost.

At the time of writing, native A2A connections and incoming A2A endpoints in Foundry Agent Service remain preview capabilities without a production service-level agreement. Organisations should isolate them behind a controlled integration layer, use feature flags and maintain a fallback path rather than making a preview connector the single point of failure.

Our guide to building interoperable AI agents with A2A and Agent Framework covers the implementation pattern in more detail.

5. Operate the agent as an ongoing service

Production approval is not the end of the project. Models change, business data changes, connected systems change and users find unexpected ways to interact with the agent.

A practical operations dashboard should track task success, incorrect answers, blocked actions, response time, human escalations and cost per completed task. Monthly business reviews should compare those measures with the original target.

High-impact actions should include human approval. If an agent can issue a refund, disable an account, modify a customer record or send an external communication, a person should review the action before execution.

Long-running workflows also need checkpoints. These save progress so a task can resume after a system failure or approval delay instead of starting again and repeating actions.

A realistic 200-person business scenario

Consider a 200-person professional services company receiving 500 internal IT and operations requests each month. Staff spend an average of 12 minutes classifying each request, locating information and routing it to the right team.

The company introduces a coordinator agent in Foundry. It identifies the request type and uses A2A to call separate agents for Microsoft 365 support, device management and policy questions. Each specialist has different permissions and cannot access systems outside its role.

If the service safely handles 60 per cent of those requests, the business recovers around 60 staff hours per month. More importantly, sensitive actions still require approval, every agent interaction is logged, and costs can be linked to completed work rather than raw AI usage.

A sensible path from pilot to production

1. Select one repeatable workflow with enough volume to produce a measurable return.
2. Document the agent boundary, including data access, tools, prohibited actions and approval points.
3. Build a representative test set containing normal, difficult and unsafe requests.
4. Deploy through controlled environments rather than modifying the live agent directly.
5. Release to a small user group and compare results with the existing process.
6. Monitor quality, risk and cost before expanding access or adding more agents.

If you are still building the technical foundation, start with building Microsoft Foundry agents with Microsoft Agent Framework. For organisations moving from general AI chat toward controlled business workflows, see from Copilot Chat to governed AI agents with Microsoft Foundry.

The real goal is controlled business value

The best production agent is not the one with the most tools or the most advanced model. It is the one that completes a valuable task consistently, stays inside clear security boundaries and can be supported when something goes wrong.

CloudProInc combines more than 20 years of enterprise IT experience with hands-on expertise across Azure, Microsoft Foundry, OpenAI, Claude, Microsoft Defender and Wiz. As a Melbourne-based Microsoft Partner and Wiz Security Integrator, we help organisations design operating models that fit their existing security, compliance and support practices.

If your AI proof of concept is attracting attention but nobody is comfortable putting it into production, we are happy to review the architecture, controls and operating model with you — no strings attached.