MyContext: A Local-First Context Layer for AI

Every AI tool you use starts from nothing. It doesn't know who you work with, what you decided last month, or which of the four projects you mentioned is the one that matters. So you re-explain, every time, and the explaining is most of the work.

MyContext is a personal context layer for AI that tries to fix this from the opposite end: instead of each app building its own memory, one local desktop application ingests your work sources, keeps a private evolving picture of what you know and who you work with, and lets models and agents retrieve from it under your control.

openTrinity/mycontext, with a site at mycontext.md, opened on August 3, 2026 and reached 524 stars by August 10. Electron and React on the front, TypeScript throughout, and one licence detail worth knowing before you read further: it's Elastic License 2.0, which is source-available rather than open source.

Key Takeaways:

• Local by default. Conversations, documents, indexes and derived context live in your own data directory on your own machine.
• Working ingestion today covers instant messaging, documents and meeting records. Calendars, tasks, approvals and mail are designed for, not shipped.
• The Elastic Licence lets you use, modify and self-host it, including inside a company, but forbids offering it to third parties as a hosted or managed service.
• Search combines local full-text, semantic retrieval and graph queries, and falls back to ranked local results when the agent runtime is unavailable rather than inventing an answer.
• The maintainers call it an evolving working prototype. Take them at their word.

What MyContext is

A desktop app that sits between your work systems and whatever AI you point at them.

Source connectors bring in authorised data through a shared interface. Incremental ingestion keeps local copies current, tracks progress and fills gaps without re-reading everything. A context pipeline turns raw records into structured facts, preferences, relationship context and reusable working knowledge. Retrieval and graph services combine full-text search, semantic similarity, entity relationships and source-scoped evidence. An agent runtime gives search and drafting controlled access with isolated workspaces and scoped permissions.

Three experiences sit on top. The personal context graph links people, projects, topics, events, conversations and supporting facts, explorable from your own point of view, with the underlying evidence reachable rather than replaced by a summary. Search and answers works in natural language across your history. And the digital self uses your communication patterns and relationship history to understand incoming messages, recall background and draft replies in your style.

Sending anything is gated. Action guardrails put sending, deletion and other consequential operations behind explicit confirmation, which is the correct default for a system with access to every conversation you've had.

Local-first versus cloud context, and what actually differs

The privacy argument is the obvious one and it's real: your messages, documents and meeting records stay in a directory on your machine rather than being uploaded to a service that indexes them.

But the more interesting difference is who owns the relationship. A hosted memory service holds your context and rents it back to you through its own interface, which means the context is only as portable as the vendor allows and only as durable as the company. A local layer inverts that. The project's stated principle is that AI is a consumer, not the owner: models and agents reach the context through controlled interfaces, and you hold the data and the permissions.

There's a real cost on the other side, and it's the same one every local-first tool pays. Your context lives on one machine. Nothing is available from your phone, nothing survives the laptop dying without a backup you arranged, and nothing keeps ingesting while the machine is asleep. Cloud services solve those problems by taking custody, which is the trade in one sentence.

Worth separating two ideas that get conflated here. A durable store of what you know is not the same as an agent doing work with it, a distinction we've picked at in agent memory versus chat history. MyContext is squarely the first thing.

What it actually ingests today

Check this before assuming it covers your stack, because the README distinguishes carefully between shipped and designed-for.

Working ingestion paths exist for instant messaging conversations, documents and meeting records. The source model is built to extend to calendars, tasks and approvals, mail, local work artefacts, agent interactions and other sources, without coupling the rest of the product to any one provider. That's an architectural commitment, not a feature list, and the difference matters if you were expecting your calendar to be in there.

The stated design goal is that MyContext shouldn't become another silo: connect personal work data once, keep coherent context over time, expose it to whichever AI tools you choose. Achieving that depends entirely on how many connectors get written and how well they hold up, which is the part nobody can evaluate from a README six days after launch.

