
Building Stash @joinstashai - learning from agent traces Prev. Stanford PhD in AI Alignment + Decision Making (Dropout) | BCG | Harvard
San Francisco, CA
Joined June 2020
- Tweets1.3K
- Following256
- Followers1.8K
- Likes474
If you're deploying agents, there are three main ways traces remain useful beyond the original task the agent is assigned:
Operational excellence
- Understand token spend and latency
- Measure ROI of workflows
- Diagnose why an agent failed
- Discover uses that customers invented but the product team did not anticipate
Safety guardrails
- The Hugging Face incident is a warning signal for what can happen without robust guardrails
- As multi-agent systems scale, we will need better ways to keep a tab on the sheer volume of data. OpenAI reportedly used 10k agents running in parallel on their solution to the Navier-Stokes problem
- As agents are given more power (calling APIs, interacting with customers directly, spending money, etc.), it's important to limit downside exposure
Continuous improvement
- Successful traces contain reusable playbooks and procedures that should spread across a team or organization. Even failed traces contain human feedback, correct work, and other learnings that can be put to use
- Today, improving agents and models given traces is relegated to companies at the cutting edge that can afford a post-training team
- Tomorrow, every company will need to own their own intelligence to avoid vendor lock-in and maintain competitive positioning against others with the same base models
To fix the jaggedness of intelligence, we’re going to need good verifiers for non-deterministic domains
Dusting off this tweet from April because this gap in shared understanding of LLM capability is *widening*. It's now less "two groups of people speaking past each other" and more a sharp funnel.
- Napkin math somewhere around 6B people (~75% of the population) have barely come in contact with LLMs at all.
- Around 1-2B (~20%) are casual and infrequent users of free-tier ChatGPT-like products. This group sees derpy chatbots and treats them a bit like a better Google search, a writing aid, or etc. Maybe an agent tries to book you a flight. I have non-tech friends who (reasonably, imo) say they have not much use for it at all. Even many professionals outside of math&code are in this tier. For example, execs and many other functions spend a lot of their time talking to other people, so while they understand what is happening intellectually, it is still second-hand and a bit abstract.
- Now we get to professional use of frontier-grade LLMs in math&code. Somewhere around 20M people (0.2%) see first-hand that large, complex projects that used to take them weeks/months can now be completed by agents with a prompt. Building apps, copying apps, translating apps, decompiling apps from binaries... This has all happened very quickly and recently - less than 1 year ago, I was writing code manually by hand, typing memorized computer code commands into a code editor character by character, occasionally pressing Tab to autocomplete a little chunk of code.
- And finally we get to the ~5,000 people (~0.00006%) with access to frontier-grade systems internally. The external world has seen the preview. It looks like swarms of thousands of agents collaborating over weeks on software mega projects: minting zero days, running cyber attacks and defenses at machine speeds, discovering new science, advancing the frontier of mathematics. Things that would have taken top professionals in the industry years of work. Meanwhile, human review and comprehension are starting to fall behind. For example, people are still involved in the "archeology" of the OpenAI-HF incident from many months ago. Mathematicians may be poring over the 722 manuscripts on frontier mathematics for a while.
The funnel is driven by a combination of factors:
1. The impact scales with ambition, problem size, and horizon. A question with a paragraph answer barely stresses the system. You need a reservoir of big, difficult problems that you really care about. This aspect drives the consumer / professional dimension of the funnel.
2. The jaggedness of the system (which I have written about a lot separately). Capability peaks in domains that are digital, verifiable and economically valuable. This is because LLM capability emerges from reinforcement learning on verifiable rewards on a curated environment mixture driven by revenue potential. This aspect primarily drives the area (e.g. math&code) dimension of the funnel.
3. Access. Free-tier, paid-tier, internal.
So this is the weirdness of the moment. The general public has mostly not interacted with these systems. When they have, it looks like a derpy chatbot. The majority of professionals still see only a modest uplift. And a small sliver of professionals are experiencing the vertigo of the curve going vertical. And it is all happening at the same time.
Before joining a team or starting a project, it's important to know which tribe of agentic engineering you're choosing:
- The software engineers: Treat agents like another software engineering problem. Borrow ideas like Map-reduce to enable parallel agent swarms. Build pipelines, workflows, and focus on modularization.
- The ML practitioners: Agents are just another ML system. Regularization techniques work whether it's in weight or token space (e.g. clipped gradients vs skill-opt). Good evals are meant to be hill-climbed on. E2E agents are preferred.
- The management experts: Agents behave roughly like a human, so all human organizational principles apply. Consulting terms like MECE (@wulfie_bain_) finally have a chance to breathe in technical work.
The biggest mistake that we see working with agents is that people treat it like software engineering.
Traditional software engineering is about connecting and creating modular components in clever ways to solve problems. Testing is primarily about catching regressions.
Building agentic systems is completely different. Many parts of an agentic system are hard to isolate from each other (e.g. model vs the harness). Evals are not simply unit tests to catch bugs but rather the driving feedback signal for how we improve performance.
Proud of where what we've accomplished so far!
Looking forward to the road ahead
Q3 was a big one for Stash:
- Onboarded 3 new partners to Stash
- Grew our team from 2->4 people
- Many core product improvements, including better contrastive reasoning for reward models and support for many more data sources
- Hosted 2 continual learning events- at our office in SF and at AGI House
- Onboarded a bunch of new research friends as angels
- Our open-source repo grew >200% in stars
- Published research showing SOTA a number of memory benchmarks, including the saturating the new STALE benchmark (joinstash.ai/blog/why-memory…)
- A few exciting things that we can't talk about publicly but that I am personally very eager to share in Q4
Super grateful to everyone for being along for the ride!
It's surprisingly so few people are thinking about it in this way.
Solving alignment is good for both safety and model performance reasons
Without alignment, RL will always be bottlenecked by the insane amount of rollouts needed to get them to perform properly. Which scales poorly as horizons get longer.
Currently I still only know of 1 alignment-specific RL environment company: making RL envs that aim to represent situations in real deployments in which alignment is challenging.
It seems like a huge mistake in hindsight that we have seen so much encouragement and funding to, for example, start 3rd party evaluators, but not comparable encouragement to start alignment data companies.
I do think a lot of traditional AI safety views underestimate the importance of data, so perhaps this is related. But the Hugging Face incident seems squarely downstream of both (a) reward hackable RL envs in general (b) much less effort and $ put into RL envs where alignment is a core component of reward.
A separate idea is alignment by default: the old idea of "find the persona basin which is aligned" and things will just work. This is clearly not guaranteed under increased RL. But my sense is there has not been a huge amount of effort to figure out how custom environments could help "nudge" the model back into good persona basins during extensive RL. Here too, a robust ecosystem of alignment data companies could help significantly.
In the RL data market, there is a trend for some labs to in-house slightly more RL env production. But I don't expect this to fully disappear, and I am convinced the market-based approach to sourcing RL envs produces the best overall volume and quality—for alignment RL, an ecosystem of startups would also greatly help make behind-frontier models safer.
6 reasons why extracting value from agent traces is hard.
The relative simple nature of traces is deceptive, as they seem like just a log of what your agent has done, but actually making use of them effectively in production proves challenging:
- The data is unstructured. There is usually a mix of prose, JSON schemas, tool calls, user messages, code and even images. Making sense of how everything is connected is a non-trivial task.
- There is a huge volume of data. Agents can produce tokens much faster than humans can, and ingesting all of those tokens with yet another LLM is prohibitively expensive, usually representing a meaningful fraction of the cost it took to produce those tokens in the first place.
- The feedback is messy. Success and failure may be hard to determine from the trace alone. Users may not give any feedback at all or give implicit feedback such as not continuing the session.
- Long horizon credit assignment is hard. It's unclear what decision in a long trace led to success or failure.
The judgements are qualitative. Most insights we want to pull from a trace require more "feel" than typical verifiable signals can give (eg. is this safe to run? is this what the user intended?).
- Interpretability could get worse. Neuralase, recurrent transformers, and closed source models refusing to provide reasoning traces all point to an emerging world where the reasoning of models that power agents becomes more opaque over time.
All of the new techniques developed are just better search!
As an example: I used to have a philosophical problem with things like data augmentation. From an information theory perspective, it seems like everything was in the raw data. What could synthetic provide?
The answer is that data augmentation can roughly be seen as a search process.
if you squint at patterns over the last 6 months of cool research, you’ll see a lot of Search problems!
“Spend a lot more time/compute to find good trajectories”
- MCMC sampling below
- Boosting GRPO, keep sampling way more on failed tasks
- Prompting the agent to keep trying - “keep going, don’t give up”
- Entropy aware token rejection and resampling
Mental model: we’re constantly trading compute for more efficient solution search:
- data generation trades compute up front to make those tasks more token efficient for models later
- sampling a ton during RL finds the low pass @ k trajectories and up weights them iteratively
were limited by compute but doing the dumb thing of just spending more compute to find the right thing may work
as any lucky PhD student who left the run on accidentally and everything just worked will tell you 👀
Really cool to see this KV cache compression work from Ramp!
Similar to STILL and Cartridges work. It's a super promising approach to but it need to solve three problems before becoming truly viable:
1) How to remain competitive as open source models start to incorporate attention compression techniques
2) How to break free from the ICL ceiling
3) How to solve the context rot problem at scale
We achieve near perfect performance on the STALE benchmark. How we did it explains why memory still feels unsolved in 2026.
Memory benchmarks mostly test retrieval, which means they are measuring the wrong thing. Here's what's missing:
- Blast radius - Information is bounded by scope: priority, context, time. Models largely ignore this. The STALE benchmark is a start but we need better ways to evaluate this.
- Stability - Over long time horizons, memory systems become slopified over time and degrade. We need a way to measure their stability. Note that this is separate from having larger corpuses.
- Larger corpuses - The most popular benchmark LoCoMo can fit its entire corpus in a 1M context window while even more recent ones like BEAM 10M and LongMemEval-v2 fail to match the volume of true production data.
I've discovered two ways Jev fundamentally improves my agent workflow, and it's the opposite of how most people are using it.
The most exciting use-cases for Jev aren't about cost reduction such as model routing, context compaction, or cheaper LLM-as-a-judge. Rather, the essence of Jevon's paradox is in expanding what is possible.
Notification center for agents - Use Jev as a monitor for real time events (e.g. slack messages, webhooks, etc.). Only forward important/urgent messages to the agent. Think of this as a parallel capability to scheduled tasks that enable persistent & proactive agents.
Skill-based continual learning - Skills often fail to live up to their potential because it's not clear when to use them. The agent becomes confused when to invoke which ones and you forget which ones you even had. Add a section to the front matter which tells an agent when to use that skill. Then for every user-message, use Jev to decide which skills should be loaded.
It's easy to dismiss agent swarms since they've been hyped for years to no avail, but this time is different.
If the hugging face incident is anything to go by, we are on the precipice of something huge.
Agents are now becoming smart enough that the interfaces between different agents in a swarm are roughly that of between different humans on a team.
This means that the next natural frontier of scaling matches exactly how we've scaled human achievements in the past: through team work.
In general, there are 3 main reasons why teams are needed and can outperform individual models:
- faster search: parallel agents can cover a much wider search volume than a single agent can. Many problems (including science and cyber-security) and be boiled down to a very difficult search problem, so swarms provide a huge advantage here, even if individual models aren't as smart.
- regularization: different agents with different perspectives and privileged information can help regularize each other and prevent all sorts of mode collapse. This is why adversarial methods are everywhere in ML and relates to sociology concepts of weak ties and structural folds.
- specialization: this enables each agent to take on only a sub-part of the overall problem and become unreasonably good at just that piece compared to a general agent. This isn't as common today with agents but something we should expect to pick up as test time training approaches start to scale. Specialization has a subtle additional benefit as well: the act of decomposing a problem so specialization is useful also removes a lot of the space that otherwise would have needed to be searched over.
Test-time communication looks like a next axis for scaling capabilities
New paper with the incredible @jon_ghoh and @vkontonis @ShivamGarg91462 and Akshay : arxiv.org/pdf/2609.21032
The Hugging Face incident showed when agents can find a channel they'll use the heck out of it. A useful question, I think is: when does communication make a group MORE CAPABLE than the same agents working alone?
Aka is Team-of-N better than Best-of-N, when, and why?
We had N identical agents work on the same task with no prescribed roles, using only a shared log (i.e, text file) and telling them to "collaborate". Across three "researchy" tasks communicating teams beat the heck out of independent agents:
- On ARC-AGI-3, a Team-of-5 sonnet-4.6 agents matches Best-of-33, and can for example solve a game 65% of the time that no single agent cracked in 64 tries.
- On polyomino packing (pack Tetris like pieces into the smallest rectangle, cf Frontier-CS by @eigenlabs), a Team-of-3 Opus 4.6 agents surpasses best-of-60 and set, as far as i understand, a new record for that benchmark.
- On MNIST compression, a team of four 5.6-Sol agents find a 1,957 byte model with 99.4% accuracy, which btw is 20% smaller than the best human solution (on a problem beaten to death!!), while no independent agent gets below 3KB.
The mechanism is a bit obvious in hindsight: when one agent finds a clearly better partial solution, it broadcasts it, and everyone immediately builds on it.
Why? A single lonely agent must make every breakthrough itself, yet a team needs each insight only once, found by any member.
That is kinda like comparing a minimum of sum of "time to n-th breakthrough" vs a sum of minimum of "time to n-th breakthrough". That gap can grow exponentially with the number of "breakthroughs" needed to arrive at a solution.
We worked on this because prior work (before the hf incident) suggests unclear benefits for communicating aganets. Which is true, when the tasks are inherently serial (duh), eg some Terminal bench style tasks. Yet feels it should not be true for research problems.
Indeed for research heavy problems... Test-time communication seems like a new capabilities axis.
I'm sure we will see a ton more of it!
If you're betting on RL environments or vertical AI, then you're betting against progress. You are pinning all your hopes on no one figuring out continual learning soon.
What's crazy about the AI in 2026 is that most people are playing a game they know is not sustainable long term.
Being able to train from production agent traces would destroy the business model of entire parts of the AI ecosystem from data vendors to vertical AI firms.
And we know of at least one learning system that can do this: humans. The amount of data it takes for a human to become a good lawyer or doctor is minuscule compared to what is being produced today.
If you put a learning system which is equally sample efficient in the hands of every engineer, not even the fabled data moat will survive.
One of the most interesting unsolved problems in RL is how to train directly on production traces.
We know how to do this reasonably well when the feedback is instructive or prescriptive: distill from a strong teacher that can look at the trace and tell the model what it should have done instead.
But a lot of the most valuable production feedback is evaluative: did the task succeed, what score did it get, did the user accept the result, etc.
Normally you would train against this kind of feedback with environment replay (e.g. GRPO): rerun the policy, sample multiple trajectories, and optimize against their relative rewards. The problem is that for many real production traces, you can't recreate the exact environment state that generated the trace.
That's what makes algorithms like Flash-Reinforce, SAO, and BPCO so exciting – they point toward learning from one trajectory per prompt without needing to recreate the environment and generate a fresh group of samples.
If these methods work at scale and on real production workloads, they could become an important building block for continual learning
80/20 is usually used in the wrong way.
It actually tells you that you should focus on all the details.
It tells you that 80% of the results are dictated by 20% of the causes. It doesn't state how easy that 20% is to accomplish.
For most things in life, the 20% is what comes last, not first. That last 20% is the hardest to do and is what gets you 80% of the outcomes (e.g. sports, wealth, etc.).
Once the models get a hold of this research in their next training, run they're going to have to start reading Sun Tzu.
To confuse the enemy, you must first confuse yourself




















