Several Agents Are Not One Change
Ask an engineer to add rate limiting to a public API and the request quickly spreads. The middleware may live in api-gateway, plan tiers in billing-service, shared configuration in platform-infra, and the customer meter in web-console.
Several coding agents can edit those repositories. The remaining problem is keeping one contract, landing order, approval boundary, and review record across them. Independent sessions do not create that shared object automatically.
This article describes that coordination problem. Skyflo currently supports missions across registered Git checkouts, plan approval, isolated specialist worktrees, browser and terminal surfaces, automations, independent read-only review, and accepted personal memory. CI, telemetry, and infrastructure connectors are Planned and remain labelled that way on the status page.
What Separate Sessions Leave With the Operator
Each agent session can be competent and still leave four system-level decisions unowned:
- The shared contract. Producers and consumers need one agreed interface rather than separately inferred versions.
- The landing order. Infrastructure, producers, consumers, and cleanup often have to ship in sequence.
- The approval boundary. The team needs one record of what was approved before work began.
- The combined review. Local correctness in each repository does not establish that the pieces form the intended change.
The issue is not that coding agents cannot work across repositories. Several products now support multi-repository and multi-agent execution. The issue is that parallel execution is not the same thing as shared ownership.
What Coordinated Change Requires
The architecture is straightforward:
- Register the repositories that belong to the objective.
- Establish one plan and approval boundary before implementation.
- Give each specialist a bounded slice in an isolated worktree.
- Carry the same interface contract and landing order into every slice.
- Review the combined result against the objective, not only each local diff.
CI matrices, deployment state, and runtime telemetry should eventually join that record. In Skyflo those connectors and evidence-gated completion remain Planned, so the current product does not claim that end-to-end chain today.
The Mission as the Shared Object
Skyflo calls the persistent local object a mission. It contains the objective, registered checkouts, approved plan, delegated work, execution history, independent review, and any memory the user accepts.
The six states are discover, plan, delegate, implement, verify, and remember. In the current build, the reviewer can inspect files and report findings but cannot edit the workspace or run mutating capability operations. The broader evidence-gated Verify state is the target architecture, not a shipped completion gate.
The missions page shows an illustrative example rather than a measured customer run.
The Contract Is the Load-Bearing Artifact
For the rate-limiting example, the contract might define response headers, the 429 failure shape, and which repository owns tier limits. Every specialist receives the same version.
That turns an open coordination problem into bounded work. It also gives human review a precise question: do all sides still implement the contract that was approved? Automated continuous contract checks would make this stronger, but they should not be described as current Skyflo behavior until the product and status registry say so.
What Better Coordination Buys
The useful outcome is legibility. A team can recover what it approved, which repositories were in scope, what each specialist changed, what the independent reviewer found, and which source-linked memory was accepted for later work.
The staff engineer still decides what is worth changing and whether the result is good enough. The harness keeps those decisions attached to the work instead of distributing them across unrelated sessions.