Field notes
Your feature crosses teams and systems. Your AI agent workflow does not.
AI coding agents made the local step of software delivery dramatically faster. They did nothing for the seams - and the seams were already where delivery broke.
Where features actually break
A feature starts as one product intent. Then it fans out: technical analysis, a design, a backend change, a web change, sometimes mobile, an admin surface, analytics, a config flag, QA notes, a release step. The fan-out is normal engineering, not an accident - and it happens in teams with perfectly healthy engineering culture.
What people say afterwards is just as familiar. The feature that was clear at planning fell apart into five different truths during implementation. Backend is done and frontend is done, but the product flow still doesn't work. Analytics and the admin panel got remembered late. The heaviest bugs live on the boundaries between systems. Every team shipped its part - and nobody owns the combined outcome.
None of that is an agent problem. It is the oldest delivery problem there is.
What agents changed - and what they didn't
An agent session is local by construction: one repository, one context, one conversation. That is exactly why agents are good at the local step, and exactly why a session cannot own a crossing. When a team adopts agent tools, the asymmetry gets worse, not better: the local steps compress from days to hours, while the seams stay manual - a human reconciling two transcripts from two repos, hoping they describe the same feature.
The failure mode that follows is specific, and it is not "the agent wrote bad code." It is both sides green, the boundary red: the producer renames a payload key, both test suites pass, and the integrated flow is broken while nobody's tests are wrong. No amount of per-repo agent quality fixes this, because the defect does not live in either repo. It lives between them.
What owning the crossing means
If the seams are where delivery breaks, the unit of control has to be the feature - not the repository. Concretely, that requires:
- one intent, decomposed into per-system workstreams that stay linked to it;
- each system executing with its own worker, plan, and review - the local depth agents are good at is preserved, not flattened;
- the boundary as a first-class check: an explicit contract review across the systems' changes, instead of a human diffing transcripts;
- one system-level gate deciding readiness, with per-system evidence attached;
- and nothing shipping until the crossing itself has proof.
We built this, and recorded it
Orcho's cross-project mode runs one spec across an API repository and a web repository: separate worker runs per system, a contract check that looks exactly at the boundary - it catches the renamed payload key above and rejects the delivery before anything ships - and one run history for the feature. This is a real recording, not a storyboard:
How the check actually works
Worth being precise, because the mechanism is the product. You do not hand-author a boundary contract per feature: the planning phase writes it as part of the cross plan - what each system must uphold at the seam, like the fields the API returns matching what the client reads. The check itself is an inferential gate, not deterministic schema-diffing: a reviewer run - deliberately a different worker than the one that wrote the code, never the author grading itself - reads each side's real changes against that contract and returns a typed verdict (approved, or rejected with named blockers), not a paragraph to interpret. A rejected contract check blocks the run; the final release call stays with a human. Orcho's stance is verifiable autonomy with advisory authority - the gate does the reading and produces the evidence, a person still owns the decision.
Try it on your own seams
Orcho's engine is open source (Apache-2.0), and installing the public alpha takes a minute. Symphos runs early team pilots: if your team works across more than one system with more than one agent tool, bring one real workflow.