Graham Neubig — 2024 in Agents

In one sentence

The core challenge of 2024 in agentic AI is transitioning from "chatting" to "doing"—which requires agents to possess high-level instruction following, the ability to recover from errors, and a structured way to remember successful workflows.

Why read this (and who it's for)

This summary is for AI engineers and researchers who are moving past the "wow" factor of LLM chat and into the "how" of production-grade agents. It solves the problem of why agents often get stuck in loops or fail at simple tasks by identifying the specific architectural requirements—like environment understanding and error recovery—that distinguish a toy demo from a useful tool. After reading this, you will be able to audit your agent's failures to see if they stem from a lack of "common sense" (environment understanding) or a lack of "memory" (workflow persistence).

The big idea

Professor Graham Neubig argues that while we have incredible models, building a truly capable agent requires a shift in focus from the model's raw intelligence to its interaction with a specific environment. An agent is not just a "smarter" chatbot; it is a system that must navigate a world (the web, a terminal, a file system) and perform actions that have consequences.

The logic of his argument follows a hierarchy of needs: first, the agent must understand the environment (what is a button? what is a file?). Second, it must have error awareness (if this command failed, why did it fail?). Third, it must be able to plan and iterate (how do I break this big goal into small steps?). Finally, it must be able to remember (how do I avoid repeating the same mistakes in a recurring workflow?).

Key ideas

Environment Understanding

• What it is — The ability of an agent to interpret the state of the world it is interacting with, whether that is a visual screenshot of a website or a text-based HTML tree.
• Why it matters — Without a grounded understanding of the environment, an agent cannot reliably predict the outcome of its actions. It will "misclick" or attempt to type into an un-interactive element.
• In the book — Neubig notes that models are currently better at identifying elements in HTML than using vision alone, but both require the agent to understand the "rules" of the interface.

Error Awareness and Recovery

• What it is — The capacity for an agent to recognize when a tool call or action has failed and to generate a corrective strategy rather than repeating the same failing action.
• Why it matters — This is the difference between a "looping" agent and a "thinking" agent. Many models (like GPT-4.0) struggle here, whereas models like Claude have shown a better "personality" for trying different approaches.
• In the book — Neubig highlights that a common failure mode is an agent getting stuck in a loop because it doesn't realize its previous attempt failed.

Explicit vs. Implicit Planning

• What it is — The architectural choice between a single agent trying to do everything via a massive prompt (Implicit) versus a multi-agent system with a clear hierarchy (Explicit).
• Why it matters — While multi-agent systems can be harder to manage because they can deviate from the plan, they offer a way to break down complex problems into manageable sub-tasks.
• In the book — He discusses the "CoAct" paper, which explores generating plans and then specifically going in to "fix" those plans when they deviate.

Workflow Memory (The "Skill" Library)

• What it is — The ability to persist successful experiences from one run of a task into the prompt of the next.
• Why it matters — Software engineering involves many repetitive tasks (e.g., fixing a failing GitHub Action). If an agent can "remember" the successful fix, it doesn't have to "re-think" the solution from scratch every time.
• In the book — Neubig describes a "workflow memory" curve where the agent's success rate improves as it is fed its own successful past experiences.

Fast Sanity Checks vs. Realistic Evaluation

• What it is — A dual-track evaluation strategy: using "mini" benchmarks for quick iteration and "real-world" benchmarks (like SWE-Bench) for final validation.
• Why it matters — You cannot wait for a full 10-minute agent run to know if a prompt change worked. You need "fast" feedback for the developer's inner loop.
• In the book — He mentions "miniWoB" for web navigation and "SWE-Bench" for real-world GitHub Pull Requests.

Frameworks & tools

The 8 Perennial Problems of Agents

To build a robust agent, you must address these eight dimensions:

1. Agent-Computer Interface: Provide minimal viable tools (Execution Sandbox, File Editor, Web Browsing).
2. Human-Agent Interface: Determine the best UI (Chat, GitHub Plugin, etc.).
3. Choosing an LLM: Evaluate based on instruction following, tool use, and error recovery.
4. Planning: Decide between Single Agent (Implicit) vs. Multi-Agent (Explicit/CoAct).
5. Reusable Workflows: Move from manual prompting to "Learning from Experience" (SteP).
6. Exploration: Use "Agentless" or "BAGEL" to bootstrap exploration.
7. Search: Utilize Tree Search to explore paths and "rewind" on failures.
8. Evaluation: Use a mix of Fast Sanity Checks and Realistic Environments (WebArena, SWE-Bench).

The "Micro-Agent" Trigger

A design pattern for managing complexity without a full multi-agent overhead:

1. Identify Triggers: Detect specific keywords or actions (e.g., "GitHub" or "NPM").
2. Inject Instructions: When a trigger is hit, append specific instructions to the prompt (e.g., "Use the API, do not browse").
3. Contextual Switching: This allows a single agent to switch "modes" without needing a massive, confusing prompt for all possible tasks at once.

Memorable examples & stories

The "Yellowstone" Misclick

• The Story: A vision-based agent was accused of "looking for a vacation" because it was staring at a picture of Yellowstone. In reality, it had simply misclicked on an ad.
• The Lesson: We must be careful not to anthropomorphize "hallucinations" or "errors" as intentional behaviors; they are often just failures of the model to understand the UI.

The "Cache File" Bug

• The Story: While developing a monitor website, Neubig encountered a bug where the agent was writing a cache file to one directory and reading it from another. He had no idea what was going on.
• The Lesson: This illustrates the "black box" problem of agentic behavior—sometimes they fail in ways that are logically consistent but completely unexpected to the human developer.

The "GitHub Action" Workflow

• The Story: Most software engineers spend a significant amount of time fixing failing GitHub Actions.
• The Lesson: This is a prime candidate for "Workflow Memory." Instead of asking the agent to "solve" the problem every time, we should identify the successful "fix" and persist it as a skill.

Key quotes

"I think this is a pretty powerful tool set... and I am trying to do... come up with agents that are able to manipulate these things." Why it matters: It defines the agent's goal: manipulation of tools (browser, terminal, file system) to achieve a result.

"If you provide all, if you provide instructions that it should do information gathering beforehand, it tends to do well." Why it matters: It highlights that "thinking before acting" is a promptable behavior that solves many "rushed" agent failures.

"The actual ability of models is maybe closer to 30 to 40%... but I need to give it feedback." Why it matters: It sets a realistic expectation for the current state of the art: agents are assistants, not replacements.

How to apply it

This week

• Audit your "Loop" Failures: Identify one task where your agent gets stuck in a loop. Determine if it's a "Reasoning" failure (it doesn't know what to do) or an "Environment" failure (it doesn't understand the tool's output).
• Implement a "Micro-Agent" Trigger: If you have a complex prompt, try to break out one specific tool (like a specific API) into a triggered instruction block to see if it reduces noise.
• Add an "Information Gathering" Step: Explicitly prompt your agent to "List all files and read the config before attempting any changes" to see if it reduces "blind" errors.

