Atlas Guide
The research papers behind agentic AI: a reading list for people running agents
By Atlas AI Resources · Published October 27, 2026
Most of the ideas inside today’s AI agents were first tested in research papers: the loop of reasoning and acting, memory, reusable skills, retrieval, teams of agents, and ways to measure and attack them. You don’t need to read every paper to run a few bots well, but knowing where these ideas came from makes it easier to understand what your agents are doing and why they fail. Below are twenty papers we think are worth knowing, grouped by topic, each with what it shows and why it matters when you run agents.
1. Reasoning, acting, and learning from mistakes
How an agent thinks, uses tools, and improves within a task.
What it shows: Has the model interleave written reasoning steps with actions such as searches, so each step can use what the last action returned.
Why it matters: This think, act, observe loop is the basic shape of most agents you run today, so it explains what you see in their transcripts.
What it shows: Trains a model, in a self-supervised way, to decide which APIs to call, when, with what arguments, and how to use the results.
Why it matters: Tool calls are a learned skill, not magic. Clear tool names and descriptions make that choice easier for the model.
What it shows: LATS combines Monte Carlo Tree Search with the model as planner, evaluator, and self-critic, using feedback from the environment to explore several paths.
Why it matters: Trying more than one path and checking results costs more calls but can rescue hard tasks. It is a tradeoff you choose, not a free upgrade.
What it shows: Agents write reflections on task feedback into an episodic memory and use them on the next attempt, without updating model weights.
Why it matters: Written lessons from a failed run can improve the next one. That is the idea behind keeping notes and memory files for your agents.
What it shows: One model drafts an output, critiques it, and revises it in a loop, with no extra training data or fine-tuning.
Why it matters: A review pass before handing work back is cheap to add. It still uses the same model, so it does not replace an outside check.
2. Memory and skills over time
How agents remember and build up reusable abilities.
What it shows: Simulated characters store a natural-language record of their experiences, reflect on it, and retrieve it to plan their behavior.
Why it matters: It is an early, readable design for agent memory: record, reflect, retrieve. Many memory features follow a similar pattern.
What it shows: Treats the context window like fast memory and outside storage like slow memory, and lets the model move information between them.
Why it matters: Context is limited. Long-running agents need a plan for what stays in view and what gets stored and looked up later.
What it shows: A Minecraft agent with an automatic curriculum, a growing library of skills stored as code, and a prompting loop that uses errors and self-checks.
Why it matters: Saving a working procedure as a reusable skill is how an agent stops solving the same problem from scratch.
3. Multi-agent systems
Several agents working together.
What it shows: An open-source framework for building apps from agents that converse, combining models, human input, and tools.
Why it matters: It shows how roles and conversation patterns between agents can be designed on purpose, including where a human joins in.
What it shows: Encodes standard operating procedures into prompts so role-based agents produce and check structured intermediate work.
Why it matters: Naively chaining agents can compound errors. Clear roles and written handoff formats help, which is useful for any small fleet.
4. Retrieval: grounding agents in real information
Fetching documents instead of relying on what the model remembers.
What it shows: Lewis et al. combine a generator with retrieval from a document index, so answers draw on outside text, not only the model's parameters.
Why it matters: This is where the term RAG comes from. Knowing it helps you judge any tool that says it searches your documents.
What it shows: Trains a model to decide when to retrieve and to critique the passages it retrieves and its own output.
Why it matters: Retrieving every time, whether or not it helps, can hurt answers. Retrieval should be a decision, with a quality check.
What it shows: CRAG adds a lightweight evaluator that scores retrieved documents and switches to other actions when retrieval looks poor.
Why it matters: Retrieval can go wrong. Plan for what your agent should do when the search results are weak.
5. Benchmarks: measuring agents on real tasks
How researchers test agents, and what the tests leave out.
What it shows: A benchmark of 2,294 problems drawn from real GitHub issues and pull requests across 12 popular Python repositories.
Why it matters: It is the benchmark behind many coding-agent claims. Knowing how it is built helps you read those claims carefully.
What it shows: Argues that agents are a new kind of user and builds an interface designed for them to edit code, navigate repositories, and run tests.
Why it matters: The tools and interface you give an agent shape how well it works, often as much as the model does.
What it shows: A reproducible environment of working websites in four areas: e-commerce, forums, collaborative software development, and content management.
Why it matters: Browsing agents are tested on realistic sites here. It is a reminder that web tasks are harder than demos suggest.
What it shows: A benchmark with 8 distinct environments for testing models as agents on reasoning and decision-making.
Why it matters: It compares many models in the same agent settings, which helps when you pick a model for agent work.
What it shows: Tests agents in conversations with a simulated user, with domain tools and policy rules, and adds a pass^k metric for reliability over repeated trials.
Why it matters: Getting a task right once is not the same as getting it right every time. Reliability is what matters for routines.
6. Safety and honest evaluation
Attacks on agents and how to judge results.
What it shows: An extensible environment with 97 realistic tasks, such as managing email, for testing prompt injection attacks and defenses on tool-using agents.
Why it matters: Data returned by tools can hijack an agent. Anyone connecting agents to email or the web should understand this risk.
What it shows: Reviews agent benchmarks and evaluation practices, criticizes a narrow focus on accuracy, and argues for weighing cost alongside accuracy.
Why it matters: A more complex agent is not automatically better. Judge agents by results and cost together.
A suggested reading order
- Start with the loop: ReAct, then Reflexion and Self-Refine.
- Then tools and retrieval: Toolformer, the original RAG paper, then Self-RAG and CRAG.
- Then memory and skills: Generative Agents, MemGPT, Voyager.
- Then teams: AutoGen and MetaGPT.
- Then measurement: SWE-bench, SWE-agent, WebArena, AgentBench, τ-bench, and LATS if you want to see search in action.
- Finish with safety and honesty: AgentDojo, then AI Agents That Matter.
Our advice
- Read the abstract and the figures first. You can get most of the practical idea without the math.
- Map each paper to one of your bots. Ask where your setup already does this and where it doesn’t.
- Treat benchmark scores as context, not promises. Your tasks, tools, and data are different from any test set.
- Copy the habits, not the complexity. A written reflection after a failed run or a saved skill is often enough.
- Read the safety papers before you connect email or the web. Then keep sends, deletes, and spending behind your approval.
- Watch cost as closely as quality. Extra loops, critics, and agents add calls. Check they earn their place.
- Revisit the list now and then. Newer work builds on these papers, and some details will age.
Frameworks are not the same as engineering
Learning a framework teaches you which buttons to press. These papers teach you why the buttons exist: why an agent loops, why it forgets, why retrieval misleads it, and why a good score can hide a fragile system. Frameworks change every few months. The engineering underneath changes much more slowly, and it is what lets you fix an agent when the framework’s defaults stop working.
Related: What is MCP (Model Context Protocol)? · Keeping AI agents safe from prompt injection · Agent memory for AI fleets · Small AI fleets and handoffs