ArchitectureThe harness, layer by layer
How the harness runs a mission.
The loop, the specialists, the surfaces they run on, the rules, and what gets written back.
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 accepted memory. 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 the harness 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 harness
readstask and prior execution context
writesscheduled engineering work
availableMemory
local service
readsscoped · cited · relevant records
writesreview · accept · dismiss · forget
reviewedFour 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 implementation boundary.
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 it proposes records: outcomes, constraints, ownership facts. Each one keeps a link to the work that produced it, and none of them is kept until you accept it.
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 records are scoped, where their sources come from, and how you remove one.
See how agent memory works
pricingWhat it costs
The whole harness is on the free plan. Price buys capacity, not capability.
Compare plans and pricing
Questions
How the boundaries work.
What persists, when implementation starts, and what each role is allowed to do. 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?+
The current harness exposes code, browser, terminal, monitors, and automations according to each role's capabilities.
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.
Skyflo Desktop
Start with one objective.
Install the local harness, use a supported signed-in harness or provider key, and approve the plan before implementation begins.
Local execution, with no markup on BYOK or provider-direct usage.