Knowing Is Not Doing: When LLM Agents Pass the Task but Fail the World

A task is finished. The agent found the file, clicked the button, moved the object, submitted the form, or reached the winning state. The dashboard turns green. Everyone relaxes.

That is usually the moment when the real question gets quietly buried: what did the agent actually learn about the world it just operated in?

The paper What Do LLM Agents Know About Their World? Task2Quiz: A Paradigm for Studying Environment Understanding asks exactly that question, using a controlled TextWorld-style benchmark where the full environment structure is known by construction.¹ The paper’s core move is simple but useful: stop treating task completion as evidence of understanding. Completion measures whether the agent got somewhere. Environment understanding asks whether it knows what kind of place it just moved through.

That distinction sounds philosophical until one tries to deploy agents in business workflows. A customer-support agent may close a ticket without remembering which policy exception mattered. A procurement agent may complete a vendor search while losing track of which supplier constraint blocked approval. A research agent may answer one query correctly while failing to preserve the map of sources, dependencies, and unresolved facts. In each case, the task is done. The world model is not.

Task2Quiz, or T2Q, is interesting because it does not merely complain about this gap. It builds a deterministic way to measure it.

The paper compares what benchmarks usually merge

Most agent benchmarks measure trajectories. Did the agent reach the goal? How many steps did it take? Was the final answer correct? These are useful measures, but they mostly evaluate “doing.”

T2Q adds a second axis: after the agent interacts with an environment, quiz it on what it should now know. Not what it guessed from prior knowledge. Not what a judge model feels is reasonable. What the agent’s own trajectory made available.

That is the crucial design choice. The benchmark does not ask arbitrary trivia about the environment. It generates questions from known environment metadata and then conditions answerability on the agent’s actual interaction history. If the agent never entered the kitchen, it should not be punished for not knowing what was in the kitchen. But if it entered the kitchen, saw the object, opened the container, or traversed the connection, then the corresponding question becomes fair game.

This gives the paper a comparison frame:

This is why the paper is not just another benchmark paper with a new acronym, because apparently those are produced by the metric ton. Its main contribution is diagnostic separation.

T2Q turns task execution into a later examination

The evaluation has two stages.

In Stage 1, the benchmark gives the agent a set of coverage-oriented tasks inside a controllable TextWorld-style environment. These tasks are not randomly chosen one-off goals. The paper formulates task selection as a weighted set cover problem: identify reachable rooms and interactive entities, generate candidate tasks whose solution trajectories cover different parts of the environment, then greedily select a compact set of tasks that maximizes coverage. Interactions and objects receive higher priority than simple room traversal, because opening, unlocking, matching, and inspecting are more informative than merely walking through a hallway.

In Stage 2, the agent receives quizzes about the environment. These questions cover five categories:

The answer key is generated from environment metadata plus the agent’s trajectory. That makes the evaluation deterministic. It also avoids a common evaluation problem in agent benchmarks: using another LLM as judge, then hoping the judge is not confidently hallucinating in a slightly more expensive voice.

The resulting benchmark, T2QBench, contains 30 environments, 224 coverage-oriented tasks, and 1,967 grounded QA pairs across three difficulty levels. The easy environments have 3–5 rooms and 6–10 objects; the hard environments have 16–20 rooms and 28–32 objects. As difficulty rises, the average number of tasks and questions rises as well.

This matters because the paper is not asking whether an agent can solve one puzzle. It is asking whether interaction leaves behind a usable representation of the environment.

Doing and knowing diverge, but not in the lazy way

The headline result is that Task Success Rate and Environment Understanding Score do not move together cleanly.

The paper evaluates GPT-5.1 and several open-source models, including GLM-4.6, DeepSeekV3.2, and Qwen3-32B. For the open-source models, it also compares an in-context baseline with memory systems such as Mem0, LangMem, and A-MEM.

The main table already tells the story. GPT-5.1 has the highest task score in the reported table, 68.75, but its total Environment Understanding Score is 50.23. Qwen3-32B with A-MEM has a much lower task score, 18.30, but the highest total EUS in the table, 60.29. Qwen3-32B in-context also has a low task score, 34.38, while achieving a total EUS of 58.55.

