Knowing What to Ignore
· updated
Around July of last year, the RL-for-agents papers started landing in waves. I bookmarked them faster than I could read them. After a couple of weeks of this, I had the specific feeling that anyone building agentic systems will recognize — the certainty that I was falling behind on something I couldn’t quite name. I knew the basic RL theory, popular policy optimization algorithms like TRPO, PPO and GRPO, the basic shape of reward modeling for agents. What I didn’t have was hands-on practice. The gap, I assumed, was practice — find the right tutorial, run the right experiments, get my hands dirty. So I went in to close it.
The investigation disagreed with me.
The Investigation
A note on dating: This investigation was conducted in September 2025. Some specific empirical claims may have shifted since. The structural observations — and the pattern across users — have not. For example, Kimi K2.5's Agent Swarm (January 2026), trained via Parallel-Agent Reinforcement Learning, has since shown what RL-trained orchestration can do at scale — though PARL learns over a parameterized orchestration space with frozen sub-agents, not the full multi-agent RL dream.
I had framed the question narrowly. Which RL algorithm should I learn next, in what order, for what kind of agent? That’s the question I went in with. The investigation reframed it before answering: the more important question wasn’t which RL algorithm — it was whether RL was the right tool at all, and when.
The honest version of where I started is less flattering than the version I remembered. I told myself I had gone in open-minded, just collecting papers to figure out what mattered. That wasn’t true. I had already committed to the answer being algorithmic before I’d done the work to check. The reframing landed because it caught me in a position I hadn’t realized I was occupying. What I noticed only later, looking back, is that the process had also given me more accurate language for where I’d actually started than my own memory had supplied.
Two specific findings followed from the reframe.
The first: multi-agent RL — the direction holding my loosest, largest hope — was largely oversold. What ships as “multi-agent” in real systems is almost entirely deterministic workflow orchestration. The terminology has run ahead of the empirics by a margin I hadn’t appreciated.
The second is structural and more interesting. A prominent empirical result bundles RL gains with workflow engineering improvements in a way that makes it impossible to isolate how much the RL actually contributed. The field itself cannot yet answer the question does RL add three percent or fifteen percent here? That’s not a gap in my understanding. That’s an open question in the literature.
The Shift
What changed wasn’t tactical. It was the frame I was operating from.
I came in with a deficit. I’m behind. I need to fill an RL gap. Falling-behind anxiety has a particular shape — vague, urgent, and impossible to discharge, because you can’t know when you’ve caught up to something you can’t name. I left with a position. Here’s what’s real. Here’s what’s not yet proven. Here’s what would have to be true for that to change. The vague anxiety became a structured question — and a structured question, unlike an anxiety, gives you something to act on. Or deliberately not act on.
The relief surprised me. I would have predicted that finding out my biggest unnamed hope — multi-agent RL — was largely overstated would feel disappointing. It didn’t. It felt freeing. Disappointment assumes the hope had a clear shape worth wanting; relief comes from being able to put down something you couldn’t put down before. The lower expectation didn’t take anything away. It gave me back the attention I’d been spending on guarding against missing it.
What I gained wasn’t a set of answers. It was legible uncertainty — I could name what I didn’t know, why I didn’t know it, and what would have to happen for the picture to shift. I didn’t leave with conclusions. I left knowing exactly where not to spend the next six months, and why.
That relief — knowing what to ignore — was what I had actually needed.
That was my story. Because I was the builder and the user, I assumed it generalized only as far as people like me — engineers building agentic systems, trying to keep up with RL papers. I was wrong about that part too.
I started letting other people use what I’d built. They came from different fields. Their questions didn’t look anything like mine on the surface. What they said back to me did.
The Memory Research
Among the people who started using it after me was a researcher working on LLM memory. Her stakes were different from mine. She had two production products — a conversational assistant and an AI social platform with group chat — and she needed to figure out where to invest her own research attention. Memory was the question, but a specific kind of memory: multi-party, with multiple real users in shared conversations, and the AI tracking individual members, group dynamics, and relationship histories all at once. Her questions were already sharp going in. She knew what she didn’t have working frameworks for.
What the process gave her was something she hadn’t been able to construct on her own: a concrete direction for the hardest part of her problem. Memory optimization needs feedback, and feedback for memory is sparse — interactions are infrequent, and whether a stored memory was “used well” is mostly implicit. She had been treating this as a recognized obstacle she couldn't get past. The early part of her session focused on something else — designing a scheme to capture memory-user feedback directly. It was only when the conversation turned to how group-chat memory might connect to other scenarios that a different idea surfaced: cross-signal verification — using alignment or contradiction between what the AI knows in different contexts as a signal. It wasn't what she'd come in expecting to find. She described it as the difference between knowing the obstacle existed and having a direction past it.
The thing that struck me wasn’t just that the session was useful. It’s what happened weeks later, when she ran a follow-up. The follow-up didn’t repeat the original framing; it contested it. It found that external self-evolution approaches in memory contexts hit a fundamental signal ceiling, and pointed past the engineering frame she’d been operating in toward something more structural — that gradient surprise itself, the prediction error extracted automatically from data’s regularity, might be the only viable signal for what’s worth remembering at all.
Her words about the original session: she would have missed the cross-signal insight without the process. My observation about what happened next: the value didn’t just hold. It compounded, by arguing with its own earlier framing.
The DBA Trial
A DBA student in the lit review and research-model revision phase of her dissertation, who had already read more than 200 papers on her topic. A paying ChatGPT user who had been doing AI-assisted research on this dissertation for months — so she had a working baseline for what AI tools could do for her work. She came in during what she later described as a thinking-chaos phase — the period when too many directions feel viable, the scope keeps drifting, and adding more reading makes it worse.
In her session, the process surfaced a paper she had completely missed across all those 200 — and didn’t just point at it but showed that her own research could answer a specific black box that paper had left open. The rest of the session worked on the scope of her dissertation, narrowing the boundaries through what she described as repeated heuristic questioning that eliminated distractions she hadn’t noticed she was carrying.
Her own line, unprompted, in the report she wrote afterward: “It solved my pain as a researcher of not knowing what I don’t know.”
The Pattern
Two people. Different fields. Different career stages. They don’t know each other.
The researcher made the same point in different words: she hadn’t known the direction the process gave her existed, and the absence of that direction had been invisible to her until it wasn’t. The DBA student said it more compactly: it solved my pain of not knowing what I don’t know. It may not be enough to call a category yet — n=3 with me inside it doesn't make a solid pattern — but it's enough to be the working hypothesis I'm building against.
When the field is moving faster than you can read, and the deliverable you owe is a judgment you’ll have to defend, the thing you actually need is not more information. It’s the ability to see what you’re missing — including, especially, what you don’t yet know you’re missing.
There’s a class of tasks AI can do for you, and you can check afterward. Math. Code with tests. “Find the hardest material that meets these specs.” These have ground truth, and as models improve they absorb more and more work of this kind. That’s the easy case.
The kind of work the three of us were doing isn’t in that class. A judgment about which research direction to pursue, which technical bet to make next quarter, which paper opens which black box for your work — these don’t have ground truth in the same way. When you make a call like that, you own the consequence. The only way to verify a judgment like that is to do the work that produced it.
You bring what no model can — the stakes, the bar for good enough, the judgment at the forks. The question itself evolves as you investigate, and you have to be there when it does. Steering at the forks is the cheapest work in the process: each step rests on the one before it, so one imprecise turn early doesn’t cost you that step — it cascades and invalidates everything after, and you don’t find out until the end. Because you were in the loop the whole way, the judgment is already yours. You defend it without rebuilding it.
That’s what no autonomous tool can hand you — not because the model’s reasoning is weak; a perfect oracle wouldn’t change it — but because the consequence lives with you, and always will. Which is why this gets more valuable as AI improves, not less: every task with an answer key the models absorb leaves the ones without behind — and those were always the ones that mattered.
The question worth asking right now isn’t which model is best. It’s what the loop should look like when the work is judgment. That’s the question I’ve been trying to answer for myself.
I’m building this now. ElenX is available by invitation. If the patterns above match how you work, .