Overview

How Floating Keys works

Floating Keys is a workspace where you direct AI agents across your projects. Every piece of work records who asked for it, what it was allowed to touch, what actually happened and whether a person accepted the result.

Live: Available to the public on floatingkeys.com today.
Local: Implemented in the local desktop app and Core; setup and provider prerequisites apply.
Partial: Some pieces exist and are verified; the full experience is still being built.
Planned: A design target for the hosted beta. Not available yet.

One product, three names#

You will see three names in these docs. They describe layers of the same system, not separate products you need to buy or configure.

Floating Keys: The product you use: the web and desktop interface for projects, threads, runs, approvals, connectors and Keys.
OpenSaddle Core: The control plane underneath. Core is the authority for projects, conversations, runs, policy, approvals and receipts. Some technical identifiers still carry the OpenSaddle name for compatibility.
KRAIL: Repository-backed project knowledge. Floating Keys can read a project’s KRAIL layout so agents start from reviewed, sourced context instead of guesses.

Surfaces

Web appInvite-only hosted betaPlanned

Desktop appPlus permissioned local powersLocal

OpenSaddle Core

Projects and threads

Runs and approvals

Policy and receipts

Work and knowledge

Agent harnessesCodex, Claude CodePartial

Connectors and KeysOutside servicesPlanned

KRAIL knowledgeRepository-backedLocal

Diagram How the layers relate. Interfaces present Core’s state; Core decides what may happen; agents do the work inside the authority Core grants.

What is available today#

Floating Keys is early. The public site runs a live waitlist for an invite-only beta. Sign in with Google or an emailed link to open the new workspace UI. Scheduled, Images and Sites examples are explicitly simulated. The desktop app and Core run locally for a single user. Hosted chat, hosted agents and connected provider accounts are planned and not yet available.

Public waitlistLive
Join with your email and confirm it. Joining does not create an account.
Desktop app and CoreLocal
Single-user projects, threads and governed runs on your own computer.
Coding agentsPartial
Codex task execution and result review are verified locally. Other agents are at earlier stages.
Account identityPartial
Google and emailed sign-in links. Phone verification awaits Twilio configuration. Sign-in does not grant beta access.
Signed-in workspace UILive
Navigation, appearance and isolated previews. Agent execution remains unavailable on the public host.
Hosted chatPlanned
Invite-only durable chat in the browser.
Connectors and KeysPlanned
Governed access to outside services with per-project, revocable Keys.
Hosted agentsPlanned
Long-running agents on isolated hosted workers.

Design principles#

Confirmed state only. The interface shows an effect as done only when the system that owns it has confirmed it. A pending action looks pending.
Authority is explicit. Agents are their own principals with their own grants. They never silently inherit everything the person who started them can do.
Evidence over judgment. Agents can report what they did. Decisions that settle something for other people — merging, closing, publishing — stay with a person.
Finished is not the same as accepted. A run can complete, pass checks and still wait for a human to accept it. Floating Keys keeps those states separate.
Honest status. Capabilities are labelled as live, local, partial or planned. A catalog entry is not proof that something works.

Where to go next#

Projects and threads — how work is organized and who can see it.
Runs and review — how a request becomes durable, reviewable work.
Agents, models and environments — what actually does the work, and where.
Keys and connectors — how outside services will be reached safely.
Memory and context — KRAIL, imported history and what agents are shown.
Architecture — the layers, and how web and desktop differ.

Status reflects September 2026. Planned items are design targets, not commitments to a date.