Artificial Intelligence人工智能

From weeks to minutes: How Formula 1® uses agentic AI on AWS to accelerate data operations从数周到数分钟:F1如何利用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.Formula 1®(F1)全年通过数字平台、F1 TV、社交媒体、票务和商品与全球超过8亿车迷互动。比赛每两周举行一次,车迷互动的窗口以分钟计算,商业决策需要跟上赛场上的速度。在幕后,F1的营销技术(MarTech)平台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.”然而,该平台面临着一个重大的运营挑战。F1 IT总监Chris Roberts表示:“我们的MarTech平台是F1车迷互动的神经系统。但每个新的数据源都需要6到8周的手动工程工作。我们积压了18个月的工作,仅仅是为了整合12个新数据源。”业务产生的数据速度超过了工程团队能够接入的速度。因此,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数据平台从手动维护的系统转变为自我管理、可观察且统一的数据资产。在本文中,我们展示了Data Accelerator如何将数据源接入时间从最长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 S3路径、Amazon Redshift控制表、Airflow日志和DBT输出之间追踪问题。

Solution overview解决方案概览

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

  • 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:Data Accelerator的核心是一组平台智能体,它们接收包含数据源有限信息的业务需求文档(BRD),并生成完全可用于生产的接入管道。这包括基础设施代码、数据转换、治理策略和GDPR分类,而无需人工编写任何样板代码。这些智能体分两个阶段工作:

Phase 1: Configuration generation阶段1:配置生成

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,将这些文件作为拉取请求推送到标准化的Git仓库,并通过REST API访问Jira,创建引用该PR的工单。所有智能体对话和操作都通过内置的AgentCore可观测性追踪到Amazon CloudWatch。指派的工程师进行审查,必要时进行调整,然后批准。

Phase 1 workflow showing a BRD upload triggering an agent that generates config files and opens a pull request

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

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

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. DBT transformation framework. Governance policies including GDPR tagging.AWS Glue应用程序和基础设施代码。DBT转换框架。包括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工单,以确保可追溯性。工程师在Infrastructure、DBT和Governance仓库中逐一审查并批准。

Phase 2 workflow where the agent generates infrastructure, transformation, and governance pull requests linked to one Jira ticket

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

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 workflow where an agent detects an upstream change, assesses impact, and generates code updates with a Jira ticket

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.在Data Accelerator之前,使用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.数据平台的可信度取决于团队回答一个问题的能力:数据现在是否正确?在Data Accelerator之前,回答这个问题意味着登录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原始摄取到Processed层再到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 graph with pipeline health color-coded across data sources and processing stages

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

Observability dashboard showing pipeline failure details including source, status, and timing

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上观看并通过社交媒体参与。将这些互动统一为单一身份,而不会错误合并或漏匹配,是Fan Personalization Platform(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.Data Accelerator遵循“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 Gateway进行治理,以实现统一的访问控制、成本管理和审计日志记录。但架构只是故事的一半。安全态势才是使其能够投入生产的原因。

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:Data Accelerator为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. Schema evolution: end-to-end resolution in hours instead of days. Integration backlog: 18-month backlog cleared in weeks.实现价值的时间:减少约99%。模式演变:端到端解决时间从数天缩短到数小时。集成积压: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平台的可靠性、一致性和数据完整性得到了提高,同时运营开销减少:“Data Accelerator不仅仅加快了速度。它改变了我们的运营方式。我们的数据工程师从编写样板摄取代码转变为专注于战略举措。问题可以在最终用户注意到之前就被发现并修复。”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.Data Accelerator的成功归结为三个原则:在开发人员已经工作的地方与他们见面,让他们保持主导地位,并从第一天起嵌入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服务的更多信息:

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.这一成果是多年来对MarTech平台进行渐进式改进的结果,通过F1与AWS之间的密切合作实现。两个组织的许多贡献者都塑造了架构,并加强了为Data Accelerator奠定基础的根基。我们感谢以下思想领袖和开发者的奉献和专业知识:Paula Marenco Aguilar、Nadeen Nilanka、Taye Aduewa、Marton Juhasz、Deepak Gulia、Alex Goff、Nick Morgan和Seshadri Senthamaraikannan。


About the authors关于作者

Subhro Bose

Subhro Bose

Subhro is a Senior Data & AI Architect at AWS and the creator of CausalIF, an open-source causal inference library that brings causal inference to model reasoning with consistency of results, discovering why things happen in complex systems. His work spans agentic AI, self-healing platforms, and turning causal discovery into production-grade intelligence across logistics, finance, and compliance.

Jerome Descreux

Jerome Descreux

Jerome is a Senior Delivery Manager within AWS Professional Services. He leads large scale transformation programs and strategic projects for major EMEA enterprise customers, across various industries including logistics, manufacturing, financial services, aviation, and sports.

Matt Kemp

Matt Kemp

Matt leads CRM and Customer Data Operations at Formula 1, overseeing the data, insight and engagement capabilities that connect millions of fans with the sport. He has delivered large-scale digital transformation programmes and is championing the use of AI, machine learning and agentic technologies to drive innovation, operational efficiency and personalised fan experiences.

Arunraja Kumar

Arunraja Kumar

Arunraja is Senior Data Architect at Formula 1, responsible for shaping the data platform and architecture that powers fan engagement, insight and innovation across the sport. He led the technical transformation of F1’s Fan Personalisation Programme, evolving the platform into an AI-native, agentic ecosystem that enables scalable, real-time experiences and supports Formula 1’s ambition to deliver personalised engagement to more than one billion fans worldwide.