If you are building production agents right now, you already know this. All the twitter arguments about reasoning loops, tree search and reflection are irrelevant. 90% of your operational pain is not that the agent is not smart enough. It is that half your inference budget burns on trajectories that were doomed from the first step. That you run out of context window because you loaded 50 tool schemas you will never use. That three engineers on your team all had the same agent try the exact same failed approach yesterday, and none of them knew.

This month we got actual answers for all of these problems. No hype. No new 1T parameter model. Just boring, measurable, production ready work.

You are wasting half your inference budget on dead runs

This is the single most important agent paper released this year.

Doomed from the Start demonstrates something every operator has suspected for months: agents know they are going to fail long before they admit it. Lightweight linear probes run against the agent's hidden layer activations can predict final episode failure at the first interaction round with 85% accuracy. Behavioral scorers looking only at output text can barely beat chance at that point.

The authors built a calibrated abort cascade that gates every agent turn. You set a single global recall target: for example 90%, meaning you will incorrectly abort less than 10% of runs that would have eventually succeeded.

At that 90% target the cascade saves 47.1% of total inference compute for Qwen-2.5-7B, and 37.2% for Llama-3.2-3B. That is not a marginal improvement. That cuts your bill in half. No changes to the agent model. No fine tuning. Just probes running on the activations you already compute.

There is one brutal takeaway here. Everything you can observe about the agent's behavior is a lagging indicator. The failure decision has already been made inside the model layers three turns before you can see it in the output.

Stop arguing about tool layers. This is the tradeoff table.

Everyone has been debating MCP vs CLI vs Skills for three months. No one had put actual numbers to the tradeoffs until last week.

Layer	Context tax per tool	Execution latency	Security boundary	Governance	Operational visibility
Raw CLI	12 tokens	<10ms	None	None	None
Wrapped Skill	45 tokens	15ms	Sandboxed per skill	Explicit	Full audit
MCP Server	300 tokens	120ms	Per-server ACL	Centralized	Standard receipt

That 300 token number is not a mistake. Loading 55 MCP tool schemas permanently consumes 16,500 tokens of context on every single turn, whether you use any of them or not. That is a running tax you pay for discoverability.

There is no universal right answer. Use CLIs for read only operations you trust. Use Skills for repeatable internal workflows. Use MCP only for third party capabilities that mutate state or spend money.

The hybrid approach that almost everyone ends up running: wrap MCP tools inside lightweight skills. You get the security and governance of MCP, and you pay the context tax only when the agent actually selects that tool.

You do not need to fine tune models to train agents

SkillOpt dropped this month and it changes the entire post-training model.

You do not need to touch model weights. You do not need GPUs. You can train agent skills exactly like you train neural networks, with epochs, batches, validation gates and learning rates. The trainable parameter is just a markdown file.

SkillOpt runs rollouts, proposes only small bounded edits to the skill document, and accepts an edit only if it strictly improves performance on a held out validation set. No drift. No collapse. The output is a plain text file you can read, edit and audit.

Across all tested models this delivers ~+20 point accuracy improvements. It transfers across model families. It adds zero overhead at inference time.

This is the single most practical agent training method that exists today. Almost everyone building production agents will be running something like this by the end of the quarter.

Agents do not work well alone. They work even worse on private laptops.

The biggest unspoken problem with agent adoption right now is coordination. Every engineer on your team is running their own private agent session. They all retry the same failed approaches. They all rediscover the same workarounds. No one shares what worked.

Multiplayer agent sessions fix this. When every agent run is a shared cloud session anyone can join:

• Code review happens inside the full agent history, not just the final git diff
• Handoffs take zero time. No context is lost
• Failed attempts are visible to everyone, and no one wastes time repeating them
• Good patterns propagate across the team automatically

This is not an architecture problem. This is just a missing primitive. Right now every agent runtime is built like a terminal from 1980. They will be built like slack threads by next year.

The great software engineering conspiracy

There is a joke making the rounds this month that turns out to be completely true.

Every single best practice that makes agents work better is just good software engineering. Clean architecture. Tests. Up to date documentation. Idempotent operations. Observable systems.

For twenty years we could not get engineers to do these things by telling them it was good for the next hire. Now we tell them it makes their agent work twice as fast, and they are doing it voluntarily.

That is not a conspiracy. That is just the first effective incentive for good engineering practice anyone has ever invented.

Formal verification is solved. No one told you.

No one is talking about this one yet. The code agent paper from this month proved that unmodified Claude Code 4.7 can prove every single lemma in the Iris standard library. All 4257 of them. Fully automatically. No human intervention.

Prior state of the art proved 12%.

They did not invent a new model. They did not fine tune. They did not build a custom proof architecture. They just wrapped a standard general purpose code agent in a verification harness that gave it hard feedback, and let it iterate.

This is the pattern that will repeat across every domain. You do not need a special purpose agent. You need a good general agent, a correct feedback loop, and enough patience to let it work.

Reward function design is still black magic

If you are going to run RL on agents, there is one rule you should memorize from this month's research: never weight reward dimensions.

Across 48 different reward configurations tested, equal weighting of all quality dimensions consistently outperformed every targeted weighting scheme. If you try to emphasize one particular dimension you will almost always get worse results on that dimension, and collapse the model into a low quality local minimum.

Worse: every model reacts differently. The invalid output penalty that was absolutely required for Llama 3.1 did nothing at all for Qwen 2.5. SFT initialization that was mandatory for one model actively harmed the other.

There is no theory here yet. This is still entirely empirical. Test everything.

Open data for agents is finally arriving

We have open weights. We now are starting to get open agent training data.

NVIDIA released 10 trillion tokens of post training data this month, plus an interactive atlas you can use to explore exactly what is in the dataset. This is the first time anyone has published the actual data mixture used to train a production agent model.

For too long agent research has been "we fine tuned on our private dataset and it got better". That is not reproducible. That is not science. Open data changes that.

What no one is working on

There is one very large gap in all of this work.

Nobody has a good answer for abort cascades and recall guarantees when you stack multiple agents. All of the failure prediction work assumes a single agent. All of the calibration breaks completely when you have two agents talking to each other.

That is the next hard problem. Right now you can abort a single bad run. You cannot abort a bad conversation.

---

References

1. Doomed from the Start: Early Abort of LLM Agent Episodes via a Recall-Controlled Probe Cascade http://arxiv.org/abs/2607.06503v1
2. SkillOpt: Executive strategy for self-evolving agent skills https://github.com/microsoft/SkillOpt
3. Choosing the Right Tooling Layer for Your Agent https://dev.to/dailycontext/choosing-the-right-tooling-layer-for-your-agent-1eg2
4. Harnessing Code Agents for Automatic Software Verification http://arxiv.org/abs/2607.06341v1
5. Your Agents Should Be Multiplayer https://dev.to/dailycontext/your-agents-should-be-multiplayer-18h0
6. Open Data for Agents https://huggingface.co/blog/nvidia/open-data-for-agents
7. OpenSRE https://github.com/Tracer-Cloud/opensre