An experiment with local-first software, AI coding agents, shared memory, and the strange habit of building things just to see if they can work.

It started with a very ordinary frustration.

I was working on a project, switching between my editor, terminal, browser, and a coding agent. Nothing unusual. Just another day of development.

At some point, I found myself repeating something I had already explained.

The project structure. A decision we'd made earlier. What had already been implemented. What was still pending.

And I remember thinking:

Why am I explaining this again?

Not because explaining things is difficult. But because the information already existed somewhere. In an earlier conversation, a terminal session, a document, or simply in my head.

Yet every time I switched tools, some part of that context seemed to disappear.

That was the tiny frustration that started this experiment.

I didn't have a business idea. I wasn't trying to build the next developer productivity tool.

I just wanted to see if I could make my Mac a little more aware of what I was doing.

So I started building something I called Bhai.

Yes, Bhai. Because naming a serious developer tool something completely unserious felt appropriate.

It Was Supposed to Be a Small Thing

The original idea was straightforward.

What if I could type something like:

bhai memory dekh

And get useful information about my Mac?

Or ask Bhai to open a project, inspect its Git status, or help with the small repetitive tasks that come with development?

I didn't want another chatbot connected to an API.

I wanted something local. Fast. Predictable. Something that could understand a handful of commands and execute them without needing an LLM to interpret every sentence.

So I started with Electron, React, TypeScript, and SQLite.

A small macOS menu-bar application. A floating panel. Some deterministic commands. Local storage.

Nothing particularly revolutionary.

And for a while, that was the entire plan.

But building side projects has a funny way of changing the questions you're trying to answer.

The more I worked on Bhai, the less interested I became in asking it to check my RAM.

Something else was bothering me.

Why Does Every AI Agent Feel Like a New Colleague on Their First Day?

I'd been experimenting with different AI coding agents.

Claude Code for one task. Codex for another. Sometimes an agent inside an editor.

They're all capable tools, but there's a frustrating moment when you move from one to another.

The new agent often needs to understand things the previous agent already figured out.

Why a certain approach was rejected.

Which files were changed.

What broke during testing.

Which architectural decision should not be revisited.

What work remains unfinished.

Of course, there are ways around this.

You can maintain an AGENTS.md file. Write documentation. Create handoff notes. Give the new agent a detailed prompt.

But I kept coming back to one question:

What if project context didn't belong to any individual AI agent?

What if it belonged to the project itself?

And every agent could contribute to it?

That idea was much more interesting to me than a macOS command assistant.

So Bhai slowly became something else.

Giving Different Agents a Shared Notebook

I started experimenting with a local project memory system.

The concept was simple.

Imagine Claude Code is working on an authentication feature.

During the session, it discovers an important constraint, makes an architectural decision, modifies some files, and encounters a blocker.

Instead of leaving that information buried in a conversation, it can record a few structured checkpoints.

Something like:

Authentication middleware implemented.

Existing session validation must remain backward-compatible.

Unit tests passed. Protected-route integration tests are still pending.

Later, I open Codex.

Codex asks Bhai for the latest project context, retrieves the previous handoff, and can see where the work stopped.

The idea is not to make one agent remember another agent's entire conversation.

It's to give both agents access to a small, durable record of what matters.

I used the Model Context Protocol (MCP) to connect the agents to Bhai.

Underneath, it's a local SQLite database, a permission-controlled MCP bridge, and a set of tools for reading and contributing project knowledge.

I also gave the MCP tools slightly ridiculous Romanized-Hinglish names.

yebata — tell me the relevant context.

yesavekar — save this checkpoint.

kahanthe — where did we leave off?

yaadrakh — remember this decision.

I could have used conventional names.

But honestly, where's the fun in that?

The underlying operations still have precise contracts. The unusual names are just part of Bhai's personality.

Then Came the Memory Problem

Once agents could write checkpoints, another question appeared.

What happens after a hundred checkpoints?

Or five hundred?

If Bhai simply collects everything and sends it to the next agent, I've recreated the same problem I was trying to solve.

Too much context.

Too much repetition.

Too many historical details that might no longer matter.

So I started building a deterministic context-compaction layer.

The goal was to reduce redundant information without throwing away things that should remain important.

Repeated progress updates could be merged.

Architectural decisions needed to survive.

Unresolved blockers needed to remain visible.

Conflicting claims couldn't simply overwrite each other.

If one agent claimed a service used port 5001 and another claimed 5002, Bhai shouldn't silently pick the latest answer and pretend it was a verified fact.

It should preserve that uncertainty.

I also experimented with three different context sizes:

  • Quick: Just enough to orient an agent.
  • Task: The relevant details for the current work.
  • Deep: More comprehensive architectural and historical context.

The entire process could work without a cloud LLM.

I explored optional local-model assistance, but the deterministic layer was always supposed to work by itself.

That was an important constraint for me.

I wanted Bhai to remain useful even when the internet wasn't available.

A Result That Looked Almost Too Good

