Anyone Can Rent the Same Model. Almost No One Builds the Same Harness.

You don't really "build an agent." You build a little company made mostly of plain software, and you drop the AI in at the handful of spots where a judgment call actually beats a hard rule. That's it. The model is one hire, not the whole org.

That's the thread running under the agent conversation on X right now. Past the demos and the dunking, the same realization keeps showing up from every direction: the magic was never the model. It's everything you build around it.

Three things shifted this year: we stopped obsessing over how to word the prompt and started obsessing over what we put in front of the model -- which facts, in what order, at what moment. We stopped reaching for whole armies of agents and went back to one sharp agent with good tools, because a swarm looks amazing on stage and quietly burns something like 15x the compute, then breaks in ways nobody can trace. And we stopped chasing a slightly better model and started building a better harness around it -- the loop, the tools, the memory, the guardrails, the tests.

That last word is the one to keep: harness. It's everything wrapped around the model that makes it actually reliable.

Here's the working framework I built from my own surfing of "agent design" these last few weeks, as we optimize what we've built and build better now. Ten principles that hold up while a lot of flashier ideas don't, grouped into five clusters. I'll keep it plain.

1. What an agent actually is

An agent is mostly software. The good ones aren't "write a clever prompt, hand it some tools, and let it loop until it figures things out." They're mostly normal, predictable code, with the model called in only at the moments that genuinely need judgment. Own that flow yourself. Don't hand the steering wheel to a framework you can't see inside.

Keep it simple. Add complexity only when it earns its place. Most agent disasters are just over-building. Start with the dumbest thing that could possibly work, keep what it's doing easy to follow, and add moving parts only when the problem forces your hand -- not because something felt more sophisticated.

2. Context is the product

What you feed it beats how you word it. Less about phrasing, more about what's loaded in front of the model and when. Treat that context like real infrastructure -- curated, kept clean, version-controlled -- not a text file you fiddle with. Good, structured knowledge is exactly what makes the output feel specific instead of generic, and it compounds the longer you invest in it.

Mind the "dumb zone." Cram too much into the model's working memory and it gets foggy, even when there's technically room left. People call it context rot, and it's a slow fade, not a hard cliff. So put your best material at the very top or the very bottom, never buried in the middle, and clear out whatever it no longer needs.

Don't dump everything up front. Let the agent see a quick menu of what's available, then pull the full details only when a task actually calls for them. Think of a great onboarding doc -- index first, deep dives on demand. Keeps the agent lean and sharp instead of drowning in stuff it isn't using.

3. How the agent touches the world

Tools are the interface -- few, sharp, obvious. An agent is only as good as what it can actually do -- send the email, pull the record, run the report -- and how clearly it understands its options. Build a small set of sharp, well-labeled tools instead of a junk drawer of vague ones, and test them like you'd test any real software. A handful of excellent tools beats a pile of mediocre ones every time.

Let it pause and pick back up. A good agent can stop mid-job -- to wait on a human's approval, or on something it depends on -- and resume cleanly without losing the thread. Build it like a clean handoff. And let people kick it off from wherever they already are: Slack, email, a button somewhere. Don't make them learn a new place to find it.

4. One agent, or a team of them

Start with one. One good agent with good tools is still the right place to begin. The "team of agents" thing is wildly oversold -- it demos great, costs a fortune in compute (upwards of 15x or more), and fails in ways nobody can untangle. Only split into more when the pieces are genuinely separate jobs that need different tools, different context, or a real wall between them.

When you do split, go small and narrow. Don't build one giant know-it-all. Use a lead that coordinates a few narrow specialists, each handed a clean slate and reporting back a tight summary instead of its whole messy transcript. Narrow scope is what keeps each one reliable. (Sound like any agency you know?)

5. Trust: people and proof

Build in the human, and actually test the thing. Two steps everyone skips. First, make "check with a human" a real, built-in step -- an approve-or-edit gate, sized to how much is at stake. Second, test it honestly: keep a set of your real past failures, run the agent against them, and catch it before it quietly backslides. Boring work? Yes. It's also the whole difference between a slick demo and something you'd put in front of a client.

What actually changed this year

Zoom out and the center of gravity moved three times. From wording the prompt to loading the right context. From more agents to fewer, sharper ones. From picking the model to building the harness around it. None of those are small tweaks -- they're a different way of thinking about the whole problem.

What's still up for grabs

I'm not going to pretend this is settled, because it isn't. Three honest open questions: how foggy is too foggy -- exactly where the model starts losing the plot as you fill its memory. How much to hard-wire versus how much to let the model decide for itself. And the nerdiest one: the best way to plug new abilities into an agent, where a few competing standards are fighting it out and the answer's shaping up to be "use all of them, for different jobs" rather than one winner. Treat these as tensions to hold, not answers to sit around and wait for.

Why this lights me up

Because every one of those moves is just... how a good agency already works. Narrow roles. The right tools for each person. A clean handoff. A tight summary back instead of the whole mess. The org is the architecture.

At Sageworx, the agency is already the shape of the system. Every person is a specialist with a clear lane, the right tools, and a clean handoff. Our shared knowledge base is our version of "feeding it the right context" -- structured, looked after, compounding -- and it's the part nobody can just rent. The hard part we're still building, the part almost no one has, is the harness and the testing around all of it.

The teams who win the next year won't have the biggest model. They'll have built the best harness around it -- and that's a craft, not a download.