From weeks to minutes: How Formula 1® uses agentic AI on AWS to accelerate data operations从几周缩短至几分钟：一级方程式赛车 (Formula 1®) 如何利用 AWS 上的智能体 AI 加速数据运营

Formula 1^® (F1) engages an audience of over 800 million fans globally across digital platforms, F1 TV, social media, ticketing, and merchandise year-round. Races happen every two weeks. Fan engagement windows are measured in minutes and commercial decisions need to move at the speed of the grid. Behind the scenes, F1’s marketing technology (MarTech) platform, Customer 360, captures interactions across all of these touchpoints to power personalization, segmentation, and commercial strategy.一级方程式赛车 (F1) 全年通过数字平台、F1 TV、社交媒体、票务和商品销售，与全球超过 8 亿车迷互动。比赛每两周举行一次。车迷的互动窗口以分钟计，商业决策必须跟上赛道的节奏。在幕后，F1 的营销技术 (MarTech) 平台“客户 360 (Customer 360)”捕获了所有这些接触点的互动数据，以推动个性化、细分和商业战略的实施。

However, the platform faced a significant operational challenge. According to Chris Roberts, Director of IT at Formula 1, “Our MarTech platform is the nervous system of F1’s fan engagement. But every new data source required 6 to 8 weeks of manual engineering. We had an 18-month backlog just to integrate 12 new sources.” The business was generating data faster than the engineering team could wire it up. As a result, Matt Kemp, F1 Head of Data Operations, set to improve efficiencies and data quality. “Manually ingesting data sources is time consuming, creates solution variances, and ultimately results in data integrity issues. I wanted a solution that was repeatable, robust and reliable. AWS worked backwards from our needs to implement an agentic solution that worked end to end, applying business logic at each step.”然而，该平台面临着重大的运营挑战。一级方程式赛车 IT 总监 Chris Roberts 表示：“我们的 MarTech 平台是 F1 车迷互动的神经系统。但每接入一个新的数据源，都需要 6 到 8 周的手动工程工作。我们仅集成 12 个新数据源就积压了 18 个月的任务。”业务产生数据的速度超过了工程团队的对接速度。因此，F1 数据运营主管 Matt Kemp 着手提高效率和数据质量。“手动摄取数据源既耗时又会导致解决方案差异，最终引发数据完整性问题。我想要一个可重复、稳健且可靠的解决方案。AWS 从我们的需求出发，实施了一个端到端的智能体解决方案，并在每一步应用业务逻辑。”

In early 2026, F1 and AWS worked together to build the Data Accelerator, a solution that uses agentic AI on Amazon Bedrock AgentCore to transform F1’s MarTech data platform from a manually maintained system into a self-managed, observable, and unified data estate. In this post, we show how the Data Accelerator reduced data source onboarding from up to 8 weeks to approximately 40 minutes of code generation plus hours of deployment. It also identified and fixed data source anomalies in production, tracked data platform operations and agent lineage in a single window, and opened a gateway for analysts, engineers, and scientists to collaborate. “For the first time, we have end-to-end visibility across the entire MarTech platform with data lineage and root cause analysis, not just dashboards full of alerts,” says Roberts.2026 年初，F1 与 AWS 合作构建了“数据加速器 (Data Accelerator)”。该解决方案利用 Amazon Bedrock AgentCore 上的智能体 AI，将 F1 的 MarTech 数据平台从手动维护的系统转变为自主管理、可观测且统一的数据资产。在本文中，我们将展示数据加速器如何将数据源接入时间从最长 8 周缩短至约 40 分钟的代码生成加上数小时的部署。它还能识别并修复生产环境中的数据源异常，在单个窗口中跟踪数据平台运营和智能体血缘关系，并为分析师、工程师和科学家提供协作门户。Roberts 说：“我们第一次实现了整个 MarTech 平台的端到端可见性，包括数据血缘和根本原因分析，而不仅仅是充满警报的仪表板。”

