Sharing an agent with a client

Sharing an agent with a client means giving one outside person a room where they can ask the project’s agent questions, watch it work and receive deliverables, while the agent, the code and your credentials stay on your machine. Done well it is read-only by default, limited in time, and revocable in one click. Done badly it is a shared login.

This is the setup we recommend for agencies, freelancers and anyone whose client wants “to see how it’s going” more often than a weekly call allows.

The shape

One client, one room, one agent, one directory.

• One directory. ~/clients/acme holds only that client’s project. The agent pinned to it cannot see ~/clients/beta, your company folder or your keys.
• One agent, named for the client so nobody mistakes it: acme.
• One room, with the client and you. Your other rooms are invisible to them.
• Plan mode for the agent, so questions get answered and nothing changes on disk unless you decide otherwise.

The client sees the room; the room sees one directory; everything else on the machine is out of reach.

What the client can do

• Ask questions: “what changed this week”, “why does the export take a minute”, “show me the current design tokens”.
• Watch the agent work in the timeline: which files it read, which commands it ran, the tail of the output.
• Receive artifacts: a summary, a diagram, an exported file, a preview image.
• Attach things: a screenshot of a bug, a spreadsheet of copy changes.

What the client cannot do

• Change code, in plan mode. If you switch the agent to acceptEdits for a phase, their edits still cannot push, delete, spend or touch credentials without your approval.
• See files. The daemon uploads timeline events, not the working tree. See what the daemon uploads.
• See other rooms, other clients or your own agents.
• Approve their own dangerous actions. Those route to you.

Time-boxing

Give the client a standing grant for the project’s duration, and put a reminder on the end date. Revoking the grant, removing them from the room, or stopping the daemon each takes effect immediately; queued requests from them are cancelled and anything running finishes and stays in the history. Invite links themselves can carry an expiry and a maximum number of uses.

Deliverables and approvals

A client asking the agent to “push the fix” hits push to a shared branch and pauses for you. That is the right behaviour: you decide when a deliverable ships. Approve it, reject it, or answer “continue read-only” and ship it yourself later. The note you attach is part of the record.

What it replaces

Checklist

1. Create ~/clients/<name> and check the project out there.
2. Create an agent pinned to it, in plan mode, named for the client.
3. Create a room; add the agent; invite the client with an expiring link.
4. Approve their first request; then grant “always allow” for the project’s duration if you want them to stop waiting on you.
5. Install the daemon as a service so the room works when you are not at your desk.
6. On project end: revoke the grant and remove the member. The history stays for you.

Frequently asked questions

Does the client need an account? They sign in with an email code or Google to accept the invite. No install.

Can two clients share one agent? Don’t. One directory per client keeps the boundary physical, not just logical.

What does it cost me? Requests run on your subscription. Per-person usage is recorded, so you can see what the client’s questions cost and bill accordingly if you like.

Can the client see my prompts to the agent? Only what happens in their room. Your own work with the same codebase belongs in a different room with a different agent.

Give the project a room and let the client ask. Start here.