Skip to content
← Notes
September 14, 2026 · updated September 15, 2026
The Shortlist

The shortlist

Everything from the four-page thread, consolidated. Nine decisions, seven actions in dependency order, one open question.

13 Sep 2026 · closes the Paseo / Warp / TB scoping thread

Decided

No daemon.Cloud agents cover remote work. Local development judged low-value, QA goes to preview environments from GitHub, latency is not a concern. If it ever bites, the answer is SSH or tbase serve, not a product.
Worktrees: skip.Claude Code ships the mechanic itself, hardened, with its own isolation enforcement.
Cloud agents are the near-term build.And the seam for them is already written, tested and wired to nothing.
Triggers target the cloud agents, not the Mac.Slack and GitHub events land beside the agents in the hosted tier. The client never grows an inbound event path.
The hub is the directory and the reply surface.See every agent, respond to it, discuss with it. For cloud agents that is just an API call behind a button.
Permissions: build the verb, not a policy engine.Org policy arrives later as a scope the gateway issues or refuses.
Record events with an actor.Accepted. This is the prerequisite for the whole team product.
Repo-host integration: nothing new.One correctness fix only.
The gateway is the moat, and it stays proprietary.Client, hub and cloud agents open. A self-host loses managed credentials, metering, the grant, and not having to configure any of it.

A correction you prompted

You were right: it is not only for quick answers

You asked why the return path would carry only yes-or-no gates rather than normal commands. It should not, and I over-narrowed it. "Send this prompt to session X" is just as much a typed verb as "allow once".

The rule that matters is verbs, never raw keystrokes. The client already types prompts into live sessions locally and already refuses to do so when a dialog is up. Driving that from the phone is the same operation with a remote trigger, protected by the same existing gate. So the return path carries two verbs, not one.

Actions, in dependency order

01

Fix the event shape before writing more events

client + hub

Every recorded event names the actor and the object: agent, action, device, account, time, outcome. Not a rendered row.

Do this first. Everything below writes events, and re-instrumenting a year of history that never recorded the actor is the expensive version of this task.

02

Wire the provider seam to one real provider

client

crobot first. The seam has zero implementations and nothing in the app or CLI calls it, so this is the first time it can be known to work rather than assumed to.

It is also the shortest path to the thing you want soonest, and it introduces no new architecture.

03

Render the cross-machine agent list

hub

The data already arrives: a heartbeat per device every 20 seconds, a page per agent, accounts and device tokens in the schema. This is a rendering job over data in hand.

04

Respond and dispatch to cloud agents from the hub

hub + gateway

A button calls the provider API. The gateway holds the credential so a phone never does. This completes "drive your agents from anywhere" without touching the Mac.

05

The return path: two verbs on the heartbeat

client + hub

Read the response body the heartbeat already receives and discards. Queue a few pending verbs per device; execute and ack on the next beat. Answer a gate, and send a prompt.

Lower priority than it looked at the start of this thread, since you would accept SSH for the rare case. Still worth it: it is the away-channel promise, and it rides a loop that already runs and already authenticates.

06

Answer permission gates through the seam

client

Implement respond(to:with:) so a gate takes allowOnce, allowAlways, rejectOnce or rejectAlways. This is what would eventually let the launch default stop being a full bypass.

07

Match merged PRs by head SHA

client

Branch names get reused, so matching a closed or merged PR by branch will eventually show a stale one. Small fix, free lesson, taken from Paseo.

Explicitly not doing

  • A daemon or a relay. Ruled out, with SSH as the escape hatch.
  • A worktree or workspace manager. Setup hooks, service ports, reverse proxies, merge UI.
  • A plugin platform. ACP delivers third-party providers without one.
  • A trigger service of our own for local agents. Triggers belong beside the cloud agents.
  • An execution-profile system. Org policy is a gateway scope, not a client feature.
  • Deeper repo-host integration. Everyone shells out to gh anyway.
  • Usage and quota scrapers. Out of scope, unchanged.

The one open question

You said AGPL, then wondered whether the shape is really "whatever Outline does". Those are different instruments, and the difference matters. Outline is BSL 1.1, not EPL.

LicenceStops a closed forkStops a hosted competitorCounts as open sourceWho picked it
MITNoNoYesUs, today
Apache-2.0NoNoYesPaseo
AGPL-3.0YesNoYesWarp
BSL 1.1YesYes, until the change dateNoOutline

AGPL is the right call, and your first instinct was correct

BSL would buy protection you do not need. The client is not the moat, the gateway is. Someone who forks and hosts the client still has no managed credentials, no metering and no grant, so a hosted competitor built on our client is not the threat BSL exists to stop.

What AGPL does buy is the thing that is actually worth having: a fork that gets hosted has to publish its changes. And it keeps the "open source" label honest, which BSL does not, at no cost to a business whose value sits one layer behind.

Cheap now, expensive later: relicensing gets much harder once outside contributors arrive. Worth doing as a deliberate change rather than a drift.

Closes the thread that ran across the six-decision scoping page, the return path, host or client, and where the state lives. All four are on this hub.