One behaviour deserves credit. If the agent runtime isn't available, search degrades to ranked local results rather than producing an answer anyway. A tool that says "here are the documents" instead of confidently hallucinating a summary is making the right call, and plenty of shipped products don't.

The licence, which is not what most people will assume

Elastic License 2.0. Not MIT, not Apache, not open source under the OSI definition, and the difference has practical consequences.

What you may do: use it, modify it, self-host it, run it inside your company, read all the source. What you may not do: provide it to third parties as a hosted or managed service. Components under kl-graph/ and vendor/ keep their own licences.

For an individual, this changes nothing at all. For a company deploying it internally, also nothing. For anyone considering wrapping it into a product, it's the whole question, and the answer is no without a separate agreement.

Calling it "open source" in a procurement document would be inaccurate. Source-available is the right term, and it's the same category as the licence changes Elastic, MongoDB and others made for the same reason: they wanted a community without funding a competitor's SaaS.

Should you run it?

If your work genuinely lives across scattered messages, docs and meetings, and re-explaining that context to an AI several times a day is a real cost, this is a serious attempt at the problem with a coherent set of principles behind it: context organised around the person rather than the app, evidence kept next to the answers, and irreversible actions behind a confirmation.

If you're looking for something dependable, wait. The project describes itself as an evolving working prototype, has no tagged releases, and is a week old. Its core desktop flow, local data layer, search, context graph and digital-self workflow are implemented; the source coverage that determines whether any of it is useful to you is the part still expanding.

The idea worth watching is the shape, not this implementation. A personal context layer for AI that several tools can read from, owned by the person rather than by whichever vendor got there first, is a better architecture than every app keeping its own partial memory. Whether it arrives as a local desktop app, an MCP server, or something nobody has built yet is an open question, and the context engineering problem underneath it isn't going away.

Evidence before answers, which is the principle worth copying

Five principles are listed in the README, and one of them is doing more work than the rest: evidence before answers, meaning source references stay available for review rather than being consumed into a summary.

Anyone who has asked an AI tool about their own documents knows why that matters. You get back a fluent paragraph asserting something about your project, and the only way to check it is to go find the original yourself, at which point the tool has saved you nothing. Worse, the paragraph is usually right, which trains you to stop checking, and then it's wrong about the one that counted.

A personal context layer for AI built around evidence changes what you do with a wrong answer. The claim links to the message it came from. You open it, see the date, see who said it, and see that the decision was reversed two days later in a thread the retrieval missed. That's a recoverable failure. A summary with no sources isn't.

The related principle, that irreversible or externally visible operations require explicit confirmation, comes from the same instinct. Both assume the system will be wrong sometimes and design for the moment it is, which is rarer in this category than it should be.

FAQ

Is MyContext free and open source?

Free to use and fully source-available, but not open source in the OSI sense. It's licensed under Elastic License 2.0: use, modify and self-host freely, including within a company, with one restriction, you may not offer it to third parties as a hosted or managed service. Third-party components under kl-graph/ and vendor/ carry their own licences.

What does local-first mean for my data?

Personal work data and indexes live in your own data directory on your machine. Conversations, documents, source references, indexes and derived context are stored locally rather than uploaded, and the project's principles state that models and agents are consumers of that context rather than owners of it.

Which sources does MyContext connect to?

Today: instant messaging conversations, documents and meeting records. The architecture is designed to extend to calendars, tasks and approvals, mail, local work artefacts and agent interactions, but those aren't shipped ingestion paths as of August 2026.

What is the "digital self"?

A drafting layer that uses your personal context, communication patterns and relationship-specific history to understand incoming messages, recall relevant background and prepare replies in your style. It drafts; it doesn't send. Sending and other consequential actions need explicit authorisation.

Is MyContext ready for daily use?

The maintainers say to treat it as an evolving working prototype rather than a finished product. The desktop flow, local data layer, search, context graph and digital-self workflow are implemented, while source coverage and external integrations are still expanding. There are no tagged releases yet.