How Cornerstone OnDemand cut database diagnosis by 78% with Amazon Bedrock

來源原標題

How Cornerstone OnDemand cut database diagnosis by 78% with Amazon Bedrock

作者

Derek Ziehl

原始標籤

Amazon Bedrock · Customer Solutions

原始連結

https://aws.amazon.com/blogs/machine-learning/how-cornerstone-ondemand-cut-database-diagnosis-by-78-with-amazon-bedrock/

摘要原文

Cornerstone OnDemand, Inc. (Cornerstone) is a global leader in workforce readiness solutions, serving 140 million users across 186 countries. The company built a multi-agent AI system that transforms database operations from reactive firefighting into proactive, self-orchestrating workflows. The system, called Orion AI, uses Amazon Bedrock and Strands Agents , an open source agent orchestration framework from AWS, to coordinate specialized agents. Before Orion AI, Cornerstone’s Enterprise DataOps team would spend up to 45 minutes per database incident manually querying system views and cross-referencing logs before handing off across teams. With Orion AI, database diagnosis dropped from 45 minutes to 10, a 78% reduction. A three-person team delivered the system in six months. In this post, we walk through the operational problem Cornerstone faced, how they designed Orion AI, the outcomes they measured, and the design decisions other teams can reuse. Before Orion AI, Cornerstone’s Enterprise DataOps team operated reactively, with four recurring pain points: Together, these meant engineers spent their time on manual coordination instead of resolving issues. Orion AI is a multi-agent system where a coordinating agent (the meta-orchestrator) delegates work to specialized child agents arranged in a hub-and-spoke topology. Engineers interact with it through a web application, asking questions and approving actions in the same place they already coordinate operational work. The agents cover infrastructure monitoring, database diagnostics, database lifecycle operations, customer analytics, and knowledge-driven support. Two tenets guided the build: data privacy using AWS controls under the shared responsibility model , and deep integration with existing operational tools. Amazon Bedrock provided managed access to foundation models, and Strands Agents provided the orchestration layer. Orion AI delivered measurable improvements in both diagnosis speed and accuracy and freed the team from manual coordination. By automating manual bottlenecks and streamlining cross-team workflows, Cornerstone achieved the following outcomes. Reducing database diagnosis time was Orion AI’s largest single efficiency gain to date. Previously, engineers manually connected to the affected SQL Server instance, queried system views for blocking chains and wait types, cross-referenced logs to isolate long-running queries, and correlated evidence to form a root cause hypothesis. This averaged approximately 45 minutes per incident. With Orion AI, three specialized agents share the investigation, each owning a distinct stage. Beyond diagnosis, Orion AI carries issues through remediation: identifying the root cause, recommending the fix, and creating a populated Jira ticket assigned to the right on-call engineer. A four-step manual handoff collapses into a single interaction. Tasks that previously required over 10 manual steps, from establishing database connections to running cross-system queries to communicating status updates, now run as a single natural language interaction. Orion AI identifies the right tools and data sources, runs queries across systems, validates results, and returns a unified response. From the engineer’s perspective, the work is reduced to prompting Orion AI and validating the findings it reports back. Orion AI removed the 15-minute SRE-to-data-team reporting lag, replacing periodic manual checks with continuous cross-system visibility. Orion AI reduced redundant alerts by a median of 65 percent through deduplication, threshold filtering, and cross-signal correlation. For every 10 alerts previously generated, only 3–4 now reach engineers. Alerts route directly to the responsible teams without an intermediate alerting layer. Three decisions shaped Orion AI, and you can apply them to your own multi-agent projects: Orion AI is deployed as containerized services on Amazon Elastic Container Service (Amazon ECS). Users interact through a web application that routes each request to the appropriate agent, invokes the required tools, and assembles the response. The following diagram shows how these components connect within the AWS Cloud. Figure 1: Orion AI architecture: a meta-orchestrator on Amazon ECS routes requests to specialized agents, which reach data sources through a Portal-Tools MCP server and use Amazon Bedrock for models, long-term memory, and retrieval augmented generation The preceding design principles show up concretely in the architecture. The rest of this section walks through Orion AI’s core components. Orion AI expresses its topology with a handful of Strands Agents primitives. The Agent class is the building block for both specialist agents and the meta-orchestrator. Each agent’s tools are ordinary Python functions marked with the @tool decorator. This derives a tool’s specification from the function’s type hints and docstring, meaning there is no separate schema to maintain. BedrockModel wraps the Amazon Bedrock model each agent runs on, and MCPClient connects agents to external tool servers. At runtime, the hub invokes a specialist by name through the registered call_agent tool. Each specialist runs its own tool-calling loop and returns synthesized text back to the hub, which assembles the final response. Orion AI uses keyword-first routing with a semantic search fallback. Approximately 80 percent of queries resolve through an in-memory keyword fast-path in under a millisecond. When keywords are insufficient to determine intent, the system falls back to semantic search powered by Amazon Titan Text Embeddings V2 to route by meaning. For model availability by AWS Region, see Supported models by AWS Region in Amazon Bedrock . When direct tool invocation isn’t appropriate, a fallback chain activates: Amazon Bedrock Knowledge Bases , the fully managed Retrieval Augmented Generation (RAG) capability, retrieves operational documentation so responses are grounded in approved procedures rather than generated without context. Orion AI uses 13 domain-specific agents. The three SQL Server agents illustrate how domain splitting maps to the stages of a real investigation: The remaining agents follow the same principle of narrow ownership: infrastructure monitoring, operational analytics, database lifecycle management, customer analytics, knowledge retrieval from runbooks, notification routing, compound query decomposition, Availability Group listener resolution, and model connection warm-up. Orion AI reaches data sources through two patterns: This split means each agent uses the lightest mechanism that fits its source, while the MCP server centralizes the tools that several agents share. These connections run over TLS, and credentials such as the MCP token and REST API authorization are supplied per request, not embedded in agent code. Amazon Bedrock AgentCore , a platform to build, connect, and optimize agents at scale with any framework or model, provides the cross-session memory layer. Orion AI coordinates context through a central memory manager that reads from three tiers in parallel, each with its own timeout and token allocation. Orion AI coordinates context across three tiers. Short-term memory keeps same-session context in Amazon DynamoDB , encrypted at rest by default, paired with a rolling conversation summary that Amazon Nova 2 Lite generates asynchronously. Long-term memory provides cross-session recall through AgentCore memory, a capability of Amazon Bedrock AgentCore, namespaced by user ID. On task completion, Orion AI calls create_event to trigger automated extraction, summarization, and consolidation. A third tier, inter-agent memory, is an ephemeral in-memory scratchpad that carries findings across sub-agent steps within a single task. The memory manager retrieves across the tiers within a 500-millisecond hard timeout against a 4,000-token budget, backed by a least-recently-used cache.