Finding / Founding Braintrailz

Treking across 30 Years of Deep Thoughts

I have a habit of rediscovering the same problem in different forms.

Sometimes it takes me a while to notice.

BrainTrailz is a good example.

I have been using the name for years. I have described trails as paths through problems, accumulated knowledge, experiments, things learned along the way. I built a whole vocabulary around it: trails, Trailcraft, the Backpack, trail guides.

I thought I understood where the idea came from.

I'm no longer sure I did.

Because recently, while working on something called the BrainTrailz Protocol, I realized that BrainTrailz may have a much longer lineage than I thought.

Maybe thirty years longer.

Before There Were BrainTrailz

I spent a large part of my career in integration software.

Back then, the problem was fairly straightforward to describe and remarkably difficult to solve.

Companies had lots of systems.

The systems were built by different vendors, ran on different platforms, spoke different protocols, represented data differently, and generally had no interest in cooperating with one another.

Everybody's first instinct was to connect System A to System B.

Then A to C.

Then B to D.

Keep going and pretty soon you have created spaghetti.

The important architectural realization was that the problem wasn't really how to connect two systems.

The problem was how to create a common way for any system to participate.

That led to adapters, common contracts, metadata, reusable services, routing, transformation and all the things that eventually became integration platforms, ESBs and iWay.

One of the architectural ideas I worked on was a universal adapter framework.

The details aren't especially important today.

The lesson is.

Keep the center clean. Put the differences at the edges.

If a new system shows up, you shouldn't redesign everything in the middle.

You write another adapter.

That idea got buried pretty deeply in my brain.

Then the Systems Learned to Talk

Fast-forward a couple of decades.

Now the things we are connecting aren't just applications and databases.

They're intelligent.

ChatGPT, Claude, Gemini, Cursor, Codex, Grok, Muse, etc...

Whatever appears six months from now.

And something strange has happened.

We built astonishingly capable systems, but when we move between them, we are back in the integration business.

Except this time the human is the integration layer.

I work on something in ChatGPT.

Then I move into Cursor to build it.

Cursor doesn't quite know what ChatGPT knows, so I explain it again.

Later I want Claude's opinion.

I explain it again.

Maybe Claude gives me an interesting insight, so when I go back to Cursor I explain that.

Then I pick up my phone and open ChatGPT.

Now I'm explaining the explanation of the explanation.

We solved this problem once.

We called it point-to-point integration.

It didn't scale then either.

And That Is Where BrainTrailz Came Back

The original idea behind BrainTrailz was always about continuity.

You move.

The environment changes.

The trail continues.

Over time I expanded the idea.

BrainTrailz became a place for experiments, ideas, things I built, things I learned and paths I wanted other people to be able to follow.

Trailcraft became the practice of figuring out how to get from an unclear problem to a working answer.

The Backpack became the tools I carried with me.

All of that still makes sense.

But underneath it was something simpler that I had nearly lost sight of.

The trail isn't the conversation.

The conversation is just where something happened.

The trail is what continues.

That distinction suddenly matters a great deal in an AI world.

The Wrong Unit Is the Chat

Every AI company is working on memory.

That's useful.

But memory usually answers a question like:

What should this AI remember about Marc?

That isn't quite the problem I want to solve.

The question I care about is:

What does the next capable participant need to know to continue this work?

Those are very different things.

A project has a purpose.

It has a current state.

Things have been decided.

Things have happened.

There are things we should do next.

There are artifacts worth knowing about.

That state should not disappear because I closed one application and opened another.

And it shouldn't belong to OpenAI, Anthropic, Google, Cursor or anyone else.

It belongs to the work.

And ultimately it belongs to me.

That's the trail.

One Plus N

Once I saw the problem that way, another old idea came roaring back.

Don't integrate ChatGPT with Claude.

Don't integrate Claude with Cursor.

Don't integrate Cursor with Gemini.

That road ends exactly where it ended thirty years ago.

Instead:

One trail. N participants.

The trail has a stable contract.

Every capable participant can read it.

Every participant can contribute useful things back to it.

Every participant is replaceable.

The weird behavior of a particular AI belongs in an adapter at the edge.

The center should know as little as possible about who is using it.

If another AI appears next year, BrainTrailz shouldn't need a redesign.

Give the new participant an adapter.

Welcome to the trail.

It is such an old integration idea that I am slightly embarrassed by how satisfying it was to rediscover it.

Then We Played Telephone

Of course, an idea like this can become architecture astronautics very quickly.

Add agents.

Add orchestration.

Add a vector database.

Add embeddings.

Add a knowledge graph.

Add twelve services.

Draw an impressive diagram.

Congratulations. You now have a product that doesn't exist.

I wanted to know whether the central idea was actually true.

So we played Telephone.

We created one small canonical trail.

The first AI read it.

It added something.

Then another AI entered without getting a recap from me.

It got only the trail.

Could it tell what was originally true?

Could it distinguish that from what another AI had added later?

Could another participant do the same?

And another?

Most importantly, after passing through all of them, was the original meaning still intact?

That is a surprisingly important question.

Because AI systems are very good at interpretation.

Interpretation is useful.

Interpretation is also how Telephone works.

One person whispers something to another person, who passes along what they understood, who passes along what they understood.

Eventually everybody is still talking about roughly the same thing.

But it isn't the same thing anymore.

A trail changes that architecture.

The participants don't inherit one another's whispers.

They keep returning to the card sitting in the middle of the room.

Interpretation can change.

New knowledge can accumulate.

Decisions can be made.

But the system doesn't casually rewrite history because one AI summarized another AI's summary.

That little experiment worked.

And for me, that is where BrainTrailz stopped being only a metaphor.

The Funny Part

The funny part is that this new thing is made out of ideas from several different periods of my life.

BrainTrailz contributed the idea of continuity.

Trailcraft contributed the idea that the path itself has value.

Integration architecture contributed the contract.

Adapters contributed the 1 + N model.

AI created the new version of the problem.

MCP happened to provide a convenient doorway.

Git and JSON gave us a deliberately boring way to prove it.

None of those things alone is BrainTrailz Protocol.

The interesting thing is where they meet.

And apparently I have been walking toward that intersection for a very long time.

Maybe That's What a Brain Trail Actually Is

I've spent most of my career moving between technologies.

Mainframes and PCs.

Operating systems.

Enterprise software.

Integration.

Cloud.

Data.

Distributed systems.

Now AI.

The technologies keep changing.

The recurring ideas don't change nearly as much.

Systems need contracts.

Boundaries matter.

Point-to-point solutions eventually hurt.

Adapters are cheaper than redesigning the center.

Humans should not have to compensate forever for bad architecture.

And useful knowledge should survive the tool that created it.

Maybe that is the real lineage of BrainTrailz.

Not a product name.

Not a website.

Not even a protocol.

A trail is what remains when the tools change.

Which leads to the shortest description of the whole thing I have found so far:

Conversations are transient.

Trails persist.