cofound

Claude Code for your whole team.

One coding agent, one shared thread. Your cofounder's correction lands in the same context your instruction did, so the agent carries on from there instead of starting a new conversation.

Watch it workSign in to buildThe walkthrough needs no account. Building needs a GitHub account on this deployment's access list.
cofound/paymentsACMRDKCofound is editing 2 files
Files
app
billing
subscribe.ts
portal.ts
lib
billing.ts
COFOUND.md
app/billing/subscribe.tsCofound is editing
41import { createCheckout } from "@/lib/billing";
42 
43export async function subscribe(userId: string, plan: Plan) {
44 const price = PRICES[plan];
45 // billing.ts already owns price lookup and idempotency
46 return createCheckout({ userId, plan });
47}
AgentA model per phase · Standard
AlexAdd Stripe subscriptions to the pricing page.
Read the project4 files
Adding a checkout route and wiring it to the pricing page.
MayaUse the existing billing abstraction, don't re-implement price lookup.
Change files2 edits
edit_fileapp/billing/subscribe.ts
read_filelib/billing.ts
Reusing createCheckout from lib/billing.ts
Message the agent…Send
Maya is reviewing 2 changed filesDev is viewing lib/billing.tsCOFOUND.md · 6 project decisions

The agent changes course and the team reviews

An illustration of a Cofound session: Alex and Maya are directing the same agent in the same thread, and it answers both from one shared context.

The problem

The agent is powerful. Your team's context is scattered.

Coding agents got good fast, and they are all still built for one person. On a team of three that means three conversations, none of which know about each other.

  • One founder's laptopthe agent conversation that has all the context
  • A second branchwork the agent knows nothing about
  • Slackthe decision that changed the approach
  • A pull requestthe review, three hours later

The work is shared. The agent's memory of it is not.

The solution

One agent. One context. Everyone in it.

Cofound stores the agent's transcript against the project rather than against a person, and replays it into every run. There is one thread, and everyone with access is in it.

How it works

Three steps, then you are building.

  1. Create a projectStart empty or import a GitHub repository. The project is the unit everything else hangs off: files, agent memory, members.
  2. Invite your cofounderThey open the same URL and see the same tree, the same editor and the same agent thread, live.
  3. Both of you direct one agentWhoever types, the agent answers from one shared context and writes to one set of files.

Why this is different

The agent is a participant, not a tool each of you owns.

A shared editor lets two people type in one file. This lets two people direct one agent. The second instruction below is not a new request: it arrives inside the first one's context, and changes what the agent is already doing.

  1. AlexAdd Stripe subscriptions.
  2. CofoundReading the project. Found lib/billing.ts, writing a checkout route.
  3. MayaUse the existing billing abstraction.
  4. CofoundSwitching to createCheckout. Dropping the duplicate price lookup.
  5. DevApproved 2 changed files.

Maya never explained what Alex asked for, and never will again: it is written down in the project, not in someone's tab.

What works today

Built, not announced.

The agent's memory is the project's, not yours

Its transcript is stored per project and replayed on every run, so a teammate's next message continues your conversation instead of opening a new one. That is the whole difference.

Standing instructions the agent actually reads

COFOUND.md at the project root goes into every run. Write your stack, your conventions and your product decisions there once, and nobody has to retype them in a prompt again.

Everyone watches the same run

The prompt someone sent, every file the agent touches and every line it writes stream into your screen as they happen. Not a transcript pasted afterwards.

Changes can wait for a second pair of eyes

Turn on review and the agent's writes are staged until a teammate approves them. Whoever ran the agent cannot approve their own run.

The agent can show its plan first

Turn on plan approval and it stops after planning, so the team agrees on the approach before any file changes.

Real presence, and honest about it

You see who has the project open, by their GitHub account, and their cursor on the same code as yours. When you are the only one there, it says so.

Not yetThe live preview tier (a real dev server running in a microVM) is built but switched off. Previews are static today.

Compared with a single-player agent

Same agent. Different unit of memory.

Nothing here is a criticism of tools built for one person, which are excellent at being that. These are the dimensions that change when a team shares one.

 An agent per personCofound
Who the agent remembersYour sessionThe project
Where a teammate's correction goesTheir own conversationThe same thread
Standing instructionsPer person, per machineA file in the repo, shared
Watching a runThe person who started itEveryone in the project
Approving a changeAfter the fact, elsewhereBefore it lands, in place

Who it is for

Teams small enough to build in one room.

Technical and non-technical cofounders

One of you writes the product instruction, the other reviews what the agent actually did. Neither has to learn the other's tool.

A founding engineering team

Correct the agent mid-run instead of waiting for a pull request. The correction becomes part of the context, so it is not repeated next week.

Product and engineering together

The product founder directs the agent, the engineer reads the diff and sets the write rules on what it may touch.

Build with your cofounder, not beside them.

One project, one agent, one thread. Bring the person you are building with.