The challenge挑战

F1’s Customer 360 platform ingests data from ticketing partners, streaming integrations, sponsor activation feeds, social media, and merchandise systems. Operating a data estate of this breadth and velocity surfaced three areas of friction the team set out to solve. First, onboarding each new data source was a heavily manual effort: engineers wrote schema mappings, built ingestion pipelines, configured data quality checks, defined General Data Protection Regulation (GDPR) classifications, and set governance policies by hand. This process took 6 to 8 weeks per source. Second, the platform had to keep pace with constantly evolving upstream feeds. Providers frequently changed column names, added fields, or restructured and rescheduled payloads without notice. Those changes often surfaced at the worst possible moment, such as mid race-weekend or during a mission-critical campaign launch. Third, visibility was fragmented. Logs were scattered across services with no unified data lineage. When a stakeholder questioned a metric, engineers spent hours manually tracing the issue across Amazon Simple Storage Service (Amazon S3) paths, Amazon Redshift control tables, Airflow logs, and DBT outputs.F1 的 Customer 360 平台从票务合作伙伴、流媒体集成、赞助商激活馈送、社交媒体和商品系统中摄取数据。运营如此广度和速度的数据资产带来了三个团队急需解决的摩擦点。首先，接入每个新数据源是一项繁重的手动工作：工程师需要手动编写模式映射、构建摄取管道、配置数据质量检查、定义通用数据保护条例 (GDPR) 分类并设置治理策略。每个数据源的此过程需要 6 到 8 周。其次，平台必须跟上不断变化的上游馈送。提供商经常在不通知的情况下更改列名、添加字段或重构和重新安排负载。这些变化往往出现在最糟糕的时机，例如比赛周末期间或关键任务活动发布期间。第三，可见性碎片化。日志分散在各个服务中，没有统一的数据血缘。当利益相关者质疑某个指标时，工程师需要花费数小时手动追踪 Amazon Simple Storage Service (Amazon S3) 路径、Amazon Redshift 控制表、Airflow 日志和 DBT 输出中的问题。

Solution overview解决方案概述

The Data Accelerator addressed these challenges through five workstreams delivered simultaneously:数据加速器通过同时交付的五个工作流解决了这些挑战：

• Agentic data source onboarding using Amazon Bedrock AgentCore, hosting agents in its runtime containers.使用 Amazon Bedrock AgentCore 进行智能体数据源接入，并在其运行时容器中托管智能体。
• Automated schema evolution detection and remediation.自动化的模式演变检测与修复。
• Unified data access through Amazon SageMaker Unified Studio.通过 Amazon SageMaker Unified Studio 实现统一数据访问。
• End-to-end observability with root cause analysis tool (RCA) and context graph.具备根本原因分析 (RCA) 工具和上下文图谱的端到端可观测性。
• Automated identification of a failure in observability dashboard and agentic operation if they could be fixed with code changes.在可观测性仪表板中自动识别故障，如果可以通过代码更改修复，则进行智能体操作。

A sixth workstream optimized the customer identity resolution algorithms that unify fan touchpoints across channels. The following sections describe each workstream in detail.第六个工作流优化了跨渠道统一车迷接触点的客户身份解析算法。以下部分详细介绍了每个工作流。

Agentic data source onboarding智能体数据源接入

The centerpiece of the Data Accelerator is a set of platform agents that take a Business Requirements Document (BRD) with limited information about the data source and produce a fully production-ready onboarding pipeline. This includes infrastructure code, data transformations, governance policies, and GDPR classification without a human writing a single line of boilerplate. The agents work in two phases:数据加速器的核心是一组平台智能体，它们接收包含有限数据源信息的业务需求文档 (BRD)，并生成完全可用于生产的接入管道。这包括基础设施代码、数据转换、治理策略和 GDPR 分类，无需人工编写任何样板代码。智能体的工作分为两个阶段：

