Cornerstone OnDemand 借助 Amazon Bedrock 将数据库诊断时间缩短 78%

Cornerstone OnDemand, Inc.（Cornerstone）是全球劳动力就绪解决方案领域的领导者，为 186 个国家的 1.4 亿用户提供服务。该公司构建了一套多智能体 AI 系统，将数据库运维从被动式救火转变为主动式、自组织的工作流。该系统名为 Orion AI，采用 Amazon Bedrock 及 Strands Agents；后者是 AWS 推出的开源智能体编排框架，用于协调各类专业智能体。

在 Orion AI 出现之前，Cornerstone 的 Enterprise DataOps 团队每次处理数据库事件时，需要花费最多 45 分钟，手动查询系统视图、交叉比对日志，然后再在团队之间进行交接。借助 Orion AI，数据库诊断时间从 45 分钟降至 10 分钟，缩短了 78%。一个由三人组成的团队在六个月内交付了这一系统。

本文将介绍 Cornerstone 面临的运维问题、其如何设计 Orion AI、所衡量的结果，以及其他团队可以复用的设计决策。

运维挑战

在 Orion AI 之前，Cornerstone 的 Enterprise DataOps 团队以被动方式开展工作，面临四项反复出现的痛点：

• 数据库性能调查平均每起事件需要约 45 分钟，且需要跨多个工具和系统视图操作。
• 数据库生命周期工作流需要 10 个或更多手动步骤，包括建立连接和传递状态更新。
• 站点可靠性工程（SRE）团队与数据团队之间的报告存在 15 分钟延迟。
• 冗余和重叠的告警制造了噪声，掩盖了真正重要的信号。

这些问题共同导致工程师将大量时间花在手动协调上，而不是解决实际问题。

解决方案：Orion AI

Orion AI 是一套多智能体系统：一个协调智能体（元编排器）将工作委派给采用中心辐射拓扑组织的专业子智能体。工程师通过 Web 应用与系统交互，在他们原本就用于协调运维工作的同一位置提出问题并审批操作。智能体覆盖基础设施监控、数据库诊断、数据库生命周期运维、客户分析以及知识驱动的支持。

两项原则指导了系统构建：一是基于 共同责任模型 使用 AWS 控制措施保障数据隐私；二是深度集成现有运维工具。Amazon Bedrock 提供对基础模型的托管访问，Strands Agents 则提供编排层。

结果

Orion AI 在诊断速度和准确性两方面均带来了可衡量的改进，并使团队摆脱了手动协调工作。通过自动化人工瓶颈并简化跨团队工作流，Cornerstone 取得了以下成果。

指标	之前	之后	改善幅度
数据库诊断时间	45 分钟	10 分钟	快 78%
手动生命周期步骤	10+ 步骤	1 次交互	减少 70%
SRE-to-data-team 报告延迟	15 分钟	即时	实时
冗余告警	高基线数量	已过滤	减少 65%（中位数）

更快的性能故障排查

缩短数据库诊断时间是 Orion AI 迄今为止带来的最大单项效率提升。此前，工程师需要手动连接到受影响的 SQL Server 实例，查询系统视图以查看阻塞链和等待类型，交叉比对日志以定位长时间运行的查询，并关联证据以形成根本原因假设。每起事件平均需要约 45 分钟。

借助 Orion AI，三个专业智能体共同开展调查，每个智能体负责一个不同阶段。除诊断外，Orion AI 还能将问题推进至修复阶段：识别根本原因、推荐解决方案，并创建已填充内容且分配给正确值班工程师的 Jira 工单。原本由四个步骤组成的手动交接被压缩为一次交互。

自动化数据库生命周期管理

此前需要超过 10 个手动步骤的任务——从建立数据库连接、运行跨系统查询，到传递状态更新——如今可通过一次自然语言交互完成。Orion AI 会识别合适的工具和数据源，跨系统运行查询，验证结果，并返回统一响应。从工程师的角度看，工作被简化为向 Orion AI 发出提示并验证其返回的发现结果。

实时监控与减少告警疲劳

Orion AI 消除了 SRE-to-data-team 的 15 分钟报告延迟，以持续的跨系统可见性取代了周期性的手动检查。

Orion AI 通过去重、阈值过滤和跨信号关联，将冗余告警的中位数减少了 65%。此前每产生 10 条告警，如今仅有 3 至 4 条会送达工程师。告警会直接路由给负责团队，无需经过中间告警层。

关键设计原则

三项决策塑造了 Orion AI，你也可以将它们应用于自己的多智能体项目：