This does not mean “weak task agents secretly understand everything.” That would be too convenient, and therefore probably wrong. It means the two metrics capture different capabilities.

Task success is heavily affected by long-horizon planning, constraints, and execution efficiency. Environment understanding measures whether the agent can answer grounded questions after exposure. An agent can fail to complete a task because planning is hard, while still collecting useful facts. Another agent can complete a task through a narrow route while ignoring much of the surrounding world.

The difficulty-level analysis makes the point sharper. For GLM-4.6 with the in-context method, Task Success Rate is 100% on easy environments, drops to around 85% on medium environments, and falls to around 43% on hard environments. Environment Understanding Score, however, stays much flatter, around the low-to-mid 50% range.

The likely interpretation is not that understanding is magically robust. It is that task completion and environment knowledge are constrained by different bottlenecks. Harder environments make goal completion harder, but the agent may still retain some observed facts. Conversely, an easy task can be completed without requiring broad exploration.

That is the paper’s first useful correction: a finished task is not a certified world model.

Memory helps only when it preserves the right evidence

The second comparison is more uncomfortable for the current agent stack: explicit memory systems do not reliably improve environment understanding.

The paper compares three memory-augmented approaches against a naive in-context baseline that keeps the full interaction history. In many reported cases, the in-context baseline matches or outperforms the memory systems on task success, environment understanding, or both. For GLM-4.6, the in-context baseline reaches a total EUS of 52.41, while Mem0, LangMem, and A-MEM score 46.21, 51.65, and 48.30 respectively. For DeepSeekV3.2, A-MEM slightly leads on total EUS, but the in-context baseline remains competitive and has the highest task score among that model’s variants.

The paper’s explanation is plausible: memory systems may organize information less than they damage fidelity. They often compress trajectories into higher-level events or summaries. That can be useful when the question is “what happened?” It is less useful when the later question is “which key matched the locked container two rooms east of the pantry after the agent opened it?”

This is not an argument against memory. It is an argument against treating memory as a magic filing cabinet. A business agent does not need “memory” in the abstract. It needs a representation that preserves the operational facts that future decisions require.

For enterprise use, this is the section that should make people pause before buying another “agent memory layer” because the diagram has three boxes and a tasteful gradient. The question is not whether the agent has memory. The question is whether the memory is shaped like the job.

A support agent may need a customer-state ledger. A compliance agent may need a rule-trigger map. A procurement agent may need a constraint graph. A lab assistant may need provenance-linked experimental state. In all cases, a generic conversation summary can be worse than raw context if it erases the exact facts that later questions depend on.

Exploration, not recall, is the nastiest bottleneck

The third comparison is between question types.

Agents perform relatively well on location questions. That makes sense: object location is often available from a direct observation and can be retained as a simple fact. The harder categories require either structural aggregation or active discovery. Direction questions require spatial consistency across moves. Match questions require knowing which key opens which lock. Property questions require interacting with objects to reveal states like locked, closed, or open.

The paper’s figure on question types shows location performance as the strongest category across models, while property questions are consistently weak. The reported property scores range from roughly 0.28 to 0.44 across models. This is not merely a memory retrieval problem. The agent often has to perform the right exploratory action before the fact exists in its observed history.

That is a subtle but important point. If the agent never tries to open the box, the fact that the box is locked remains latent. No memory module can retrieve an observation that was never produced. No vector database can embed the sound of a tree falling in a forest if the agent did not bother walking into the forest. Very innovative, yes.

The appendix analysis of answerable versus non-answerable questions reinforces this interpretation. The purpose of that appendix is diagnostic rather than a second main result: it asks where correctness comes from. For location questions, agents more often satisfy prerequisites and answer from observed evidence. For orientation and connectivity questions, insufficient coverage can make some questions non-answerable, so correctness may partly come from identifying that lack of evidence. For property questions, models perform poorly on both answerable and non-answerable cases, suggesting that proactive interaction is indeed a major weakness.

This matters for business agents because many workflow failures are not recall failures. They are exploration failures.

The agent did not check whether the document was the latest version. It did not inspect the exception clause. It did not ask whether the vendor account had a regional restriction. It did not open the attachment. It did not test whether the API token had write permission. It did not verify whether the dashboard filter excluded inactive customers.