Phase 1: Configuration generation第一阶段：配置生成

When a new data source needs onboarding, a team member uploads a BRD to an Amazon S3 bucket. The upload triggers an AWS Lambda function, which invokes Amazon Bedrock AgentCore Runtime, a capability of Amazon Bedrock AgentCore. The agent reads the BRD and generates a set of configuration files. It then accesses GitHub through a GitHub App to push these files as a pull request to the standardized Git repository, and accesses Jira through its REST API to create a ticket referencing the PR. All agent conversations and actions are traced in Amazon CloudWatch through built-in AgentCore observability. The assigned engineer reviews, adjusts if necessary, and approves.当需要接入新数据源时，团队成员将 BRD 上传到 Amazon S3 存储桶。上传操作会触发 AWS Lambda 函数，进而调用 Amazon Bedrock AgentCore Runtime（Amazon Bedrock AgentCore 的一项功能）。智能体读取 BRD 并生成一组配置文件。然后，它通过 GitHub App 访问 GitHub，将这些文件作为拉取请求 (PR) 推送到标准化的 Git 仓库，并通过其 REST API 访问 Jira 创建引用该 PR 的工单。所有智能体的对话和操作都通过内置的 AgentCore 可观测性在 Amazon CloudWatch 中进行追踪。指定的工程师进行审查，必要时进行调整并批准。

Phase 1 workflow: a BRD upload triggers the agent to generate config files and open a pull request第一阶段工作流：BRD 上传触发智能体生成配置文件并打开拉取请求

Phase 2: Full pipeline generation第二阶段：完整管道生成

Once the configuration files are approved, a human triggers the next stage. The agent takes the approved configuration and generates three separate Pull Requests:配置文件获得批准后，由人工触发下一阶段。智能体获取批准后的配置并生成三个独立的拉取请求：

1. AWS Glue application and infrastructure code.AWS Glue 应用程序和基础设施代码。
2. DBT transformation framework.DBT 转换框架。
3. Governance policies including GDPR tagging.包括 GDPR 标记在内的治理策略。

All three PRs link to a single Jira ticket for traceability. Engineers review each one across the Infrastructure, DBT, and Governance repositories and approve.所有三个 PR 都链接到同一个 Jira 工单以实现可追溯性。工程师分别在基础设施、DBT 和治理仓库中审查每一个 PR 并进行批准。

Phase 2 workflow: the agent generates infrastructure, transformation, and governance pull requests第二阶段工作流：智能体生成基础设施、转换和治理拉取请求

Automated GDPR classification自动化 GDPR 分类

What distinguishes this from a basic code generator is the integrated GDPR classification. The agent proactively analyzes every data column, determines whether it contains personal data, sensitive personal data, or pseudonymized data, and tags it with the appropriate GDPR category. These tags publish directly to the governance registry in SageMaker Unified Studio, giving the compliance team immediate visibility without manual review cycles.与基本代码生成器不同的是，该系统集成了 GDPR 分类功能。智能体主动分析每一列数据，确定其是否包含个人数据、敏感个人数据或假名化数据，并为其打上相应的 GDPR 类别标签。这些标签直接发布到 SageMaker Unified Studio 中的治理注册表，使合规团队无需手动审查周期即可获得即时可见性。

Modular skill architecture模块化技能架构

