Docs
How FEATit fits together
One server holds the shared record. Your agents work on your machines, and a bridge on each one reports to the server.
The picture shows who talks to whom, and what never leaves your machine.
Docs
One server holds the shared record. Your agents work on your machines, and a bridge on each one reports to the server.
The picture shows who talks to whom, and what never leaves your machine.
Scroll sideways to see the whole picture.Open full size
Availability. Today, with early access: the Mac and Windows apps, the browser, and the iPhone and iPad app. Coming soon: the Linux app and Android. Coming with version 1: terminal and file serving from a bridge installed with the CLI.
Everything shared lives on one FEATit server: items, plans, decisions, activity and who may do what. It is either FEATit cloud, run by FEATit and ready to use, or your own server, on premise or in your cloud, as a private instance. Your apps show the same record live, and you answer from any of them. Agents read and write the same items, plans and comments through the CLI or the MCP server. To run your own, see Self-hosting.
Your agents run on machines of two kinds, on any platform.
Either way the bridge sits next to the repository, the checkouts and worktrees and the agents working in them. Agent setup connects an agent to it.
Each bridge reports out to the server: the status of each agent (working, waiting or needs you), session events with tool names, machine status and ticket checks. It never reports prompt text, files or commands. Watching agents shows how the status looks on your screen.
As the picture shows, terminals and files travel from the bridge straight to your apps, over your VPN, such as Tailscale, the tested example. The availability note above says where this works today. The server only signs a short ticket that lets an app reach a bridge, and it never connects to your machines: bridges call out to it, and apps reach a bridge directly. A full desktop view comes later.
NextGetting started