你是一名合同管理负责人，负责数百份、甚至数千份供应商合同。每份合同都包含关键数据：合同金额、到期日期、签署状态和关键联系人。这些信息被锁在 PDF 中，你和团队需要花费数小时手动提取数据、维护电子表格，并反复回答相同的问题：“我们在哪家供应商身上的支出最多？”或者“哪些合同即将到期？”

于是，你转向 AI 聊天工具和企业问答解决方案。你上传一份合同，用自然语言提问；对于单份文档，甚至少量文档，这类工具确实表现良好。真正的挑战出现在规模扩大后，即面对数百份合同之时。

大多数这类工具依赖一种称为检索增强生成（Retrieval Augmented Generation，RAG）的技术。RAG 会将长文本拆分为多个片段，并分别为每个片段建立索引。在搜索过程中，RAG 只检索与问题最相关的前 k 个文本片段，这种方法更广为人知的名称是语义搜索。当答案只存在于某一个位置时，这种方式没有问题。但如果问题跨越全部合同，例如总风险敞口或即将续约的合同，语义搜索就难以胜任。答案需要在完整数据集上进行聚合，而不是只查看少量片段。更好的提示词无法解决这个问题，需要的是不同的架构。

本文分享 AWS 上一个合同智能平台背后的架构。它利用 AI Agent 提取合同数据，通过多模型方法验证准确性，并通过嵌入式分析和自然语言查询即时提供答案。所有功能均在一个 Web 应用程序中运行。

挑战：AI 聊天工具何时达到极限

假设你的合同组合包含 250 份供应商合同，而管理层不断提出相同的四个问题：

• 合同组合的合同总金额。
• 哪些合同已经到期。
• 合同组合中金额最高的协议。
• 最近签署的一笔交易。

这些都是基础问题，但答案深埋在文档中。你的 250 份合同每份有 10–20 页，也就是说，最多可达 5,000 页非结构化数据。为了回答这些问题，分析人员要打开每个 PDF，搜索相关字段，将数值复制到电子表格中，然后重复 250 次。仅清理积压工作就要花费一周以上，而这还发生在任何一份新合同到来之前。管理层的每一个后续问题，都意味着又一轮筛选和分析。每一轮都面临使用过时数据，或因新数据破坏硬编码公式的风险。

于是，你把整个合同组合上传到某个领先的 AI 聊天工具，并询问总金额。答案很快返回，充满信心，却是错误的。

RAG 的适用场景，以及何时需要聚合

这个错误答案并非偶然，而是由这些工具的构建方式决定的。在内部，它们会将每份文档切分为向量，并存储在知识库中。当你提出问题时，它们会返回最匹配的前 k 个片段，然后仅利用这些片段作为上下文构建答案。

对于目标明确的查询，这正是你想要的效果。比如问：“AnyCompany 合同中的付款条款是什么？”正确的片段会出现，并给出清晰答案。但合同组合问题与该机制并不匹配。当你问：“全部 250 份合同的合同总金额是多少？”系统仍然只返回前 k 个片段，并仅对这些片段求和。它无法跨整个合同组合进行求和、计数或比较，因为整个组合从未被提供给模型。这不是某一个工具的缺陷，而是 RAG 工作机制本身的限制。

关键洞察

答案是结构化提取，而不是更好的检索。要回答跨越数百份文档的聚合问题，应将关键字段提取到数据库中，再使用专门为此设计的分析工具查询它们。AI 负责大规模完成从非结构化到结构化的转换，数据库负责数学计算。原始文档仍保留在知识库中，用于处理其擅长的单合同问题。最终得到的系统能够回答两类问题：覆盖整个组合的聚合问题，以及精确的单文档查询。

解决方案概述

该平台是部署在 AWS 上的 React Web 应用程序，可将合同 PDF 组合转化为结构化、可查询的数据。AI Agent 会从每份合同中提取关键字段并独立进行验证；对于签名方面的任何分歧，则由 Amazon Textract 作出裁决。随后，用户可通过嵌入式仪表板和自然语言聊天 Agent 浏览结果，同时获得覆盖整个合同组合的答案和单份合同细节。

该流水线的工作流程如下：

