Every agent team hits the same wall. Your eval suite is green. A real user opens a messy spreadsheet, and the agent collapses. The model was never the problem. The test was.

Ramp Stack built a bookkeeping agent and ran straight into this. Their documented mistake was almost automating a process they had not described well enough. So before writing code, they wrote down how an accountant actually does accounts payable reconciliation: pull unpaid bills, pull the ledger, line them up, then hunt for the gap when the bills total $3,500 but the ledger shows $3,000. Each step is something the agent must do and something the eval has to check.

You cannot evaluate a process you cannot describe. That is the whole foundation.

An eval has four moving parts

Once you can describe the work, the structure of the eval is straightforward. Every case combines a task, a world, a trajectory, and a score.

A task is the request: "Reconcile our AP payables and bills for Q4 2025." A world is the synthetic business data the agent can read. The trajectory is the sequence of steps the agent takes. The score is a rubric of criteria graded by a judge model.

The rubric is what makes any of this useful. Pass/fail tells you almost nothing. Six criteria such as "Q4 AP balance correct" and "duplicates flagged" tell you the agent scored four out of six and exactly which two it missed. Have domain experts write those criteria, because they know what a real reviewer would reject.

The comment thread on Ramp's write-up agreed on this point hard. Multi-criterion scoring was what finally turned a meaningless red X into "here are the two it missed."

Synthetic worlds and why the mess is the signal

Before launch you have no production data to evaluate against. You have to simulate it. Ramp built what they call worlds: full synthetic businesses with realistic books. One world is a DTC home goods brand selling through Shopify, Amazon, and wholesale, with an ERP and Excel files that are deliberately ugly.

Teams that build clean synthetic data get an agent that looks brilliant offline and breaks the first time it meets a customer's actual export. The mess is the signal. If your test world is tidy, you are testing a version of the job that does not exist.

Quick Take: The best hour you can spend on an agent is writing down exactly how a human does the task before you write a single line of agent code.

Making the eval fight back

A fixed answer key tests recall. It does not test decisions. eSlams takes the opposite approach: put models into games where the environment responds, new information invalidates old plans, and every move carries consequences into the next one. In Connect Four, building your own threat is worthless if you miss your opponent's. In poker, a sensible call can lose the hand because you cannot see the cards.

The real value is in what gets recorded. eSlams Core, an MIT-licensed engine on GitHub and PyPI, logs moves and technical failures separately, enforces what each player can see, and saves matches as portable records that can be replayed and validated. If the software substitutes a move after a model fails, that intervention is flagged and the run is excluded from scoring.

I installed eslams-core 0.6.2 and ran that fallback path end to end to see how clean the separation really was. The substitution is recorded properly: replay rows carry action_provenance: "fallback_action" with markers for no_action and fallback_action, distinct from the opponent's genuine moves. The run is then correctly marked match_valid_for_scoring: false with invalid_reason_codes listing agent_error, provider_timeout, and fallback_action_used.

Then I read the public summary for that same run. It says the seat won 1.0 to 0.0 by three-in-a-row, with a confidence interval of [1.0, 1.0]. A player that never produced a single legal action is shown to spectators as a decisive winner.

That is the failure mode worth internalizing. The disqualifying flags sit in the same JSON object, so nothing is hidden, but winner and score are the two fields a spectator reaches for first, and both report the opposite of the truth.

Memory is not learning

Here is the trap that eats teams alive. Someone tells the agent something important. A few sessions later the memory is gone. You tell it again. Nothing compounds.

A hedge fund director put the problem bluntly: training an agent is not the hard part. The hard part is that the moment a second person on the team starts using it, everything resets to zero.

The instinct is to add more memory. Longer context windows. A vector database. Store every conversation, tool call, and past decision. Then you run evaluations and find that more context did not reliably improve performance. In some configurations it made things worse. The counterintuitive result is that giving an agent less to remember often makes it sharper.

The reason comes down to a distinction most memory systems blur. Facts and learnings are different things. A fact describes the world: the contract expires next month, the API needs authentication. Those belong in a database. A learning describes how to act: when investigating a production incident, check recent deploys before debugging unrelated components; when two sources conflict, prefer the recently verified one over the most semantically similar document. Those are judgments, and they come from experience.

Ten similar failures should not become ten separate memories. They should collapse into one lesson.

The learning loop has five stages

A useful memory system runs as a lifecycle.

Capture records meaningful experiences, not every interaction. Evaluate checks whether the strategy actually worked, ideally with independent verification. Consolidate turns repeated experience into reusable lessons. Retrieve surfaces the right lesson when it is relevant. Update revises or deletes memories as the environment changes.

