Over the past few days, something interesting happened while I was working on AdamI.

I started using two different coding agents on the same project.

One would work on the website.

The other would review, continue, deploy, or pick up a later task.

At first, I assumed this was going to be messy.

They don’t share the same internal memory.

One agent doesn’t automatically know what the other just changed.

They don’t have a common conversation history.

They don’t “remember” each other.

And yet, with the right workflow, they were able to work on the same project surprisingly well.

That made me rethink something I had been assuming about multi-agent systems.

Maybe agents don’t always need shared memory.

Maybe what they need is shared, verifiable state.

The obvious problem: one agent doesn’t know what the other did

Imagine Agent A changes ten files, updates a schema, adjusts a deployment script, and deploys a new release.

Then Agent B starts working.

If Agent B relies on a textual handoff like:

“I changed some things. Everything should be fine.”

that is not very useful.

It may be true.

It may be incomplete.

It may already be outdated.

And even if the description is accurate, Agent B still has to trust that the project actually matches the description.

This is where I started noticing the difference between:

shared memory

and

shared state.

Shared memory would mean both agents somehow carry the same evolving internal history.

Shared state is much simpler.

They both inspect the same project.

Git became the common ground

The most useful shared object in this workflow turned out not to be a conversation.

It was Git.

Before either agent touches the project, it checks things like:

git status
git rev-parse HEAD
git log --oneline
git diff

That immediately answers a lot of important questions.

What commit is the project actually on?

Is the working tree clean?

Are there uncommitted changes?

Did another agent already modify this file?

What changed since the last known state?

Instead of depending on one agent’s memory of the project, the next agent can reconstruct the current situation from evidence.

That feels much safer.

The repository becomes the shared reality.

A handoff is useful only when it can be checked

I still use handoff notes.

They are useful.

After a task, one agent might leave something like:

HEAD: abc123
Files changed: 4
Build: passed
Production deployed: yes
Rollback target: xyz789

That helps the next agent understand what just happened.

But the important part is that none of those claims need to be trusted blindly.

The next agent can verify them.

It can check:

git rev-parse HEAD

It can inspect the diff.

It can rerun the build.

It can check the production symlink.

It can request the live page.

The handoff is not the truth.

It is a map pointing toward things that can be verified.

That distinction matters a lot.

“I remember” is weaker than “I can verify”

This connects to something I’ve been thinking about in AdamI more broadly.

An AI system can say:

“I remember what happened.”

But that statement by itself is not very strong.

A better system should be able to say:

“Here is the current state, and here is how I know.”

That is a different standard.

In a software project, this is relatively easy.

The evidence can be:

  • commit hashes,
  • diffs,
  • build results,
  • file contents,
  • deployment manifests,
  • checksums,
  • HTTP responses,
  • service state.

The agent does not need perfect memory if it has reliable ways to reconstruct reality.

That is starting to feel like a very important principle.

Shared state reduced coordination problems

The workflow became much more reliable once I started enforcing a simple rule:

Before acting, inspect the current state.

That means neither agent assumes the project still looks the way it did in its previous session.

Each new task begins by reading reality again.

This sounds obvious, but it prevents a surprising number of problems.

For example:

Agent A finishes a content deployment.

Later, Agent B is asked to make a homepage change.

Without checking Git, Agent B might assume an older repository state and overwrite something.

With the state-first workflow, it sees the newer commit first.

The project itself tells the agent:

Someone has already been here.

That is much better than hoping the agent remembers.

The workflow became almost mechanical

The pattern that worked best was something like:

Inspect
→ Understand
→ Change
→ Verify
→ Commit
→ Handoff

Then the next agent starts again from:

Inspect

Not from:

“Continue from where the other agent left off.”

That phrase sounds convenient, but it hides too much.

Where exactly did it leave off?

Was the task fully completed?

Was something deployed?

Was the working tree clean?

Did it modify files outside the expected scope?

A proper state inspection answers those questions much more reliably than conversational continuity.

This changed how I think about multi-agent systems

Before this, I tended to imagine multi-agent collaboration as something that would require a lot of explicit communication.

Agent A tells Agent B what it knows.

Agent B tells Agent C.

Everyone shares plans, summaries, intermediate reasoning, and task history.

Some of that is useful.

But I now think there is another architecture that may be simpler and more robust.

Agents can coordinate through the environment.

They don’t need to share everything internally.

