Train the Agent, Not the Model

The short version

Stop building agent swarms on top of agents that still need a human. Make one agent reliable first. You can do that by training it, not the model, but the agent itself: its prompts, skills and tools. And the training data already exists. It's the sessions your developers have with coding agents every day.

This is a concept, not a finished result. I'm sharing it to start a discussion and hear how others are approaching the same problem.

Why now, and how I got here

Core models are now smart enough to generalize. They don't need pages of instructions anymore. So a small amount of training on the right parts of the setup should get you 80% of the result for 20% of the effort.

I learned this by hand. On an e-commerce migration project I set up a lean agent for my team. I split the migration into its most common tasks. Then I ran the agent, watched where it went wrong, tweaked the prompts and skills, and ran it again. By the end we had templated prompts for everyday tasks, and the agent needed far less human help.

It worked. But I was the training loop. This post is about automating it.

Reliable nodes first

Automation is built from tested, reliable blocks. Agents should be no different. An agent in your chain should already work without a human before it joins the system.

The industry does the opposite. We wire agents to Jira, browsers, MCP servers and each other while each one still needs a developer steering it. If every step is 95% reliable, ten in a row land at about 60%. More plumbing won't fix that. Better nodes will.

And nodes will get smaller. I expect a Shopify developer agent, a Salesforce Commerce Cloud agent, each narrow, each with its own prompts, skills and tools. Narrow, repeatable work is exactly what you can train for. E-commerce is a great place to start, but any team on a long-running project fits.

The training loop

If you've trained a neural network, you already know this shape. Each step maps to a familiar idea.

training loop for one agent · 6 steps, closes on itself

The loop never stops. Developers use the better agent, and their new sessions become the next batch.

What gets trained

four parameter groups, each split into clusters

Agents are non-deterministic. Parametrization is how you make them predictable. Each part of the agent is split into pieces, and every piece is its own parameter. The whole part is a parameter too. So training can rewrite one rule inside a skill, drop the whole skill, or rewrite the system prompt from scratch.

Start from a structure that already works, with a few clusters per part. The cluster count can be learned too, but gently. Tests will tell.

Three things fall out of this. Skills that never help get pruned, judged by impact, not usage. The developer's raw prompt can be reshaped into a clearer task before the agent starts. And you learn what a good agent looks like: how many skills and tools it needs and how its system prompt is shaped. Those principles carry over to other agents, even ones you never train.

Where the data comes from

Every developer session is a training example: ticket in, PR out. The corrections are the gold. They're free, expert labels showing exactly where the agent went wrong. The data is noisy, but a PR a developer was willing to open is a fair sign that human and agent agreed on a solution. Each correction is also a cut point, so one ticket gives several examples.

Replay turns those sessions into a benchmark. Snapshot the repo, replay the original prompt, then score the run two ways:

• Smoke tests written from the final PR, for example in Playwright. Keep only tests that fail on the old code and pass on the new one. Test behavior, not implementation.

• A rubric from the corrections, like "reuse the existing cart service", scored by an LLM judge.

Where this could break

• Overfitting and noisy replays. A project may have only a hundred tickets. A generalization filter at the end of each step rewrites accepted edits into general rules and adds variation, like data augmentation.

• Clusters that split meaning. Starting from a proven structure with few clusters keeps this risk small.

• The optimizer. An LLM critique isn't a real gradient. That's fine for now. The core idea is the training setup, and the optimizer can later be swapped for something more deterministic, even a model trained for this job.

What exists, and what's new

The optimizer side is already proven, which is good news.

The new part is everything around the optimizer: real work as data, corrections as labels, replay as the benchmark.

Open questions

The ones I find most interesting:

• How cheap can replay get?

• How do you separate a real mistake from one developer's taste?

• In a chain of agents, which node caused the failure?

I build with coding agents for e-commerce clients every day. At a Meta event this summer, talks with engineers there confirmed this is still an open problem. I'd love to hear from anyone exploring this space, whether you've tried something similar or see a hole in the idea.

Sources

• SkillOpt: Executive Strategy for Self-Evolving Agent Skills, Microsoft, May 2026

• TRACE: TRajectory Attribution for Automated Context Engineering, Amazon, August 2026