Then someone calls it a hallucination. Sometimes it is. Sometimes the agent simply never looked.

What the paper directly shows, and what business readers should infer

The paper directly shows that, in controlled TextWorld-style environments, task success can diverge from environment understanding; current memory systems do not reliably improve grounded environment knowledge; and question types requiring proactive discovery are especially difficult.

The business inference is narrower but still valuable: enterprise agent evaluation should not rely only on task completion metrics.

A practical agent evaluation stack should include at least three layers:

For a business workflow, the “quiz” does not need to look like a school exam. It could be generated from logs, database states, document metadata, tool calls, and process rules. After an agent completes a task, the system can ask:

• Which source documents did you rely on, and which were not inspected?
• Which constraints determined the final decision?
• What changed in the system state after your action?
• Which required checks were completed, skipped, or impossible?
• Which facts are known from observation, and which remain non-answerable?

The non-answerable category is especially important. Good agents should not only know facts. They should know when the evidence was never collected. In business settings, that distinction is audit gold.

The real ROI is cheaper diagnosis, not a prettier benchmark score

T2Q is not directly an enterprise benchmark. It is a diagnostic pattern.

The ROI path is not “use TextWorld to evaluate your procurement bot.” Please do not put your ERP system into a dungeon and ask it to find a latchkey. The useful transfer is methodological: convert workflow execution into a post-task state-understanding test, with answerability conditioned on what the agent actually observed.

That pattern helps in three ways.

First, it separates planning failure from knowledge failure. If the agent fails the task but answers the environment quiz well, the issue may be planning or execution. If it completes the task but fails the quiz, the issue may be shallow interaction or poor state representation.

Second, it evaluates memory systems honestly. Instead of asking whether memory “sounds useful,” teams can ask whether memory preserves the facts needed for later decisions. A compressed summary that destroys key state is not memory. It is amnesia with bullet points.

Third, it gives developers a way to test exploration policy. If an agent routinely marks important questions as non-answerable because it never gathered the evidence, the issue may be incentive design. The agent was optimized to finish, not to understand. That may be acceptable for low-risk automation. It is not acceptable for workflows requiring auditability, transfer, or recovery.

Boundaries: TextWorld is clean, business environments are not

The paper is careful about its limitations, and those limitations matter.

T2QBench is built on TextWorld-style text games. These environments are controllable, symbolic, and fully observable through metadata. That is exactly what makes deterministic verification possible. It is also what limits direct generalization to messy business systems, web interfaces, multimodal workspaces, or physical environments.

The evaluated model set is also limited by compute and API cost. The paper covers representative proprietary and open-source models, but the result should not be read as a final ranking of all agent systems. The point is the metric separation, not a leaderboard coronation.

Finally, the world-analysis and coverage-planning pipeline relies on TextWorld machinery and state-space search. Scaling this style of evaluation to richer environments would require more engineering, better instrumentation, and domain-specific state models.

These boundaries do not weaken the central lesson. They define where it applies. T2Q is strongest as a controlled diagnostic framework for studying agent world modeling. For business use, it should inspire evaluation design, not be copy-pasted as a production benchmark.

A better agent report card has two columns

The paper’s most useful contribution is not the benchmark number. It is the insistence that agent evaluation needs two columns.

One column asks whether the agent can act. The other asks whether the agent has acquired a faithful enough model of the world it acted in.

Business teams usually care about the first column because it is visible. The workflow either finished or it did not. But as agents take on longer, more stateful, and more consequential work, the second column becomes harder to ignore. An agent that completes tasks while failing to preserve state is difficult to audit, difficult to transfer, and dangerous to reuse under changed constraints.

T2Q gives a clean research version of that problem. The enterprise version will be messier: logs instead of rooms, permissions instead of locked doors, document provenance instead of object locations, policy exceptions instead of key-lock matches. But the underlying comparison remains the same.

Doing is not knowing. Memory is not necessarily understanding. Recall is not exploration. And “non-answerable” is not a weakness when the evidence was never collected.

That is the kind of boring distinction that makes agent systems less magical and more useful. Naturally, it is also the kind of distinction dashboards tend to hide.

Cognaptus: Automate the Present, Incubate the Future.