How to Stop Devin From Losing Task Context Between Runs (2026)

Knowledge is scoped to the codebase, not the task

Worth restating because it determines everything downstream. Knowledge is "a collection of instructions and advice that Devin can reference in all sessions." The documented examples are all durable, repo-level material: "code conformance practices, deployment workflows, PR naming conventions, testing workflows, how to interact with proprietary tools and more."

None of those is "the thing we figured out about this bug last Tuesday." Task-level findings aren't in scope for the store, which means they persist only if you deliberately promote them — or write them somewhere else.

Unpinned Knowledge is only used when triggered

The second-biggest cause, and it's a configuration detail people skip. "Knowledge is retrieved based on the Trigger you set. The more specific the trigger (e.g. which file, repo or type of task the Knowledge applies to), the better the retrieval."

And from the best-practices list: "If you want Devin to retrieve the Knowledge note anytime it's working on a session, make sure to pin it to all repositories. Otherwise, you can pin it to a specific repo if the information is only relevant in that context. If Knowledge isn't pinned, it will only be used when triggered so make sure your Trigger Description is clear."

So a Knowledge note you wrote and never pinned is sitting behind a trigger description. If that description is vague, it may simply never fire. The note exists; it isn't reaching the session. This is the same family of failure described in why agents ignore the instruction files you wrote.

There's a genuinely useful affordance here, and it's underused: "Devin will tell you in a session what Knowledge it used; you can see this under 'Accessed Knowledge' in the session chat." That's a direct answer to "did it actually read my note?" — check it before assuming anything.

Auto-generated Knowledge is a starting point, not a record

Devin bootstraps for you: "Devin will automatically generate repo knowledge based on the existing READMEs, file structure and contents of the connected repositories."

Helpful, and it means your Knowledge base starts out describing what your README says — which, in most repositories, is partly out of date. The documented first best practice is exactly this: "Review any auto-generated Knowledge and verify for (a) completeness and (b) accuracy."

Skipping that step leaves you with confident, retrievable, slightly wrong context. That's worse than an empty store, because it gets used.

Devin reads specialized files and skips plain .md

A precise and easily-missed rule: "Devin will automatically pull and update Knowledge based on specialized files in your codebase including .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md, and AGENTS.md. Note that Devin won't automatically pull in more general file types like .md."

Two consequences. First, if your conventions live in docs/engineering-standards.md, Devin isn't pulling them in automatically. The documented recommendation is to fix that: "If you don't have a centralized specialized documentation file in your codebase, we definitely recommend setting one up with a specialized file extension."

Second — and this is the pleasant surprise — if your repo already has CLAUDE.md, AGENTS.md, or .cursorrules from another tool, Devin picks those up. The instruction files you wrote for a different agent are already doing work here.

No repo access means no Knowledge

Stated as a plain caveat: "Note that if you don't give Devin access to the repo, it won't generate any associated Knowledge." If a particular repository feels like a blank slate to Devin, check access before checking anything else.

Re-briefing Devin at the start of every session. Works, and it's the entire cost of the problem paid again each time — the loop in how to stop re-explaining context to AI.

Writing every task finding into Knowledge. Understandable, and it fills a codebase-level store with task-level noise, which degrades retrieval for the material that does belong there.

Pinning everything to all repositories. Guarantees retrieval and puts unrelated context in every session. It's the blunt end of a dial that has a finer setting.

Leaving auto-generated Knowledge unreviewed. The most common shortcut, and it converts a stale README into authoritative-looking guidance.

Keeping a running doc of decisions in the repo as notes.md. Reasonable instinct, wrong extension — Devin won't automatically pull in general .md files.

Assuming coding preferences carry across runs on their own. They carry if they're in Knowledge and reachable. That's the case behind why Devin forgets coding style.

Two jobs. Get Knowledge working properly for codebase-level material, and give task-level reasoning a home that isn't a session.

Review the auto-generated Knowledge today. Completeness and accuracy, as the docs instruct. Delete anything describing a system you retired. Stale entries get retrieved with the same confidence as correct ones.

Decide pin versus trigger for each note. Should always apply? Pin it to all repositories. Only relevant in one repo? Pin it there. Genuinely situational? Leave it triggered — and then write a trigger description specific enough to fire, naming the file, repo, or type of task it applies to.

