About the project

Inspiration

I grew up in a house where money often ran short. That is where the lottery first caught my attention — not simply as a game, but as one of the few doors a kid in that situation could see. Thousands of people would stare at a set of numbers, all hoping to guess what would happen next.

What stayed with me was not the prize. It was the question behind it: when an outcome is uncertain, what can the available information actually tell us? I began wondering which events were truly random, which contained patterns, and how often people relied on intuition without examining the evidence.

Years later, Moneyball gave that curiosity a practical direction: in sports, you can use data to estimate what is likely to happen instead of relying only on instinct. I studied economics, so probability was already part of the way I had learned to understand the world, and I have always loved sports.

I began analyzing matches in spreadsheets. The more I measured, the more I enjoyed watching.

The problem was not the method. The problem was execution. The information I needed was scattered across schedules, recent results, home and away performance, lineups, injuries, player statistics and historical matchups. Preparing a serious analysis manually took too long to be practical.

My career has been in banking and fintech. Before ParlAI, I had never built a software product. At 38 and while unemployed, I spent six months learning how to move from writing a prompt in a friendly interface to coordinating coding agents, managing a repository and operating a real application in production.

That journey made it possible to build the tool I had wanted for years.

I started by trying to predict the right outcome. I ended up building a product whose most important ability is recognizing when the evidence is not strong enough to make a recommendation.

What it does

ParlAI is a conversational sports analysis copilot for Liga MX, MLS and Leagues Cup. Its current scope is deliberately narrow: the goals market.

A user selects a match and talks naturally with the Copilot. ParlAI examines the available evidence, calculates the probability of different goal lines and explains whether the numbers support a recommendation.

The most important response is sometimes no.

When the evidence is insufficient, ParlAI does not manufacture certainty or change its conclusion because the user insists. It explains what is known, what is missing and why it cannot support a selection.

This behavior comes from a deliberate separation of responsibilities: an autonomous system prepares the evidence, a deterministic engine performs the calculations, and Gemini understands and communicates with the user.

How we built it

ParlAI is a hybrid agentic system composed of three cooperating layers.

The autonomous Orchestrator

The Orchestrator prepares verified match dossiers before users request them. It collects and organizes information such as:

  • Recent form in the correct home or away context
  • Attacking and defensive performance
  • Leading scorers and designated penalty takers
  • Head-to-head history when available
  • Injuries and probable or confirmed lineups
  • Match timing and competition context

This process runs on a schedule so that most conversations can begin with the analysis already prepared.

There is also an on-demand path. If someone wants to analyze a match before its dossier has been prepared, the Copilot can activate the same analysis pipeline and build the missing context. This first request takes longer, but the resulting dossier can then be reused.

That combination gives ParlAI two useful behaviors: proactive preparation for speed and tool-driven analysis when a request arrives early.

The auditable goals engine

The Orchestrator passes a structured dossier to a deterministic statistical engine.

The engine calculates relative attacking and defensive strengths, estimates expected goals, and applies Poisson probabilities and competition-specific calibration. It then evaluates whether the evidence crosses the required threshold for a recommendation.

For a projected total-goals rate, the probability of observing exactly (k) goals is:

$$ P(X=k)=\frac{e^{-\lambda}\lambda^k}{k!} $$

The engine is intentionally separate from the language model. Given the same input and rule version, it always returns the same result. Every conclusion can therefore retain its inputs, calculated probability, confidence and rule version.

Gemini cannot modify those calculations. This prevents the system from producing a more confident answer simply because the conversation asks for one.

The Gemini Copilot

Gemini 2.5 Flash is responsible for the conversational intelligence.

It understands free-form Spanish, identifies the user’s intent, recognizes the relevant match and goals line, uses the conversation history, and combines the verified match dossier with the engine’s conclusion.

It can answer follow-up questions, explain the evidence in accessible language and activate the analysis pipeline when the required context is missing.

Gemini contributes language understanding, contextual reasoning and communication. The statistical engine retains authority over the numerical conclusion.

The result is neither a traditional decision tree nor an unrestricted chatbot. It is a system in which autonomous preparation, mathematical discipline and conversational intelligence have distinct responsibilities.

Within a single conversation, ParlAI can distinguish between multiple matches and preserve each one as a separate analysis cycle. The interface reflects that state in the conversation sidebar and gives the user a direct action to save a selection without losing the context of the other matches being discussed.

Why we chose this architecture

The architecture was driven by latency, cost, reliability and auditability.

Running every calculation and data request from scratch during every conversation would make responses slower and more expensive. Allowing a language model to calculate or rewrite probabilities would make the results difficult to reproduce.

