It wasn’t long ago that clients were asking us which model they should use. Now they want to know how to run hundreds of AI agents in production without losing control of them. What was once a model question is now an infrastructure, identity and governance question, and it lands directly on the cloud team's desk. 

Securing each agent individually doesn’t scale. Instead, enterprises need a shared foundation: identity, governance, observability and lifecycle management, built once and reused. Without it, AI initiatives stall somewhere between a successful pilot and a second business unit. 

While many enterprises already have AI agents running in production, few have the platform underneath to support them. Understandable — building it isn’t exactly easy. Most enterprises have operations spread across cloud environments, so the same platform has to work across AWS, Microsoft Azure and Google Cloud, and reach the systems still running in their own data centers. It’s not impossible, though, and with the right strategy, teams can refine operations while paving the way for secure, collaborative agentic ecosystems.

In this post, we lay out the blueprint for that foundation and share insights that we’ve gained from building one ourselves to use internally at Astreya.

Cloud engineering has solved a similar problem before 

With agentic AI, cloud teams are facing a similar challenge to the one posed years ago by containerization. Containers made it easier to package applications, which led to rapid proliferation. Cloud teams had to figure out how to run all those applications — reliably, while maintaining security and cost. Kubernetes solved the coordination issue but created an operational burden that gave rise to platform engineering.

Today, AI agents are getting easier to deploy, which will likely lead to more deployments that require more coordination and engineering. 

But hundreds of agents are not like hundreds or even thousands of static applications. Applications run on fixed logic and predetermined paths. Agents, on the other hand, reason and make their own decisions. They’re more like a workforce, while applications are more like a fleet. 

Kubernetes could solve container sprawl with orchestration rules because containers don't deviate from their code. You can't fully solve agent sprawl the same way, because the thing spreading isn't just instances, it's autonomous judgment. For that you need a single shared foundation that every AI agent runs on top of, so identity, governance, observability, and lifecycle management get built once and reused

Blueprint for a shared foundation 

With a single shared foundation, identity, governance, observability, and lifecycle management get built once and reused. Teams don’t have to reconfigure it every time they deploy an AI agent, and controls stay consistent without hindering progress. 

Below are some key elements of this shared foundation.

