A folder that syncs, remembers, and stays yours.

The thing you can't do today is collaborate

Start with the gap that's hardest to route around, because it's the one that exposes what's missing: you can't collaborate with another person and their agent.

Look at how knowledge work runs now. Each person keeps their working context their own way — some files, a few shared docs, a thread or two — and points their own AI at it. The moment two people need to work the same problem, there's no shared place that context can live. So they fall back to the old motions: mail a document around, paste state into a chat, and let each agent laboriously re-derive what the other's agent already worked out.

The deeper issue isn't the friction — it's that there's nothing to grant access to. Scoped permissions for a shared workspace aren't hard to build; they're impossible, because the workspace doesn't exist. There is no agreed-upon substrate that two people, and both their agents, can read and write.

That absence is the tell. The same missing piece is why a lone agent feels starved for context and forgets everything between sessions. Three symptoms, one root cause: no shared place the work lives. Everything below is what becomes possible once it does.

Three pains, one substrate

Name the three symptoms; they're all one substrate apart.

No common ground. Collaborating with another person and their agent is barely possible. There's no shared place the work lives, so there's nothing to grant access to — permissioning can't even exist yet. The substrate has to come first.

Context by duct tape. Getting the right context into a single agent is a patchwork of brittle connectors and grudging APIs, with a remote source of truth forever a step out of sync with what's actually on disk. The agent spends its turn fetching instead of thinking.

The agent forgets. Not literally — there's a transcript to scroll, and lately a memory file the harness scribbles to. But both miss the point: a log and a sticky note sit beside the work, assisting it. The real unlock is the work itself as a living system of record — decisions, findings, data refined by compute into insight — compounding on disk and read first by whatever model picks it up next. Memory shouldn't be a static file off to the side; it should be front and center: the project's state of record.

One fix for all three: a constantly-synced filesystem that mirrors your sources in, captures the agents' work, and gives you a real place to grant access. That's Common.

Dropbox, not GitHub

The instinct is to reach for git. But run that experiment — a monorepo with a dozen projects nested inside — and the lesson is quick: git is the wrong tool for knowledge.

Git earns its ceremony because for code, one wrong line can take down production, so you branch, review, and gate every change. But reviewing a literal pull request almost never matters for a notes file. Knowledge isn't code. Notes have no prod. Blocking sync behind human review of every prose edit is friction with zero payoff.

The move is Dropbox's, not GitHub's. Dropbox didn't win by being a better version-control system — it won by deleting the act of syncing entirely. You stopped managing state and just had it, current on every machine the instant you opened the lid.

Common is that move for the data your AI runs on. Every project sits at the top level of one folder — one per deal, launch, or research thread — side by side, never buried in a monorepo. Shared things that many projects need — skills, secrets, and your harness's own state — sit at the root too. A daemon watches the tree and reconciles continuously. No push. No pull. No "did I commit?" You stop managing state and start just having it.

Every platform shift moves distribution — this one moves it to tools

Step back, because this is a bet on where software is going, not just a better sync app.

Twice in twenty years the platform moved, and the way you reach people moved with it. In the 2000s the platform was servers and fiber — the internet itself — and distribution was the website. In the 2010s the platform was mobile plus the internet, and distribution was the app. Whoever owned the most-reached-for unit owned the channel.

The 2026 platform is the harness plus the model plus the internet — Claude Code, Cursor, Codex, ChatGPT, and whatever ships next quarter, each driving a model that improves on a quarterly cadence. On this platform the unit of distribution is the tool the harness reaches for. Distribution is a tool call.

So which tool is worth owning? Not the model — it's rented by the token, and next quarter there's a better one. Not the harness — they multiply and churn. Those are the fastest-depreciating layers in the stack. The one thing that appreciates is accumulated context: the diligence, the project state, the institutional memory the agents produce and consume. Data outlives the model that wrote it and the harness that rendered it.

The durable bet is a user-owned data tool — portable and harness-agnostic by construction — that plugs into whatever you run today and whatever replaces it tomorrow. Common is that tool.