1. 按领域而非任务复杂度拆分智能体：每个智能体仅承载某一运维领域的一组有限工具集成。这能使模型上下文保持聚焦，并提升工具选择的准确性，而不是要求一个通用智能体完成所有事情。
2. 默认采用关键词路由，在必要时回退至语义搜索：可预测的请求通过关键词匹配以获得速度；模糊请求则回退至语义搜索以确保准确性。这样既能保持较低延迟，又不会牺牲复杂查询的正确性。
3. 将对话记忆限定在会话范围内，并针对实时指标绕过记忆：持久记忆支持多轮对话，但运维问题始终应读取当前系统状态。对实时指标绕过记忆有助于防止过期数据污染实时诊断。

架构概览

Orion AI 以容器化服务形式部署在 Amazon Elastic Container Service（Amazon ECS）上。用户通过 Web 应用交互，应用将每项请求路由至适当智能体、调用所需工具，并组装响应。下图展示了这些组件如何在 AWS Cloud 中连接。

图 1：Orion AI 架构：Amazon ECS 上的元编排器将请求路由至专业智能体；这些智能体通过 Portal-Tools MCP 服务器访问数据源，并使用 Amazon Bedrock 获取模型、长期记忆和检索增强生成能力。

架构深入解析

前述设计原则在架构中得到了具体体现。本节其余部分将介绍 Orion AI 的核心组件。

使用 Strands Agents 构建中心辐射模式

Orion AI 使用少量 Strands Agents 原语来表达其拓扑。Agent 类是专业智能体和元编排器的基础构建块。每个智能体的工具都是使用 @tool 装饰器标记的普通 Python 函数。该机制会从函数的类型提示和文档字符串中推导工具规范，因此无需维护单独的 schema。BedrockModel 封装每个智能体运行所使用的 Amazon Bedrock 模型，MCPClient 则将智能体连接至外部工具服务器。

拓扑如下：

• 中心是一个充当元编排器的 Strands Agent（TaskExecutor）。它不持有领域工具，只持有路由工具（find_relevant_agents、call_agent）和控制流工具（emit_plan_step、emit_confirmation_gate），以便能够逐步推理请求。
• 辐射节点是独立的 Agent 实例，通过基于装饰器的注册表进行延迟加载。每个智能体都拥有自己的模型、领域工具和本地化系统提示。

运行时，中心通过已注册的 call_agent 工具按名称调用专业智能体。每个专业智能体运行各自的工具调用循环，并将综合后的文本返回给中心，由中心组装最终响应。

混合路由

Orion AI 采用关键词优先路由，并以语义搜索作为回退。约 80% 的查询通过内存中的关键词快速路径在不到一毫秒内完成解析。当关键词不足以确定意图时，系统会回退至由 Amazon Titan Text Embeddings V2 驱动的语义搜索，按语义进行路由。有关模型在不同 AWS 区域的可用性，请参阅 Amazon Bedrock 中按 AWS 区域列出的受支持模型。

当不适合直接调用工具时，系统会激活回退链：Amazon Bedrock Knowledge Bases——一项完全托管的检索增强生成（RAG）能力——会检索运维文档，从而确保响应以获批流程为依据，而不是在缺少上下文的情况下生成。

领域专属智能体及其边界

Orion AI 使用 13 个领域专属智能体。三个 SQL Server 智能体说明了按领域拆分如何映射到实际调查的各个阶段：

• 数据库诊断智能体会呈现阻塞链、等待类型和长时间运行的查询，随后将技术发现转换为业务影响，并给出修复建议。它回答的是：“发生了什么，以及这意味着什么。”
• 会话阻塞分析智能体使用推理模型执行多步骤调查，将阻塞链映射至根阻塞源。它回答的是：“为什么会发生，以及根本原因是什么。”该智能体提供按优先级排列的建议，从立即终止会话到长期架构修复。
• 实时 SQL 诊断智能体通过 Cornerstone 的 DATAOPS API 直接查询 SQL Server 实例，获取实时阻塞数据和高 CPU 会话分析。它回答的是：“此刻真实情况是什么。”

其余智能体同样遵循狭窄职责范围的原则，负责基础设施监控、运维分析、数据库生命周期管理、客户分析、从运行手册中检索知识、通知路由、复合查询拆解、Availability Group 监听器解析以及模型连接预热。

Orion AI 通过两种模式访问数据源：

• 对多个智能体共享的工具（例如实时 SQL 诊断）采用 Model Context Protocol（MCP）。Strands @tool 函数通过可流式传输的 HTTP，调用连接到 Portal-Tools MCP 服务器的 MCPClient，该服务器再访问 SQL Server 和 DATAOPS API。Jira 集成也通过外部 Atlassian MCP 工具采用相同方式实现。
• 对不需要共享 MCP 接口的数据源，采用直接 SDK 或 REST API 调用。这包括指标与仪表板、值班计划，以及通过 AWS SDK for Python (Boto3) 访问 Amazon Bedrock Knowledge Bases。