1. Agent identity — Every agent gets its own scoped login, not a shared password or a blank check
   
   
2. Tenant isolation — One team's agent can't accidentally touch another team's data
   
   
3. Governance — The rules (what an agent can and can't do) are set in one place, not decided separately by every team
   
   
4. Memory/state — Agents can remember context across a task without each team building their own memory system
   
   
5. Evaluation — One system checks whether agents are actually making good decisions, not just running without crashing
   
   
6. Observability — You can see why an agent did what it did, not just whether it ran
   
   
7. Cost tracking — You know what each agent costs to run, not just a big unexplained bill
   
   
8. Tool access — Agents reach other systems (Salesforce, databases, etc.) through one controlled gateway, instead of each agent having its own direct password into everything

The diagram below shows how those eight capabilities sit inside the platform. Requests come in through a gateway, get picked up by an agent, orchestrated, then run through the eight capability services before reaching real enterprise systems. 

Notice that hybrid (positioned alongside AWS, Azure and Google Cloud, on the bottom) doesn't require separate platforms. A single platform can securely govern agents across cloud and on-premises environments through shared identity, centralized governance and secure gateways to enterprise systems.

‍

Of the eight, agent identity is the hardest to get right. A single application typically needs one service account. An agent fleet needs hundreds of short-lived principals, each requiring scoped access into systems that were designed with human users in mind, not machines. 

It's also worth being clear that evaluation and observability aren't the same thing. Watching an agent's latency dashboard tells you about as much as confirming an employee showed up to the office on time. It doesn't tell you whether the work was any good. Decision quality can degrade even as error rates stay perfectly flat the whole time, which is why you need golden datasets and regression gates built into the pipeline, not just a dashboard. 

Evaluation depth should follow risk, not be applied uniformly. This includes how sensitive the data an agent can reach, how much breaks if it gets it wrong, and how far it has moved from pilot towards running on its own. A read-only agent needs little more than spot checks. One acting on production systems with customer data needs a golden dataset, a rubric, and safety checks that block release. Gates tighten as autonomy grows.

Why a shared foundation is so urgent 

In our experience, three things tend to surface within about 18 months of a pilot succeeding, usually before anyone goes looking for them.

• Controls lag adoption. Individual business units start standing up their own agents, each with its own credentials and no shared audit trail. It’s shadow IT, but with write access to production.
  
  
• Privileged access spreads. Giving an agent a broad service account is the fastest way to make it useful today. It is also the fastest way to fail an audit, once that same shortcut has been taken by forty different teams.
  
  
• Cost appears in arrears. Consumption tracks reasoning depth and retry behavior rather than headcount, so Finance usually finds out about a quarter after the fact.

Lessons from our own build

Before developing this blueprint, Astreya built a shared platform in its own cloud operations environment first and ran it for a while. 

It operates a set of specialized agents for identity, Kubernetes, virtual infrastructure, log analytics and cost optimization, each doing one job well. Posture management, Infrastructure as Code generation, and AI FinOps, sit underneath as shared platform services rather than tacked onto each agent individually. None of the agents hold direct credentials to enterprise systems; they reach everything through a governed Model Context Protocol interface instead. A few of these pieces have since turned into internal solution accelerators we reuse on client engagements, and the capability model below is now how we frame every agent platform we design.

We learned a lot from this trial. For example, observability that stops at latency and error rate doesn't survive a readiness review. You need the reasoning trace too. We were surprised to see that most of the engineering time went into evaluation, not into integrating the model itself, and that most unexpected costs came from retry behavior, not from the number of people using the system.

We translated these and other insights into the design principles below:

• Identity before autonomy: An agent should have a scoped identity before it's given any ability to act not after, so it can constrain whatever follows. Get it wrong and you're not just patching it later, you're rebuilding.
• Capabilities before cloud services: Design what the platform needs to do first. The specific service you use to do it will likely have a different name in eighteen months anyway. This is also what makes a multicloud estate workable. Each business unit can run its own runtime and gateway in its own cloud, provided both register against one shared policy catalogue and emit to one audit pipeline.
• One control plane, properly isolated tenants: Isolation should be a configuration of the platform, not a second platform standing next to it.
• Policy as code, by default: Controls that live in a wiki page don't get enforced. Controls that live in a pipeline do.
• Open interfaces over proprietary integrations: Protocols like MCP and OIDC make it cheaper to walk back a vendor decision later, which you'll probably want to do at some point.

Putting it to work: How to build a shared foundation

1. Foundations - Q1: Get agent identity, tenant isolation and one governed tool interface working properly. Pick one low-risk, high-frequency use case and take it all the way to production. This beats investing in five different use cases that only make it as far as a demo.
2. Operability - Q2–Q3:  Build out reasoning and tool-call traces. Add the "why did it do that" tracking, a real system for checking if agents are making good decisions, and start tracking what things cost.
3. Scale - Only after everything else is set: Focus on developing multi-agent collaboration, self-service onboarding, and a policy catalog that new agents inherit automatically. Let multiple agents work together, let teams self-serve new agents, and automate policy for new agents joining.

Closing thought

Even if your teams aren't yet standing up their own agents, you need a shared foundation to manage them. The process takes time, and without it, teams have no choice but to build their own identities, guardrails, ways of tracking costs, and evaluation checks. That kind of piecemeal engineering isn't sustainable, and it can undermine the parts of the business that already rely on clean audit trails and reliable cost visibility.

Astreya's Cloud & Hybrid IT practice builds that foundation — multi-cloud architecture, governance, and FinOps discipline, across AWS, Azure, Google Cloud, and whatever's still running in your own data centers. Let's talk about where yours stands.

‍

Read more from our Cloud Practice

• ‍Cloud Cost Optimization: 8 Practical Strategies to Cut Waste‍
• Cloud Infrastructure-as-Code Automation Value Model for ROI Optimization‍
• Autonomous Cloud Operations: Moving Beyond Scripts and Alerts‍
• Production-Ready Code Starts with Governed Infrastructure‍
• Google Cloud Next 2026: AI Operations Start with IT Operations