Commoditize your complement

There's an old strategy move: when you sell something, work to make its complement abundant and cheap — because the more abundant the complement, the more valuable your thing becomes. Hardware makers want free software; software makers want cheap hardware. You make the layer next to yours a commodity, and demand flows to you.

In the agent stack, the complement to your data is the intelligence itself — and it's racing toward commodity on its own. A model is a stateless function: context in, tokens out, nothing kept. Two frontier models a quarter apart are increasingly interchangeable; you swap one for another and keep working. The harness is going the same way. You rent both, and next quarter you rent better ones.

So follow the value. The thing that doesn't reset between turns, doesn't churn between vendors, and compounds with every project is the accumulated state — the diligence, the decisions, the work in flight. If the intelligence is the commodity, value accrues to the state. The model is the complement to your data, not the other way around.

Common is the state. The intelligence is a guest that comes and goes; the house it works in is yours.

Two kinds of state, flowing in opposite directions

Inside every Common are two kinds of state, and the distinction is the design. They differ by where the source of truth lives — and, it turns out, by which way they sync.

Common Knowledge is everything already written down somewhere else. A Google Doc, a Sheet, a Gmail thread, a Notion page, a chat history — the remote owns it; Common pulls a local, agent-traversable copy so the model can grep it at filesystem speed instead of round-tripping a brittle connector every turn. Like Dropbox, there's a server in the middle: the Common cloud does most of the work — it polls your connected stores and fans the mirror down to every machine. Call it 80/20 — mostly cloud-orchestrated, occasionally a local pull pushed back up. Common Knowledge flows inward.

Common Ground is the truth that originates here — the live, evolving output of the agents' own work: the strategy, the findings, the running state, the markdown and static HTML that grow as you go. This isn't a memory file off to the side assisting the work — it's the project's system of record. There's no upstream to defer to; this is the upstream. Here the ratio inverts — 80/20 the other way — because nearly all the authoring happens on a person's machine, where they're driving an agent. The agent flushes Ground to disk; it syncs up to the cloud and down into every collaborator's identical tree. Common Ground flows outward.

That asymmetry is just honest distributed-systems design: pull-heavy data is cheapest to orchestrate centrally; author-heavy data belongs at the edge where the work happens. Map it back to the pains — Common Knowledge cures context by duct tape, Common Ground cures the agent forgets, and the synced tree beneath both is the shared ground that makes collaboration, and permissioning, finally possible.

The anatomy of a Common

Here's what it actually looks like — because the structure is the product, not an implementation detail.

One synced root: your Common. At the top sit the things every project shares — Common Skills (reusable tools the agents can call), Common Secrets (shared keys), any Common Knowledge that's organization-wide, and your Common Harness (more on that below). Then each project is its own top-level folder — never buried in a monorepo — and one level down it repeats the same small vocabulary: its own Project Skills and Project Secrets, a common-knowledge/ where its mirrored sources land, and a common-ground/ where its markdown and static HTML evolve.

Same four words at every scope — Skills, Secrets, Knowledge, Ground. common- means shared at the root; project- means scoped to one project. Knowledge always flows in; Ground always flows out. See one project and you've seen them all — and so has any agent, on any machine, the moment it opens the folder.