The system is not a tightly coupled agent graph. A single agent operates with modular skill definitions, each encapsulating a distinct capability: schema mapping and data type inference, data quality validation, governance enforcement, and sensitive data classification. At runtime, the agent evaluates incoming requirements and activates the relevant skills, composing them through a multi-pass reasoning process. Pass-0 handles token management through scrubbing, Pass-1 summarizes tool outputs, and Pass-2 rolls up an overall assessment, refining accuracy and completeness progressively rather than relying on a one-shot response. New capabilities ship as new skill modules without changing the core agent loop, keeping the architecture maintainable and composable as the platform grows.该系统并非紧密耦合的智能体图。单个智能体通过模块化技能定义进行操作，每项技能都封装了不同的能力：模式映射和数据类型推断、数据质量验证、治理执行以及敏感数据分类。在运行时，智能体会评估传入的需求并激活相关技能，通过多轮推理过程将它们组合起来。Pass-0 通过清理处理令牌管理，Pass-1 总结工具输出，Pass-2 汇总整体评估，逐步提高准确性和完整性，而不是依赖一次性响应。新能力作为新的技能模块发布，无需更改核心智能体循环，从而在平台扩展时保持架构的可维护性和可组合性。

The result is onboarding time dropped from 6 to 8 weeks to approximately 40 minutes of code generation plus hours of deployment and review. AI agents now handle 95% of the work autonomously.结果是接入时间从 6 到 8 周缩短至约 40 分钟的代码生成加上数小时的部署和审查。AI 智能体现在可以自主处理 95% 的工作。

Automated schema evolution自动化模式演变

Onboarding new data sources is one challenge, but keeping existing integrations healthy is another. Upstream providers frequently modify their data structures, from renaming a column to creating a new field. Previously, the F1 team discovered these changes when a pipeline failed, often during a live race weekend. The same agent architecture that handles onboarding now continuously monitors for upstream schema changes. When a provider modifies their data structure, the agent detects it through event-driven triggers using AWS Lambda and Amazon EventBridge. It assesses the downstream impact, identifying which pipelines are affected, and which consumers depend on the changed fields. It then generates the necessary code updates across all affected repositories and creates a Jira ticket with full context and linked PRs. Engineers receive a notification that explains what changed, describes the impact, and presents a proposed fix for review. End-to-end resolution now takes hours instead of days.接入新数据源是一项挑战，但保持现有集成的健康是另一项挑战。上游提供商经常修改其数据结构，从重命名列到创建新字段。以前，F1 团队是在管道失败时才发现这些变化，通常是在比赛周末期间。处理接入的相同智能体架构现在会持续监控上游模式变化。当提供商修改其数据结构时，智能体通过使用 AWS Lambda 和 Amazon EventBridge 的事件驱动触发器检测到该变化。它评估下游影响，确定哪些管道受到影响，以及哪些消费者依赖于已更改的字段。然后，它会在所有受影响的仓库中生成必要的代码更新，并创建一个包含完整上下文和关联 PR 的 Jira 工单。工程师会收到通知，解释发生了什么变化、描述影响，并提供建议的修复方案以供审查。端到端的解决现在只需数小时，而不是数天。

Schema evolution agentic workflow模式演变智能体工作流

Unified data access with Amazon SageMaker Unified Studio通过 Amazon SageMaker Unified Studio 实现统一数据访问

Before the Data Accelerator, working with Customer 360 data required navigating multiple disconnected environments. Data engineers curated pipelines in one account. Data scientists who wanted to model fan behavior needed access to a separate account, and analysts operated in a third world entirely. Nobody shared tooling or context, and getting from a question to an answer took days of coordination before any analysis could begin.在数据加速器之前，使用 Customer 360 数据需要浏览多个断开连接的环境。数据工程师在一个账户中策划管道。想要模拟车迷行为的数据科学家需要访问单独的账户，而分析师则在完全不同的第三个世界中工作。没有人共享工具或上下文，从提出问题到得到答案需要数天的协调，分析才能开始。

