Enterprises have learned the hard way that wiring a powerful model into an application is not the same as engineering a production-grade AI system. What begins as a working prototype often evolves into a collection of loosely connected components prompt logic, tool integrations, access controls, and evaluation scripts each solving a local problem, but collectively difficult to operate, govern, and extend.
The Engineering Production-Grade AI Systems white paper argues that this outcome is predictable. Systems that survive beyond initial deployment require a clear separation of concerns capabilities, orchestration, safety, observability, compliance, and lifecycle. These layers exist whether they are explicitly designed or implicitly embedded in application code; the difference is whether they can be reasoned about, reused, and governed consistently.
What is changing now is not just the availability of agentic capabilities, but where these system responsibilities live. Capabilities that previously required bespoke engineering identity, orchestration, evaluation, and policy are increasingly being absorbed into managed hyperscaler agent platforms. Amazon Bedrock AgentCore, Azure AI Foundry Agent Service, and Google's newly announced Gemini Enterprise Agent Platform each represent a different approach to this transition but converge on a common idea: agents are no longer patterns implemented inside applications; they are workloads that run on a shared control plane.
This article takes a technical, implementation-focused view of how these platforms behave in production systems where orchestration, policy, and observability become first-order concerns how they map to an architecture suitable for long-lived AI systems, and how concrete use cases such as sales analytics agents, clinical intake automation, and operational copilots change when rebuilt on these platforms. The intent is to be explicit about system behavior and trade-offs: where these platforms reduce complexity, where they introduce constraints, and how they redefine the boundary between application logic and platform responsibility.
From bespoke agents to shared platform concerns
GoML's early production deployments of agentic systems followed a familiar pattern:
- A sales analytics assistant for Sun Pharma used Microsoft Autogen and GPT-4 to coordinate multiple agents – a conversational front-end, a query agent, an analysis agent, and a visualization agent running on top of PostgreSQL, Streamlit, and PyGWalker.
- A Doppelio enterprise chat agent used structured prompting to improve information extraction by 67%.
- Clinical workflow automation for WizTherapy combined AWS Lambda, Textract, and custom orchestration to reduce intake effort by 80%.
These systems delivered tangible value. They also carried a substantial amount of hidden platform logic.
Each implementation embedded its own handling of long-lived sessions, tool invocation, error handling, access control, logging, and evaluation pipelines. These concerns were necessary for the system to function reliably, but they were implemented repeatedly, across projects.
The white paper breaks this hidden layer into explicit components: model access, orchestration, tools, data and knowledge, safety and policy, observability and evaluation, and lifecycle. The implication is straightforward. These layers must exist somewhere; if they are not centralized, they become distributed across application code, making systems harder to evolve and govern over time.
Centralizing agent development with hyperscaler agent platforms
The current generation of hyperscaler agent platforms is best understood as an attempt to centralize these concerns. The key transition is not the introduction of new capabilities, but the relocation of responsibilities – from application-level implementations to platform-level primitives.
A notable aspect of this transition is that agents are no longer treated as static deployments. Evaluation, monitoring, and optimization are increasingly built into the platform layer, enabling continuous improvement based on real-world usage rather than one-time testing.
Amazon Bedrock AgentCore
Among the hyperscalers, AWS approaches this problem from an infrastructure-first perspective. Amazon Bedrock AgentCore can be viewed as an operating system for agents within the AWS environment, where orchestration, tool invocation, and policy enforcement are exposed as managed primitives rather than implemented within application code.
At its core, Amazon Bedrock AgentCore provides a managed runtime responsible for session handling, multi-step workflows, and tool orchestration, while maintaining isolation between sessions. In practice, this includes native support for multi-step task decomposition, structured tool invocation using defined API schemas, and memory for maintaining context across interactions. An Agent Gateway standardizes how services are exposed as tools, whether they are AWS-native or external APIs, with unified authentication and access control.
Identity and policy are integrated with AWS IAM and external identity providers, enabling fine-grained permissions to be enforced at the platform boundary. Observability and evaluation capabilities provide tracing, logging, and scoring of agent behavior, enabling feedback loops that resemble established SRE and QA practices. Additional capabilities, such as a secure browser and code execution environment, allow agents to interact with external systems in a controlled manner.
Revisiting the Sun Pharma analytics system under this model makes the transition concrete. Orchestration logic that previously lived inside an Autogen-based application moves into the managed runtime. Query and analytics capabilities become tools exposed through the Agent Gateway, with explicit contracts and centralized access control. Memory tracks evolving analytical context per session, while policy enforcement ensures that data access aligns with user roles at the platform level. Observability pipelines capture failure modes malformed queries, inconsistent outputs, latency spikes and feed them into evaluation workflows.
Clinical intake automation follows a similar pattern. Instead of coordinating Lambda functions and extraction pipelines manually, the entire intake process can be modeled as an agent that orchestrates document ingestion, extraction, validation, and persistence under a unified policy boundary, with evaluation pipelines measuring performance across templates and edge cases.
The result is a system where orchestration, policy, and evaluation are treated as infrastructure concerns rather than application logic. This approach provides flexibility and composability, but assumes that surrounding platform practices identity management, data access, and operational discipline are already well-defined.
Azure AI Foundry Agent Service
Microsoft approaches the same problem from a different direction, treating agent capabilities as an extension of the existing enterprise control plane rather than a new infrastructure layer.
Azure AI Foundry Agent Service provides a managed runtime for hosting agents and coordinating tool execution, but its defining characteristic is integration with the broader Azure ecosystem. A rich tool catalog connects agents to enterprise data sources such as SharePoint, Microsoft Fabric, Azure AI Search, and external systems via the Model Context Protocol (MCP). The use of MCP introduces a standardized way to expose tools and data sources to agents, reducing the need for custom integration logic and enabling more consistent behavior across environments.
A defining aspect of this model is that agents operate directly on enterprise data through managed connectors, rather than relying primarily on application-level retrieval pipelines. Identity and governance are anchored in Microsoft Entra and Azure RBAC, aligning agent behavior with existing access control and compliance models.
Observability, safety, and compliance capabilities are integrated into Azure's monitoring and policy framework, providing a unified view across AI and non-AI workloads.
In an Azure-native implementation of the sales analytics use case, the agent exists as a managed entity within Foundry, orchestrating data access through enterprise connectors and integrating with visualization tools such as Power BI or Fabric. Security and observability align with existing enterprise controls, reducing the need to build parallel systems for access management and monitoring.
For structured extraction scenarios like Doppelio, built-in capabilities file search, retrieval, code execution, and custom tools combine into a pipeline that ingests unstructured data, transforms it, and writes structured outputs back into enterprise systems under managed authentication.
This model simplifies integration and reduces duplication of platform concerns but introduces tighter coupling between agent architecture and the Azure ecosystem. The trade-off is between speed of adoption and long-term portability.
Gemini Enterprise Agent Platform
Google's approach moves the focus from infrastructure and integration to coordination, lifecycle management, and governance at scale. The Gemini Enterprise Agent Platform introduces a runtime, registry, and gateway that together act as a control layer for managing a distributed set of agents.
The Agent Runtime handles execution, scaling, and multi-step workflows. The Agent Registry provides a catalog of agents and tools, including metadata about ownership, usage constraints, and governance attributes. The Agent Gateway enforces policy and routing for agent interactions, acting as a central point for access control and compliance.
What distinguishes this platform is that it is not just an execution layer, but a unified system that combines model development, agent orchestration, and enterprise integration into a single surface. Built on top of Google Cloud's Vertex AI, it supports multiple model providers while integrating with a centralized Gemini Enterprise interface for end users. Deployment, monitoring, and optimization are part of the same system, rather than separate concerns.
This structure addresses a problem that becomes visible as agent adoption grows: the lack of a centralized view of what agents exist, what they can do, and which data they access. The registry and gateway together provide that visibility and control, enabling traceability and policy enforcement across all agent interactions.
Integrated with Google Cloud IAM, DLP, and Workspace, the platform enables agents to operate across both application data and collaboration artifacts documents, spreadsheets, email within a unified governance boundary.
This approach emphasizes coordination and discoverability. It makes it easier to manage a large number of agents as a system but introduces a more opinionated abstraction that may limit low-level control over execution and orchestration compared to infrastructure-centric models.
Convergence in architecture, divergence in strategy
Across these hyperscaler agent platforms, there is clear convergence in structure. Each provides a managed agent runtime, a standardized tool integration layer, platform-level identity and policy enforcement, and built-in observability and evaluation capabilities. These correspond closely to the layers required for production-grade AI systems as outlined in the white paper.
One dimension that cuts across these hyperscaler agent platforms is how they treat the model layer. Amazon Bedrock abstracts access to multiple foundation models while keeping the runtime separate. Azure AI Foundry Agent Service tightly integrates models with the broader platform and enterprise data ecosystem. The Gemini Enterprise Agent Platform combines model development and agent execution into a unified system, with support for both proprietary and third-party models. These differences influence not just flexibility, but how tightly coupled agent behavior becomes to the underlying platform.
At a high level, Amazon Bedrock AgentCore treats agents as infrastructure, Azure AI Foundry Agent Service treats them as part of an enterprise control plane, and the Gemini Enterprise Agent Platform treats them as a coordinated, governed system integrated with both model development and end-user experience.
These differences translate into practical trade-offs. Infrastructure-centric approaches provide control and extensibility but require stronger internal discipline. Platform-centric approaches accelerate integration but increase dependency on ecosystem boundaries. Coordination-centric approaches improve visibility and governance at scale but may abstract away lower-level control.
In practice, the question is not which model is correct, but how these trade-offs align with existing systems, organizational structure, and operational maturity.
Implications for hyperscaler agent platform architecture
The emergence of these platforms reframes a set of foundational questions. The problem is no longer how to build individual agents, but where the responsibilities for orchestration, policy, and evaluation should live.
In practical terms, the control plane determines how agents are authenticated, what data they can access, how tools are invoked, how behavior is monitored, and how failures are handled across the system.
This includes deciding:
- where the agent runtime should be hosted
- how identity and access control are enforced across tools and data sources
- how tools are exposed with clear, reusable contracts
- how observability and evaluation are implemented across all interactions
These are not implementation details; they define the operating model for AI systems.
In AWS-first environments, Amazon Bedrock AgentCore provides a flexible foundation for centralizing these concerns. In Azure-centric environments, Azure AI Foundry Agent Service extends existing governance models into AI workloads. In Google-centric environments, the Gemini Enterprise Agent Platform offers a consolidated approach to managing agents as a coordinated system.
Regardless of platform choice, the underlying discipline remains consistent. Agent runtimes function as shared infrastructure. Identity and policy are enforced at the platform boundary. Observability and evaluation are built in from the outset, not added after deployment.
Systems that do not make these distinctions tend to accumulate hidden complexity, with each new use case reintroducing the same concerns in slightly different forms.
Where systems fail
These hyperscaler agent platforms also change where failures occur. Instead of failing inside application logic, failures increasingly surface at the platform boundary incorrect tool invocation, insufficient context, policy enforcement conflicts, or degraded model behavior.
Understanding and instrumenting these failure modes becomes as important as defining the happy path. Systems that treat observability and evaluation as first-class concerns are better positioned to detect regressions, enforce constraints, and evolve safely over time.
Closing perspective
What is underway is not simply about more capable agents; it is about the emergence of a control plane for AI systems. Hyperscaler agent platforms are converging on a common answer to how agents should be built, deployed, and governed as part of a broader system.
The question is no longer how to assemble individual components, but where control resides what is implemented within application code, what is delegated to platform primitives, and how those decisions define the system over time.
This is exactly where GoML's AI Matic framework fits in, providing a structured approach to move from fragmented agent patterns to production-grade, governed AI systems. It helps teams standardize orchestration, deployment, and lifecycle management so systems can scale without accumulating hidden complexity.
Systems that treat agent capabilities as isolated features will continue to fragment. Systems that treat them as part of a shared, governed hyperscaler agent platform will be easier to operate, evolve, and extend as the underlying technology changes.
.jpg)
