the battle of cannae — the Muse & the Machine
← back to blog
project spartacus

the battle of cannae.

why the obvious product is already surrounded — and where to stand instead.

jul 2026 11 min read

the pincer.

on the morning of August 2, 216 BC, near a ruined hilltop town in southern Italy called Cannae, a Roman army of some 80,000 men marched into the center of a smaller Carthaginian line and pushed.

the center gave way. it bent backward, slowly, exactly as Hannibal meant it to. while the Romans leaned into that yielding middle, the Carthaginian cavalry swept the wings and the African infantry folded in from both flanks. by afternoon, the largest army Rome had ever fielded was surrounded on every side, pressed so tightly that its soldiers couldn't even raise their swords. fifty thousand men died on that ground in a single day (some estimates put it at 70,000). two millennia later, the battle was still required study for the German general staff, and it's still taught at West Point, for one reason: it is the cleanest double envelopment in the history of war.

the trap was never the strong center. it was the two flanks closing in at once.

I've been thinking about Cannae because of a small agentic experiment I'm running — one that listens to what software developers are begging for, the loud, repeated, budgeted pain on GitHub, and then checks it against what already ships. two weeks running, it has handed me the same smackdown that Hannibal delivered to the Romans.

· · ·

week one. the loudest, most repeated cry in the data was about the seam between an AI agent and everything it talks to: the model providers, the tools. eight separate bug reports, one fault line. a representative one, filed on OpenAI's own Codex tracker: an agent's login breaks and the whole run dies on NoneType object is not iterable, 59 developers piling on. another, from the OpenCode project: a model stream "freezes in working state, high CPU, idle socket" — the connection is alive, the machine is burning electricity, and nothing comes out the other end. these aren't feature requests. they're production outages, filed by people paying for the downtime in real money. on demand alone, the verdict writes itself: build it.

a few weeks ago, I argued that this reliability layer was the real frontier in agentic AI. then I ran the supply check on my own thesis. the broad version of that product — a reliability gateway that fails over between providers, governs your tool calls, caps your spend — already exists three times over. Portkey ships it as open source, routes more than 1,600 models, and was acquired outright by Palo Alto Networks this past May. Databricks ships the same control plane from above, as a feature of its platform. and a project called Bifrost gives the whole thing away free, in Go.

above you, a platform. beside you, a rival now inside a security giant. below you, free open source. the center you wanted to hold was already a kill box.

undaunted, I soldier on.

· · ·

week two. different pain, same shape. this time, the clearest gap the platforms can't close was reliability for self-hosted, local models — the teams who, for privacy or cost or an air gap, can't push their code through OpenAI's cloud and need a capable agent running on their own hardware. this time, there seems to be a real buyer, a real reason to pay, and better still, a gap the cloud vendors are structurally conflicted against fixing, because they'd rather that you stayed on the cloud. once again, on demand alone, the verdict writes itself: build it.

but the supply check handed me the same story, again. LiteLLM — funded, open source — already translates tool calls to any provider, local models included. the model runtimes themselves, llama.cpp and Ollama, are baking tool-call reliability in at the grammar level; Unsloth publishes a free guide that makes a local model call tools "as reliable as GPT." and the actual product — the self-hosted coding agent — already exists as Tabby and as Continue: single-binary, air-gapped, and ready to point at any model. last week, the flanks engulfing me were a platform and a funded company. this week they were: free, free, and free. same envelopment, run entirely from below.

two weeks, two standout opportunities, two verdicts: don't jump in. not because the demand was fake — the actual demand was the realest thing in the data — but because the demand was loud, and loud is precisely the signal that tells everyone else (the platforms, the funded incumbents, and the free open-source projects) to show up. by the time a thousand developers have filed the same bug, the gateway companies have read it too, and some unpaid stranger has already given the commodity version away to pad a résumé.

"free ate it first" is half of it. the fuller truth is the pincer: in the agentic era, the middle gets taken from above and below at the same time.

the broad, obvious, well-supported product is eerily reminiscent of the Roman center at Cannae. the strongest-looking ground on the field, and the first to be surrounded and swallowed whole by the crafty ones who happen to try Hannibal's brilliant strategy from 200 years before Christ.

· · ·

so where do you stand, if not the center?

at Cannae, the only Romans who lived were the ones who quit pushing forward and cut their way out the side — a few thousand who found a thin spot on the flank and broke through it while everyone else pressed deeper into the trap and got crushed. the equivalent in the data was consistent, and quiet. both weeks, the one slice nobody had taken was the same shape: not a product, but a dataset that compounds from a workflow no one is loudly asking for. week one, it was the failure that never trips an alarm — not the provider going down, which everyone handles, but the quieter way a run can stall while every dashboard still reads green — and a private record of every way that failure mode reveals itself. week two, it was whether your model, on your hardware, against your private tools, still behaves after you change anything — a history only you accumulate, that no free tool monitors on your behalf.

neither of those is particularly loud. neither will ever trend on GitHub. that's the whole point.

the defensible ground in a commoditizing market is never the thing a thousand people are shouting for. that ground is already encircled, better-capitalized players closing in from one flank and free open source from the other.

it's the unglamorous workflow that quietly piles up data only you possess. it's the vertical so narrow that the giants won't stoop to claim it, and the audience you've built so that when you finally ship, they hear it from you first. this, I believe, is where trust and relationships — the things that take time and attention, and that AI cannot do for you — matter most. you can't beat a free offering on plumbing. but if you build on top of that free offering, maybe you can go somewhere that the free offerings can't afford to follow.

· · ·

here's the move you can run tonight, before you build anything. take your idea and run two searches. first: what are builders actually begging for, in their own words, with the reactions to prove it? second — the one most builders skip: what already ships against it, including the free thing some stranger released last month? if both come back crowded, you haven't found a company. you've found a blog article or a podcast episode. (here I am, writing the one you're reading.) the second search costs you an afternoon. it can save you the six months you were about to spend marching into the center — the center of your own personal Battle of Cannae.

if this landed, the newsletter goes out twice a week — news, tools, and field notes from the same studio.

subscribe → more essays →