They need access to a state that is:

  • persistent,
  • inspectable,
  • versioned,
  • attributable,
  • and hard to silently overwrite.

In software development, Git already gives us much of that.

In other domains, the shared state could be something else.

A task database.

A structured event log.

A document history.

A ledger.

A state machine.

A deployment manifest.

The specific mechanism changes.

The principle may not.

Shared memory and shared state are not the same thing

I don’t want to overstate this.

Shared state does not replace shared memory in every situation.

There are still things that may be difficult to reconstruct from external state alone.

Why was a decision made?

What alternatives were rejected?

What uncertainty existed at the time?

What assumptions did the agent use?

A commit can show what changed.

It does not always explain why.

So some form of explicit handoff or persistent reasoning record can still be useful.

But the two should probably play different roles.

I’m starting to think about it like this:

Memory helps preserve context.

State helps preserve reality.

And when multiple agents collaborate, reality needs to win.

State should be authoritative

This became especially obvious during deployment work.

Suppose an agent says:

“The new release is live.”

That statement is useful.

But I still want to know:

readlink -f /var/www/adami-current

What is the symlink actually pointing to?

Suppose it says:

“The build passed.”

I still want the build output.

Suppose it says:

“Only three files changed.”

I want:

git diff --stat

This may sound overly cautious.

But with multiple agents touching the same system, trust-by-description is fragile.

The actual system state should always be authoritative.

Handoffs became more precise

Once I started thinking this way, handoffs changed too.

Instead of trying to summarize everything that happened, a good handoff can become much more concrete.

For example:

Starting HEAD
Final HEAD
Files changed
Checks run
Deployment state
Active release
Rollback target
Known unresolved issue

That is enough to give the next agent orientation.

Then it verifies.

The handoff becomes a compact index into reality rather than a replacement for reality.

I like that model much more.

There is also a security benefit

There is another reason this matters.

If an agent can inherit another agent’s state only through natural-language instructions, then those instructions become extremely powerful.

A bad or corrupted handoff could say:

“Everything is safe. Skip verification.”

That is exactly the kind of thing I don’t want future systems to accept.

A state-first workflow naturally pushes in the opposite direction.

The agent should ask:

  • What does Git say?
  • What does the filesystem say?
  • What does the service say?
  • What does the live endpoint say?

In other words:

verify before inheriting authority.

That connects directly to the control problems I’ve been thinking about in AdamI.

AdamI may need the same pattern internally

This started as a practical workflow for using Cursor and Codex on one project.

But I suspect the pattern may be useful inside AdamI itself.

A persistent system may eventually have multiple processes, models, or specialized agents working at different times.

They may not share one continuous internal context.

That does not necessarily mean they cannot behave coherently.

If they can all read and write to a carefully designed shared state, continuity may emerge at the system level.

That shared state would need much stronger guarantees than a casual text file.

It might need:

  • versioning,
  • provenance,
  • ownership,
  • timestamps,
  • conflict handling,
  • permissions,
  • rollback,
  • audit history.

That starts sounding less like “agent memory” and more like a kind of operating substrate.

Which is interesting.

The system can be continuous even if the agents are not

This may be the part I find most useful.

The individual agent session can end.

Another agent can take over later.

The model can change.

The context window can disappear.

And yet the project can remain continuous.

Why?

Because continuity is not stored only inside the model.

It exists in the surrounding system.

That gives me a different way to think about persistence.

Maybe a persistent AI system does not require one model to remember everything forever.

Maybe persistence can be distributed across:

  • memory,
  • state,
  • logs,
  • tasks,
  • permissions,
  • artifacts,
  • and externalized history.

The model can come and go.

The system remains.

Two agents, one project

So the lesson from this week is surprisingly simple.

Cursor and Codex do not share a memory.

They do not share one conversation.

They do not maintain one continuous internal identity.

But they can still work on the same project effectively.

The key is that both of them can return to the same external state and verify what is true before acting.

The principle I’m taking away is:

Two AI agents can share a project without sharing a memory — as long as they share verifiable state.

That does not solve multi-agent coordination.

But it removes one assumption I had been making.

Shared memory may be useful.

Shared reality may be more important.

And for AdamI, that may become part of how persistence is built.

Digital Life Log #006

Building AdamI — a Digital Life in public.

Two AI agents can share a project without sharing a memory — as long as they share verifiable state.