Bigger Windows Raise the Ceiling. TokenOps Decides What's Context-Worthy.

The next frontier for AI agents isn't holding more tokens. It's governing which tokens earn a place in the prompt. Bigger context windows increase capacity.

Capacity is necessary. It isn't sufficient.

Every few months a model ships with a bigger context window, and the announcement lands like a milestone. 128k. 200k. A recent model even allows a million tokens. A larger window genuinely raises the ceiling on what an agent can hold.

But a window is a capacity ceiling, not a plan. Raising the ceiling doesn't answer the harder question: at the moment the prompt is assembled, what actually belongs inside it?

The frontier is no longer only "how much can we hold." It is "what deserves to be there."

Why production agents overflow

Long-running agents fill context from three directions at once: conversation turns, entries pulled from persistent memory, and the raw outputs of tool calls, which are frequently the largest of the three. The window fills long before the underlying task is done, and something has to give.

This isn't an abstract concern. In production, bad context selection shows up as three things buyers recognize immediately: higher inference cost, slower response time, and agents that forget the one fact they were supposed to remember. Those are budget-owner problems, not just developer problems, and they get worse as histories grow

The default answer breaks down in production

When context overflows, most agent frameworks reach for the same reflex: recency truncation, sometimes with a summarization pass on top. Keep the newest turns, drop the oldest.

The problem is that recency is topic-blind. It throws away a fact established early in a session precisely because it's old, even when the current question is about exactly that fact. Meanwhile it happily retains verbose, irrelevant recent chatter. The one workload where memory matters most, recalling information across many turns, is the exact case where "keep the newest stuff" fails hardest.

The adjacent tools don't fix this either. Retrieval augmented generation fetches new external documents into the prompt, but it doesn't arbitrate the context the agent is already carrying. Prompt compression shrinks token count by rewriting or pruning text, but it works query-blind and it's lossy. None of them treat memory, conversation, and tool outputs as one pool to be selected from, by relevance, at the exact moment the prompt is assembled.

That assembly moment is the unowned seam in every agent stack. TokenOps is about owning it.

TokenOps: the discipline of context judgment

We borrow the naming on purpose. DevOps made deployment a disciplined, observable, governed process instead of a heroic one-off. FinOps did the same for cloud spend. TokenOps does it for the context window.

The core claim is simple: every token in the prompt is a decision. In most agent stacks, that decision is still made by accident. TokenOps says the assembly step deserves a real objective, real instrumentation, and real controls. Done well, it pays off in ways both developers and budget owners feel:

Better answer quality, because the model sees what matters to the current query. Lower cost and latency, because smaller, denser prompts are cheaper and faster to process. More predictable behavior, because selection follows an explicit objective instead of a timestamp or position. Observability and governance, because teams can inspect what was kept, what was dropped, and why.

Because TokenOps lives above any one framework, the same policy can travel across runtimes instead of being rebuilt project by project. That portability is why context selection belongs in the open, at the layer that governs your agents, rather than buried inside whichever framework happens to be running today.

How the pieces fit: TokenOps, PACMS, and Nasiko

It's worth being precise, because these are three different things:

TokenOps is the operational discipline. It's the what and the why. PACMS is a selection method, described in our research, for choosing context by query-relevant coverage under a token budget. It's a how, and a strong one, but it's swappable. Nasiko is where TokenOps policies are governed, observed, and applied across every agent in your fleet, through a registry with attached governance, observability, and cost hooks.

TokenOps is not a branded name for a single algorithm. PACMS is one method that proves the discipline works. Nasiko is what makes it a durable, portable practice rather than a per-project script.

The proof: the PACMS method

We didn't want TokenOps to be a slogan, so we researched and measured a method for it. Our team's paper, PACMS: Submodular Context Selection as a Pluggable Engine for LLM Agents (arXiv:2606.20047), describes that method and puts numbers behind it.

PACMS reframes context assembly as a budget-constrained submodular selection problem. In plain terms: given the whole pool of candidate items and a token budget, pick the subset that best covers everything relevant to the current query, and skip anything redundant. In the paper it's implemented as a pluggable context engine, so the same interface can swap between PACMS, top-k, MMR, recency, or RAG without changing the rest of the stack. Tool outputs are treated as first-class candidates, which means a 5,000-token file read competes for its spot on the same terms as a short user message.

The finding that matters, with the numbers

Here's the result worth sitting with. All figures below are at a 45% token budget with two turns of injected redundancy, on a shared 100-question sample of the LongMemEval benchmark.

On evidence-round recall, the fraction of annotated evidence kept, PACMS and the LangChain MMR baseline landed within 0.014 of each other (0.909 for PACMS, 0.895 for MMR). Both slightly trailed top-k relevance ranking (0.933). If recall were the whole story, you'd call PACMS and MMR a wash.

But recall isn't the metric your users feel. End-to-end answer quality is. And on QA accuracy, PACMS led every budget-constrained baseline under both reader models:

So against MMR, PACMS delivered +8 points with the first reader (52.0% vs 44.0%) and +12 points with the stronger one (68.0% vs 56.0%), despite that recall parity. It even edged out top-k on answer quality (+2 and +4 points) while slightly trailing it on recall.

That divergence is the point. Retaining the right evidence is not the same as assembling a prompt the model can actually extract from. Coverage-based selection produces more extractable context than either pairwise diversification or raw relevance ranking. Retention is table stakes. Extractability is the win.

And recency? Under redundancy, recency truncation stays flat near the bottom (44.0% and 42.0%), and a stronger reader can't rescue it. Query-blind selection stays broken no matter how good the model is.

What this looks like in a real session

The paper includes a captured OpenClaw workspace session that makes it concrete. Across four sessions over eleven days, a user added Rust to their environment notes and later asked the assistant to confirm Rust was actually installed. Before answering, PACMS selected 17 of 168 pooled candidates to fit the budget: the relevant tool failures, the earlier Rust addition, the closest preceding turns. Unrelated older content, like identity questions and file-listing exchanges from days prior, was dropped.

A fact from many turns back returned to the prompt not because it was recent, but because it was relevant. That is the entire difference between a bigger window and a better decision.

Bigger context windows increase capacity. TokenOps decides what earns that capacity. Raising the ceiling is a model-provider job. Deciding what belongs under it, at runtime, per turn, with cost and quality on the line, is an operational discipline, and it belongs in the open at the layer that governs your agents.