One element at the root is different in kind: Common Harness — a backup of your harness's own state, captured from disk and namespaced per machine. Your sessions and history, your agent's memory, your custom skills and agents, your settings — the accumulated setup that makes your agent yours. The harness is rented and swappable (that's the whole bet); Common Harness is what makes swapping it cheap, because your state was never trapped inside it. Change machines, change harnesses, and pick up exactly where you left off.

Audit, rollback, and blame — minus the ceremony

Dropping the pull request doesn't mean dropping accountability. It means keeping the three things review was really a proxy for, and throwing away the gate nobody needed.

Audit — ask the agent what changed in a folder this week, in plain language, and get a real answer. Rollback — undo one specific change without untangling a commit graph or running a rebase. Blame — every change attributed not just to a person but to the person and the agent acting for them: You · Claude Code, a teammate · their agent.

These come from an append-only, agent-readable change log — semantic entries you query in natural language — not from commits a human reads in a diff viewer. The agent is the auditor; you ask it questions instead of reading diffs.

Conflicts get the Dropbox answer, not the git answer: last edit wins, both versions preserved as conflict copies, and the agent surfacing the divergence in the log rather than halting on a merge marker. Knowledge tolerates a brief disagreement; a later flush reconciles it. This change log isn't bureaucracy — as the next section argues, it's the accountability record.

You can outsource thinking. You can't outsource accountability.

There's a line from an IBM training manual in 1979 that has aged into a warning.

Not "two agents collaborate." Two accountable people, putting their agents to work.

This is the Dropbox arc — the most proven motion in software — but pointed at people, not bots.

It starts single-player: a personal utility where your own context finally syncs itself, current everywhere, nothing to push or pull. But the file you were already keeping for yourself turns out to be exactly the file a collaborator's agent needs. Single-player becomes multiplayer the instant a second person writes to the same tree — and that's the real unlock.

The headline isn't "watch two agents work together." It's two accountable people putting their agents to work on the same ground. Because every project is its own top-level folder, a project is a shareable unit: grant a partner read access to one deal room — their agent and yours now share its live Common Ground — without exposing anything else you keep. A contractor sees only the project they're on. That per-project, per-person scoping is exactly what a single shared repository structurally cannot express.

And the boundary can run far larger than one folder. Link a personal Common to a company's Common and its Common Knowledge flows into context where it's allowed to. But the two must stay sealed by default — a hard airgap, so private data never bleeds into corporate and the reverse holds just as firmly. Think identity-scoped Commons — the way an enterprise account and a personal account already sit side by side but separate, except here it's the data layer, not the chat history. Links are explicit, directional, and scoped; nothing crosses unless someone draws the line.

Sharing context with a person and their AI should be as ordinary as sharing a folder — and keeping two worlds apart should be as ordinary as not sharing one. With a real substrate underneath, and a real boundary around it, both finally are.

The moat is outside the turn loop

There's a crowded category of agent-memory products — Mem0, Zep, Letta, Supermemory, Cloudflare's agent memory — and they all live in the same place: inside the turn, racing to store-and-retrieve a little faster on each request. That layer is already commoditizing toward zero. Store-and-retrieve is becoming table stakes.

Common lives in a different place. It operates mostly outside the turn-based back-and-forth between you and the model — in the background, between the turns: the continuous sync, the Common Knowledge refresh, the Common Ground flush, the audit-and-blame ledger. It's a tool the harness can reach into for context, but it isn't fighting for a slot inside the request/response cycle. Your data is the bedrock; the chat is just weather on top.

The defensible surface isn't memory — it's the workflow around the data (sync, mirror, audit, rollback, blame, access control) plus distribution as a tool any harness calls. That's exactly where value pools when the layers above it — the models, the harnesses — are interchangeable and racing each other to the bottom.

To make that concrete, here's where Common sits next to the tools people reach for today.

Common, or Forge?

An honest page names its own loose ends. Here's the one that matters.

The thinking behind this started life under another name — Forge — framed as "GitHub for agent knowledge": a version-controlled natural-language substrate with semantic diff, review, and path-level access control, a wedge into eventually owning the whole agent stack down to the harness and the model.

The bet hasn't changed; the metaphor has. GitHub was the wrong shape for knowledge — knowledge isn't code, so the pull-request ceremony was pure tax. Dropbox is the right shape: constant sync, no ceremony, but keep audit, rollback, and blame.

The cleanest resolution, and the one I'm leaning to: Common is the product — the synced, sovereign data layer shipping today, the thing you install and feel. Forge is the company and the long-game thesis — own the neutral data layer, then earn the right to go down the stack. Common is the wedge; Forge is the gravity. That doesn't contradict the original plan — the data layer was always where everything started. It just got a friendlier name and a better metaphor.

Whether the two names stay split, or Common simply absorbs both, is the call still genuinely open.