At one point, I ran a synthetic compaction experiment involving 100 checkpoints.

The raw checkpoint history was estimated at approximately 6,985 tokens.

After compaction, it was around 594 tokens.

<escape>That's roughly a 91% reduction in the amount of checkpoint text.</escape>

My first reaction was pretty much:

Okay, that's interesting.

But then I started questioning what that number actually meant.

Did it prove an AI coding agent would use 91% fewer tokens?

No.

Did it prove that the compacted context preserved everything an agent would need?

Not necessarily.

Was the benchmark representative of a real project, with messy context, outdated assumptions, and incomplete documentation?

Not yet.

And this distinction matters.

Compressing information is relatively easy. Compressing information without losing what matters is the actual problem.

The result was encouraging, but it wasn't proof of better real-world coding-agent performance.

That would require actual tasks, real agent sessions, and comparisons against approaches like AGENTS.md and ordinary repository exploration.

It was a good reminder not to confuse an impressive benchmark with a solved problem.

I Kept Building Anyway

By this point, Bhai had grown well beyond its original purpose.

There was a local memory engine, structured checkpoints, architectural decisions, tasks, handoffs, context packs, agent permissions, and a desktop interface to browse everything.

I had also spent time thinking about process supervision, local developer services, and restoring development environments.

The architecture was becoming more sophisticated.

But something strange was happening.

Every time I finished one feature, I could think of three more.

And every time I asked myself what made Bhai genuinely different from existing tools, I struggled to give a convincing answer.

Sure, individual pieces were useful.

But was the complete experience compelling enough that another developer would install and keep using it?

I didn't know.

And I realized I had spent much more time answering:

Can I build this?

Than asking:

Does this actually need to exist?

Those are two very different questions.

The Hardest Part Wasn't Technical

The technical problems were interesting.

How do you isolate local processes safely?

How do you prevent MCP clients from accessing projects they aren't authorized to use?

How do you preserve decisions without accumulating endless context?

How do you distinguish agent-reported claims from verified facts?

How do you keep the whole system local-first?

Each problem had trade-offs I enjoyed thinking through.

But the most difficult question was surprisingly nontechnical.

Why would someone choose Bhai over the tools they already have?

I had built pieces of a developer assistant.

I hadn't yet discovered its defining reason to exist.

There's a temptation at this point to keep building.

Maybe the next feature will make everything click.

Maybe adding workflows will solve it.

Maybe restoring an entire development workspace will finally make the product feel complete.

And sometimes that approach works.

But I didn't want to keep expanding the project just because I'd already invested time in it.

So I decided to pause.

Not because the experiment failed.

And not because I regret building it.

I just felt that the next thing I needed wasn't another implementation phase.

It was a better understanding of the problem.

What I Actually Got Out of It

Looking back, I learned more from this experiment than I expected.

I got to explore local-first application architecture, Electron's process boundaries, SQLite persistence, MCP integrations, structured agent memory, context compaction, and a surprising number of security and reliability edge cases.

But there were a few lessons that stayed with me.

First, shared memory and shared understanding aren't the same thing.

Two agents having access to the same information doesn't guarantee they'll interpret it correctly.

Second, less context doesn't always mean better context.

A concise handoff is valuable only if the information that was removed wasn't necessary.

Third, infrastructure can be technically useful without being a compelling product.

That's probably the biggest lesson for me.

And finally, I was reminded that experimentation doesn't always need to end with a launch.

Sometimes you build something because a question bothers you.

You explore it, learn from it, and move on.

That's a perfectly reasonable outcome.

If You're Curious, Here's Bhai

I've also put together a small website for Bhai and open-sourced the project.

If you're curious about what I built, how it works, or just want to explore the code:

🌐 Website: https://hi-bhai.vercel.app/

💻 GitHub: https://github.com/vibhanshu2001/bh-ai

It's an experiment, not a polished commercial product. There are rough edges, unfinished ideas, and probably a few things I'd do differently if I started over.

But that's the fun of building in public. Someone else might find an interesting idea in something you've decided to leave unfinished.

One Question I'm Still Curious About

I haven't ruled out returning to Bhai someday.

But for now, I'm leaving it where it is.

There's still one question I genuinely want to explore:

When you switch between Claude Code, Codex, Cursor, or other AI coding agents, how do you preserve the context of what you've already done?

Do you maintain an AGENTS.md file?

Do you rely on each agent's built-in memory or session history?

Do you use an MCP memory server?

Or do you just explain everything again and get on with it?

I'm particularly curious whether cross-agent context loss is something other developers actually struggle with—or whether I've spent a lot of time solving a problem that's mostly in my own workflow.

Either answer would be useful.

And that's probably what I like most about experiments.

You don't always need to know what you're building toward.

Sometimes curiosity is enough to get started.

Bhai started as a small personal experiment, grew into something much more complex, and is now open-source. I'm sharing it not because I've solved the problem, but because I enjoyed exploring it—and maybe someone else will find something useful in the journey.