1. 你将合同 PDF 存储在 Amazon Simple Storage Service（Amazon S3）存储桶中，这会触发自动化处理流水线。
2. AI 提取 Agent（由 Claude Sonnet 系列模型驱动）读取 PDF，并提取八个关键字段，每个字段均带有置信度分数。
3. 独立的 AI 验证 Agent（由更轻量的 Claude Haiku 模型驱动）会独立读取同一份 PDF 并验证提取结果。
4. 如果两个 Agent 在签名检测上存在分歧，Amazon Textract 会使用计算机视觉提供确定性的裁决结果。
5. 系统将经过验证的结果存储在 Amazon Aurora PostgreSQL 中。
6. 用户可通过 WebSocket 查看实时流水线状态，并立即通过嵌入式仪表板和自然语言聊天 Agent 查询数据。

在典型条件下，整条流水线可在数秒内处理一份合同；无服务器架构旨在帮助系统扩展，以并行处理大量合同。以下是该解决方案的参考架构。

图 1：从摄取到查询的合同智能流水线

注意：本文引用的是构建该解决方案时可用的语言模型。模型选项变化很快，请使用你当前可用的模型，并在依赖结果前重新测试该解决方案。

AI 提取流水线内部机制

该流水线将每份上传的合同转化为经过验证的结构化数据。它以两个 Agent 为起点：一个负责提取字段，另一个负责独立检查字段；两者均运行在完全托管的基础设施上。以下章节将介绍它们如何协同工作，以及背后所用的模型。

基于 Amazon Bedrock AgentCore 中 Strands Agents 的双模型验证

提取 Agent 和验证 Agent 使用 Strands Agent SDK 构建，并部署在 AgentCore runtime 上；后者是 Amazon Bedrock AgentCore 的一项能力。Strands Agent SDK 是一个开源、模型驱动的框架，用于构建自主 Agent。AgentCore 负责无服务器托管、自动扩缩容和会话隔离，因此无需为 AI 组件管理基础设施。

借助 Amazon Bedrock AgentCore 中的 Policy，你可以定义并执行安全控制，在 Agent 操作周围建立保护边界。这能够安全处理定价条款、财务承诺和供应商关系等敏感数据。基于 Cedar 的策略独立于 Agent 代码存在，并可在执行前通过自动化推理进行验证。Agent 和用户只能访问其被授权查看的合同。

我们有意为提取和验证选择了两个不同的基础模型：

• **用于提取的 Claude Sonnet 4.6：**具备先进的文档理解能力，可原生读取完整 PDF（无需光学字符识别（OCR）预处理），并针对每个字段返回带置信度分数的结构化 JSON。
• **用于验证的 Claude Haiku 4.5：**快速、成本效益高，并提供独立视角。由于它是训练方式不同的另一模型，因此可以捕捉到重复运行同一模型可能遗漏的错误。

有关按区域划分的模型可用性，请参阅 Amazon Bedrock 中的 Supported models by AWS Region。

这种双模型模式是实现高准确度合同数据处理的关键，因为合同数据中的错误代价高昂。单一模型可能以很高的置信度幻觉出某个数值。两个独立模型产生分歧，则是需要人工审查的强烈信号。

在测试中，我们发现了一种具有启发性的失败模式。验证模型有时会以 95–100% 的置信度将合同标记为“已签署”，尽管合同实际上没有签名；这与提取模型的判断不一致，后者正确地将其识别为未签署。模型误读了空白签名区块，将签名字段的存在（“Signature: __________”）当作存在签名的证据。

我们没有接受这种幻觉，也没有编写复杂的提示词来规避它，而是将基于 Amazon Textract 计算机视觉的签名检测作为架构层面的裁决机制。Amazon Textract 使用视觉分析而非语言理解来检测页面上实际存在的手写或数字签名。它仅在两个模型对 is_signed 字段存在分歧时运行，因此在捕捉误报的同时将成本保持在最低水平。

这体现了一个重要模式：将大语言模型（LLM）用于其擅长的任务（文档理解、字段提取、上下文理解），并将其不擅长的任务（视觉元素检测、精确计数、数学运算）交给确定性服务。

数据驱动的模型选择

流水线的准确性最依赖于负责提取的模型，因此我们在确定最终方案前测试了多种提取器和验证器组合。我们使用包含 20 份合同的样本数据集，对全部 8 个字段进行人工标注（共 160 个值）以建立真实标签，然后衡量每种组合与真实标签的匹配程度。

