Five days ago we made Azure DevOps the system of record for everything we are building. Before that, the source of truth for in-flight work was a constellation of markdown files, GitHub issues, and what was top-of-mind for whoever happened to be at a keyboard. The migration is structurally complete. This post is about what actually changed in how we work, and what we are now able to do that we previously could not.
What ADO replaces
Three things.
First, the markdown coordination files. We had per-agent SYNC files that captured what each lane was doing. Useful at session start; useless when a director needed to see the whole machine. Now the SYNC files are working pads — colour and texture for handoff between sessions in the same lane — and ADO is the system of record for state.
Second, the GitHub issue stream. Issues are excellent for code-adjacent bug reports and useless for cross-cutting strategic work. ADO holds work items at every altitude from Epic down to Task with proper hierarchy.
Third, the architect's mental model. Decisions that lived in Founder's head — what is in flight, what is blocked, what depends on what — are now queryable by every agent at session start. The architect is no longer a single point of context.
The bidirectional link
The most operationally important part is the bidirectional link between source documents and ADO work items. Every work item carries a Sources section listing the canonical doc that drove it. Every canonical doc is supposed to link forward to the work items it produced. Forward lineage answers "where did this idea go." Backward lineage answers "why does this exist in production."
This is harder than it sounds. The temptation is always to link in one direction — usually doc to work item, because the work item is what gets actioned. But that direction alone leaves you unable to read a work item and find the architectural reasoning behind it. You see the action without the orientation. You end up re-deriving the rationale every time the work item is revisited.
Bidirectional lineage forces both directions. It is mechanically more expensive at write time. It pays back hundreds of times at read time.
If you cannot answer "why does this exist in production" by clicking a link, you do not have lineage. You have hope.
The GitHub Actions sync workflow
Every product repository ships a small workflow that watches pull request events and patches the linked ADO work item to the corresponding state. Open a PR with AB#65 in the title — the workflow flips the work item to Active. Merge — the workflow flips it to Resolved. Close without merging — the workflow flips it back to New.
This is twenty lines of YAML and one organisation-level secret. It removes an entire class of "did anyone update the work item?" friction. The work item state and the code state cannot drift, because the code state is what drives the work item state. If you are writing the code, you are updating the system of record by side effect.
We piloted this on the orca-deploy repo last week. End-to-end verified on PR #5. Then rolled it out to all 18 product repos in an afternoon. The total ongoing maintenance cost is zero — the workflow runs without human intervention and only fires on events that already happen.
What this enables that was previously impossible
Three things specifically.
Drift detection. ADO is now the canonical statement of "what we believe the system is." We can compare ADO state against the running infrastructure (Container Apps, ACR images, deployed gateway revision) and surface drift mechanically. A work item marked Resolved with no merged PR is a candidate for false-resolved. A Container App image that does not match any work item is a candidate for unsanctioned change. The drift detector becomes a real thing the moment the source of truth is queryable.
Sprint-as-pipeline. A sprint is a one-week iteration with a Sunday deploy. Work items move through New → Active → Resolved → Closed in lockstep with PRs through Open → Merged → Deployed. The sprint review is now a dashboard query, not a meeting agenda. We can see, for any historical sprint, exactly what was promised, what was delivered, what slipped, and where the slippage compounded.
Cross-cutting coordination. Four AI sessions working in different lanes can now see each other's state without sharing conversation context. A product-lane session finishes a PR and the architecture-lane session sees the work item flip to Resolved at session start. Coordination becomes structural, not interpersonal.
What it cost
One day of architectural work to draft the migration spec and the agent-coordination protocol. One day to ship the GitHub Actions sync to 18 repos and set up the org-level PAT secret. One day to migrate the existing in-flight items into ADO with proper Sources sections.
Three days. The cost was knowing what to do, not doing it.
What it does not solve
ADO is the system of record for work. It is not the source of architectural truth. The architectural truth lives in the canonical documents — strategy, architecture specs, INTENT files, runbooks. ADO holds the implementation state of those documents.
If the documents drift from reality, ADO will faithfully reflect work happening on the wrong specifications. The migration has not solved the problem of keeping the documents themselves current. That remains an editorial discipline, separately enforced.
What ADO has solved is making the "is this work item actually being done" question answerable in milliseconds rather than days. That single change has compounded into a different operating cadence.
Why this is a positioning post
Because operating discipline is the product. We are not selling AI-augmented consultancy in the way the phrase usually implies. We are selling the discipline that makes AI-augmented work auditable. The ADO migration is one example of that discipline applied to ourselves before we apply it to anyone else's engagements.
You cannot sell discipline you do not practice. Customer #0 of every commitment is us.