Start a conversation
Open a context and talk to your agent in plain language. Everything lives on your own node, local-first, from the very first word.

Real capabilities for your agent, explicit permission to use them, and a direct line to whoever holds the rest of the work. The context travels with it — threads, decisions, the actions already taken — so the team can change shape without the work starting over.
Open a context and talk to your agent in plain language. Everything lives on your own node, local-first, from the very first word.

Add a peer — a teammate, a device, or another agent. Once a signalling host has introduced you, the connection is direct and end-to-end encrypted.

Bring in MCP servers, ACP agents, skills, and device primitives. Each capability becomes something your agent — or a trusted peer — can run.

Your agent engages the right peers, runs the actions they have been granted, and carries the work forward — while you stay in the loop.

A capability is anything you have equipped and granted — from a tool on a remote server to a script on your own disk. Your agent sees one flat surface; you decide what is on it.
Connect any Model Context Protocol server — spawned locally or reached over HTTP, with authorization handled in-protocol. Its tools arrive as capabilities your agent can call.
The inverse of MCP: bring a whole coding agent — Claude Code, Gemini CLI — and KeepTalking drives it as the client. The peers you trust can put work to it without it ever leaving your machine.
Package an instruction, a script, and the files it needs into one capability. Skills run inside a sandbox with a declared filesystem and network boundary — and nothing outside it.
The things only the device in front of you can do — run a Shortcut, read a calendar, open a link, ask you for a file. Small, scoped, and callable by a peer you have granted.
Your contexts are the knowledge base. Threads are grouped and indexed as they happen, so an agent can go find what was decided instead of being told again.
There is no house model, and no preferred one. KeepTalking is the substrate your agent plugs into — which agent that is stays entirely your call.
OpenRouter, OpenAI, or any OpenAI-compatible endpoint. Your key, your account, your bill — we never sit between you and the model you chose.
Point a node at a machine on your own network, or at the one under your desk. The conversation and everything it touches stays inside your perimeter.
The active provider is a setting, not an install. Change it between turns, run different models on different devices, and keep the history you already have.
Once two peers have found each other they talk directly, not through us. That is a privacy property, but it is also how authority survives: when two nodes act on two people's behalf, nobody in between gets to arbitrate.
Nodes negotiate a path with ICE and then talk straight to each other. When a direct route exists — and it usually does — nothing in the middle is in a position to read the traffic.
Action calls and their parameters are sealed to the caller and the callee. A capability invocation is legible to the two nodes involved and to no one else.
Peers still have to find each other, and that introduction happens through a signalling host. It is the one central piece — so it is yours to run, on your own network, for your own fleet.
Nothing to sign up for, nothing to migrate off, nothing held hostage. The whole state of your work is on devices you already own.
A node is a keypair generated on the device. Nothing to sign up for, and no directory you have to appear in before two people can work together.
Optional, and only about your own devices: sign in with a passkey and your Mac, iPhone, and iPad recognise each other as yours without you introducing them one by one.
Permission is granted per peer and per action, by you, in the moment. No inherited role quietly hands someone a capability you never considered.
Contexts, threads, embeddings, and grants live in a local database on hardware you own. Backups are yours to take, and deletions are real.
Not to use it. Your identity is a keypair generated on your device the first time you open the app, and two people can work together on nothing more than that — no email, no seat count, no billing wall.
Claiming your own devices. Sign in with a passkey and your Mac, iPhone, and iPad recognise each other as yours, so they trust each other without you introducing them one at a time. It is optional, it is only about your own fleet, and the key-value host behind it is yours to run.
Whichever you like. Point it at OpenRouter, OpenAI, or any OpenAI-compatible endpoint — including one running on your own machine or inside your own network. The provider is a setting, not an install, so you can change it between turns.
On your devices. Contexts, threads, grants, and keys sit in a local database on hardware you own, and sync directly to the peers you have trusted. We do not run a server that holds your conversations, because there is no such server.
Partly, and we would rather be straight about it. Everything already on your device stays readable, and a local model keeps answering. But peers find each other through a signalling host, so with that unreachable you are working alone until it comes back — genuinely serverless discovery is not something we ship today.
Whatever you have equipped and granted. MCP servers, ACP agents, skills, device primitives, and retrieval over your own contexts all become capabilities your agent — or a peer you trust — can call, and each one runs only against an explicit grant you can withdraw.
Yes, and for a fleet you probably should. The signalling host is the one central piece, and it is fully self-hostable — put it on your own network alongside a model you host, and nothing about the deployment has to leave it.
The SDK is. KeepTalkingCore is a public Swift package — domain models, distributed actions, semantic threading, and the peer-to-peer transport. The app that sits on top of it is in private testing.
Mac, iPhone, and iPad, with the beta open now. The SDK itself builds on Apple platforms and Linux, so a node does not have to be a person at a screen.
The SDK the app is built on — domain models, distributed actions, semantic threading, and the peer-to-peer transport, with encryption and MCP to be wired in.
The workbench experience, on your own devices.