The solution uses Amazon SageMaker Unified Studio as the foundation for a data mesh framework where a central governance account brokers data discovery and access across multiple producer teams. The key enabler: governance is codified as declarative configuration, not manual console operations. A single data source definition simultaneously publishes data to the catalog and provisions the access control needed for consumers to subscribe. This means agents can safely onboard new data products end-to-end, from storage to catalog to governed access, because the framework enforces security constraints by construction. No human needs to review IAM policies or AWS Lake Formation grants. The platform guarantees correctness structurally. This is what makes the “one front door” possible.该解决方案使用 Amazon SageMaker Unified Studio 作为数据网格框架的基础，其中中央治理账户负责代理跨多个生产者团队的数据发现和访问。关键推动因素是：治理被编码为声明式配置，而非手动控制台操作。单个数据源定义同时将数据发布到目录并提供消费者订阅所需的访问控制。这意味着智能体可以安全地端到端接入新数据产品，从存储到目录再到受控访问，因为框架通过构建强制执行安全约束。无需人工审查 IAM 策略或 AWS Lake Formation 授权。平台在结构上保证了正确性。这就是实现“统一入口”的原因。

Data engineers curate and govern datasets in one place, and data scientists find those same datasets in the same environment: governed, documented, and ready to model. A data scientist building a fan segmentation model or optimizing the customer identity algorithm doesn’t need to know where the data lives, who owns the pipeline, or which S3 prefix to use. They open Unified Studio, find the curated Customer 360 datasets, and start modeling. They get shared notebooks, consistent tooling, and governed access, because declarative governance made safe self-service possible without sacrificing control. The curation and the consumption finally live side by side.数据工程师在一个地方策划和治理数据集，数据科学家在同一个环境中找到相同的数据集：受治理、有文档记录且可用于建模。构建车迷细分模型或优化客户身份算法的数据科学家无需知道数据存储在哪里、谁拥有该管道或使用哪个 S3 前缀。他们打开 Unified Studio，找到策划好的 Customer 360 数据集，然后开始建模。他们可以获得共享笔记本、一致的工具和受治理的访问权限，因为声明式治理使安全的自助服务成为可能，而无需牺牲控制权。策划和消费最终并存。

End-to-end observability with RCA and context graph具备 RCA 和上下文图谱的端到端可观测性

A data platform is only as trustworthy as the team’s ability to answer one question: is the data correct right now? Before the Data Accelerator, answering that question meant logging into Apache Airflow, checking Amazon S3 paths, querying Amazon Redshift control tables, and reading DBT logs. “Nobody had the full view. When a stakeholder asked, ‘why does this number look wrong?’ the answer was always, ‘give us a few hours.’ The observability dashboard changes that entirely,” adds Roberts.数据平台的可靠性取决于团队回答一个问题的能力：数据现在正确吗？在数据加速器之前，回答这个问题意味着登录 Apache Airflow、检查 Amazon S3 路径、查询 Amazon Redshift 控制表并阅读 DBT 日志。“没有人拥有全景视图。当利益相关者问‘为什么这个数字看起来不对？’时，答案总是‘给我们几个小时’。可观测性仪表板彻底改变了这一点，”Roberts 补充道。

The observability layer presents full data lineage from S3 Raw ingestion through Processed layers into Amazon Redshift DBT stages as a single interactive graph, color-coded for health. Users click on any node to drill down to individual sources and tables, each showing pass/fail status, last run time, and duration. If a pipeline fails, the lineage visualization shows exactly where the break occurred, and which downstream data is affected.可观测性层将从 S3 原始摄取到处理层再到 Amazon Redshift DBT 阶段的完整数据血缘呈现为单个交互式图谱，并按健康状况进行颜色编码。用户可以点击任何节点深入查看单个源和表，每个节点显示通过/失败状态、上次运行时间和持续时间。如果管道失败，血缘可视化会准确显示中断发生的位置以及受影响的下游数据。

