In our last article we walked through the data foundation underneath Ask OddMan: why we started with nflverse, how we mapped the ontology before trusting it, and how that work is becoming a real knowledge graph. This note is about what sits on top of that foundation: the agentic harness that actually does the thinking, and the guardrails we're building around it.

We’re building Ask OddMan as a multi-agent system, not a single model answering questions. The distinction sounds subtle but it changes almost everything about how the product is structured underneath.

We're currently working through a few core capabilities that make up the harness:

Agentic orchestration

This is the coordination layer, the part responsible for planning and routing tasks across our internal fleet of agents rather than asking one model to do everything at once.

A question about a player's usage trend and a question that requires pulling a chart, checking a narrative, and cross-referencing an injury report are different shapes of work. We also believe they deserve different handling rather than one model trying to be good at all of it simultaneously.

Data sources

This is the connective tissue between the harness and everything we described in Part 1: querying into our data warehouse, connecting out to third-party APIs, and running retrieval and vector search over both narrative content and memory.

This is also where the knowledge graph gets used in practice, not just stored.

Skill builder

We're composing workflows as structured files, markdown documents that define a skill, the tools it can call, and the connections it needs, rather than hardcoding every capability into the agent logic directly.

We like this approach because it means teaching Ask OddMan something new looks more like writing a document than shipping a new build.

The model

Given that we are a start up and that speed to market is what we are up against, we have decided to use an LLM for many reasons to begin with. Let’s breakdown the thinking behind that choice.

We’re building instrumentation into the harness itself to understand volume, cost, and token spend broken down by which skill is actually being executed, not just an aggregate bill at the end of the month.

We believe that's the only honest way to know what a system like this really costs to run at scale, skill by skill rather than as one number.

Once we see that volume cross a real cost threshold, we intend to use what we've learned from that instrumentation to start building and fine-tuning our own language models for the specific skills where it makes sense, rather than staying dependent on general-purpose models for everything indefinitely.

Right now we're still gathering the data that will tell us when we should be.

There's a version of Ask OddMan that only ever repackages numbers other people already published, and we don't think that's interesting enough on its own.

Alongside the harness work, we're currently building our own machine learning models to produce original stats and insights for the NFL, not just retrieve and narrate the ones that already exist across nflverse or anywhere else.

The part we care about most is what happens after a model produces something new.

We're not treating an original stat as a one-off output that lives in a chart and then disappears. We're feeding it back into the knowledge graph itself, as a real node connected to the players, teams, and games it describes, the same way everything else in that graph is connected.

That means a proprietary insight we generate isn't sitting off to the side as a separate feature. It becomes part of the same structure Ask OddMan is already traversing, available to inform the next question a user asks, not just the one that prompted it.

We're early in this, and we're being careful not to call something a "stat" until we trust the model behind it the same way we came to trust the ontology work in Part 1.

But this is the direction we're building toward: an Ask OddMan that doesn't just know what's already been said about a player, but is starting to say some genuinely new things of its own.

We think a lot about what "memory" should mean for a research partner, because the word gets used loosely.

For us it's a few distinct layers working together, not one big undifferentiated context blob:

• Thread sessions

  Thread sessions hold the immediate back and forth of a single conversation.

• Projects

  Carries context forward across an entire body of work, the way a real project should, so a session doesn't start from zero every time.

• Tools

  This lets the agent reach out and get fresh information rather than relying only on what it remembers.

• The way you view sports

  Learn how a given user tends to think and what they tend to care about, so the system gets more useful to that specific person over time rather than staying generic.

We believe this layered approach is closer to how an actual research relationship works. You don’t re-explain your point of view to a colleague every morning, and we don’t think you should have to re-explain it to Ask OddMan either.

We’re building this with governance in mind from the start, not bolting it on after the fact.

A system that can plan, route tasks across agents, query a live data warehouse, and remember things about a user is a system that needs real boundaries, not just capability.

We don't have a polished answer to give you here yet, because we're still building it. But we wanted to say plainly that we're thinking about it now, at this stage, rather than treating it as a problem for later.

That's consistent with how we think about everything else on OddMan: the tools should give Independent Creators real leverage, and the leverage has to come with protection built in, not around.

We're not finished. Most of what we described across these two articles is still being built, tested, and rebuilt as we learn where our own assumptions were wrong. That's the actual shape of this right now, and we'd rather tell you that than pretend otherwise.

We'll keep sharing this as we go.

We’re going to spend the next two articles walking through how we’re building Ask OddMan, our AI research partner grounded in live sports data. Not the finished-product version. The actual version, mid-build, with the decisions we made and why we made them.

We wanted to start with data, because everything else depends on getting this part right. An AI research partner is only as trustworthy as what it's standing on, and before we wrote a single line of agent logic, we spent real time just trying to understand the shape of the world we were about to model.

