The Lie in the Word "Change"
Ask an engineer to "add rate limiting to the public API" and watch what actually happens.
The middleware lands in api-gateway. The plan tiers live in billing-service. The counters need a Redis cluster, which means platform-infra. Customers will ask where their quota went, so web-console needs a usage meter. The delivery pipeline needs to know about the new dependency, and production needs a canary before anyone believes any of it.
One sentence of intent. Five or six systems of consequence.
We talk about "a change" as if it were a single object, but in any organization past a certain size, a change is a distribution — a set of coordinated edits with an invariant that must hold between them. The invariant is the real deliverable. The edits are just how you get there.
This is the part of engineering that current AI tooling almost entirely ignores.
Why Single-Repository Agents Plateau
Coding agents are genuinely good now. Point one at a repository, give it a well-scoped task, and it will often come back with a competent pull request. That is not the ceiling being described here.
The ceiling is structural. An agent that lives inside one repository has three blind spots it cannot reason its way out of:
- It cannot see the other half of its own contract. If the API shape it emits must match what another service consumes, that constraint lives outside its world. It will happily produce a locally perfect, globally wrong change.
- It cannot sequence. Cross-system changes have an order: provision the infrastructure before the code that needs it; ship the producer before the consumer; migrate data before removing the old path. Sequencing knowledge is exactly the kind of thing that lives in a staff engineer's head and nowhere else.
- It cannot verify the outcome. "The tests pass in this repo" is not the same claim as "the change works." The proof lives in CI matrices, staging behavior, and production metrics — systems the agent never touches.
Teams work around this by making a human the integration layer. Someone opens four chat sessions with four agents, copies context between them, holds the interface in their head, and manually checks that the pieces still fit. It works. It is also the least leveraged possible use of your most senior people — and it quietly caps how much of the work you can hand to agents at all.
What Coordinated Change Actually Requires
Strip the problem to its invariants and the requirements are surprisingly crisp:
- A map before a plan. You cannot coordinate systems you have not identified. Discovery — walking imports, pipeline definitions, infrastructure code, and runtime topology — has to happen first, read-only, before anything is proposed.
- Interfaces pinned before parallel work begins. The moment two workstreams proceed simultaneously, the contract between them must be frozen — explicitly, versioned, checkable. Otherwise you have built a drift generator.
- One boundary per worker. Whether the worker is a person or an agent, giving it one repository and one pinned contract keeps its context small and its failure modes local.
- Continuous cross-checks while work is open. Drift you catch at merge time is a conflict. Drift you catch while both PRs are open is a course correction. The difference is hours versus days.
- Verification that spans the whole change. The unit of "done" is the objective, not any individual PR.
None of this is novel. It is exactly how a well-run platform team executes a migration. The difference is that today it lives in tribal knowledge and heroic project management. The claim behind Skyflo is that this structure can be made explicit, durable, and executable.
The Mission as a First-Class Object
Skyflo's answer is the mission: one durable object that owns an objective from acceptance to verified outcome.
A mission is not a chat session. Sessions are ephemeral, single-threaded, and scoped to whatever context you pasted in. A mission has:
- An objective and constraints — "introduce per-tenant rate limiting; no breaking change for existing clients."
- A discovered scope — the actual set of repositories, infrastructure, and pipelines in play, found by reading the systems rather than asking you to enumerate them.
- A system-level plan — workstreams per repository, with the shared interfaces pinned first and human approval gates placed where consequences live (infrastructure spend, production mutations).
- Delegated specialist agents — one per repository, each holding only its own boundary plus the contract. A lead orchestrator holds the whole.
- Linked pull requests — the change lands as normal, reviewable PRs, grouped under the mission, with interface drift re-checked on every push.
- Independent verification — a separate agent that wrote none of the code reads tests, CI, canary, and runtime before the mission is allowed to claim completion.
- A remembered outcome — what changed, why, and what constraints were discovered, written to engineering memory where the next mission will look first.
The six phases — discover, plan, delegate, implement, verify, remember — are not a marketing diagram. They are the control flow. You can watch a full replay of one mission, phase by phase, on the missions page.
Pinned Interfaces: The Load-Bearing Idea
If one idea in this design carries the most weight, it is pinning interfaces before delegation.
When the rate-limiting mission plans its work, the very first artifact is the contract: response headers (RateLimit-Limit, RateLimit-Remaining, RateLimit-Reset), the failure mode (429 with Retry-After), and where limits are defined (a per-tier limits.yaml). Every delegated agent receives that contract as a constraint, not a suggestion.
This does two things. It converts an open-ended coordination problem into four independent, well-scoped tasks — which is precisely the shape of work agents are already good at. And it gives the harness something objective to check: on every push, does each side still conform? A pinned contract turns "are we still consistent?" from a meeting into a test.
Notably, this is also how the best human-run migrations work. The design doc that says "here is the interface, teams go build your side" is a pinned contract with worse tooling.
What This Looks Like in Practice
The honest pitch is not that missions make cross-repository change effortless. It is that they make it legible.
You see the map before any edit. You approve the steps that cost money or touch production. You review normal pull requests, in your normal review flow, with the mission holding them together. And when the verification agent signs off, you get an evidence chain — change, tests, CI, canary, runtime — rather than a vibe.
The work that used to require a spreadsheet, a war room, and one heroic staff engineer becomes a durable object you can inspect at any phase.
That staff engineer, meanwhile, gets to do the part only they can do: decide what is worth changing, and whether the evidence is good enough. The coordination — the part that was always overhead — is what got automated.