The validation step is what separates real learning from superstition. An agent can repeat a strategy and see it succeed without knowing whether the strategy caused the outcome or whether it was luck. Track when a lesson was last validated and under what conditions it applies, because a strategy that worked three months ago can turn dangerous after an API or policy change.

Timing matters as much as content. A perfectly accurate memory surfaced at the wrong moment can wreck a decision. Progressive disclosure, handing the agent the minimum it needs for the current decision and revealing more only when required, consistently outperformed dumping everything in.

Key numbers from one agent team's tuning2.8 points mean score gained by trimming 8 skills to 4 across six worlds 61% size cut on the largest spreadsheet skill, quality essentially unchanged $30k / month saved from that single compression 5.7 points gained by distilling memory from prior trajectories with period-specific amounts stripped out 0% to 100% on one task from a memory that captured a reusable workflow 75% to 25% on another task from a memory that smuggled in last month's specific numbers

What actually moves the number

Two popular ideas did not survive contact with a fixed baseline. Auto-tuned skills, the GEPA-style autoresearch approach, showed gains that failed to generalize. High reasoning effort produced the same accuracy at higher cost.

What worked was treating the agent like an ML model and its context like features. Benchmark one skill at a time against a no-skill baseline. Keep only what moves the score. Several skills actively hurt performance, and no single skill was best across all worlds.

What trips people up

The most common mistake is grading only the final output. An LLM judge handed a right-looking answer will pass it even when the reasoning that produced it was broken. Add assertions on the trajectory itself, not just the result, or you will ship an agent that gets the right number for the wrong reasons.

The second trap is a rubric that drifts. Domain experts write the criteria, then the product shifts underneath them and nobody updates the rubric. Ours went stale faster than expected. Put an owner on it and review it on a schedule.

Third, teams treat memory as a storage problem. Storing every interaction and retrieving by semantic similarity is what produced worse results in Ramp's tests. Memory needs consolidation and a freshness policy, or old lessons quietly become permanent rules after the world has changed.

Fourth, letting public-facing scores ignore validity flags. A run that used fallbacks is not a win, no matter what the headline number says.

Where these patterns map to real components

Prompt Paws, an open-source teaching sandbox that runs at 60 FPS in the browser, maps each cozy bakery station to a production pattern. It sounds like a toy, but the mapping is the clearest one-page summary of an agent stack I have seen.

Bakery station	Production AI pattern	What it protects against
Flash Pastry Oven	Low-latency model (gemini-2.5-flash, Gemma)	Slow responses on high-volume traffic
Context Cache Jar	Prefix and context caching	Repeated prompt cost (around 95% token savings)
Guardrail Flour Sieve	Input classifier and injection sanitizer	Prompt injection
Vector Berry Patch	Vector search and fact grounding	Hallucination
Tool-Call Boba Mixer	Deterministic sandbox and function calling	Arithmetic and API errors
Deep-Think Soufflé Oven	Extended reasoning	Multi-step planning failures
Subagent Sous-Chef Bell	Parallel delegation	Throughput (about 45% speed gain)

The reason it is worth a look: it forces you to see orchestration, caching, guardrails, and RAG as one system. Miss the guardrail and stolen tokens bypass every downstream oven. Miss the cache and you pay full price on every repeated query.

One thing to remember

An agent that remembers every mistake it has made is not the same as an agent that stops making them. The goal is a system where experience compounds: a task runs, an outcome is observed, a lesson is extracted and validated, and that lesson changes the next decision. If the lesson stops being useful, the system revises or drops it. That loop, running continuously, is what separates an agent that stores from an agent that improves.

The bottom line

If you are building your first agent eval, steal Ramp's anatomy directly: write the human process step by step, build one synthetic world that is deliberately messy, and score against a six-criterion rubric instead of pass/fail. You will find the gaps in a week instead of a quarter.

If your agent has memory and it keeps repeating mistakes, the problem is almost never storage. Add a validation step that checks whether a strategy actually caused the outcome, consolidate ten similar failures into one lesson, and stamp every lesson with when it was last verified. Period-specific numbers belong in a fetch, not a memory.

If you are worried about runaway cost, look at skill compression before you look at cheaper models. Cutting one oversized skill by 61% saved one team about $30k a month with essentially no quality loss. That is a bigger lever than switching model tiers, and it does not require retraining anything.

One thing to watch: validity signaling in public agent scoreboards is still immature. The plumbing to record a fallback exists, but the headline fields often ignore it. If you publish agent results, gate the score on a validity flag, or carry the error counts into the public row so nobody reads a broken run as a win.