Where we stand: KarmaBox builds a sovereign AI workspace for individuals and small teams. Beacon, discussed below, is an open-source project from Asymptote Labs. KarmaBox has no partnership or integration with Asymptote Labs or Beacon. Everything we say about Beacon and the funding round comes from the company's own announcement and docs, so treat it as vendor-reported. The part about our own product is labeled and comes near the end.
Tuesday, 9:40 a.m.
A scenario first. It is a composite built from how many engineers describe their week, not a real person or a real ticket.
You are three weeks into refactoring a payment webhook. Yesterday in Cursor you finally worked out why retries kept failing: the repo has a special signing rule tucked into an unremarkable middleware file, and the README never mentions it. You left behind a long thread, a few corrected prompts and a patch that actually works.
Today a teammate suggests Claude Code for the multi-file part, so you open it. The new session is polite and completely blank. It does not know the signing rule. It does not know you lost an afternoon in a dead end yesterday. It certainly does not know that the "obvious" fix was already tried and made production worse.
So you explain it all again. Or you paste yesterday's thread into a scratch file and hope the new agent reads it. Or you give up on switching and stay in Cursor, even though the next chunk of work clearly suits another tool. None of that is memory. It is a workaround. The root problem: what your AI learned is locked inside the tool that collected it.
Most AI coding assistants keep context inside their own product, so switching tools wipes out the corrections, conventions and dead ends you already paid for. Asymptote Labs' open-source Beacon is a local-first memory layer that records activity across 20+ coding agents and turns human-reviewed lessons into reusable project memory. The deeper question is ownership: working context and identity should travel with the person, not rent space in whatever tool you used yesterday.
What actually gets lost
People hear "context" and think about window size. In day-to-day agent work, the expensive loss is not tokens. It is experience that only exists inside one chat. Five kinds come up again and again: corrections — "Don't touch that migration," "We already tried that library," "The webhook uses the old signing key, not the one in .env.example"; repo conventions — naming, folder layout, which test suite counts, which file is the real source of truth; dead ends — the agent already burned forty minutes going the wrong way, and without a record, the next session burns them again; approvals — what a human already allowed or blocked last time; and handoffs — the person holding the key thread is on vacation, and the thread sits in an account only they can open. None of this is exotic. It is the tax you pay for using several good tools at once.
An illustration (not survey data): a mid-sized product team uses Cursor for interactive edits, Claude Code for long refactors and a cloud agent that opens PRs overnight. Over one month, the same flaky integration test gets "fixed" four times, once per tool, because nothing kept the fix that finally worked. Beyond the lost hours, the quieter cost is that teams stop switching tools. Not because the current one is best, but because switching means amnesia.
What happened this week: Asymptote Labs and Beacon
On October 20, 2026, New York-based Asymptote Labs announced an oversubscribed $5.5 million seed round led by Tower Research Ventures, with Lytical Ventures, 1984 Ventures and South Park Commons participating. Co-founders Justin D'Souza (CEO) and Shukan Shah (CTO) were both early engineers at Doppel.
At the center is Beacon, an MIT-licensed open-source project launched in May 2026. According to the announcement, the Beacon site and its docs (all vendor-reported), it records activity from 20+ agent tools including Claude Code, Codex, Cursor and OpenCode, normalizing events into a schema that extends OpenTelemetry; it defaults to local-first, with routine recording staying on the machine, hooks making no external eval calls, and dry runs fully offline; memory is opt-in and human-reviewed, with the system proposing candidate lessons that a person approves before they enter project memory; storage is a local memory.db, scoped per project by default rather than shared machine-wide; reuse happens through MCP tool calls or as installed Agent Skills; and Beacon Cloud is optional with its own review flow. One distinction worth keeping: Asymptote also sells an enterprise platform on top of Beacon, focused on runtime visibility, risk detection and policy guardrails — a separate commercial product from the open-source memory loop this piece cares about.
Taking it apart: the layers of a cross-tool memory system
Set the product name aside. Any agent memory layer that works across tools needs roughly five layers: record, capturing prompts, tool calls, edits, approvals and outcomes across tools, without which every tool keeps its own private diary; normalize, mapping events from different tools into one format, without which the "same" action can't be compared across tools; distill, pulling candidate lessons out of raw logs, without which you get a mountain of logs and nothing reusable; gate, human review, scope, retention and redaction, without which wrong or sensitive content hardens into "knowledge"; and supply, handing approved memory to the next agent, without which lessons sit in a database nobody queries. Beacon is one concrete implementation, focused on recording, normalizing, reviewed distillation and local supply. Other projects will do it differently, but the shape is bigger than any single repo.
Two design choices are worth remembering. Human review beats "auto-learning": if every session quietly rewrites project instructions, you inherit every confident hallucination; needing a human nod is slower, and much safer. Project scope beats one global pool: a signing rule that holds in payments-service may be wrong in marketing-site, and scoping by project matches how engineers already think about repos. One more detail: Beacon's guidance says that when memory and repo docs disagree, the docs win — it positions itself as a supplement to documentation, not a replacement.
What it is not
This category is easy to oversell, so a few boundaries: not a bigger context window — stuffing yesterday's whole thread into today's prompt is a brute-force patch, not a memory system; not instant expertise — reviewed lessons can still be wrong, stale or too narrow, and a human stays the editor; not a substitute for docs — READMEs, architecture decision records and tests remain the authority, and memory supplements them; and not a fix for every enterprise multi-agent problem — runtime safety, spend control and identity are neighboring problems, not the same one.
Under the tool war is an ownership question
Amnesia on switching is the visible pain. Ownership is the layer underneath. If your corrections live only in one vendor's chat history, then leaving the vendor means leaving your memory. Your company has no reliable record of how agents actually changed production. And your own working habits, the prompts, preferences and "never do X" lists, are rented.
Asymptote's announcement takes a side for enterprises: agent session history should belong to the company, not to a tool. For solo developers and small teams we would push one step further: session history should belong to the people doing the work, with clear lines on what is personal, what belongs to the project and what belongs to the employer. That is why this topic ends up at identity, not just logs.
An agent that has worked with you for six months slowly accumulates things: how you like diff summaries written, which systems are fragile, which client data must never be used as an example, which commands need a human click before they run. If all of that is locked in one vendor account, you do not own an assistant. You hold a lease. When the lease ends, the know-how evaporates.
Memory without identity is just a file. Identity without memory is a nameplate on an empty office.
Tie the two together and memory can move across tools, machines and time, and other people can verify who it came from and what it is allowed to do.
Three failure modes we keep seeing
These are illustrative patterns, not research findings. One: chat archaeology — someone searches old Cursor threads like case files, and the one useful sentence is buried under twenty failed attempts, with new hires inheriting "ask Sam, he knows why" instead of a reviewed lesson. Two: the prompt collage — a shared doc fills up with "prompts that work," and nobody knows which repo they apply to, whether they survived the last dependency upgrade or who checked them; it looks like knowledge and behaves like clutter. Three: lock-in by amnesia — the team outgrew a tool long ago but won't switch, because switching means re-teaching six months of corrections, and the real migration cost is not features, it is memory. A cross-tool, reviewed memory layer helps with all three: it replaces raw chat logs with short approved lessons, keeps those lessons scoped to the project and makes leaving a tool less scary, because the lessons were never the tool's property in the first place.
In fairness to the objections
| Common objection | How to respond |
|---|---|
| "I only use one tool." | Then cross-tool memory is optional for you. Memory between sessions in the same tool still matters, and the ownership question arrives the day you change vendors. |
| "Our repo docs are excellent." | Great. Then memory should hold only the corrections your docs haven't absorbed yet. Once a lesson stabilizes, promote it into the README and delete the soft memory. |
| "Logging agent activity is itself a security risk." | Yes, if logs get uploaded indiscriminately. Local-first defaults, redaction, retention limits and human review exist precisely because raw traces can contain secrets. Treat them like production logs: record less, scope tightly, control access. |
| "Automatic memory makes agents stubborn." | It can. That is why reviewed writes are the interesting design, rather than silently feeding in everything you typed. |
How a small team can try it
An illustrative starting path, not a Beacon tutorial and not a guarantee. Pick one repo, the one where you already bounce between two tools. Turn on local recording for just those two tools, to keep the blast radius small. Write nothing automatically in week one — only collect. Review five sessions where a human had to correct the agent, write each lesson as one paragraph and approve only those. Supply the approved memory to the second tool through whatever channel you trust: MCP, a skill file, or internal docs generated from the same source. Track one metric: how often the second tool repeats an already-corrected mistake — if it doesn't drop, the lessons are too vague or nobody is using the channel. And settle ownership: memory on a personal machine, skills in the team repo and telemetry the employer keeps are three different buckets. Label them. This path is compatible with Beacon's public model, and it also works with a lighter in-house setup. Discipline matters more than the brand.
What KarmaBox does here
This is product information about our own work, not an independent review. KarmaBox is a "Sovereign AI Workspace for Your AI Avatar." Beacon handles memory migration between coding agents. KarmaBox cares about the other half of the same problem: keeping working context and identity together, and yours. Memory follows the avatar, not the model — switch between cloud models, local models and your own GPU, and your avatars and history stay intact. A local knowledge base keeps documents, preferences and working context on your device or private cloud. Each avatar carries a signed did:wba identity, so others can check who it is and what it may do. Multiple avatars collaborate, splitting the work while context moves within one space. Key actions need your OK — sending, publishing, spending and deleting require your confirmation, enforced server-side rather than by politely asking the model in a prompt. Local mode counts as 0 tokens, with no usage caps.
Memory isn't only about whether something is remembered. It's also about whether what's remembered can be checked. The retrieval method behind KarmaBox's local knowledge base is called BFS (Bubble File Search), and it shares the same instinct as the reviewed-memory approach above: most document Q&A tools chop files into small chunks and match on keywords, so each chunk is an isolated fragment and an answer can look right while missing the context that would have changed it. BFS makes each chunk remember where it sits in the original file and what surrounds it, so an answer can carry its context back with it and point to where in the source it came from. Put differently, an avatar's memory shouldn't be a few assertions pulled out of a pile — it should be traceable and verifiable. That's the same worry as Beacon's insistence on human-reviewed memory, just showing up in a different corner of the product.
To avoid confusion, here is a side-by-side. The left column is Beacon's public description, the right is KarmaBox's product description. They are independent projects:
| Concern | Beacon (public description) | KarmaBox (product description) |
|---|---|---|
| Where memory lives | Local-first, local memory.db, optional cloud | Your device or private cloud |
| Coverage | 20+ coding-agent tools | Multiple AI avatars, plus multi-model switching |
| What is owned | Agent activity and reviewed project memory | Avatar identity, working context, permissions |
| How it's reused | Via MCP and Agent Skills after human approval | Avatar continuity, permission boundaries, bring your own model |
| Can the answer be verified | — | BFS retrieval keeps chunk context and the source location, so answers can be traced back |
An illustration (not a customer case): an avatar has spent three weeks organizing a client's requirements and decisions, and halfway through you switch its underlying model from cloud to local. The next day it still remembers which requests were rejected and what must never be said to the client, because that context lives in your space, not with a model vendor. If that approach is useful to you, take a look at karmaboxai.com. If it isn't a fit, no problem: the steps above work with any tool.
Frequently asked questions
Q: What's the actual root cause behind losing everything when you switch AI tools?
Most AI coding assistants store your corrections, conventions and hard-won lessons inside their own product, not with you as a person. Switching tools means leaving that experience behind.
Q: How does Beacon specifically address this?
A: It's an MIT-licensed open-source project from Asymptote Labs that records activity across 20+ coding-agent tools like Claude Code, Cursor and Codex, turns it into human-reviewed project memory reusable across tools, and defaults to local-first storage.
Q: Why does memory need human review instead of letting the agent learn on its own?
A: If every session silently rewrites project instructions, you inherit every confident hallucination along with the useful lessons. Human review is slower but prevents a wrong "lesson" from hardening into something treated as settled fact — a point this article keeps coming back to.
Q: How does this connect to "memory should belong to the person"?
A: Beacon solves whether memory can move across tools. Ownership solves who that memory belongs to once it has moved. Neither is enough alone — without ownership, portable memory can simply migrate into another vendor's account, and the same problem resurfaces somewhere else.
Q: What does KarmaBox do in this direction?
A: Memory follows the avatar rather than the model, and stays local or on private cloud; each avatar has a verifiable did:wba identity; and the retrieval method (BFS) lets memory trace back to its source instead of being a handful of assertions with no clear origin. This is independent of Beacon, with no integration between them, but points the same direction: keeping experience and identity together, in the hands of the person using them.
Closing thought
Amnesia when you switch tools sounds like a productivity problem. Look closer and it is an ownership problem. What an engineer spends months teaching an AI should not reset because they changed editors, and it should not belong to a vendor by default. An open-source memory layer like Beacon is half of freeing experience from the tool. Keeping identity and context together in your own hands is the other half. Do both, and your AI is actually building up value for you, not for someone else.
Data note: Information about Asymptote Labs' funding and Beacon's features comes from company announcements and project documentation. It is vendor-reported and has not been independently audited. Scenarios and team examples are illustrative, not survey data or customer cases.