Which approach to agent context should you try first?

How it helps

An AGENTS.md file gives compatible agents a set of project instructions: how to run tests, which conventions to follow, and what to be careful with. You keep those instructions alongside the code, where you can review and update them.

It works well when you keep correcting agents on the same stable rules: use this test command, follow these conventions, leave generated files alone. Compatible agents can use the same instructions across sessions. Other tools may have their own instruction-file formats.

Where it reaches its limits

The catch is that the file only changes when you or an agent updates it. A decision made in yesterday’s session won’t appear there automatically. Tools also discover and load instructions according to their own rules, and the loaded text takes up space in the model’s context window.

You can record changing decisions and handoffs in repository files too. As that material grows, someone has to keep it current, and the agent needs a way to find the relevant parts without loading everything.

When to try it first

Try this first if your main frustration is repeating project rules. If you’re repeatedly explaining what happened and why, you’ll also need a way to preserve and retrieve that knowledge.

How it helps

Built-in memory can remember preferences and project facts within a tool you already use. It can be a convenient starting point when most of your work stays in that tool.

Where it reaches its limits

The catch is visibility and control. The tool may choose what to remember and when to use it without making either obvious. Even if you can eventually inspect the stored memory, it may be hard to see which memories influenced a particular answer.

That matters because a mistaken assumption, an outdated decision, or a preference that only applied to one task can shape future work. You can end up repeatedly correcting behavior without realizing a saved memory is driving it.

Also check where the memory applies. Some tools separate it by project; others apply it more broadly across your work. Without clear boundaries, a decision from one project can influence another where it doesn’t belong.

These differences come from how the tool stores, scopes, and retrieves memories. They affect what the model receives in a future session.

When to try it first

Try this first if you mainly want continuity within one tool and can easily inspect, correct, remove, and scope its memories. If you work across tools, check whether those tools can access the memory too.

How it helps

A knowledge vault can hold decisions, research, meeting notes, experiments, and lessons in a system such as Obsidian or Notion. Links between notes can give it a relationship graph, helping both people and agents explore how the knowledge fits together.

A vault works best with deliberate curation: useful relationships, clear project boundaries, and a distinction between current decisions and earlier thinking.

Where it reaches its limits

The agent still has to navigate those relationships and judge what matters for its task. How much of that work falls to the model depends on the search and retrieval capabilities you connect. An agent may handle simple questions well, then struggle when an answer requires piecing together several notes or resolving conflicting conclusions.

There’s setup and maintenance work too. You need to organize the vault, connect the agent, establish how discoveries get added, and keep old decisions from looking current. That effort can be worthwhile when the vault also serves as a useful reference for people.

Control over hosting

One advantage is control over where the knowledge lives. Depending on the system you choose, you can keep it on your own machine or host it on a private server. Check the agent connection as well: locally stored notes may still be sent to a hosted model when it reads them.

When to try it first

Try this first if you want a curated knowledge base for yourself and your agents, and are willing to maintain it. Test whether your agent can use connected knowledge on a difficult task, beyond simply finding individual notes.

How it helps

Sometimes the information your agent needs already lives in tickets, documentation, a database, or another work system. A job-specific MCP server exposes tools that let a compatible agent query that source directly.

The advantage is access to context specific to the job, without copying everything into a separate knowledge base. If the answer lives in your issue tracker, the agent can look there.

Where it reaches its limits

The tradeoff is that each server can handle context differently. What it exposes, how you search it, what its responses contain, and whether it supports updates depend on the integration. Access to tickets does not automatically include the reasoning from a coding session unless someone recorded it there.

The agent also has to choose among the available tools. As you connect more systems, it may consult the wrong source or skip one you expected it to use. Tool descriptions and routing support help, but a connection alone doesn’t ensure the right context reaches the task.

When to try it first

Try this first if the knowledge you need already has a home and an integration can make it available. Check whether the agent consults the intended sources and can connect information across them.