Create a specialized documentation file if you don't have one. AGENTS.md is a good default: Devin pulls it in automatically, and other agents read it too. If you already maintain CLAUDE.md or .cursorrules, you're covered — those are on the list.

Use "Accessed Knowledge" as your feedback loop. After a session, look at what Devin actually used. If a note you expected isn't listed, the problem is the trigger or the pin, not the writing.

Check repo access on anything that feels blank. No access, no generated Knowledge.

That gets codebase-level context reliable. It still leaves the category the documentation explicitly places outside Knowledge — task-level reasoning. What you tried in the last run and why it failed. The constraint you discovered halfway through. The approach you evaluated and rejected. Promoting all of it into Knowledge is the wrong move: it's not codebase-level, and it dilutes retrieval for what is.

That's what MemoryLake holds: task and project reasoning in a layer your agents query, separate from the repo-level store. Setup is three steps.

Step 1: Create an API key

Sign in to MemoryLake and create an API key. One credential across the tools you connect.

Step 2: Upload your first memories

Short entries, one claim each. The categories that pay for themselves fastest with an autonomous agent:

What was tried and rejected, with the reason. The single highest-value class of entry when the agent works unattended. Without it, run three re-derives what run one already disproved — and spends real time doing it.

Findings from a run that outlive the run. "The staging seed data has no rows after 2024, so date-range tests pass locally and fail there." That's not codebase-level advice and it's not a one-off either.

Constraints that only became visible mid-task. Rate limits, a dependency that behaves differently than documented, an ordering requirement nobody wrote down.

Decisions and the constraint behind them. A convention can go in Knowledge. The argument for it belongs where it can be retrieved and reasoned over.

Step 3: Connect your AI & agents

Connect the tools you use. MemoryLake is reachable over MCP and over an API, so MCP-native agents — Claude Code, Codex, and OpenClaw among them — connect by pointing at the MCP server, while other assistants read the same memory through the API.

Three honest limits. MemoryLake does not write into Devin's Knowledge and isn't a replacement for it — Knowledge is the right place for codebase-level context and you should set it up properly. It holds only what you or your agents write into it, so Step 2 is real work. And it doesn't guarantee compliance: retrievable context isn't enforced configuration.

Run three stops repeating run one. The rejected approaches are written down, so an unattended agent doesn't spend a session rediscovering them.

Knowledge stays clean and retrieval stays sharp. Codebase-level material in the codebase-level store means trigger descriptions match fewer, more relevant things.

"Accessed Knowledge" becomes informative. When the store isn't a dumping ground, seeing what was used tells you something.

Instruction files earn double duty. AGENTS.md and CLAUDE.md feed Devin's Knowledge automatically and are read by other agents, so one file serves several tools.

Task reasoning survives a tool change. What you learned about your own system isn't Devin-specific — the shape covered in episodic memory for AI agents.

Keep Knowledge codebase-level. It's the documented purpose. Task findings go somewhere else or they degrade the store.

Pin what must always apply. Unpinned Knowledge is used only when triggered — that's the documented behavior, not a bug to work around.

Write trigger descriptions that name something. File, repo, or type of task. Specific triggers retrieve better; the docs say so directly.

Review auto-generated Knowledge before trusting it. It's derived from READMEs, file structure, and repo contents, and those age. Verify completeness and accuracy.

Use a specialized file extension. .rules, .mdc, .cursorrules, .windsurf, CLAUDE.md, or AGENTS.md — not plain .md, which isn't pulled in automatically.

Check "Accessed Knowledge" after important sessions. It's the cheapest diagnostic available and most people never open it.

Record rejections immediately. The moment an approach is ruled out is the only moment the reason is fully in your head.

Date anything environmental. Staging quirks and rate limits change. An undated entry becomes a future wrong answer — the general problem in what AI memory is and isn't.

Devin's Knowledge system does persist context across sessions, and its documentation is precise about the boundary: it's for codebase-level rather than task-level context, it's retrieved by the trigger you set unless you pin it, it's auto-generated from material you're expected to review, and it pulls from specialized files rather than general .md ones.

Set those up properly and the repo-level half stops being a problem. Then treat task-level reasoning as its own category — rejections, mid-task discoveries, environmental constraints, the argument behind each decision — and keep it in a layer your agents can query. That's the difference between an agent that starts every run as a competent new hire and one that starts every run as the same new hire on their first day.