评估发现了两种规律。提取是影响更大的步骤。即使搭配较轻量的验证器，能力更强的提取模型仍能维持较高准确度；而无论验证器如何，更轻量的提取模型都会降低准确度。更高能力并不总是值得额外成本。最强的模型在我们的数据上并未显著优于能力足够、成本更低的验证器。

Amazon Bedrock 提供了广泛的模型选择，合适的组合取决于你的数据。这只是针对 20 份合同进行的小规模、方向性测试，并非穷尽性评估；结果会随合同格式和字段复杂度而变化。我们强烈建议你使用构建时可用的模型，依据自己的基准和成功标准运行评估。

使用 Amazon Quick 进行大规模查询

提取和验证数据只解决了一半问题。人们仍然需要向这些数据提问，问题范围可以从宽泛的合同组合总额到单份合同的详细内容。Amazon Quick 将结构化记录和背后的原始文档连接到同一个界面中，因此任何人都可以提出任意一类问题。在 Amazon Quick 内部，Amazon Quick Sight 功能为仪表板提供支持，而自然语言查询和聊天功能则处理自然语言问题。

连接结构化数据与非结构化数据

合同数据现已提取至 PostgreSQL 数据库，我们将其连接到 Amazon Quick，使用户可以通过可视化仪表板和自然语言查询来浏览。最终形成一个能够回答两类问题的统一界面：

• 聚合查询（通过结构化数据和 Topics）： “我们的合同总金额是多少？” → “20 份合同共计 5,000 万美元。”
• 文档特定查询（通过知识库）： “AnyCompany 合同中的付款条款是什么？” → 从源 PDF 中提取的精确条款。

嵌入式仪表板

Amazon Quick Sight 仪表板通过 Amazon Quick Sight Embedding SDK 直接嵌入 React 应用程序。用户无需离开应用程序，即可获取所需的合同分析，无需导出数据，也无需使用独立的商业智能（BI）工具。我们没有将数据缓存在 SPICE（Super-fast, Parallel, In-memory Calculation Engine）中以避免额外成本，而是直接查询数据，因此仪表板始终是实时的。合同一完成处理，便会立即显示。

仪表板包含多个视图：

• **概览：**关键绩效指标（KPI），例如合同总数和总金额；已签署与未签署合同的饼图；以及带筛选器的完整提取结果表。
• **详情：**提取 Agent 和验证 Agent 的置信度分数，以及逐字段的匹配状态。
• **成本：**突出展示无服务器架构的按服务划分成本明细。

聊天 Agent：自然语言与分析能力结合

借助 Amazon Quick 中嵌入式聊天 Agent，你可以使用自然语言询问有关合同组合的问题。由于它同时连接到 Topic（用于结构化数据库查询）和知识库（用于文档级搜索），因此你可以提出完整范围的问题：

• “我有多少份合同，总金额是多少？” → 20 份合同，5,000 万美元。
• “有多少份合同已到期，它们的总金额是多少？” → 3 份已到期，370 万美元。
• “已签署和未签署的合同各有多少？” → 17 份已签署，3 份未签署。
• “我应优先处理的前 3 份合同是什么？” → 按金额排序、接近到期的未签署合同。

在同一个聊天界面中完成结构化分析和文档问答：这就是价值所在，聚合问题和文档查找问题均可通过一个界面回答。

实时流水线透明度

一项改善用户体验的设计决策，是加入基于 WebSocket 的实时状态更新。当合同进入流水线时，React 前端会显示

You’re a director of contracting, responsible for hundreds, maybe thousands, of vendor contracts. Each one is packed with critical data: contract values, expiration dates, signing status, and key contacts. With that information locked inside PDFs, you and your team spend hours manually extracting it, maintaining spreadsheets, and fielding the same recurring questions: “Which vendor are we spending the most with?” or “Which contracts are about to expire?”

So you turn to AI chat tools and enterprise Q&A solutions. You upload a contract, ask questions in natural language, and for a single document, or even a handful, it genuinely works well. The real challenge shows up at scale, across hundreds of contracts.

Most of these tools rely on a technique called Retrieval Augmented Generation (RAG). RAG breaks long text into chunks and indexes each one individually. During a search, RAG retrieves only the top-k chunks of text most relevant to a question, an approach more widely known as semantic search. That’s fine when the answer lives in one place. But when a question spans every contract, like total exposure or upcoming renewals, semantic search falls short. The answer requires aggregation across the full dataset, not only a handful of chunks. A better prompt won’t fix this. A different architecture will.