这种划分意味着，每个智能体都会使用最轻量、最适合其数据源的机制，而 MCP 服务器则集中管理多个智能体共享的工具。这些连接均通过 TLS 运行，且 MCP token 和 REST API 授权等凭证均按请求提供，而非嵌入智能体代码中。

对话记忆

Amazon Bedrock AgentCore 是一个可使用任意框架或模型大规模构建、连接和优化智能体的平台，它提供跨会话记忆层。Orion AI 通过一个中央记忆管理器协调上下文，该管理器并行读取三个层级，每个层级都具有独立的超时设置和 token 分配。

Orion AI 跨三个层级协调上下文。短期记忆将同一会话中的上下文保存在 Amazon DynamoDB 中，该服务默认提供静态加密，并配合由 Amazon Nova 2 Lite 异步生成的滚动式对话摘要。长期记忆通过 Amazon Bedrock AgentCore 的 AgentCore memory 能力提供跨会话回忆，并以用户 ID 作为命名空间。任务完成时，Orion AI 调用 create_event，触发自动提取、摘要和整合。第三个层级是智能体间记忆，即临时的内存中暂存区，用于在单个任务内的子智能体步骤之间传递发现结果。

记忆管理器在 4,000 token 预算内跨各层级进行检索，并设置 500 毫秒的硬超时，同时由最近最少使用缓存提供支持。当请求涉及当前系统状态时，智能体会完全绕过记忆，直接读取实时数据，从而避免过期上下文污染实时诊断。

负责任 AI 与护栏

由于 DataOps 安全性依赖于领域专属规则，例如哪些数据库操作具有破坏性，因此团队构建了自定义护栏逻辑，而不是依赖通用内容过滤器。Orion AI 在四个层面应用控制措施：

• 提示级安全约束被注入每个智能体的系统提示中，以阻止危险建议（例如，

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.

The operational challenge

Before Orion AI, Cornerstone’s Enterprise DataOps team operated reactively, with four recurring pain points:

• Database performance investigations took approximately 45 minutes per incident, spread across multiple tools and system views.
• Database lifecycle workflows required 10 or more manual steps, from establishing connections to communicating status updates.
• Reporting between the site reliability engineering (SRE) team and the data team ran on a 15-minute lag.
• Redundant and overlapping alerts created noise that buried the signals that mattered.

Together, these meant engineers spent their time on manual coordination instead of resolving issues.

The solution: Orion AI

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.

Results

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.

Metric	Before	After	Improvement
Database diagnosis time	45 minutes	10 minutes	78% faster
Manual lifecycle steps	10+ steps	1 interaction	70% reduction
SRE-to-data-team reporting lag	15 minutes	Instantaneous	Real-time
Redundant alerts	High baseline volume	Filtered	65% reduction (median)

Faster performance troubleshooting

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.

Automated database lifecycle management

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.

Real-time monitoring and reduced alert fatigue

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.

Key design principles

Three decisions shaped Orion AI, and you can apply them to your own multi-agent projects:

1. Split agents by domain, not by task complexity : Each agent carries a narrow set of tool integrations for one operational domain. This keeps a model’s context focused and improves the accuracy of tool selection, rather than asking one general-purpose agent to do everything.
2. Default to keyword routing, fall back to semantic search : Predictable requests are matched by keyword for speed. Ambiguous requests fall back to semantic search for accuracy. This keeps latency low without sacrificing correctness on the harder queries.
3. Scope conversational memory to sessions and bypass it for live metrics : Persistent memory supports multi-turn conversations, but operational questions always read current system state. Bypassing memory for live metrics helps prevent stale data from contaminating real-time diagnostics.

Architecture overview

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

Architecture deep dive

The preceding design principles show up concretely in the architecture. The rest of this section walks through Orion AI’s core components.

Building the hub-and-spoke pattern with Strands Agents

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.

The topology:

• The hub is a single Strands Agent acting as the meta-orchestrator (the TaskExecutor). It holds no domain tools — only routing tools (find_relevant_agents, call_agent) and control-flow tools (emit_plan_step, emit_confirmation_gate) so it can reason through a request step by step.
• The spokes are independent Agent instances, loaded lazily through a decorator-based registry. Each carries its own model, domain tools, and localized system prompt.

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.

Hybrid routing

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.

Domain-specific agents and their boundaries

Orion AI uses 13 domain-specific agents. The three SQL Server agents illustrate how domain splitting maps to the stages of a real investigation:

