Why I’m Building Agent Model Fit

I have enough projects now that figuring out how they work together has become another project.

There’s the NFL prediction system. There’s this blog. There’s the work of building websites, maintaining them, and using agents to help with all of it. Each has its own files and decisions, but the connections are where things get interesting. The NFL project generates data I can write about. A website change becomes a development story. Working with agents raises questions that follow me from one repository to the next.

Agentic development has become a project of its own.

That’s why I’m building Agent Model Fit, a publication about matching agents and models to real work. I want a place to examine those decisions carefully enough that someone else can learn from them.

Agent Model Fit’s homepage, captured September 26, 2026.

Start with the work

The tagline is “Right agent. Right model. Right problem.” The problem is where I want to start.

“Which model should I use?” needs more context before it becomes a useful question. What are we trying to accomplish? What information is available? What tools can the agent use? How will we check the result? What happens if it gets something wrong?

Consider two ordinary development tasks. One updates a known field across a handful of files. The other investigates why a feature works locally but fails somewhere else. Both involve code. The first has a clear transformation; the second requires collecting evidence and testing explanations.

That difference changes the assignment before we’ve even chosen a model.

I want Agent Model Fit to make those choices easier to examine. A useful comparison should explain the task, what the model could access, what counted as success, and how much checking or correction the result needed. Otherwise, it’s hard to know whether someone else’s result applies to your situation.

The first answer is only part of the job

Imagine an agent produces a draft in a minute, then a person spends an hour finding unsupported claims. Timing the first response would tell a very incomplete story.

The review matters. So do repairs, missing information, and decisions that still need a person. That’s the kind of work I want to account for when thinking about whether an agent is useful.

An assignment also needs a finish line. “Improve the site” can keep expanding. “Make this change, check these things, and bring back the result for review” gives everyone something more concrete to work with.

Those are practical questions I can carry into my own projects. They also give the publication a direction: explain the work well enough that a reader can decide what to try and how to judge it.

Building the publication is part of the material

Agents help build Agent Model Fit itself. The project uses written assignments, versioned files, reviewable changes, and records of what was checked. That gives us real decisions to inspect, including the small, unglamorous ones.

The retrospective about building Agent Model Fit describes a useful example. Review caught confusing setup guidance and a stale next step in the documentation. The fixes were small, but the next person—or agent—would have been working from those instructions.

A project can have working code and misleading context at the same time.

That is especially relevant when the work stretches across multiple projects and conversations. Another session needs to find the current source, understand what changed, and see which decisions remain open. The context has to survive beyond the chat that produced it.

The retrospective is also clear about its limits. It documents decisions and corrections from one build. It doesn’t establish a productivity gain or prove that one model is better than another. A measured comparison would need evidence designed to answer that question.

I want to keep that distinction visible as the publication grows. An observed result, a proposed approach, and an open question can all be useful. Readers should be able to tell which one they’re looking at.

Where it fits with this blog

Agent Model Fit has its own focus: helping digital and IT leaders reason through where AI belongs in their work. Here, I can write more personally about what I’m building and how the projects connect.

The NFL work can generate a story for this blog. A development problem can lead to a question for Agent Model Fit. A lesson from either project can change how I organize the next assignment.

That connection is what I’m trying to make more deliberate. The projects can stay independent while contributing to the same body of work.

If you’re curious, take a look at Agent Model Fit. The question I want to keep returning to is concrete: given this task, this evidence, and this way of checking the result, what would make an agent a good fit?