Root cause analysis (RCA) is an agentic tool within F1’s platform that reads system logs and identifies failure points across the data estate. On its own, RCA can tell you what failed. We augment the RCA tool by passing through business context and system topology, codified as JSON. A missing file in S3 might be the error, but with the context graph, RCA tells you that the upstream provider rescheduled their delivery window, which is why the file wasn’t there when the pipeline ran. That’s the difference between knowing what failed and understanding why.根本原因分析 (RCA) 是 F1 平台内的一个智能体工具，它读取系统日志并识别整个数据资产中的故障点。RCA 本身可以告诉您什么失败了。我们通过传递编码为 JSON 的业务上下文和系统拓扑来增强 RCA 工具。S3 中的文件缺失可能是错误原因，但有了上下文图谱，RCA 会告诉您上游提供商重新安排了交付窗口，这就是为什么管道运行时文件不在那里的原因。这就是知道“什么失败了”与“理解为什么失败”的区别。

For the first time, F1 has full lineage, causal root cause analysis, and business context definitions in one place, and the dashboard auto-refreshes every 15 minutes.F1 首次在一个地方拥有了完整的血缘、因果根本原因分析和业务上下文定义，并且仪表板每 15 分钟自动刷新一次。

Data lineage visualization showing pipeline health across sources and stages显示跨源和阶段的管道健康状况的数据血缘可视化

Observability dashboard with failure details带有故障详细信息的可观测性仪表板

Customer identity resolution客户身份解析

The final workstream optimized the algorithms that resolve customer identity across F1’s fan touchpoints. A single fan might interact through the app, buy tickets on the website, watch on F1 TV, and engage on social media. Unifying those interactions into a single identity without false merges or missed matches is what makes effective personalization possible within the Fan Personalization Platform (FPP).最后一个工作流优化了跨 F1 车迷接触点解析客户身份的算法。单个车迷可能通过应用程序互动、在网站上购票、在 F1 TV 上观看并在社交媒体上参与。将这些互动统一为单一身份，且不出现错误合并或匹配遗漏，是车迷个性化平台 (FPP) 实现有效个性化的关键。

F1 already had a working identity resolution process, but it was slow and struggled to scale with the growing volume of fan interactions across channels. Rather than re-architecting the pipeline or replacing components, the team focused on optimizing the existing resolution algorithm’s computational performance. By profiling execution bottlenecks and tuning the matching logic, the engagement reduced processing time by 50%, while keeping the entire resolution pipeline and its downstream integrations fully intact. No processes were changed, no accuracy trade-offs were made: the same algorithm now runs in half the time at F1’s production scale.F1 已经有了有效的身份解析流程，但它速度缓慢，且难以随着车迷跨渠道互动量的增加而扩展。团队没有重构管道或更换组件，而是专注于优化现有解析算法的计算性能。通过分析执行瓶颈并调整匹配逻辑，互动处理时间减少了 50%，同时保持了整个解析管道及其下游集成的完整性。没有改变流程，也没有牺牲准确性：相同的算法现在以 F1 的生产规模在两倍的速度下运行。

With faster resolution, F1 can onboard any new data source and gather new customer data in half the existing time. Faster resolution means fresher unified profiles, which in turn means more timely and relevant personalization across every marketing channel.凭借更快的解析速度，F1 可以以现有时间的一半接入任何新数据源并收集新的客户数据。更快的解析意味着更及时的统一画像，进而意味着在每个营销渠道中实现更及时、更相关的个性化体验。

“The whole point is to deliver the right message to the right fan at the right time, whether that’s through email, the F1 app, ticketing, or social. Now that we can onboard sources in hours and resolve identities faster, we can actually deliver the personalized experiences our fans expect across every marketing channel,” says Kemp.Kemp 说：“重点是在正确的时间通过正确的渠道（无论是电子邮件、F1 应用程序、票务还是社交媒体）向正确的车迷传递正确的信息。现在我们可以在数小时内接入数据源并更快地解析身份，我们真正能够在每个营销渠道中提供车迷所期望的个性化体验。”

Security and governance by design安全与治理设计

