The model half improves on its own. The other half is yours.

Agentic AI splits into two halves. One is model capability, which improves on its own, arrives for free, and requires nothing from you. The other is routing, fallbacks, observability and cost control, and nobody ships that to you on a Tuesday.

The second half is where the operational wins still are. If the only decision you have made is which model to use, you have skipped the harder half.

Most agentic platforms hand you a chat box and a promise that the agent will work it out. In practice agents stall, hit blockers, announce completion they have not earned, and give you no view of what happened behind the curtain. You ask for a report. Something comes back. Eventually. Possibly. With no way to tell what was attempted or whether the thing you asked for was actually done.

Building OpenRed on the opposite bet, that agents are workers and the pipeline is the system, produced four lessons that had nothing to do with model choice.

Structure beats trust

A single agent handed a complex task fails in ways you cannot predict. It loses track of subgoals. It declares victory early. It produces output that looks convincing and does not do what was asked.

The fix is structural rather than model-shaped. Every job runs through a defined pipeline of named roles: a worker that does the legwork, an analyst that validates, a delivery role that formats and packages. An orchestrator plans the work, evaluates each phase against the original ask, and decides whether to advance, retry, or escalate to a person.

The point is that you never have to trust any individual agent to get it right. Failures get caught at phase boundaries. Every step is visible and every artifact is inspectable, so when something stalls the operator can see exactly where, with the actual prompts and responses in the log.

Agents are smart enough to do the work. They are not smart enough to manage themselves end to end. The pipeline does the managing.

It is a routing problem, not a model problem

I had one backend handling everything: parsing "schedule this for Tuesdays" into a cron expression, classifying which pipeline to fire, and running long multi-step research with tool use.

The first two are two-second classification calls. The third can run for two minutes with web searches and file operations. Making a heavyweight agent answer a simple "which of these three" question means paying heavyweight cost and latency for a featherweight answer.

Splitting it into a lightweight classifier for short verdicts and a full agent for substantive work made both paths faster and cheaper. Nothing about the models changed.

Old-school heuristics still earn their keep

Detecting when an agent has finished a long-running task looks like an AI problem, and the naive move is to ask another model: look at this state, is the work done? That works, and costs about five cents a check.

The other direction is simple pattern matching on the agent's own activity signals, the markers it emits while busy versus idle. The model call becomes the fallback for genuinely ambiguous cases rather than the primary path.

Reserving the expensive call for the moments deterministic checks cannot handle cut average per-request cost by roughly ten times. The old way of programming, patterns and state machines and signals, pairs extremely well with the new way. Use both.

The cleverest thing I built, I deleted

I built an elaborate session-reuse system to amortise a 25,000-token system-prompt overhead across multiple calls. Then I A/B tested it.

The provider's prompt cache hits on prefix content regardless of session identity, so two completely independent calls inside the cache window already got the benefit for free. The optimisation I had carefully built was buying something I already had.

I deleted it. The simpler design had been correct the whole time.

When your semantics are stateless, write stateless code. The platform you are building on has probably already solved the thing you are about to bolt on, and the only way to find out is to measure rather than assume.

The pattern in all four

None of these were model problems, and none of them were solved by a better prompt. They were solved by structure, by routing, by refusing to ask a model something a regular expression could answer, and by deleting code that was defending against a problem that no longer existed.

That is the half that does not improve while you sleep. It is also the half that decides whether the thing works in production.