Platform · Category
Sports AI Agent Platform: Architecture, Governance, and How to Evaluate One
Machina is the sports AI agent platform for verified live sports workflows.
A sports AI agent platform is software that connects approved or live sports data to sports-native AI agents, runs those agents inside a governed workflow under the approval mode configured for each surface, and delivers a measurable operator or fan output. High-risk output receives item-by-item review; trusted lower-risk output receives sampled review, and the active mode is recorded. It differs from a sports data API and a generic agent framework.
What is a sports AI agent platform?
A sports AI agent platform is the layer between a sports data source and a published output. It holds four things that a data feed alone does not: a connection to data the buyer is licensed or approved to use, an agent that understands sports entities as first-class objects rather than as strings, a workflow that applies the approval mode configured for the surface, and a record of both the active mode and what shipped so the result can be measured and repeated. High-risk output is reviewed item by item; trusted lower-risk output is reviewed by sample.
Every deployment runs the same chain: approved or live data grounds a sports-native agent, the agent runs inside a governed workflow, and the workflow produces one measurable operator or fan output that shipped under the approval mode the operator configured for that surface.
The category matters because the failure modes are specific. A sports agent that is not grounded in current match state produces confident, wrong output at the exact moment that output is most visible. A sports agent with no approval path produces output nobody is willing to publish. A sports agent with no telemetry produces output nobody can prove worked. The platform exists to close those three gaps at once, which is why buying one is a different decision from buying a data feed or adopting an agent framework.
How is a platform different from a sports data API?
A sports data API answers a question you already knew how to ask. You send a request for a fixture, a lineup, or a standings table, and you get a structured response. Everything after that response, deciding what the moment calls for, drafting something publishable, checking it against brand and compliance rules, routing it to a person, publishing it, and recording the outcome, is work you still own.
A platform owns that chain. The distinction is not that one has more data. It is that one hands you an answer and the other hands you a shipped, governed, measurable output. Teams that miss this distinction typically budget for the feed and then discover that the feed was the least expensive part of the problem.
- A data API is scoped to a request and a response. A platform is scoped to an outcome.
- A data API has no opinion about approval. A platform treats approval as a required stage.
- A data API has no memory of what you published. A platform records it so the next cycle is measurable.
How is it different from a generic AI agent framework?
A generic agent framework gives you orchestration primitives: tool calls, loops, memory, retries. Those are real and useful, and they are domain-agnostic by design. What they do not give you is a sports entity model, so a fixture, a competition, a squad, and a player are whatever your prompt says they are, and nothing reconciles them across two providers that name the same match differently.
The gap shows up in three places. Identity: the same fixture arrives from two sources with two identifiers and no cross-walk. Live state: a match is a moving object, and a framework has no notion of whether the state it is reasoning over is current. Evaluation: a domain-neutral harness cannot tell you that a recap named the wrong scorer, because it has no ground truth to check against.
This is an architecture-class comparison, not a vendor comparison. Building on a generic framework is a legitimate choice, and it is the right choice when your sports surface is small enough that the entity model fits in one engineer's head. It stops being the right choice at the point where correctness across competitions becomes someone's full-time job.
What are the layers of the platform?
The architecture reads in the same order as the output: data first, then the agent, then the workflow, then what ships. Each layer has a defined contract with the one above it, which is what makes a failure diagnosable rather than mysterious.
- Sports Skills is the open-source onramp: public sports data primitives for AI agents, with no signup, so the data layer can be evaluated before any commercial conversation.
- One open execution and evaluation layer sits inside the agent and workflow stages. It is a component of the platform, not the platform itself and not the category.
Approved and live data
Connections to licensed provider feeds, customer-approved first-party material, and public sources, each carrying an identity mapping, a rights and privacy class, a freshness expectation, and an owner. Coverage is exactly what the connected sources cover, and no more.
Sports-native agent
Agents that treat fixtures, competitions, squads, players, standings, and market context as typed entities rather than free text, so a reference resolves to the same object across providers and across a season.
Governed workflow
The stage that decides whether output leaves the building: brand and compliance rules, item-by-item review by a named person for high-risk output or sampled review for trusted lower-risk output, a record of the active approval mode and any item-level decision, and a rollback route when something is wrong after the fact.
Measurable output
Delivery to the surface the audience actually uses, plus a record of what shipped, when, under which approval mode, who approved it when item-level review applied, and what happened next, so the next cycle is an adjustment rather than a fresh guess.
Integration surfaces
The same capability reachable as an SDK inside application code, as APIs for direct service integration, and through guided configuration. MCP is documented today for World Cup Intelligence only, as a developer preview, rather than as a general platform transport. Published contracts are authoritative for what is available.
Which sports organizations use a platform like this?
Clubs, leagues, and rights holders
Jobs
- Publish matchday coverage across a full competition rather than only marquee fixtures
- Answer fan questions using the club's own approved material
- Localise the same story for several audiences without re-reporting it
Observable outputs
- Coverage published for every fixture in a connected competition
- The configured approval mode recorded in the audit trail, with the item-level reviewer recorded when that mode applies
- Reusable source contracts for club-owned material, so the next season starts from a working configuration
Broadcasters, media, and production teams
Jobs
- Surface the storylines worth covering while the match is still running
- Turn live state into production-ready notes, graphics briefs, and short-form drafts
- Use item-by-item editorial sign-off for high-risk output and sampled review for trusted lower-risk output
Observable outputs
- Draft output available inside the production window rather than after it
- An editorial approval mode whose active setting is recorded, not assumed
- A log of what was produced and used, so the next fixture is scoped from evidence
Data platforms and market operators, including sportsbooks
Jobs
- Explain fixtures, market movement, and context as informational content
- Keep informational content inside compliance rules for every market it appears in
- Cover the long tail of fixtures that manual production never reaches
Observable outputs
- Informational market context and match analysis, with no selection or wagering guidance generated
- Compliance rules applied at the workflow stage rather than checked afterwards
- An audit trail that shows what was published, the active approval mode, any item-level approver, and the market
What does a deployment look like, stage by stage?
Connect
Attach the sources the deployment is licensed or approved to use, and record what each one covers.
Control · The buyer approves the source list and its rights scope before anything is connected.
Ground
Map incoming entities to canonical identifiers so the same fixture, squad, or player resolves consistently across providers.
Control · The buyer can inspect the identity mapping and the freshness expectation for every connected source.
Configure
Set what the agent produces, in whose voice, under which brand and compliance rules, for which surfaces.
Control · The buyer owns the rule set and can change it without a code change.
Approve
Route drafted output through the approval mode configured for that surface: a named person accepts, edits, or rejects each item where the risk is high, or reviews a sample once the configuration has earned trust.
Control · The buyer sets the approval mode per surface, and the active mode is recorded next to what shipped under it.
Ship
Deliver the governed output to the destination surface and confirm the destination accepted it.
Control · The buyer sees delivery confirmation, not just a send attempt.
Measure
Record what shipped, when, under which approval mode, any item-level approver, and what happened after, so the configuration can be adjusted on evidence.
Control · The buyer holds the record and can export it.
What governance controls does a buyer get?
Governance is the reason this is a platform decision rather than a model decision. An agent that drafts well and cannot operate under a configured review mode is not deployable in a regulated or brand-sensitive context, and sport is usually both.
- Approval mode, configured per surface: item-by-item sign-off by a named person where the risk is high, sampled review once a configuration has earned trust. The active mode is recorded with the output.
- Brand and compliance rules: voice, terminology, prohibited framings, and market-specific constraints applied at the workflow stage, not corrected afterwards.
- Audit trail: what was produced, from which sources, which approval mode was active, who approved it when item-level review applied, when it shipped, and where it went.
- Human-controlled output: the agent presents evidence and options for a person to act on. It does not issue autonomous advice, and it does not generate wagering guidance.
- Rollback: a route to withdraw or correct published output, because being wrong after the fact is a normal operating condition in live sport.
- Portability: source contracts, rules, and records belong to the buyer, so a provider change is a migration rather than a rebuild.
Build in-house, generic agent framework, or sports-native platform
Scroll to compare →
| Decision criterion | Build in-house | Generic agent framework | Sports-native platform |
|---|---|---|---|
| Sports entity model | You design and maintain it | Not provided; you add it | Provided and maintained as a product surface |
| Live state handling | You build the freshness and reconciliation logic | Orchestration only; no notion of match state | Treated as a first-class concern of the data layer |
| Data rights and licensing | You negotiate and track every source | Out of scope entirely | Scoped per deployment, recorded per source |
| Approval and compliance | You build the review tooling | You build the review tooling | A required workflow stage with an audit trail |
| Domain evaluation | You build ground truth and the harness | Domain-neutral harness only | Sports-specific checks against connected ground truth |
| What determines total time | Source connection, generation, and the approval workflow you build | Source connection, generation, and the approval workflow you build | Source latency, generation time, and the configured approval mode |
| Best fit when | The workflow is your core differentiator | The sports surface is small and stable | Correctness across competitions is an ongoing job |
Architecture classes, not vendors. Building in-house is the right call when the workflow itself is the product.
What does the platform not do?
Coverage is exactly what the connected sources cover. There is no independent data universe behind the platform.
Applies to every deployment. A competition that no connected source carries is not covered, and no configuration changes that.
Data rights are customer-scoped or provider-scoped. Licensed material cannot be redistributed beyond the terms the buyer holds.
Applies to every licensed feed and to first-party material a customer connects.
No wagering advice, selections, or guaranteed outcomes are generated. Market output is informational context only.
Applies to every surface, including deployments for market operators, in every jurisdiction.
Freshness is inherited from the connected source and is not guaranteed independently of it.
Applies to live match state and market context. If a provider is late, the agent is late.
Approval is a configured mode, not one fixed rule. Item-by-item sign-off bounds throughput by reviewer availability; sampled review lifts that bound and reviews less.
Applies to every public-facing surface. The operator owns the mode and the trade it makes, and the active mode is recorded.
Source latency, generation time, and the configured approval mode determine total time. Agents remove the manual drafting delay.
No end-to-end benchmark number is published because the result is deployment-specific.
Frequently Asked Questions
What is a sports AI agent platform?
Software that connects approved or live sports data to sports-native AI agents, runs those agents under the approval mode configured for each surface, and delivers a measurable operator or fan output. High-risk output receives item-by-item review; trusted lower-risk output receives sampled review, and the active mode is recorded. It covers the whole chain rather than answering one data request.
Is a sports AI agent platform the same as a sports data API?
No. A data API answers a request and stops. A platform decides what a moment calls for, drafts it, applies brand and compliance rules, applies the configured approval mode, delivers it, and records both the active mode and the outcome. High-risk output is reviewed item by item; trusted lower-risk output is reviewed by sample. The data feed is one layer of the platform, not a substitute for it.
Can I use a generic AI agent framework instead?
You can, and it is a reasonable choice when your sports surface is small and stable. A generic framework gives you orchestration but no sports entity model, no live-state handling, and no domain evaluation, so you build and maintain those yourself. The trade-off is ownership, not capability.
Does the platform generate betting advice?
No. Market-related output is informational context and match analysis only. The platform does not produce selections, wagering guidance, or guaranteed outcomes, and output ships under an approval mode the operator configures and controls.
What data does the platform run on?
Licensed provider feeds, customer-approved first-party material, and public sources, connected per deployment. Coverage and freshness are scoped to those sources. Rights stay with whoever holds them, and the platform records the rights class for each connected source.
Where does open source fit?
Sports Skills is the open-source onramp: public sports data primitives for AI agents with no signup, so the data layer can be evaluated before any commercial conversation. One open execution and evaluation layer sits inside the agent and workflow stages as a component, not as the platform category.
How do I evaluate one?
Ask for the source list and its rights scope, the identity mapping, the freshness expectation per source, the approval path and who signs, the audit trail format, the evaluation method with its ground truth, and the export route if you leave. The evaluation checklist guide walks each of those in order.
Sources cited on this page
- Machina Sports product documentationAccessed 2026-08-11
- Sports Skills, open-source sports data primitives for AI agentsAccessed 2026-08-11
- Model Context Protocol specificationAccessed 2026-08-11
Andre Antonelli
Founder & CEO, Machina Sports
Andre Antonelli is the Founder & CEO of Machina Sports.
- How to evaluate a sports AI agent platformThe buyer's checklist: what strong evidence looks like for each criterion, and what a weak answer looks like.
- Live sports agent runtimeHow agents run against live match state: the loop, the control points, and what a one-shot tool cannot do.
- Sports data API vs AI agent platformWhat each one hands you, and what you still build yourself after the response arrives.
- Agent templatesReady-to-deploy sports agents that ship through the governed workflow described here.
- Learn hubThe full category cluster: runtime, protocol, architecture comparisons, and evaluation.