PayPal faced significant challenges managing reliability across 3,000 microservices processing $5 million per minute, with SRE teams overwhelmed by manual incident response work where 70% of effort went to data collection and correlation. The company developed an autonomous SRE agent system using Google Cloud's Vertex AI and Agent Development Kit (ADK) that orchestrates multiple specialized agents to detect, triage, mitigate, and report incidents in parallel rather than sequentially. The solution integrated with PayPal's diverse data sources through a unified MCP tools layer and was deployed into production in two to three weeks with 40-50% less code than alternative frameworks, reducing development time by 60-70% while providing built-in governance, observability, and the ability to evaluate and swap models without code changes.
PayPal, one of the world’s largest payment processors, implemented an autonomous SRE agent system to address severe operational challenges in managing reliability at massive scale. The company processes over $5 million in revenue per minute through 3,000 microservices, handling 2.5 billion API interactions daily and deploying 10.5 million production changes annually. The presentation featured multiple speakers from Google Cloud and PayPal discussing both the technical implementation and the broader operational considerations for deploying agents at enterprise scale.
The fundamental problem PayPal faced was that SRE and production engineering teams were drowning in manual, repetitive work. A key statistic highlighted was that 70% of incident response effort went into collecting and correlating data manually. Engineers experienced frequent after-hours paging leading to burnout, context was regularly lost between on-call shift rotations, and RCA documentation consistently lagged behind incidents. The challenge wasn’t a lack of tools but rather a lack of effective orchestration between them.
The presentation established a foundational framework for thinking about AI agents in production, structured around three core components: models, context, and tooling. The model selection philosophy was framed around the metaphor of having 100 interns or graduate students—you would interview them to understand their strengths and personalities. Similarly, different LLMs have different capabilities, and production systems need the flexibility to call any model suited for specific tasks.
Context engineering was described as transforming graduate students into returning interns who understand organizational practices. For LLMs, this means providing context about build practices, organizational procedures, escalation protocols, and operational standards. Without this context, even powerful models cannot make appropriate decisions in production environments.
The tooling component encompasses orchestration frameworks, deployment harnesses, monitoring platforms, and systems for validating that tool call trajectories proceed in the right direction. This represents the management layer for coordinating multiple agents in production.
PayPal’s implementation began not with AI models or frameworks but with a comprehensive audit of data sources and their interconnections. The team documented where SRE-relevant data resided, why it was stored in particular systems, how teams accessed it, and what connections existed between sources. This bottom-up approach proved critical for integrating agents into an existing complex ecosystem rather than building in a greenfield environment.
The data landscape included BigQuery in GCP as the primary SRE data lake, CAL (PayPal’s internal logging system) providing real-time observability and distributed tracing, ServiceNow for ITSM and change requests, and Splunk and Datadog for logs, metrics, dashboards, and alerting. The fragmentation across these systems meant that SRE engineers paged at 2 AM had to traverse multiple data planes to understand incidents—a cognitively demanding task under pressure.
A critical technical innovation was building what PayPal called SRE MCP tools—a unified API layer providing single-point access to all disparate data sources. This MCP integration layer made agents practical by abstracting the complexity of multiple backend systems. Rather than each agent needing custom integrations with every data source, they could access everything through standardized interfaces. This architectural decision significantly reduced the implementation complexity and made the agent system maintainable.
The presentation emphasized that the solution wasn’t creating more dashboards, alerts, or tools. In fact, a 2025 report was cited showing that despite increased investment in AI and operational tooling, engineering toil had actually increased as teams now had to monitor both their systems and their AI tools. PayPal’s approach focused on autonomous execution rather than just providing better interfaces to existing information.
The autonomous SRE system implements a complete incident lifecycle workflow encompassing detection, triage, mitigation, and reporting. The architecture features multiple specialized agents coordinated by a supervisor agent. Key specialized agents include:
A distinguishing feature is parallel execution capability. Traditional incident response is serial—detect, wake someone, triage, communicate, resolve. PayPal’s system executes many of these steps concurrently, significantly collapsing the incident lifecycle timeline. The system also maintains persistent memory across on-call shift rotations, preserving context that would traditionally be lost despite documentation efforts.
The triaging agent performs semantic matching against historical incident data, scoring new incidents and providing probable root causes before engineers are even paged. This represents a substantive improvement over traditional alert-based systems that provide minimal context.
PayPal’s model selection philosophy explicitly rejects the notion of picking a single model and committing to it long-term. The team continuously evaluates new models as they become available, with the specific use case dictating which model to deploy. This requires a flexible system architecture that supports trying different models and understanding their performance characteristics.
Google Cloud’s Model Garden provided access to over 200 models for evaluation. At the time of the presentation, PayPal was running Gemini 1.5 Pro in production, selected for its superior reasoning capabilities in incident analysis. However, the architecture allows model swapping without code changes, enabling rapid experimentation and adaptation as new models emerge.
Vertex AI’s evaluation framework proved essential for this strategy, enabling QA teams to assess models across multiple dimensions: accuracy, hallucination rates, latency, and cost profiles. Critically, PayPal developed SRE-specific evaluation tasks to test model performance on actual operational scenarios rather than generic benchmarks. This domain-specific evaluation approach ensures models are assessed on capabilities that matter for production incident management.
PayPal evaluated multiple agent frameworks and even built some in-house before settling on Google’s Agent Development Kit (ADK). The ADK reportedly accelerated development time by 60-70% and enabled deployment with 40-50% less code compared to alternatives. The team moved from proof of concept to production deployment in just two to three weeks.
The velocity gains came primarily from infrastructure capabilities built into ADK rather than requiring custom development. Key built-in features included session and memory management for maintaining context across interactions, persistent context storage, native multi-agent supervisor routing for coordinating specialized agents, and parallel agent execution capabilities. The framework also provides auto-scaling infrastructure on Vertex AI with integrated monitoring.
The presentation acknowledged that many agent demonstrations at conferences showcase greenfield scenarios—new projects with new data stores and new microservices where everything can be designed for agent integration from scratch. PayPal’s reality was integrating into an existing environment with 3,000 microservices, data across GCP and on-premises systems, and multiple alerting mechanisms. The successful integration into this brownfield environment represents a more realistic assessment of production deployment challenges.
A demonstration illustrated the end-to-end workflow using PayPal’s chaos engineering toolkit to inject anomalies into production systems. The sequence showed Datadog monitoring detecting threshold breaches, alerts routing to Slack, and the supervisor agent automatically initiating the response workflow. Multiple agents activated in parallel—the investigator agent and data collector agent ran concurrently, with the service analyst agent then determining service dependencies and blast radius. The change analyst agent correlated the incident with recent deployments, and the mitigator agent identified matching SOPs and executed a service restart. The reporting and communications agents then documented the incident and notified stakeholders.
This demonstration highlighted both the parallel execution model and the integration through the MCP tools layer, showing how agents accessed diverse data sources without custom per-source logic.
The presentation expanded beyond PayPal’s specific implementation to address broader operational considerations for deploying agents at enterprise scale. Using the metaphor of managing thousands of returning interns, the governance framework was structured around four pillars: agent security, agent gateway, identity and registry, and observability.
Agent security maps to building badge access and keycard systems—ensuring agents have appropriate permissions and cannot access restricted resources. Agent gateway functions as the onboarding process and building entry controls, managing how agents enter the production environment and what initial access they receive. Identity and registry provides the organizational chart function—tracking what agents exist, their purposes, relationships, and interactions. Observability corresponds to performance reviews and timesheets—monitoring agent decision-making, detecting hallucinations, and catching mistakes.
The presentation emphasized that observability is often an afterthought in agent deployments but must be considered from the beginning. Production agents will make mistakes just as humans do, and the system must enable operators to detect and correct those errors. Runtime protection and toxic content blocking were mentioned as additional governance requirements.
A significant operational challenge identified was the overwhelming number of choices agent builders face—selecting IDEs, frameworks, orchestrators, evaluation tools, and skill libraries. This decision fatigue compounds when deploying agents, with each deployment potentially using different approaches. In an enterprise environment, this creates security nightmares, governance problems, and makes systematic management impossible.
The solution proposed was establishing a golden path—a standardized, intentionally boring deployment approach that makes agent deployment a one-click process. The golden path architecture separates concerns between what agent builders should configure (the agent logic itself) and what should be standardized platform concerns (governance, security, identity, gateway configuration).
The implementation process has three steps. First, platform teams choose appropriate runtimes for the enterprise context. Second—the critical step—they create infrastructure deployment templates with agent governance embedded directly into the templates. This is a one-time activity for the platform team. Third, these templates are provided to agent builders throughout the organization who can use them repeatedly without modification.
This approach provides out-of-box visibility for all deployed agents, giving SecOps and governance teams immediate oversight of agent actions, security posture, and runtime behavior without requiring agent builders to implement these capabilities individually.
The infrastructure orchestrator discussed was Google Cloud’s Application Design Center, positioned as a tool for platform engineers, SREs, and SecOps teams to create deployment templates that embed governance requirements. Once templates are created, developers can deploy agent logic without being bottlenecked by security reviews or governance implementation.
Application Design Center supports multiple deployment architectures for different agent types—marketing agents, SRE agents, business processing agents—each with appropriate policies for resource access and communication patterns. It functions as a self-service portal, removing platform teams as deployment bottlenecks while maintaining governance standards.
The tool is explicitly positioned for anybody building and deploying agents at enterprise scale, not just traditional developers. The emphasis on self-service and standardization addresses the operational reality that agent development is becoming democratized across organizations, and governance must scale accordingly.
While the presentation made strong claims about development velocity and operational improvements, several factors warrant balanced consideration. The 60-70% development time reduction and 40-50% code reduction claims for ADK lack comparative baseline details—it’s unclear what specific alternative implementations were measured against. The two-to-three-week timeline from POC to production is impressive but may reflect the maturity of PayPal’s existing data infrastructure and the team’s expertise rather than just framework capabilities.
The model swapping without code changes claim, while architecturally sound, doesn’t address the reality that different models may have different prompt engineering requirements, context window limitations, or output format variations that could require logic changes in practice. The evaluation framework discussion was high-level without details on specific metrics, test scenarios, or performance thresholds.
The governance framework and golden path concepts are sound operational practices, but the presentation didn’t address change management challenges in getting diverse teams to adopt standardized approaches, especially in organizations with established alternative practices. The Application Design Center tool was presented without discussing potential limitations, learning curves, or constraints it might impose on deployment patterns.
The PayPal implementation appears genuinely sophisticated and represents thoughtful production engineering, but the presentation served multiple purposes—showcasing a customer success story while promoting Google Cloud services. The autonomous incident response capability is clearly valuable, though the presentation didn’t quantify specific improvements in metrics like mean time to resolution, false positive rates, or percentage of incidents requiring human intervention.
This case study illustrates several important LLMOps principles for production agent deployment. First, the data integration layer (MCP tools) proved as important as the AI components themselves—production agents need standardized interfaces to organizational data and systems. Second, the ability to evaluate and swap models without architectural changes provides essential flexibility as the LLM landscape evolves rapidly. Third, governance and observability cannot be afterthoughts but must be designed into the deployment architecture from the beginning.
The emphasis on brownfield integration—working with existing microservices, data stores, and alerting systems—represents a more realistic production scenario than greenfield demonstrations common in the space. The multi-agent coordination with parallel execution shows how to structure complex workflows rather than attempting to solve everything with a single monolithic agent.
The governance framework and golden path concepts address a critical gap in enterprise LLMOps—how to enable widespread agent deployment while maintaining security, visibility, and operational control. As organizations move from experimenting with a handful of agents to deploying dozens or hundreds, these operational concerns become paramount. The separation between agent logic (what builders should focus on) and governance/infrastructure (what platforms should provide) offers a sustainable model for scaling agent deployments across large organizations.
Snorkel developed a specialized benchmark dataset for evaluating AI agents in insurance underwriting, leveraging their expert network of Chartered Property and Casualty Underwriters (CPCUs). The benchmark simulates an AI copilot that assists junior underwriters by reasoning over proprietary knowledge, using multiple tools including databases and underwriting guidelines, and engaging in multi-turn conversations. The evaluation revealed significant performance variations across frontier models (single digits to ~80% accuracy), with notable error modes including tool use failures (36% of conversations) and hallucinations from pretrained domain knowledge, particularly from OpenAI models which hallucinated non-existent insurance products 15-45% of the time.
Two organizations operating in highly regulated industries—Sicoob, a Brazilian cooperative financial institution, and Holland Casino, a government-mandated Dutch gaming operator—share their approaches to deploying generative AI workloads while maintaining strict compliance requirements. Sicoob built a scalable infrastructure using Amazon EKS with GPU instances, leveraging open-source tools like Karpenter, KEDA, vLLM, and Open WebUI to run multiple open-source LLMs (Llama, Mistral, DeepSeek, Granite) for code generation, robotic process automation, investment advisory, and document interaction use cases, achieving cost efficiency through spot instances and auto-scaling. Holland Casino took a different path, using Anthropic's Claude models via Amazon Bedrock and developing lightweight AI agents using the Strands framework, later deploying them through Bedrock Agent Core to provide management stakeholders with self-service access to cost, security, and operational insights. Both organizations emphasized the importance of security, governance, compliance frameworks (including ISO 42001 for AI), and responsible AI practices while demonstrating that regulatory requirements need not inhibit AI adoption when proper architectural patterns and AWS services are employed.
Prudential Financial, in partnership with AWS GenAI Innovation Center, built a scalable multi-agent platform to support 100,000+ financial advisors across insurance and financial services. The system addresses fragmented workflows where advisors previously had to navigate dozens of disconnected IT systems for client engagement, underwriting, product information, and servicing. The solution features an orchestration agent that routes requests to specialized sub-agents (quick quote, forms, product, illustration, book of business) while maintaining context and enforcing governance. The platform-based microservices architecture reduced time-to-value from 6-8 weeks to 3-4 weeks for new agent deployments, enabled cross-business reusability, and provided standardized frameworks for authentication, LLM gateway access, knowledge management, and observability while handling the complexity of scaling multi-agent systems in a regulated financial services environment.