Ongoing

• Build a "Skill Library": Every time an agent successfully completes a complex workflow (like a specific deployment or data cleanup), save that successful prompt/sequence as a "Workflow Memory" to be injected into future prompts.
• Dual-Track Evaluation: Create a "Fast Sanity" test (e.g., "Can the agent find the login button?") to run during development, and a "Realistic" test (e.g., "Can the agent fix this actual bug?") to run weekly.

Common pitfalls

• The "One Big Prompt" Trap: Trying to make one agent do everything with a massive, conditional prompt often leads to "instruction drift" where the agent forgets the primary goal. Use "Micro-Agents" or explicit hierarchies instead.
• Over-reliance on Vision: While vision is cool, identifying elements in HTML is often more reliable for current models. Don't abandon text-based interaction unless vision provides a specific, necessary advantage.
• Underestimating "Information Gathering": Many developers expect the agent to "just know" what to do. You must explicitly instruct the agent to gather context (read files, check status) before it attempts a "write" action.

Connects to

• CoAct (Global-Local Hierarchy): For those interested in how multi-agent systems can actually manage plans without getting lost.
• SWE-Bench: The gold standard for evaluating if your agent can actually do the job of a software engineer.

If you remember only three things

• Environment & Error Awareness: Agents succeed when they understand the "rules" of the tools they use and can recover when those tools return an error.
• Workflow Memory: Don't make the agent re-solve the same problem twice; persist successful workflows as a "skill library."
• Information Gathering: The best way to stop an agent from "hallucinating" a solution is to force it to gather all necessary information before it acts.

Internalize it

• Reflection questions
  • Where is my current agent "looping," and does it lack information or is it just confused by the environment?
  • If I had to turn a recurring task my agent does into a "Skill," what would that prompt look like?
  • How can I make my agent's "Human-Agent" interface smoother for auditing?
• Flashcards Q: What are the three main ways agents interact with websites? A: 1. Screenshot/Pixel clicking (simplest, least reliable), 2. HTML element identification (no vision), 3. Hybrid/Vision-based (complex). Q: What is the "Micro-Agent" concept? A: A mechanism where specific instructions (like how to use the GitHub API) are injected into the prompt only when a specific trigger (like the word "GitHub") is detected. Q: Why is "Information Gathering" important for agents? A: It prevents the agent from attempting to solve a task without fully understanding the requirements, which is a primary cause of failure. Q: What is the difference between "Fast Sanity Checks" and "Realistic Evaluation"? A: Fast checks (like miniWoB) are cheap and quick for developer iteration; Realistic evaluations (like SWE-Bench) use real-world data to validate actual capability. Q: What is "Workflow Memory" in the context of agents? A: The practice of taking successful past experiences and feeding them back into the prompt to ensure the agent doesn't have to "re-think" a solved problem.

Fidelity note

Confidence is High. This summary is strictly grounded in the transcript of Professor Graham Neubig's presentation at NeurIPS 2024. The "8 Perennial Problems" and the specific papers mentioned (CoAct, SteP, etc.) are directly from the provided text. The distinction between "Implicit" and "Explicit" planning is captured as described by the speaker.