The Data Accelerator operates on the principle that AI proposes and humans review. The agents run on Amazon Bedrock AgentCore with long-term memory, retaining context across invocations. Development used Kiro for structured spec-driven development and Amazon Bedrock (Claude Sonnet 4.6) as the foundation model. The event-driven backbone uses AWS Lambda for compute, Amazon EventBridge for routing, Amazon Managed Workflows for Apache Airflow (MWAA) for workflow orchestration, and Amazon S3 as the raw data layer. All AI model access is governed through F1’s AI Gateway for unified access control, cost management, and audit logging. But the architecture is only half the story. The security posture is what makes this production-ready.数据加速器基于“AI 建议，人类审查”的原则运行。智能体在具有长期记忆的 Amazon Bedrock AgentCore 上运行，在多次调用中保留上下文。开发使用了 Kiro 进行结构化规格驱动开发，并使用 Amazon Bedrock (Claude Sonnet 4.6) 作为基础模型。事件驱动的主干使用 AWS Lambda 进行计算，Amazon EventBridge 进行路由，Amazon Managed Workflows for Apache Airflow (MWAA) 进行工作流编排，Amazon S3 作为原始数据层。所有 AI 模型访问都通过 F1 的 AI 网关进行治理，以实现统一的访问控制、成本管理和审计日志记录。但架构只是成功的一半。安全态势才是使其能够投入生产的关键。

The security posture includes:安全态势包括：

• Least privilege: fine-grained permissions, short-lived tokens with one-hour expiry, access limited to specific repositories and resources.最小权限：细粒度权限、一小时有效期的短期令牌，访问限制在特定仓库和资源。
• Full audit trail: every action is logged and attributed for compliance.完整审计跟踪：每个操作都经过记录和归因，以符合合规性。
• Human review: every generated Pull Request goes through engineer approval.人工审查：每个生成的拉取请求都经过工程师批准。
• Automated testing: agents generate comprehensive tests for their own changes.自动化测试：智能体为其自身更改生成全面测试。
• Rollback capabilities: issues surfaced post-merge can be reverted immediately.回滚能力：合并后出现的问题可以立即恢复。
• Network isolation: the entire system runs within private subnets in Amazon Virtual Private Cloud (Amazon VPC) with no direct internet access.网络隔离：整个系统在 Amazon Virtual Private Cloud (Amazon VPC) 的私有子网内运行，没有直接的互联网访问。
• Encrypted credentials: all secrets stored at rest in AWS Systems Manager Parameter Store.加密凭证：所有机密信息在静态时存储在 AWS Systems Manager Parameter Store 中。

“What gave us confidence to put agentic AI in our production data pipelines was what we call ‘Human at the helm.’ The agents do the heavy lifting, but humans make the decisions. Every change goes through the same review process our engineers already use, so adoption was immediate.” says Roberts.Roberts 说：“让我们有信心将智能体 AI 放入生产数据管道的是我们所说的‘人在舵手位’。智能体承担繁重的工作，但人类做出决定。每一次更改都经过我们工程师已经使用的相同审查流程，因此采用非常迅速。”

The impact影响

The Data Accelerator delivered measurable impact across F1’s MarTech operations:数据加速器在 F1 的 MarTech 运营中产生了可衡量的影响：

• Data source onboarding: reduced from 6 to 8 weeks to approximately 40 minutes of code generation plus hours of deployment and review.数据源接入：从 6 到 8 周缩短至约 40 分钟的代码生成加上数小时的部署和审查。
• Autonomous work: AI agents handle 95% of onboarding tasks without human intervention.自主工作：AI 智能体在无需人工干预的情况下处理 95% 的接入任务。
• Time-to-value: approximately 99% reduction.价值实现时间：缩短约 99%。
• Schema evolution: end-to-end resolution in hours instead of days.模式演变：端到端解决时间从数天缩短至数小时。
• Integration backlog: 18-month backlog cleared in weeks.集成积压：18 个月的积压任务在数周内清理完毕。
• Data engineers who previously spent their time writing boilerplate ingestion code and chasing schema breaks now focus on strategic initiatives that advance the business.以前花费时间编写样板摄取代码和追踪模式中断的数据工程师，现在专注于推动业务发展的战略计划。
• Implementation velocity: a single developer took the agentic solution from proof of concept to production release in 4 months.实施速度：一名开发人员在 4 个月内将智能体解决方案从概念验证推向生产发布。

