If you are building an LLM agent right now, you are almost certainly wasting 80% of your effort.

Everyone is arguing about reasoning loops, ReAct variants, reflection steps, multi-agent debates. None of that moves the needle on production reliability or cost. All the hard, boring, actually important work is happening somewhere else.

Over the last two weeks twelve new agent papers, frameworks and production deployments dropped. None of the popular narratives survived contact with real measurements. This is what actually works.

The redundancy crisis no one talks about

Every production agent today wastes 90% of the tokens it uses. Not by accident. By design.

All standard agent policies follow a maximum context strategy. When asked to make a one line change to a file, they will re-read the entire repository, pull all dependencies, re-verify every assumption, and run a full audit before making the edit. They do this even if they already saw all that information ten seconds earlier.

No human engineer works this way. No one would pay an engineer that worked this way.

This is not a model flaw. This is an architecture flaw. No existing agent framework implements even the most basic capability: estimating how hard a task actually is before starting work.

E3 changes everything

Last week researchers published E3: Estimate, Execute, Expand. It is the single most important agent architecture advance in the last 12 months.

The mechanism is embarrassingly simple:

1. First estimate the minimum scope required to complete the task
2. Execute only that minimum path
3. Verify the result. Only if verification fails, expand scope and try again.

That's it. No new models. No fancy reasoning. Just stop doing unnecessary work.

The results are not marginal. They are transformative.

Metric	Standard Agent	E3 Agent	Improvement
Task Success Rate	100%	100%	0%
Total Cost	1.00	0.15	85% reduction
Total Tokens Used	1.00	0.09	91% reduction
Files Inspected	1.00	0.08	92% reduction

This was run on MSE-Bench, a deterministic benchmark of 121 code edit tasks. E3 matched the baseline perfect success rate while cutting almost all cost. This is not a tradeoff. It is strictly better in every dimension.

The effect held up on real GPT-4o agents editing live open source repositories. The only failure mode was OpenAI rate limits, not bad edits.

No one is talking about this paper. Everyone will copy this pattern by the end of the year.

GRPO does not make your agent smarter. Stop using it.

Everyone is fine tuning agents with GRPO right now. It does not work.

A controlled study ran 18 separate GRPO training runs across 4B and 8B parameter web agents, varying every hyperparameter. No configuration produced a credible improvement over the base supervised checkpoint. On the text track, moderate and high learning rates made the agent reliably worse.

GRPO only improves performance in one case: when the greedy supervised policy already fails most of the time, and random sampling sometimes succeeds. If your agent already gets 70%+ success rate, GRPO will not help you. It will either do nothing, or break it.

This is an extremely underappreciated result. Almost every major agent team is currently burning GPU hours on GRPO fine tunes that will never deliver gains.

The interface is state, not an API

If you expose an RPC API to your agent, you have already lost.

The single best design insight from the last month came from FableCut, the open source video editor built for agents. They did not build an API. They made the entire project state one plain JSON file.

Anything that can write JSON can edit the timeline. The UI reads it. The agent writes it. Human and agent can edit concurrently. The entire concurrency model is one integer revision counter. No CRDTs. No operational transforms. No locks.

This pattern works for agents because agents are terrible at calling APIs correctly. They are extremely good at modifying structured documents.

Every time you build an add_clip() method, you are forcing the agent to translate its intent into your interface vocabulary. When you give it a document to modify, you let it work the way it already thinks.

The Shippy maritime agent team learned exactly the same lesson. They stopped letting the agent construct raw API calls. They built a minimal deterministic CLI, and the agent only ever runs typed commands. Each layer narrows what the agent can get wrong.

Model routing is a systems problem, not an ML problem

Everyone builds model routers that estimate task difficulty and send hard tasks to big models. This does not work.

IBM Research ran 417 agent tasks across GPT-4.1 and Claude Sonnet. On sticker price GPT-4.1 should have been half the cost. In practice it was almost double.

The difference was cache. Agent workloads reuse enormous amounts of context across steps. Sonnet had much lower cache read pricing, and that single factor overwhelmed every other difference.

A router that only looks at model pricing sheets is optimizing against fictional numbers. Actual cost depends on cache hit rates, endpoint load, warm start status, trajectory length, and retry rates. None of these have anything to do with the model's capability.

Good routers do not classify tasks. They optimize the entire system.

Production agent architecture patterns that actually work

These are the patterns that every successful production agent deployment is using right now, and that no framework will tell you:

1. Never let the agent modify state directly. Always write the intended change first, verify it, then apply it.
2. All tool output must be deterministic. No side effects, no hidden state, no variable formatting.
3. Isolate every user session completely. Agents leak state. Plan for this.
4. Do not evaluate the model. Evaluate the entire agent. Model benchmarks tell you nothing about production behavior.
5. Guardrails go in the tools, not the system prompt. The model will ignore system prompts. It cannot bypass tool boundaries.
6. If you can avoid agentic loop steps, avoid them. Every additional turn introduces another failure opportunity.

What we still don't know

We still have almost no good answers for very basic questions:

• Why do induced emotions change agent exploration behavior? We know anger reduces exploration and makes agents ignore penalties. We have no idea why.
• How do you reliably audit agent reasoning? The TRACE schema is the first serious attempt at this, but it is still untested at scale.
• When should an agent stop? We still have no general termination condition that works reliably across domains.
• How do you merge concurrent edits from human and agent? The FableCut revision counter works for coarse rare edits. It will break for fast fine grained changes.

The next 12 months

Almost everything you see about agents right now is noise. Over the next year all of the following will happen:

• Every major agent framework will implement some variant of E3 minimum execution.
• GRPO will fall out of favor for production agent fine tuning.
• State document interfaces will replace RPC APIs as the standard agent integration pattern.
• No one will care about multi-agent debates.

The agent gold rush is over. The era of actually building working systems has just started.