Guide · Architecture
Live Sports Agent Runtime: How Agents Run Against Live Match State
A live sports agent runtime is the loop that watches live match state, decides what the moment calls for, drafts an output, applies the approval mode configured for that surface, ships it to a destination, and records the result. High-risk output is reviewed item by item; trusted lower-risk output is reviewed by sample, and the active mode is recorded. It turns a model that can write about sport into an operator-controlled system.
Where does the runtime get its state?
Everything the runtime does depends on knowing what is true right now, so the first stage is not a model call at all. It is a subscription to state: fixtures and their status, event timelines, squads and availability, standings, and, where the deployment is licensed for it, market context.
Two properties of that state matter more than volume. The first is identity: the same fixture arriving from two providers under two identifiers has to resolve to one object, or every downstream reference is a coin flip. The second is freshness, which the runtime inherits rather than creates. If a provider is late, the agent is late, and no amount of orchestration fixes that. A runtime that cannot tell you how old its view of a match is cannot be trusted to act on it.
What are the stages of the loop?
A runtime is the loop that watches live state, decides, drafts, routes for approval, ships, and records the result. Every one of those six stages is a place a human can stop the loop, which is the difference between an agent you can deploy in production and a demo that only works when nobody is watching.
Watch
Subscribe to live state and evaluate triggers continuously. A trigger is a condition worth acting on, such as a lineup confirmation, a goal, a status change, or a market moving beyond a threshold. Control point: the operator owns the trigger list and can disable any of them mid-match.
Decide
Choose what the moment calls for and whether anything should happen at all. Most triggers should end here, because the expensive failure in live sport is not silence, it is volume nobody asked for. Control point: the operator sets the rules that decide when the runtime holds.
Draft
Produce the output, grounded in the state read at decision time rather than from memory, in the operator's voice and under the operator's terminology and compliance rules. Control point: brand and compliance rules are configuration the operator edits, not code.
Approve
Route the draft 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. In a live window this stage is the constraint, so it is designed around the clock rather than bolted on afterwards. Control point: the operator sets the mode, and the active mode is recorded with what shipped.
Ship
Deliver the approved item to its destination and confirm the destination accepted it. A send attempt is not a delivery, and in a live window the difference is discovered too late if nobody checks. Control point: the operator sees confirmation, not optimism.
Record
Write down what shipped, from which state, under whose approval, to which surface, and what happened afterwards. Control point: the record belongs to the operator and can be exported.
Why can a one-shot prompt tool not do this?
A one-shot tool answers when asked. That single property removes four of the six stages. There is no watch stage, because nothing is subscribed to anything. There is no decide stage, because the human already decided by typing. There is no approve stage in any enforceable sense, because the output goes to whoever ran the prompt. And there is no record beyond the chat history.
This is not a quality argument about the underlying model. The same model can sit inside a runtime and produce excellent output. The argument is about who has to be present. A prompt tool requires a person at the moment of every output, which is exactly the constraint an operator is trying to remove when a competition has more fixtures than staff.
How does a live runtime fail?
Knowing the failure modes is more useful than knowing the happy path, because the happy path is the same everywhere.
- Stale state: the runtime acts on a view of the match that has moved on. Mitigated by reading state at decision time and by carrying an explicit freshness expectation per source.
- Identity drift: two sources name the same fixture differently and the output references the wrong one. Mitigated by canonical identifiers and an identity mapping that is inspectable.
- Approval starvation: drafts arrive faster than reviewers can clear them and the queue outlives the match. Mitigated by narrowing triggers, not by widening the queue.
- Silent delivery failure: the destination rejects the item and nobody notices until after the fixture. Mitigated by requiring delivery confirmation.
- Unbounded volume: every trigger fires and the surface floods. Mitigated by a decide stage that is allowed to choose nothing.
- Unrecoverable publication: something wrong is live and there is no route to withdraw it. Mitigated by a rollback path designed before launch, not after the first incident.
Where do execution and evaluation layers fit?
An execution and evaluation layer is one component inside the draft and record stages: it runs the agent's work and scores the result against ground truth so regressions are visible before an operator finds them. Machina publishes one such layer in the open, and it is genuinely useful, but it is a component of the runtime rather than the platform category, and it does not replace the approval or delivery stages around it.
The practical test for any evaluation layer is whether it has ground truth to check against. A domain-neutral harness can tell you the output was fluent. Only a sports-grounded one can tell you it named the wrong scorer, which is the error that actually costs an operator something.
Runtime requirements versus a one-shot prompt tool
Scroll to compare →
| Requirement | One-shot prompt tool | Live sports agent runtime |
|---|---|---|
| Trigger | A person types something | Subscribed live state evaluated continuously |
| Decision to act | Implicit in the request | An explicit stage that is allowed to choose nothing |
| Grounding | Whatever is in the prompt | State read at decision time, with a freshness expectation |
| Brand and compliance rules | Restated per prompt, by hand | Configuration applied to every draft |
| Approval | Whoever ran the prompt | Configured mode: high-risk item-by-item review or trusted lower-risk sampled review; active mode recorded |
| Delivery | Copy and paste | Routed to the destination with confirmation |
| Record | Chat history | What shipped, from which state, approved by whom, and what followed |
| Rollback | None | A defined route to withdraw or correct published output |
Architecture classes, not products. The same model can sit inside either one.
Frequently Asked Questions
What is a live sports agent runtime?
The loop that watches live match state, decides what the moment calls for, drafts an output, applies the approval mode configured for the surface, ships it, and records the result. High-risk output receives item-by-item review; trusted lower-risk output receives sampled review, and the active mode is recorded.
How is a runtime different from a prompt or a chatbot?
A prompt tool answers when asked, which removes the watch, decide, approve, and record stages. A runtime is subscribed to state, is allowed to decide that nothing should happen, enforces the configured approval mode, and keeps a record of the active mode. The model can be identical; the operating model is not.
Does the agent publish without a human?
Human control remains required on public-facing surfaces through the approval mode configured by the operator. A named person accepts, edits, or rejects high-risk items individually; trusted lower-risk output receives sampled review. The active mode and any item-level decision are recorded so the operator retains control and an audit trail.
How fresh is the match state the agent reasons over?
As fresh as the connected source, and no fresher. Freshness is inherited, not created by the runtime. A well-built runtime states an expectation per source and reads state at decision time rather than reusing an earlier read, so staleness is bounded and visible.
What happens when something wrong is already published?
A rollback route withdraws or corrects it, and the record shows what shipped, from which state, under which approval mode, and who approved it when item-level review applied. Being wrong after the fact is a normal operating condition in live sport, so the route has to exist before launch rather than after the first incident.
Sources cited on this page
- Machina Sports product documentationAccessed 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.
- Sports AI agent platformThe category page: how the runtime sits between data and a measurable output.
- Sports MCP serverHow the runtime reaches capabilities, and what to require from the transport.
- How to evaluate a sports AI agent platformThe buyer's checklist that turns these stages into questions for a vendor.