The reliability, consistency, and data integrity of the MarTech platform were improved, while the operational overhead was reduced: “The Data Accelerator didn’t just speed things up. It changed how we operate. Our data engineers went from writing boilerplate ingestion code to focusing on strategic initiatives. Issues can be identified and fixed before our end users even notice.” says Kemp.MarTech 平台的可靠性、一致性和数据完整性得到了改善，同时运营开销减少了：“数据加速器不仅加快了速度，它改变了我们的运作方式。我们的数据工程师从编写样板摄取代码转变为专注于战略计划。问题可以在最终用户注意到之前就被识别并修复，”Kemp 说。

Conclusion结论

The Data Accelerator’s success comes down to three principles: meeting developers where they already work, keeping them at the helm, and embedding governance like GDPR classification from day one rather than bolting it on after. These principles shaped a solution where F1 partnered with AWS to use agentic AI on Amazon Bedrock AgentCore to transform MarTech data operations. By combining automated data source onboarding, schema evolution detection, and unified data access through Amazon SageMaker Unified Studio, F1 reduced onboarding time by approximately 99% and eliminated an 18-month integration backlog in weeks.数据加速器的成功归结为三个原则：在开发人员现有的工作环境中与他们会面、让他们保持在舵手位，以及从第一天起就嵌入 GDPR 分类等治理措施，而不是事后补救。这些原则塑造了一个解决方案，F1 与 AWS 合作，利用 Amazon Bedrock AgentCore 上的智能体 AI 转型 MarTech 数据运营。通过结合自动数据源接入、模式演变检测和通过 Amazon SageMaker Unified Studio 实现的统一数据访问，F1 将接入时间缩短了约 99%，并在数周内消除了 18 个月的集成积压。

The approach is deliberately replicable. Any organization dealing with multi-source data onboarding, schema volatility, and governance requirements can apply the same architecture to their own environment. The agents are domain-agnostic, and they know how to onboard, classify, and monitor. The domain is interchangeable.这种方法是有意可复制的。任何处理多源数据接入、模式波动和治理要求的组织都可以将相同的架构应用于自己的环境。智能体是领域无关的，它们知道如何接入、分类和监控。领域是可以互换的。

Getting started入门

To learn more about the AWS services used in this solution:要了解有关此解决方案中使用的 AWS 服务的更多信息：

• Amazon Bedrock AgentCore.Amazon Bedrock AgentCore。
• Amazon SageMaker Unified Studio.Amazon SageMaker Unified Studio。
• Kiro.Kiro。
• AWS Professional Services.AWS 专业服务 (AWS Professional Services)。

Acknowledgments致谢

This outcome is the result of years of incremental improvements to the MarTech platform, delivered through a close partnership between F1 and AWS. Many contributors across both organizations have shaped the architecture and strengthened the foundations that made the Data Accelerator possible. We are grateful to the following thought leaders and developers for their dedication and expertise: Paula Marenco Aguilar, Nadeen Nilanka, Taye Aduewa, Marton Juhasz, Deepak Gulia, Alex Goff, Nick Morgan, and Seshadri Senthamaraikannan.这一成果是 F1 与 AWS 紧密合作，多年来对 MarTech 平台进行渐进式改进的结果。两个组织中的许多贡献者塑造了该架构并加强了使数据加速器成为可能的基础。我们感谢以下思想领袖和开发人员的奉献和专业知识：Paula Marenco Aguilar, Nadeen Nilanka, Taye Aduewa, Marton Juhasz, Deepak Gulia, Alex Goff, Nick Morgan 和 Seshadri Senthamaraikannan。

About the authors关于作者