Instead, the Orchestrator prepares reusable dossiers, the deterministic engine performs inexpensive and repeatable calculations, and Gemini is used where it creates the most value: understanding the user and reasoning about how to communicate the available evidence.

ParlAI runs its backend and autonomous analysis pipeline on Google Cloud Run. Google Cloud Scheduler triggers the preparation of upcoming matches. Gemini powers the Copilot, while Firebase provides hosting and authentication. PostgreSQL stores the match dossiers, conversations and versioned conclusions.

Building the project with AI agents

AI was not only incorporated into the product; it also changed how the product was built.

I used coding agents in separate areas of the repository: product and backend behavior, the statistical engine, interface design, and the development method itself. Because these agents worked in the same codebase, coordination became a real engineering problem.

Limited budgets forced me to replace informal prompting with a repeatable process. Each assignment needed a written scope, an explicit boundary, a documented root cause and a verification procedure. Work was divided into controlled turns, and completion required evidence from the running system rather than an agent’s written summary.

What began as a limitation became one of the most valuable lessons of the project: an agent’s report is not proof that a system works.

What we learned

Successful automation needs observable outcomes

One scheduled process had been reporting success for weeks even though the function it attempted to call did not exist. Each match failed inside an error handler, but the endpoint still returned a successful status because nobody verified that the number of processed matches was greater than zero.

That changed the project’s verification philosophy.

A process is not considered successful because it ran or returned a successful response. Its real output must be checked. Compilation is not the same as working, and working locally is not the same as running correctly in production.

Silent failures are more dangerous than visible errors

Earlier versions of the product contained fixed fallback values that made incomplete flows appear functional. Missing information could silently become a predefined match or goals line.

Those fallbacks were removed. ParlAI now treats missing data as missing data and communicates the limitation instead of manufacturing a complete-looking answer.

For this product, an honest absence of information is safer than a polished fiction.

Historical performance must change the product

We evaluated the goals engine on approximately 1,500 historical matches. The tests showed that predictive strength was not uniform across competitions or across all matches. Some of the original rules did not generalize, and recent scoring form alone was much less informative than expected in some leagues.

We used those results to narrow the system rather than exaggerate its certainty.

Rules that were not supported by the evidence were removed. Probabilities were calibrated separately by competition where the available sample justified it. When a sample was too small, the adjustment was labeled preliminary instead of being presented as established.

Most importantly, the engine no longer assumes that every match deserves a selection. It recommends only when the configured evidence and confidence requirements are satisfied. Otherwise, it still provides an analysis and explains why it is abstaining.

The backtest did not give us permission to claim certainty. It taught the product when to be cautious.

Real devices and real production flows matter

Testing a mobile interface by narrowing a desktop browser did not reveal several issues that appeared immediately on a real iPhone, including automatic input zoom, the changing height of Safari’s interface and horizontal overflow.

The same lesson applied to subscriptions and autonomous processes: a feature that looks complete is not complete until the real flow has been exercised from beginning to end.

Challenges we faced

Incomplete data

The available sports data is not equally complete across competitions. Some leagues provide extensive injury information, while Liga MX may return none through the same provider.

ParlAI does not ask Gemini to fill those gaps through inference. Where automation has a documented limitation, verified information can be added through an internal operator workflow.

Human oversight enters where the evidence ends.

Balancing speed with depth

A complete on-demand dossier can take approximately 18 to 28 seconds to prepare. That is acceptable as a fallback, but not as the normal conversational experience.

The autonomous Orchestrator addresses this by preparing upcoming matches in advance. The on-demand path remains available for users who analyze a match before its scheduled preparation window.

This balance lets the system remain responsive without preventing early analysis.

Learning to reduce the roadmap

Earlier plans included additional markets, live notifications and a competition-oriented feature. Those ideas were removed from the MVP because they could not yet be operated and verified at the same standard as the core experience.

ParlAI now does one narrower job: conversational analysis of goals in three competitions.

Reducing the scope made the product more reliable and made every remaining claim defensible.

Where it stands

ParlAI is live on Google Cloud as a working subscription product.

Its autonomous pipeline prepares match dossiers, its engine produces auditable conclusions, and its Gemini Copilot turns those conclusions into an interactive Spanish-language analysis. When a dossier does not yet exist, the system can construct it on demand.

The project does not claim that sports are perfectly predictable. It demonstrates something more practical: AI can turn scattered information into an autonomous and explainable workflow while preserving mathematical controls and acknowledging uncertainty.

ParlAI began as a way to find the right prediction.

It became a system designed to know when the evidence is strong, when it is weak and when the most intelligent answer is no.

Built With

Share this project:

Updates