• Database diagnostics agent surfaces blocking chains, wait types, and long-running queries, then translates technical findings into business impact with remediation recommendations. It answers, “what is happening and what does it mean.”
• Session blocking analysis agent runs multi-step investigations with reasoning models to map blocking chains to a root blocker. It answers, “why is this happening and what is the root cause,” delivering prioritized recommendations from immediate session termination to longer-term architectural fixes.
• Real-time SQL diagnostics agent queries SQL Server instances directly through Cornerstone’s DATAOPS API for live blocking data and high-CPU session analysis. It answers, “what is true right now.”

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:

• Model Context Protocol (MCP) for tools that several agents share (for example, real-time SQL diagnostics). A Strands @tool function calls an MCPClient over streamable HTTP to a Portal-Tools MCP server, which reaches SQL Server and the DATAOPS API. Jira integration follows the same approach through external Atlassian MCP tools.
• Direct SDK or REST API calls for sources that don’t need the shared MCP interface. This includes metrics and dashboards, on-call schedules, and Amazon Bedrock Knowledge Bases through AWS SDK for Python (Boto3).

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.

Conversational memory

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. When a request concerns current system state, agents bypass memory entirely and read live data, so stale context does not contaminate real-time diagnostics.

Responsible AI and guardrails

Because DataOps safety depends on domain-specific rules, such as which database operations are disruptive, the team built custom guardrail logic rather than relying on generic content filters. Orion AI applies controls across four layers:

• Prompt-level safety constraints injected into every agent’s system prompt, blocking dangerous recommendations (for example, terminating critical database processes) and enforcing non-disruptive methods.
• A human-in-the-loop confirmation gate that pauses destructive operations until the user confirms within a five-minute window, defaulting to deny on timeout.
• Custom guardrail modules for input validation (length limits, prompt- and SQL-injection blocking), output sanitization (redacting secrets and personally identifiable information), rate limiting, role-based access control, and per-request cost tracking.
• Routing-level protection that blocks answering operational queries from memory, forcing live tool execution for current-state questions.

Observability

Orion AI uses standard AWS observability services for monitoring and debugging. Amazon CloudWatch provides metrics and structured logging for routing confidence, latency, and agent invocation activity. AWS X-Ray traces distributed calls across agent executions for end-to-end request path visibility.

Lessons learned

The design decisions that made Orion AI possible are ones you can reuse. Splitting agents by domain let each agent carry narrow tool integrations without bloating a single model’s context. Using keyword routing by default with semantic search as a fallback kept latency low without sacrificing accuracy on ambiguous requests. Scoping conversational memory to sessions while bypassing it for live metrics kept real-time diagnostics trustworthy.

The team also made pragmatic infrastructure choices. They deployed compute on Amazon ECS because Amazon Bedrock AgentCore runtime, a capability of Amazon Bedrock AgentCore, wasn’t available at the start of the project, and they’re now evaluating it as a future migration option. If you’re building today, weigh the same tradeoff for your own stack: start with what’s stable and available now, and revisit as managed capabilities mature.

Conclusion

Orion AI reduced database diagnosis from 45 minutes to 10, avoided 70 percent of manual lifecycle steps, and cut alert noise by 65 percent. A three-person team delivered it in six months on Amazon Bedrock. The patterns behind those results are ones other operations teams can adopt: domain-scoped agents, hybrid routing, and session-scoped memory with a live-metrics bypass.

To get started with multi-agent orchestration on AWS, review the AWS Solutions Library guidance.

---

About the authors

Harpreet Chawla

Harpreet, Cornerstone OnDemand, Inc., is a Strategic Data & AI Infrastructure Executive with over 20 years of experience driving large-scale digital transformation and operational excellence for global enterprises. He specializes in scaling mission-critical data platforms on AWS while pioneering the shift toward Agentic AI and Autonomous Platform Engineering.

Derek Ziehl

Derek is a Senior Technical Account Manager (TAM) at AWS. He has a background designing large-scale network systems and managing cloud migrations. As a TAM he enjoys enabling customers to run resilient, optimized workloads on AWS.

Madhu Pai

Madhu is a Principal Specialist Solutions Architect for Generative AI and Machine Learning at AWS, where he helps ISVs and enterprises move AI from experimentation to production at scale. He partners with organizations across the industry to navigate the real barriers to AI adoption: governance, compliance, data readiness, and trust. Drawing on deep field experience, Madhu brings a pragmatic, vendor-neutral perspective to how teams can responsibly scale AI.

Nishchai JM

Nishchai is a Senior Solutions Architect at Amazon Web Services, specializing in Data, Analytics, and Generative AI for Independent Software Vendors (ISVs). He helps customers modernize their data platforms, build large-scale distributed applications, and unlock value from AI/ML workloads on the cloud.