AI Build vs Buy: A Repeatable Way to Decide Fine-Tune vs Agents

The build vs buy question everyone asks the wrong way

If you advise or oversee several teams, you have heard the same request four times this quarter: "we want to build AI." The build versus buy answer that holds up is not a preference, it is a rule you can rerun on each team until the wrong options eliminate themselves. Most of the time the honest verdict is "buy the frontier model and prompt it," sometimes it is "build an agent," occasionally it is "fine-tune," and more often than anyone likes to admit it is "not yet." A framework gives you all four, and the same framework works on the next team next month.

That is the whole promise of a repeatable instrument, so we built one. Our fine-tune vs agents decision framework runs the rule and a sourced cost model on any team's numbers, and it hands you a verdict you can put in front of a founder or a CFO.

The four paths, and which are build versus buy

"Build versus buy" is really a four-way choice, and only two of the four are builds.

The column that decides most cases is the second one, so here is the line that settles it.

The one rule that eliminates most options

A fine-tuned model cannot call your tools or hold state on its own, so if the work has to act in your systems, fine-tuning is off the table and you are choosing between an agent now or prompting until the volume justifies more.

This single distinction resolves the majority of build versus buy debates before anyone opens a cost model. If a client's use case is "answer questions using our knowledge in our voice," that is buy and prompt, and the build instinct is expensive theater. If it is "read the record, take the action, update the system," that is an agent, and no amount of fine-tuning gets you there. Naming that early saves a portfolio team a quarter of wandering.

"The most valuable thing a decision framework does is tell a team not to build. A rule you can rerun every quarter, one that sometimes says wait, is worth more than any single answer, because it is the only kind that survives contact with a CFO."

Anmol Parimoo, founder of MLDeep

The MLDeep Fine-Tune vs Agents Framework, applied per team

You do not want a different mental model for each client. You want one rubric you trust and rerun. The MLDeep Fine-Tune vs Agents Framework is ten gates that eliminate the wrong tools in order; four of them decide most cases, and you can walk them in a fifteen-minute call.

1. Value gate. Is the task well-defined and high-value enough to justify any build? If no, the answer is buy-and-prompt or "not yet."
2. Action gate. Does it need to call APIs, mutate records, or hold state across steps? If yes, it is an agent, and fine-tuning alone is ruled out.
3. Volume gate. Is it narrow, high-volume, and stable enough that a cheaper fine-tuned model would pay for itself? If yes, fine-tuning earns a place, often as the distilled hot path of an agent that already works.
4. Knowledge gate. Is it mostly lookup in the client's voice? Then buy, prompt, and retrieve, and defer everything heavier.

The full ten-gate version, with the accuracy and error-cost gates that decide the close calls, and the interactive calculator behind it, live in the framework on the hub. There is a one-page PDF you can send a client as a leave-behind, no login and no gate.

What fine-tuning is genuinely good for

Buy-first does not mean never build, and it does not mean never fine-tune. Fine-tuning is the right tool for a narrow set of jobs: a high-volume, stable task where a small fine-tuned model matches a frontier model at a fraction of the cost; a strict output format the base model keeps missing; a domain vocabulary generic models fumble; and distillation, where you run an agent to prove a workflow and then train a small model on its successful traces to cut cost at scale. The pattern is always high volume, narrow scope, no tool calls. Advise fine-tuning there, and nowhere a task has to act in the client's systems.

A defensible TCO model you can put in front of a CFO

The reason build versus buy stalls is that nobody has a cost of ownership number anyone believes. So we made the TCO the output. Feed a team's volume, capability, and labeled-data reality into the model and it returns a 24-month total for each path, with a mid number to anchor on and honest bands around it. Two disciplines make it CFO-grade. First, we lead with the mid, because the low endpoint takes the optimistic end of twenty variables at once and never happens in reality. Second, every cost input is built on dated, published pricing from named vendors, Anthropic, OpenAI, RunPod, and Together AI, each linked with the date we read it, priced at current 2026 rates, so a finance partner can verify the numbers in the assumptions table instead of taking them on faith. That sourcing is the difference between a number a CFO signs off and a number a CFO laughs out of the room.

Applying it to one team, end to end

Take a representative portfolio team, not a specific client: a Series A running roughly 8,000 support-and-ops tasks a month where the workflow has to look up an account and update a record. The action gate fires immediately, so fine-tuning is out and the real choice is an agent now versus prompting until the volume justifies more. The calculator returns a mid 24-month total, a band, and a payback month you can defend. Drop the volume to 800 tasks a month and the same rule often returns "not yet," and you can hand the founder a worksheet instead of a build. That is the reuse you want: identical rubric, opposite verdicts, both defensible, and neither one requiring you to relitigate the whole question from scratch.

Why we can stand behind the verdict

We build these systems, we do not just diagram them. We ship fixed-scope work fast, a Series A client had three hours a week of Monday reporting automated in five days, and we are a dbt Labs certified partner working in a real production stack. As much as it costs us, our honest-fit rule is that we open every engagement with a fifteen-minute call and will say no when building is the wrong move. A framework whose author profits only when you build is not a framework; it is a pitch. This one has a verdict that tells teams to wait, and we mean it.

If you want a verdict on a specific team's stack before they commit engineering time, our AI Stack Audit gives a clear build, buy, or wait read with a 90-day roadmap, and it pairs naturally with the broader build vs buy data infrastructure decision your teams face underneath the AI question.

Frequently asked questions

When should a startup build AI versus buy?

Buy and prompt a frontier model by default, because it is faster and cheaper and covers most knowledge and drafting work. Build only when a well-defined, high-value task clears the first gate, and build an agent specifically when the task has to act in your systems, since a bought model with prompting cannot take actions safely at scale. Fine-tune only for narrow, high-volume, stable tasks. And keep "not yet" on the table: for many early teams the honest answer is to wait until volume justifies the investment.

Is there a defensible TCO model for fine-tune versus agents?

Yes, if it does two things: leads with a mid number rather than a fantasy low that assumes every variable lands at its best value at once, and sources every cost input to dated, named vendor pricing a CFO can verify. Our model computes a 24-month total for each path on your inputs, with honest bands and linked sources, so the output is a number finance can sign off rather than a marketing figure. Run your team's scenario in the calculator to see the crossover for yourself.

How do I make this decision consistently across several teams?

Use one rubric and rerun it, rather than reasoning from scratch each time. Walk the same gates in the same order for every team, value, action, volume, knowledge, and let the wrong tools eliminate themselves. Because the rule is fixed and only the inputs change, the verdicts stay comparable across your portfolio, and you can defend why one team is building an agent while another is told to wait. That consistency is what turns a decision into a framework you can delegate and reuse.