The Context Bridge

IDE wars and AI wars are over when the state of the work is outside the model.

The useful question is no longer “Which editor is the winner?” or “Which model is the smartest today?” The useful question is: where does the work live when the interface, model, or machine changes?

This is the architecture we use at Particles and Waves to keep creating across apps, websites, books, analytics, and operations.

The one-line formula

Vendor adapter → Shared external context → Versioned durable state
                 (CONTEXT_LOG.md)       (Git + primary data)

Or, more precisely:

Durable state ∉ model session
Durable state ∈ Git + primary data
Agent ∈ {Claude, Codex, Gemini, ...}
IDE = replaceable client

CONTEXT_LOG.md is not a magic memory file. It is the shared read/write protocol: decisions, observations, unknowns, handoffs, and next actions are written back in a form that another agent can verify and continue. Secrets never go into it.

The complete stack

Human operator
  ↓
iPhone + Moshi                         mobile terminal interface
  ↓ SSH over Tailscale                  private network access
Mac mini + UPS                          always-on execution server
  ↓
tmux                                    persistent live session / agent hub
  ↓
Claude / Codex / Gemini                 replaceable agent runtimes
  ↓
AGENTS.md / CLAUDE.md / GEMINI.md       thin vendor-specific adapters
  ↓ converge on
CONTEXT_LOG.md                          shared external context
  ↓ read / write
Git workspace + primary data            durable source of truth
  ↓ commit / push
GitHub                                  off-site replica / recovery point

Moshi is the phone-side interface. The current setup uses ordinary SSH over the encrypted Tailscale network; it is not the separate “Tailscale SSH” feature. The Mac mini stays available as the execution host, and the UPS protects it from short power interruptions. tmux keeps a running process alive when an SSH connection drops. It does not make a host reboot immortal: durable work still has to be written, committed, and pushed.

Three planes, one feedback loop

The agent hub branches into three operational planes:

Agent hub
  ├─ Context plane       adapters ↔ CONTEXT_LOG.md ↔ Git + primary data
  ├─ Creation plane      image / video / audio generation APIs
  └─ Operations plane    ASC, Google, GA4/Firebase, Supabase, Vercel, etc.
                         ↓
                    evidence and results
                         └──────────────→ Context plane

The loop matters more than the individual prompt:

Observe → structure → reason → act → measure → write back → repeat

At PAW, this includes App Store Connect and Google ecosystem data, analytics, user feedback, deployments, generated media, and the business decisions made from them. The external state becomes a compounding asset rather than disappearing inside a chat transcript.

What changes when the model changes?

The adapters are intentionally thin. Claude reads CLAUDE.md, Codex reads AGENTS.md, and Gemini reads GEMINI.md; all three are directed to the same repository state and CONTEXT_LOG.md. They do not share an internal hidden memory. They share a verifiable external state.

That makes model selection a runtime decision. In a compatible session, /model can change the model applied to the same task. The models are not identical and are not interchangeable in capability, but the work is portable enough to test the task against another runtime without starting the company’s memory from zero.

The human frontier loop

Automation is good at repeating, measuring, and checking. Humans still notice the new edge first: an unexpected use, a new distribution channel, a strange outlier, or a connection no model would predict from the existing corpus.

Human finds the frontier
  → agent verifies and operationalizes it
  → evidence is stored
  → the next agent starts from a higher baseline

This is the point of the architecture: not to remove the human, but to stop every insight from evaporating when a session ends.

What this does — and does not — guarantee

• It reduces vendor lock-in by moving durable context outside any one model or IDE.
• It preserves live work across an SSH disconnect through tmux.
• It provides recovery for pushed commits through GitHub.
• It does not make unsaved changes durable.
• It does not make different models equivalent.
• It does not remove the need to review API permissions, costs, release gates, or destructive actions.

The architecture is deliberately simple. Add a shared external context, define how every agent reads and writes it, and keep the source of truth versioned. Keep building.

— Particles and Waves