In this post, we share the architecture behind a contract intelligence platform on AWS. It extracts contract data with AI agents, verifies accuracy with a multi-model approach, and delivers instant answers through embedded analytics and natural language querying. Everything runs from a single web application.

The challenge: When AI chat tools hit their limit

Say your portfolio holds 250 vendor contracts, and leadership keeps asking the same four questions:

• Total contract value across the portfolio.
• Which contracts have already expired.
• The most expensive agreement in the portfolio.
• The most recently signed deal.

These are basic questions, but the answers are buried. Each of your 250 contracts runs 10–20 pages, so that’s up to 5,000 pages of unstructured data. To answer those questions, an analyst opens each PDF, searches for the fields that matter, and copies the values into a spreadsheet, then repeats the process 250 times. That’s more than a week of effort to clear the backlog, before a single new contract arrives. Every follow-up question from leadership means another round of filtering and analysis. Each round risks working from stale data or breaking hardcoded formulas on the new data.

So you upload the portfolio to one of the leading AI chat tools and ask for the total value. The answer comes back fast, confident, and wrong.

Where RAG fits, and where aggregation is needed

That wrong answer wasn’t a fluke. It’s baked into how these tools are built. Internally they chunk each document into vectors and store them in a knowledge base. When you ask a question, they pull back the top-k chunks that best match it, then build an answer using only those chunks as context.

For a targeted lookup, that’s exactly what you want. Ask “What are the payment terms in the AnyCompany contract?” and the right chunk surfaces with a clean answer. A portfolio question works against that mechanism instead of with it. When you ask, “What’s the total contract value across all 250 contracts?”, the system still returns only the top-k chunks and totals only those. It can’t sum, count, or compare across the portfolio because the portfolio never lands in front of the model. It isn’t a flaw in any one tool but in how RAG itself works.

The key insight

The answer is structured extraction, not better retrieval. To answer aggregation questions across hundreds of documents, you extract the key fields into a database, then query them with analytics tools built for exactly that. AI handles the unstructured-to-structured conversion at scale, and the database is used for math. You keep the original documents in a knowledge base for the single-contract questions it handles well. The result is a system that answers both kinds of questions: portfolio-wide aggregates and precise single-document lookups.

Solution overview

The platform is a React web application on AWS that turns a portfolio of contract PDFs into structured, queryable data. AI agents extract the key fields from each contract and independently verify them, with Amazon Textract settling any signature disagreements. Users then explore the results through embedded dashboards and a natural language chat agent, getting both portfolio-wide answers and single-contract details.

The pipeline works as follows:

1. You store contract PDFs in an Amazon Simple Storage Service (Amazon S3) bucket, which triggers an automated processing pipeline.
2. An AI extraction agent (powered by Claude Sonnet series of models) reads the PDF and extracts eight key fields, each with a confidence score.
3. A separate AI verification agent (powered by lighter Claude Haiku model) independently reads the same PDF and verifies the extraction.
4. If the two agents disagree on signature detection, Amazon Textract provides a deterministic tiebreaker using computer vision.
5. The system stores verified results in Amazon Aurora PostgreSQL.
6. Users see real-time pipeline status over WebSocket and can immediately query data through embedded dashboards and a natural language chat agent.

The entire pipeline can process a contract in seconds under typical conditions, and the serverless architecture is designed to help scale to handle many contracts in parallel. Here is the reference architecture for this solution.

Figure 1: Contract intelligence pipeline, from ingestion to query

Note: This post references the language models available when the solution was built. Model options change quickly, use the models available to you and re-test the solution before relying on the results.

Inside the AI extraction pipeline

The pipeline turns each uploaded contract into verified, structured data. It starts with two agents, one that extracts the fields and one that independently checks them, both running on fully managed infrastructure. The following section covers how they work together and the models behind them.

Dual-model verification with Strands Agents on Amazon Bedrock AgentCore

The extraction and verification agents are built with the Strands Agent SDK and deployed on AgentCore runtime, a capability of Amazon Bedrock AgentCore. The Strands Agent SDK is an open-source, model-driven framework for building autonomous agents. AgentCore handles serverless hosting, automatic scaling, and session isolation, so there’s no infrastructure to manage for the AI components.

