EnterpriseFor CTOs, platform, and security teams
One control planeabove every agent your engineers run.
Your engineers already run several coding agents, models, and repositories. Skyflo governs that work as one: a single approval policy, isolated specialists, independent review, and an append-only record for every mission, on each engineer's Mac.
30 minutes on the current build, with an objective from your backlog.
Agents your engineers already run
- Codex
- Claude Code
- Cursor Agent
- Antigravity
- Grok CLI
- OpenCode
- Pi
- ACP agents
- PlanA person approves the plan before any agent writes code
- AuthorityOne access mode on every runtime, Ask for approval by default
- IsolationA leased worktree per specialist, inside a Seatbelt profile
- ReviewA reviewer that reads, searches, and reports, and cannot write
- RecordAppend-only and hash-linked, on the Mac that ran the mission
Agents multiplied inside your organization. The layer above them did not.
Each agent brings its own permission prompts, its own transcript, and its own idea of done. Skyflo does not replace them. It gives the organization one place where authority, isolation, review, and the record live, and lets engineers keep the agents they are productive with.
Skyflo is an AI engineering harness and control plane for coding agents. It runs Codex, Claude Code, Cursor Agent, and conforming ACP agents under one governed mission, with local execution and your own model keys.
- agents
- Codex · Claude Code · Cursor Agent · Antigravity · Grok CLI · OpenCode · Pi · ACP
- keeps
- each agent's own sign-in and workflow
- adds
- approvals · isolation · review · record · memory
Authority
beforePermission prompts and auto-approve flags inside each agent, set per engineer.
skyfloOne approval policy on every runtime, four access modes, and every decision recorded.
Isolation
beforeA shared checkout, one agent at a time, and a rebase when two collide.
skyfloA leased git worktree per specialist, confined by a Seatbelt profile.
Review
beforeThe session that wrote the code is the session that says it is done.
skyfloA separate reviewer profile that can read, search, and report, and cannot write.
Record
beforeTranscripts scattered across tools, gone when the window closes.
skyfloOne append-only, hash-linked record per mission, on the Mac that ran it.
Learning
beforeEvery session starts from zero.
skyfloMemory and Skills kept on evidence, each revertible. Per engineer today.
What ships, what is Planned, and what an engagement adds.
Three lists, kept apart on purpose, so your security review starts from the same facts we do. The status page shows the code and tests behind every current row.
In the current build
09Ships in Skyflo Desktop today.
- Codex, Claude Code, Cursor Agent, Antigravity, Grok CLI, OpenCode, Pi, and conforming ACP agents in one mission
- One approval policy on every runtime, four access modes, every decision recorded
- Plan mode that blocks implementation until a person approves
- A leased worktree per specialist and a Seatbelt profile around each external agent
- A reviewer that cannot change the code it reviews
- An append-only, hash-linked record per mission
- Keys in the macOS Keychain, sensitive values masked, secrets redacted
- Memory, Skills, and an Improvements ledger with one Revert
- Linked devices listed and revocable in the account console
Planned
06Designed, not implemented. Labeled wherever it appears.
- Team administration and policyPlanned
- Organization-wide shared memoryPlanned
- Contracted security, deployment, and support controlsPlanned
- Managed inference through the Skyflo gatewayPlanned
- Typed connectors for Kubernetes, CI, and telemetryPlanned
- Missions that finish on evidence rather than a final messagePlanned
By agreement, not a product capability
04Things people do with you.
- A walkthrough of the shipped code paths behind this page with your security reviewers
- A pilot plan with named objectives, participating engineers, and success criteria
- A roadmap conversation on team administration and organization memory
- Commercial terms for Team and Enterprise plans as those plans open
Nothing in this column changes what the software does today.
Everything runs on the engineer's Mac. What leaves it is a decision you can read.
Missions, repositories, prompts, terminal output, and the record stay on the machine. A model request leaves only on the lane the engineer chose, and the privacy notice states each lane in one table. The rows below are the same facts, with the code behind them.
Repositories and files
On the engineer's Mac. Specialists work in leased git worktrees, and one mission can span the checkouts you register.
Credentials
Your keys stay in the macOS Keychain and are never sent to Skyflo. Agents keep their own sign-ins. A credential reaches a runtime only as a lease in its environment at spawn, never persisted, logged, or placed on a command line.
Sensitive files
Values in key and env files are masked before an agent can see them.
Logs and diagnostics
Secret-shaped values are redacted before anything is persisted or reported. Product usage sharing is off by default, and crash diagnostics are a separate choice.
The account service
Identity, organisation, linked devices, plan, and coarse milestones such as first launch and plan approval, as an event name, a random id, and a time. No mission content and no mission identifiers. Any linked Mac can be revoked from the console.
Local model
leaves the Mac?Nothing leaves the Mac.
counterpartyNone; no remote model is called.
Signed-in agent or your own key
leaves the Mac?The request goes to that provider from the Mac.
counterpartyThat provider, under your account and its terms. Skyflo is not in the path.
Skyflo managed inferencePlanned
leaves the Mac?Would go through Skyflo to a provider Skyflo pays.
counterpartyPlanned. Off by default and gated behind a disclosure accepted in the console.
Your code is not used to train models. Execution stays on your linked Mac. BYOK credentials stay in the macOS Keychain.
coder specialist
reviewer
Parallel work that cannot collide, judged by a process that cannot edit.
Each coder specialist receives a delegation packet: one repository, one slice of the objective, the interface contract pinned for the whole mission, and only the tools its role may call. It works in its own git worktree, so four specialists on four repositories cannot overwrite each other. A separate reviewer profile reads, searches, and reports, with mutation disabled.
What a mission writes down, and what that record can and cannot prove.
Each mission keeps an append-only record on the Mac that ran it. Every event is hash-linked to the one before it, so accidental corruption, missing events, and reordering are detectable. It is not a defense against someone who can rewrite the whole store, and there is no organization-wide view of it today.
- shape
- append-only · each event hash-linked to the last
- before write
- secret-shaped values redacted
- location
- the engineer's Mac
- org view
- Planned with team administration
- 01The objective, each plan version, and the approval that unblocked implementation
- 02Every permission decision, including the ones policy answered, with the policy in force
- 03Skyflo tool calls and their outcomes, including calls an external agent made over MCP
- 04The reviewer's findings, attached to the mission they judged
- 05Memory records with the mission and files they came from
- 06Every change Skyflo made to itself, with who judged it and the Revert that undoes it
It learns from your missions inside a boundary it cannot change.
Skyflo improves how it improves. What it keeps is kept on evidence, what it changes about itself is judged by something other than the part that proposed it, and every change can be reverted. Today this happens per engineer; organization-wide shared memory is Planned.
Can change
Memory, Skills, routing
What a finished mission taught, a workflow proven in two repositories, and the policy that picks an agent and model for a mission. A routing threshold may tighten and never loosen.
How it is admitted
Never by the part that proposed it
Routing changes are judged on held-out routes the proposal was not built from. A Skill is admitted when a second independent agent arrives at the same Skill, or a person keeps it.
Cannot touch
The root layer
Approvals, credentials, spending limits, kill switches, redaction, and evidence hashing have no field a proposal can express. Only a signed release changes them.
Start with one real objective and two to five engineers.
Skyflo is evaluated the way it is used: on your repositories, with the agents your team already runs. The engagement adds people, not a different product.
- 01
Demo on a real objective
Thirty minutes on the current build with an objective from your backlog: plan approval, delegation across the agents your team uses, independent review, and what the mission leaves behind.
- 02
Pilot with two to five engineers
Each installs Skyflo Desktop, registers the repositories a change touches, and works with their existing agents and keys. Nothing to provision centrally; the pilot runs on the current build.
- 03
Read the record together
Approvals, review reports, what was learned, and the Improvements ledger, on the machines that produced them. This is also where your security reviewers see the boundaries above in use.
- 04
Decide the shape
Continue on Free, or scope Team and Enterprise as those plans open. Paid plans and managed model access are not available yet, and nothing in an engagement changes what the software does today.
Questions
What your security review will ask.
Each answer states the shipped behavior and names the Planned item where one exists. The privacy notice is the binding statement of where data goes.
01Does Skyflo offer SSO or SCIM?+
Not today. Sign-in to the account console is Google, GitHub, or a one-time code sent by email, handled by Clerk, so Skyflo never holds a password. Team administration and policy is Planned and is labeled that way wherever it appears. Skyflo does not claim single sign-on or provisioning until they ship.
02Which compliance certifications does Skyflo hold?+
None are claimed. What Skyflo publishes is the behavior of the shipped software: where code and credentials live, what is recorded, how approvals work, and the privacy notice that states each model lane. Contracted security, deployment, and support controls are Planned.
03Does our code leave our machines?+
Missions, repositories, prompts, terminal output, and the record stay on each engineer's Mac. A model request leaves only on the lane the engineer chose: a local model sends nothing; a signed-in agent or your own key sends the request to that provider under your account, with Skyflo not in the path; Skyflo managed inference is Planned, off by default, and gated behind a disclosure you accept in the console.
04Can an agent reach our production systems?+
Skyflo's own tools do not connect to cloud, CI, or infrastructure today; typed connectors are Planned. In every access mode except Full access, connected effects are denied and the runtime is confined to its leased worktree. Full access is an engineer's explicit standing authorization, confirmed in a dialog, and what it can reach is bounded by that engineer's own credentials.
05Can we self-host Skyflo or run it in our cloud?+
There is nothing to host. Execution happens on each engineer's Mac, and Skyflo has no cloud execution. The account service is operated by Skyflo and holds account records: identity, organisation, linked devices, plan, and coarse milestones. It holds no mission content.
06Can we control which agents and versions run?+
A runtime version without a passing conformance observation fails closed, and per-runtime kill switches sit in the root layer that only a signed build changes. Each engineer chooses their agents today; a central administration surface for your organization is Planned.
07Does Skyflo train models on our code?+
No. Your code is not used to train models. On your own key or a signed-in agent, the provider is your counterparty under its own terms.
08What happens when the account service or a model provider is unavailable?+
Work on the Mac continues. Missions, approvals, and the record do not depend on the account service, which manages the account rather than the work. Model requests depend on the provider you chose, exactly as they would without Skyflo.
Enterprise
Bring one objective and the agents your team already runs.
A thirty-minute walkthrough of the current build on a real objective from your backlog, with Planned items named as such.
Paid plans and managed model access are not available yet. Pilots run on the current build.