ArchitectureThe control plane, layer by layer
How Skyflo runs a mission, and learns from it.
The loop, the specialists, the surfaces they run on, the rules, what gets written back, and how Skyflo improves from it.
Skyflo provides AI agent orchestration for software engineering through one local mission. The approved plan, specialist coding agents, execution surfaces, review, and memory stay attached to it.
Surfaces. Desktop, browser, terminal; all on one mission.
SF-05 · one mission, several surfacesInteractive cutaway · hover a layer to inspectOne objective passes through all five
Six states, persisted to disk.
A mission moves from discovery to planning, approval, execution, review, and what it learned. Its state persists locally between sessions.
- state
- persisted beyond the session
- gate
- approval is a state, not a prompt
- review
- separate mutation-disabled profile
- to
- repo agent 1 of 4
- model slot
- “frontier” · routed by you
- repository
- api-gateway · branch mission/rl-311
- objective slice
- enforce per-tenant limits at the edge
- pinned contract
- rate-limit headers v1 · read-only
tools granted
out of bounds: unassigned repositories · unrelated credentials · reviewer mutation
exit: bounded work complete · ready for review
Everything outside the packet is out of scope for that agent.
What a specialist actually receives.
The orchestrator splits the approved plan into packets. Each one names a repository, the slice of the objective it covers, the interface contract pinned for the whole mission, the tools that role may call, and the model slot it runs on.
- isolation
- one boundary per agent
- contract
- pinned before any code changes
- reviewer
- independent · writes no code
What a mission can read and write.
Six surfaces, all attached to the same objective. Opening a browser or a shell for a mission does not start a second, unrelated session, and what each role may do on each surface is explicit.
Repositories
local git
readsregistered checkouts · files · history
writesisolated specialist worktrees
localBrowser
mission surface
readsvisible and interactive page state
writesclick · type · navigate when allowed
availableTerminal
local process
readsstdout · stderr · exit state
writescommands within role capability
availableMonitors
mission schedule
readsrecurring check results
writesstatus attached to the mission
availableAutomations
local runtime
readstask and prior execution context
writesscheduled engineering work
availableMemory
local service
readsscoped · cited · relevant records
writeskeep · correct · dismiss · remove
reviewableFour rules every mission runs under.
These are properties of the loop rather than settings in a menu, so there is no configuration in which a mission starts with write access or implements before you approve. Each rule leaves a trace you can replay.
- default
- read-only until the plan says otherwise
- approvals
- consequence-triggered · yours to widen
- audit
- every action attributable
- reviewer proof
- agent-profiles.test.ts
Start read-only
Every mission opens in discovery. Writes are explicit, later states.
Gate on consequence
Plan mode blocks until you approve the boundary. One approval policy answers every runtime.
Execute locally
Agents run on your linked Mac with your repositories and local credentials.
Record everything
Actions, prompts, and approvals land in the mission log, replayable.
audit / rl-311
planplan proposed · implementation blocked
approveplan approved · boundary pinned
reviewread-only reviewer report attached
+outcomerate limits enforced at api-gateway · limits.yaml per plan tier
+constraint429 responses must carry Retry-After · v1 clients surface it
~ownershipplatform-infra owns the redis cluster (updated)
What the mission leaves behind.
As a mission closes, Skyflo drafts what it taught: outcomes, constraints, ownership facts, and the commands that verified the work. Each draft keeps a link to the work that produced it. What the evidence supports is kept; anything inferred, conflicting, or ambiguous waits for you in Needs attention.
Skyflo improves how it improves.
This is what makes Skyflo a HyperAgent. A workflow that succeeds in two of your repositories can become a Skill, and Skyflo can change the policy that picks an agent and model for each mission. Neither is admitted by the part that proposed it.
- task
- memory and Skills · another agent or you approve
- meta
- routing policy · judged on held-out routes
- root
- approvals, credentials, spend, kill switches · signed release only
npm run lint:ci then npm run test:ci
proposed by claude code · endorsed by antigravity
make check then make test
endorsed by its own proposer · not independent
route score weights · candidate
did not beat the policy in force on held-out routes
Inspect the parts in context.
One mission, phase by phase
An illustrative rate-limiting change across four repositories, with each product phase labeled.
Open the illustrative mission
memoryWhat carries forward
How Skyflo decides what to keep, how a workflow becomes a Skill, and how you undo either.
See how agent memory works
pricingWhat it costs
Everything Skyflo does is on the free plan. Price buys capacity, not capability.
Compare plans and pricing
Questions
How the boundaries work.
What persists, when implementation starts, what each role is allowed to do, and what Skyflo may change about itself. To see the same parts in one example, follow an illustrative mission.
01How does Skyflo orchestrate AI coding agents?+
An approved mission plan is divided into bounded work for specialists. Each specialist receives only the repositories and capabilities its part requires, and a separate read-only reviewer checks the combined result.
02What persists?+
The mission objective and state survive the session, so work can continue without becoming a new chat-shaped project.
03When does implementation start?+
Plan mode blocks until you approve the plan. The approved boundary then guides specialist work.
04What can specialists use?+
Skyflo exposes code, browser, terminal, monitors, and automations to each specialist according to its role's capabilities. External agents reach those tools over MCP, through the same policy and approval path.
05What does independent review mean?+
The reviewer receives only file.read, file.search, and agent.report, receives read-only capability operations, and has mutationAllowed set to false.
06What does Skyflo learn from a mission?+
When a mission completes, Skyflo drafts what it taught: conventions you stated, constraints, and command sequences the work ran successfully, each linked to its source. Drafts the evidence supports are kept; the rest waits in Needs attention. Learn automatically turns this off.
07Can Skyflo change its own rules?+
It can change how it routes work, and only through a held-out judgment it cannot influence. Approvals, credentials, spending limits, and kill switches have no field a proposal could change; only a signed release changes them. Every change it makes to itself is recorded and can be reverted.
Skyflo Desktop
Start with one objective.
Install Skyflo Desktop, use a signed-in coding agent or your own provider key, and approve the plan before implementation begins.
Local execution, with no markup on BYOK or provider-direct usage.