The shape of the next twelve months

This is a roadmap, not a press release. Session is built by a small team with community contributors who fix bugs, write lexicon entries, and stress-test the canvas in ways no internal QA would. What follows is an honest attempt to describe what we can plausibly ship between now (March 2026) and Q1 2027. The dates are intentions, not promises. If something slips, it slips publicly; if something gets cut, I'll write about why.

I'm writing this partly because members keep asking, and partly because I'd rather be held to a written plan than to a vague "soon".

What has already shipped (v0.0.x)

For context, the current state of the desktop app:

• A multi-agent canvas where you place agents on a 2D plane, wire them together, and watch them debate in real time.
• Major frontier providers plus a local-runtime option as a fourth provider. All providers are BYOK; we never see your keys (lexicon: BYOK).
• Local persistence for canvases, agents, and transcripts, kept on disk in the user's data directory. Local-first by default (lexicon: local-first).
• E-mail one-time-code authentication for the account layer, no passwords initially, no social login.
• The two-round debate with synthesis primitive: agents argue, a judge model synthesises, you keep the artefact.
• Free and Pro plans. Pro removes a couple of soft caps; the core engine is identical.
• A public lexicon, a blog, and the first two academy tracks.

That's roughly a year of work. The interesting twelve months are the next ones.

Q3 2026, Windows and Linux builds

Session is currently desktop-class on a single platform, which is a real limit for a tool that pitches itself as developer infrastructure. The cross-platform port itself is relatively cheap, the renderer is identical and most of the main-process code is too. The actual work lives in two places.

First, OS keychain integration. Each platform has its own secret store; the abstraction we ship today targets one of them and needs careful work for the others, with a sensible fallback for headless machines that don't have a keyring daemon running. Encrypted-at-rest keys are non-negotiable; we'd rather refuse to start than write keys to plaintext.

Second, CI signing. Code-signing certificates per platform, signed installer images, and a notarisation pipeline that doesn't require manual hardware-token plugging at 2am. This is unglamorous infrastructure work that always takes longer than estimated.

Honest target: a public Windows and Linux beta in Q3 2026. If signing slips, the beta still ships unsigned and the GA waits.

Q3 2026, MCP server library

MCP (the Model Context Protocol) is how agents talk to tools. Session already supports MCP servers, you can point the app at any compliant server and it shows up as a tool in the canvas, but configuration is manual, and "manual" means most members never do it. I wrote about why I think tools are not optional for serious multi-agent work; the lexicon entry on MCP covers the protocol itself.

The plan for Q3 is a curated library inside the app. One-click install, sensible defaults, a short audit note explaining what each server does and what surface it exposes. The initial set:

• Filesystem, scoped to a directory you pick.
• Web fetch, with a domain allow-list.
• Repository, read-mostly, with optional write behind a confirmation.
• SQL read-only, against a connection string you provide.
• Shell-in-sandbox, running inside a disposable container.

Members can submit their own servers to the community room. Submissions get reviewed before they appear in the curated list, anything else is a supply-chain accident waiting to happen.

Q4 2026, Cloud sync (Pro)

The most-requested Pro feature, by a wide margin, is cross-device sync: write a canvas on your laptop, open it on your desktop, no copy-paste. The desktop app remains the source of truth.

Two principles. First, local-first stays the default. Sync is opt-in per workspace, you turn it on for a specific canvas, not for your whole account. Second, sync never sees plaintext prompts or transcripts; the payload is encrypted client-side with a key derived from your account secret.

Conflict resolution: CRDTs for canvas state (positions, edges, agent configs, the things multiple devices might edit concurrently), last-write-wins for settings (theme, default model, things where convergence is fine). Transcripts are append-only and don't need either. I'll write up the design before it ships.

Q4 2026, Team rooms

Shared real-time canvases for small engineering teams. Three to twenty seats is the target band; anything bigger and we're solving a different problem. Team rooms add SSO/SAML, an audit log of who ran what against which provider, and a thin admin dashboard for seat management and per-seat key policy.

Honest note: this is the most likely-to-slip item on the roadmap. Real-time multiplayer is hard, SSO integrations are a tax, and the audit-log work overlaps with the sync work in awkward ways. If team rooms slide into Q1 2027, I won't be surprised. I'd rather ship it late than ship it broken.

Q1 2027, Self-host

The backend will become an open-spec service. Anyone can run it; the desktop app will switch between hosted and self-hosted with a single environment variable. This is partly principle (people who care about local-first should be able to extend that to the sync layer) and partly pragmatism (large customers will not adopt a tool whose sync server they can't run themselves).

The license model is not yet finalised. Expect either AGPL with commercial exceptions, or a source-available license that permits self-hosting but restricts re-selling. I'll commit publicly before the code ships, not after.

Q1 2027, Observability

A first-class transcript explorer. Time-travel through a debate, inspect any turn's tool calls and token usage, fork from any point, and replay with a different judge model to see how the synthesis changes. This is aimed at members building on top of Session's debate format, the people who want to know why a synthesis came out the way it did, not just what it said. I think this is the feature that turns Session from a tool into a substrate, but I'd rather get the boring infrastructure right first.

Always-on: academy and lexicon

Every quarter, the goal is two new academy tracks and roughly thirty new lexicon entries. The community room moderates submissions; we edit. The methodology essays, anatomy of a debate protocol, reading a debate transcript, are kept up to date as the protocol evolves.

What we will not build

This is the part of any roadmap that's usually missing, and it's the part I think matters most. Four things Session will not ship:

1. Our own foundation model. It's not our problem. There are people far better resourced than us doing it; our job is the orchestration layer above them.
2. A managed-hosted Pro that captures user keys server-side. This would violate BYOK by design. If you ever see Session asking you to "store your model-provider key with us for convenience", assume the project has been compromised.
3. A telemetry dashboard for prompt content. Same reason. We do not get to look at your prompts. Aggregate health metrics, yes; content, never.
4. A drag-and-drop agent marketplace. Marketplaces concentrate supply-chain risk, and we don't trust ourselves, or any small team, to vet third-party agents at scale. Submissions to the curated MCP library, reviewed individually, are as far as we go.

How to follow along

This blog is the canonical channel; everything important goes here first. The community room is where the day-to-day conversation happens, bug reports, feature requests, half-formed ideas. RSS will exist as soon as we write the generator, which is itself on the list. If you've read this far, you're already most of the audience I'm writing for. See you in Q3.