We’re currently building against nflverse as our primary NFL data source, and we picked it deliberately rather than defaulting to it.

The NFL doesn't run an open, self-serve developer program for its official statistical data. That data is licensed out through an exclusive partnership, currently held by Genius Sports, which covers real-time play-by-play and Next Gen Stats through the end of the 2027-28 season.

Gaining access as an outside company means entering into a formal licensing relationship, not just filling out a registration form.

We believe the right way to approach that kind of conversation is with a complete understanding of what we actually need, not a partial one.

Walking into a discussion with a league, a data partner, or a franchise before we know our own data requirements felt backwards to us. So we're building our foundation on nflverse first.

It's a community-maintained project, and the code itself is released under the MIT license. What mattered more to us was the data licensing underneath it: the majority of nflverse's datasets are published under CC-BY 4.0, meaning we can use them broadly as long as we attribute the source, with a narrower subset, the FTN charting data, carrying a CC-BY-SA 4.0 requirement instead.

That's a fundamentally different starting point than the NFL's own official data, which flows through an exclusive licensing partnership rather than an open, attributable license.

nflverse also happens to be the largest, most robust dataset available outside of the NFL's own systems, going back to 1999 for play-by-play.

We're using this phase to learn everything we can about the shape of football data, so that if and when we do sit down with a league, a data partner, or a team, we're bringing clarity instead of a wish list.

Twenty years of historical data is a lot to commit to a warehouse blind. Before we loaded any of it into our data warehouse, we pulled samples from every nflverse endpoint and started drafting the ontology underneath it.

Meaning, what a player object really is, how it relates to a team, a game, a play, or a season.

We used a free graph tool offered by Microsoft to actually visualize and draw those relationships before we committed to anything at scale.

Seeing the nodes and edges on the screen, rather than just imagining them from a schema doc, is what let us catch the relational gaps early.

A missing edge between two entities is easy to miss in a spec and very hard to miss when you're looking at the graph. We'd rather find that out with a sample than with twenty years of production data already sitting in the warehouse.

We're repeating this same process across the other major leagues we're bringing into OddMan. It's slower than just pulling everything in and sorting it out later, but we believe the upfront cost is worth it.

This is worth explaining, because it's easy to treat data cleanup as a chore that happens before the interesting work starts, and we don't see it that way.

An AI system like Ask OddMan doesn't reason about football in the abstract. It reasons about whatever structure we hand it, and if that structure is inconsistent the model doesn't know that. As an example, if a player object means something slightly different depending on which endpoint it came from, the model wouldn’t know. It just inherits the confusion and hands it back to the user with confidence.

Clean, well-related data isn't a nice-to-have ahead of the AI work. It's a direct input into whether Ask OddMan's answers are trustworthy at all.

We'd rather spend the time now finding the gaps than have Ask OddMan discover them later, in front of a user, as a wrong answer.

Here's where it stopped being a diagramming exercise and became infrastructure. The relationships we mapped, player to team, team to league, player to game, game to play, aren't just documentation now.

We're building them into our graph database, so that a league, a team, and a player exist as connected objects rather than rows that happen to share a foreign key.

That distinction matters more than it might sound like it does.

A relational table can tell you a player is on a roster. A graph can tell you how that player connects outward through every game, every transaction, and every teammate. It can also let something like Ask OddMan traverse those connections the way a person actually thinks about a storyline, not the way a database schema forces you to think about one.

Picture this. You’re asking Ask OddMan a question like "how has Patrick Mahomes' usage changed against teams that blitz heavily."

In a relational world, answering that well means writing a chain of joins across player tables, game tables, participation tables, and defensive scheme tables, and hoping the schema designer anticipated that exact question.

In the graph pictured above, Mahomes is a node, and the path outward is already there: from the player node to his participation records, from each participation record to the specific game it belongs to, from that game to the opposing team, and from that team to whatever defensive tendencies we've modeled as connected to it.

Ask OddMan doesn't need a query written in advance for that exact question. It walks the edges that already exist, the same way a scout would follow the thread from a player to a game to an opponent, and assembles the answer from real, connected structure instead of a query someone had to predict.

We're not saying every question resolves that cleanly today, as we're still early in this build.

But that's the shape of what the graph is for, and it's why we believe it's worth the extra investment over a purely relational approach.

We're still early in populating this graph fully, and we expect to keep finding gaps the same way the visualization tool helped us find them in the ontology phase. But the foundation is real, and it's the foundation everything else we're building on Ask OddMan sits on top of.

In the next article, we’ll get into the harness itself: how we’re coordinating multiple agents, how memory works across a session and across a project, and how we’re thinking about control as we hand more of this over to an agentic system.

We’ll keep sharing this as we go.