how to give an ai agent context about your own work

coding agents got very good at reading code and very bad at knowing why you wrote it.

an agent in your repo can see every file, every commit and every test. it cannot see the call where the api shape was decided, the doc that explained the constraint, the stack overflow answer you copied at midnight, or the slack thread where somebody said "do not touch that field." that context never made it into the repo. it was on your screen and then it was gone.

this is the ai agent context problem, and in 2026 it has a standard shaped solution. here is what actually works.

why agents lack your context in the first place

a model arrives at your problem with two kinds of knowledge and neither is yours.

it has training data, which is the public internet up to a cutoff. it has whatever is in the current context window, which is what you pasted plus what its tools fetched. it does not have your week. per the anthropic economic index, the single most common work task across sampled conversations is searching electronic sources for information, at 4.95%, and 51.38% of usage is augmentation, meaning long iterative sessions rather than one shot answers.

so the dominant use of these tools is a person and a model working a problem together over time. and the model forgets the working part every time the session ends.

what the model context protocol changed

mcp is an open standard for letting a model call your tools and read your data at runtime.

anthropic published it in late 2024 and by 2026 it had become the default integration layer across labs and editors, adopted by openai, google and every serious editor in under 2 years. the useful analogy is a standard plug rather than a standard brain. you write one mcp server and every host that speaks mcp can use it.

the architecture is three parts.

an mcp server is not magic. it is a process that advertises a list of tools with typed inputs, and answers when the model calls one. the research literature is mostly about the hard parts of that at scale, like active tool discovery when there are too many tools to fit in context.

the four sources of context worth wiring up

not all context is equal, and people usually wire them in the wrong order.

1. the repo. free, and every agent does it already. a claude.md or agents.md file at the root is the single highest leverage 20 minutes you can spend, because it is read every session. this is the cheapest claude code context you will ever add.
2. your issue tracker and docs. linear, notion, jira, google docs. these hold decisions. most have an official mcp server now.
3. your communications. email, calendar, meeting transcripts. high value, high risk, so scope the permissions tightly.
4. your own activity. what you actually looked at and did. this is the one almost nobody has, and it is the one that answers "why did we do it this way."

the first three are somebody else's system of record. the fourth is a personal knowledge base for ai that only exists if something was recording.

how to connect ai to your data without regretting it

three questions before you install any mcp server, in this order.

where does the server run? local means the process runs on your machine and your data never needs to leave it to be queried. hosted means a third party holds a token and your data flows through them. both are legitimate. only one of them is defensible if you are handling client work.

what can it write? read only servers are dramatically safer. a server that can send email or push commits is an agent with your credentials, and prompt injection through retrieved content is a live attack path, not a theoretical one.

what does it return? a server that dumps 40,000 characters of raw text into context on every call will blow your window and your bill. good servers return a short summary with pointers and let the model ask for detail, rather than paying for the whole archive on every turn.

if you are wiring up a machine you use for client work, the for engineers page covers the setup we run here.

a worked example: your screen history as an mcp server

the fourth source is the interesting one, so here is how it works in practice.

remynd records the focused window on a mac and runs ocr on it locally, which turns everything you looked at into searchable text sitting in a database on your disk. since august 2026 that archive is exposed to claude code and codex over a local connector.

what that buys you in a session:

• "what was i doing on august 14?" returns the actual apps, documents and pages, not a guess.
• "find where i saw that error message about the keychain." searches the ocr text remynd captured, including text inside screenshots and video calls that no file search can reach.
• "summarize the decisions from the meeting about pricing." pulls from the call and the documents open beside it.

the constraint worth stating plainly: this is read only, it runs against a local database, and it is scoped to what remynd captured. capture, ocr and storage stay on your mac by default and you can exclude apps or sites entirely, but sign in and the cloud agent do reach the network, which we spell out on the security page rather than claiming otherwise.

the part nobody tells you

context is a retrieval problem long before it is a model problem.

teams reach for a bigger window when the actual failure is that the relevant fact was never captured anywhere queryable. no window is large enough to hold a conversation that was never written down. once you have an archive of your own work, a small model with good retrieval beats a large model guessing, and it costs a fraction as much.

that is the whole argument for building the archive first and picking the model second. more on the archive side of it in what is an ai memory app and how to find something you saw on your screen.

download remynd for mac and give your agent something to remember.