With Policy in Amazon Bedrock AgentCore, you can define and enforce security controls as a protective boundary around agent operations. This securely handles sensitive data such as pricing terms, financial commitments, and vendor relationships. Cedar-based policies exist outside agent code, and you can validate them with automated reasoning before enforcement. Agents and users only access the contracts they are authorized to see.

We deliberately chose two different foundation models for extraction and verification:

• Claude Sonnet 4.6 for extraction: Advanced document understanding capabilities, reads the full PDF natively (no optical character recognition (OCR) preprocessing needed), and returns structured JSON with confidence scores for each field.
• Claude Haiku 4.5 for verification: Fast, cost-effective, and provides an independent perspective. Because it’s a different model with different training, it catches errors that re-running the same model would miss.

For model availability by Region, refer to Supported models by AWS Region in Amazon Bedrock.

This dual-model pattern is key to high accuracy on contract data, where mistakes are costly. A single model might hallucinate a value with high confidence. Two independent models disagreeing is a strong signal that human review is needed.

During testing, we found a revealing failure mode. The verification model would sometimes flag a contract as “signed” with 95–100% confidence when no signature existed, disagreeing with the extractor, which had correctly read it as unsigned. The model misread empty signature blocks, treating the presence of a signature field (“Signature: __________”) as proof of a signature.

Rather than accepting this hallucination or writing elaborate prompts to work around it, we added Amazon Textract computer-vision-based signature detection as an architectural tiebreaker. Amazon Textract uses visual analysis, not language understanding, to detect actual handwritten or digital signatures on the page. It runs only when the two models disagree on the is_signed field, which keeps costs minimal while catching the false positives.

This illustrates an important pattern: use large language models (LLMs) for what they excel at (document comprehension, field extraction, contextual understanding) and deterministic services for what they struggle with (visual element detection, precise counting, mathematical operations).

Data-driven model selection

The pipeline’s accuracy depends most on the model that handles extraction, so we tested several extractor and verifier combinations before settling on one. Using our 20-contract sample dataset, we hand-labeled all 8 fields (160 values total) to establish ground truth, then measured how closely each combination matched it.

The evaluation surfaced two patterns. Extraction is the higher-impact step. A more capable extraction model held accuracy up even when paired with a lighter verifier, while a lighter extraction model brought accuracy down regardless of the verifier. More capability wasn’t always worth the cost. The strongest models didn’t meaningfully outperform a capable, lower-cost verifier on our data.

Amazon Bedrock gives you a broad choice of models, and the right combination depends on your data. This was a small, directional test on 20 contracts, not an exhaustive evaluation, and results will vary with contract format and field complexity. We strongly recommend running your own evaluation against your benchmarks and success criteria, using the models available to you at build time.

Querying at scale with Amazon Quick

Extracting and verifying the data solves only half the problem. People still need to ask questions of it, from broad portfolio totals to the details of a single contract. Amazon Quick connects both the structured records and the original documents behind a single interface, so anyone can ask either kind of question. Within Amazon Quick, the Amazon Quick Sight capability powers the dashboards, while natural language querying and chat handle plain-language questions.

Bridging structured and unstructured

With contract data now extracted into a PostgreSQL database, we connected it to Amazon Quick so users can explore it through visual dashboards and natural language querying. The result is a single interface that answers both types of question:

• Aggregation queries (through structured data and Topics): “What’s our total contract value?” → “$50 million across 20 contracts.”
• Document-specific queries (through the knowledge base): “What are the payment terms in the AnyCompany contract?” → the exact clause, pulled from the source PDF.

Embedded dashboards

The Amazon Quick Sight dashboards are embedded directly in the React application using the Amazon Quick Sight Embedding SDK. Without leaving the application, users get the contract analytics they need without requiring exports or separate business intelligence (BI) tools. Rather than caching in SPICE (Super-fast, Parallel, In-memory Calculation Engine) and incurring extra costs, we query the data directly, so the dashboards are always live. The moment a contract finishes processing, it shows up.

The dashboard includes several views:

• Overview: Key performance indicators (KPIs) such as total contracts and total value, a signed and unsigned pie chart, and a full extraction table with filters.
• Details: Confidence scores from both the extractor and verifier agents, with field-by-field match status.
• Costs: A service-level cost breakdown that highlights the serverless architecture.

