features

Everything on the table,
everything under control

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.

how it works

From hello
to handoff

01 start

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.

Conversation view — your message and your agent replying
02 connect

Trust a node

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.

Adding a peer node and confirming a trusted, encrypted connection
03 equip

Add & grant actions

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

Adding a skill / MCP server to the action catalog
04 collaborate

Collaborate

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

Agent delegating a task to a peer and running a granted action
capabilities

What your agent can run

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.

MCP servers

protocol

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.

  • stdio & HTTP transports
  • OAuth handled for you

ACP agents

protocol

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.

  • Agent Client Protocol
  • Advisory containment · macOS

Skills

scripted

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.

  • Sandboxed execution
  • Declared inputs & outputs

Primitives

on device

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.

  • Shortcuts · Calendar · Files
  • Per-call scope, blocking prompts

Semantic retrieval

built in

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.

  • Auto-threaded contexts
  • On-device embeddings
models

Bring your own model

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.

Hosted providers

byo key

OpenRouter, OpenAI, or any OpenAI-compatible endpoint. Your key, your account, your bill — we never sit between you and the model you chose.

  • OpenAI-compatible
  • Configured per node

Local & self-hosted

in network

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.

  • No egress required
  • Same features either way

Switchable, per node

no lock-in

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.

  • Change without migrating
  • Per-turn reasoning controls
transport

How the work moves

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.

Direct by default

peer to peer

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.

  • ICE over libjuice + SwiftNIO
  • Relayed only as a fallback

Sealed end to end

encrypted

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.

  • Per-call sealed envelopes
  • Keys never leave the device

One host to meet at

self-hostable

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.

  • Self-hosted signalling & relay
  • Provisioned per deployment
identity & data

Where everything lives

Nothing to sign up for, nothing to migrate off, nothing held hostage. The whole state of your work is on devices you already own.

Keypair identity

no signup

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.

  • Created on first launch
  • Trust is peer to peer

A passkey, if you want one

your own fleet

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.

  • WebAuthn passkey · no password
  • Self-hostable key-value host

Grants, not roles

explicit

Permission is granted per peer and per action, by you, in the moment. No inherited role quietly hands someone a capability you never considered.

  • Per-action, per-peer
  • Revocable at any time

Your storage

on device

Contexts, threads, embeddings, and grants live in a local database on hardware you own. Backups are yours to take, and deletions are real.

  • Local database per node
  • Semantic threads & retrieval
questions

Before
you ask

  • Do I need an account?

    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.

  • Then what is the passkey for?

    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.

  • Which models can I use?

    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.

  • Where does my data live?

    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.

  • Does it work offline?

    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.

  • What can my agent actually do?

    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.

  • Can we run the whole thing in-house?

    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.

  • Is it open source?

    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.

  • What runs it today?

    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.

build on it

Open at
the core