Across this series one theme keeps surfacing, and it’s worth stating plainly as the finish: the model is the least defensible component in your system. Anyone can call the same API you call. The moat — the part that can’t be copied — is everything the model helped you produce once and that code has executed ever since: the library of format families, the entity-resolution graph, the confirmed-rule library, the evidence chain. Every one of those is an artifact, not a weight. Which is why the biggest architectural mistakes are the ones that pour effort into the model and neglect the artifacts. Here are four not to make.

Don’t build a single general agent with broad tool access
One capable agent with a wide toolset demos better than four narrow ones — it feels more intelligent, more flexible, more “AGI-adjacent.” And it cannot survive a compliance review or a replay request. When any run can reach any tool, you can’t reason about blast radius, you can’t scope capabilities per task, and “what could this agent have done here” has no bounded answer. Four narrow agents, each holding only the capabilities its job needs, are less impressive in a demo and vastly more defensible in production. Narrowness is a feature.
Don’t put a chat interface over a workflow that’s better as a queue
Conversation is the default AI interface now, so teams reach for it reflexively. But an ops reviewer working through a queue of exceptions doesn’t want a conversation — they want keyboard-driven, single-key actions over a tight list. Chat is the right surface when the task is genuinely open-ended dialogue. It’s the wrong surface for high-volume, structured review, where it just adds friction between the person and the decision. Match the interface to the work, not to the trend.
Don’t fine-tune early
Fine-tuning feels like the serious, differentiated move, and early on it’s almost always a distraction. Your data advantage is the artifact libraries — the format families, the entity graph, the confirmed rules — not the model weights. Those compound from day one and belong to you regardless of which model you call. Fine-tune only when a narrow, stable, high-volume task has genuinely plateaued on prompting — and expect that to be a year out, if it ever arrives. Weights you fine-tuned this quarter are stale next quarter; the artifact libraries only get more valuable.
Don’t run retrieval over everything
A general index across all of a tenant’s data feels powerful and is a leak waiting for the right question. Retrieval should be scoped per task and per party — the agent working on one party’s matter can retrieve only that party’s context, by construction. A broad cross-tenant index means the wrong prompt can surface data that should never have been in reach, and you’ve built the cross-tenant leak yourself and handed out the query box. Scope retrieval like you scope tools: to exactly what the task needs and nothing more.
The durable part
Pull the thread all the way through and it lands here. The model is a commodity you rent, swappable and copyable and slightly different every version. What you actually own — what compounds, what survives a model upgrade, what a competitor can’t reproduce by calling the same API — is the accumulated set of artifacts the model helped you build exactly once and that deterministic code has run ever since. Format families. An entity graph. A confirmed-rule library with a human name on every rule. An evidence chain you can replay. Architect so that every valuable thing your system knows is one of those artifacts, produced with the model’s help and then owned by your code — and you’ve built something that gets stronger as the models underneath it come and go.
Cheap to Be Wrong — a six-part series on agent architecture
- Put the Model Where Being Wrong Is Cheap
- Use the Model to Write the Parser, Not to Be the Parser
- Where the Model Is Genuinely Load-Bearing
- An Agent Is a State Machine, Not a Loop
- The Model Upgrade That Quietly Breaks You
- The Model Is the Least Defensible Part of Your Agent — you are here
Related: Agent Swarms Eating the Stack.





Leave a Reply