The chat agent: Natural language meets analytics

With the embedded chat agent in Amazon Quick, you can ask questions about your contract portfolio in natural language. Because it connects to both a Topic (for structured database queries) and a knowledge base (for document-level search), you can ask the full spectrum of questions:

• “How many contracts do I have and what’s the total value?” → 20 contracts, $50 million.
• “How many contracts are expired, and what’s their total value?” → 3 expired, $3.7 million.
• “How many are signed versus unsigned?” → 17 signed, 3 unsigned.
• “What are my top 3 contracts to prioritize?” → the unsigned contracts nearing expiration, ranked by value.

Structured analytics and document Q&A in a single chat: That’s the payoff, aggregation and document lookups answered from one interface.

Real-time pipeline transparency

One design decision that improved the user experience was adding WebSocket-based real-time status updates. When contracts enter the pipeline, the React frontend displays each processing stage as it happens. This turns an opaque upload-and-wait experience into a transparent process where users see exactly which service is working on their contracts. It builds trust and makes the multi-model flow clear.

Cost analysis

The solution is primarily serverless, with the bulk of ongoing cost in Amazon Quick licensing rather than AI inference:

Service	Monthly Cost (at 1,000 contracts/month)
Amazon Quick (1 Enterprise user + infrastructure fee)*	$290
Amazon Aurora Serverless v2	$44
Amazon Bedrock (Sonnet extraction + Haiku verification)	$12
Amazon Textract (signature tiebreaker)	$2
AWS Lambda, Amazon API Gateway, Amazon S3, Amazon CloudFront	< $1
Total	~$349/month

* Pricing is based on the date the blog was published. Visit theAmazon Quick Pricing page for latest accurate information.

At $0.014 per contract for AI inference (Amazon Bedrock plus Amazon Textract), the variable cost scales linearly and stays negligible next to the fixed analytics licensing. The economic savings compared to manual work are clear.

Key takeaways

1. Extract, then query: For aggregation use cases across many documents, extract key fields into a structured database. RAG excels at finding information in documents. Databases excel at aggregating across them. Use both.
2. Verify with independence: Using two different foundation models for extraction and verification catches errors that a single model would miss. The cost of a second, cheaper model is minimal compared to the accuracy gain on high-stakes data.
3. Use deterministic services for deterministic tasks: When LLMs hallucinate (signature detection, precise counting), bring in purpose-built services like Amazon Textract rather than adding a third LLM. Match the tool to the task.
4. Make the AI visible: Real-time pipeline status builds user trust and makes multi-agent architectures tangible to stakeholders. Transparency turns an opaque AI pipeline into a comprehensible workflow.
5. This pattern scales beyond contracts: Domains with large volumes of unstructured documents requiring portfolio-level queries benefit from this approach: procurement, legal compliance, insurance claims, HR onboarding documents, real estate leases.

Conclusion

We started with a director who couldn’t get a straight answer about his own contracts. By designing for structured extraction first and pairing analytics tools with AI agents, this architecture turns an unmanageable contract portfolio into one that answers questions in seconds. That holds whether the question is a total across hundreds of contracts or the payment terms in one. The pattern is straightforward: use LLMs for text-based analysis and a database for numerical queries. Where two models disagree in ways a deterministic service can’t settle, the next step is to route the contract to a human reviewer instead of auto-resolving. This keeps people in the loop exactly where judgment matters most.

To get started with the services used in this architecture, explore the following resources:

---

About the authors

Konala McGrath

Konala is a Solutions Architect at AWS. He supports digital native businesses across multiple industries and helps them build highly scalable, cost-optimized cloud solutions. In his free time, he enjoys spending time with his family and friends, and watching or playing sports.

Alberto Alonso

Alberto is a Specialist Solutions Architect at Amazon Web Services. He focuses on generative AI and how it can be applied to business challenges.

Hugo Tse

Hugo is a Solutions Architect at AWS supporting digital native businesses. He strives to help customers use cloud technologies to tackle problems and create new business opportunities, especially in the domains of generative AI and storage.

Nitish Chaudhari

Nitish is a Senior Solutions Architect at AWS. He specializes in using Amazon’s Generative AI offerings for building productivity solutions for engineers, knowledge workers and data analytics teams and scaling adoption of those solutions across organizations.