The Repo as Delivery Mechanism
An advisory mandate delivered through a private GitHub repository: what it changed about shared material, about the sessions, and what it foreshadows for services work.
Today we concluded an advisory mandate: a high-level strategic re-alignment for a founder-led consultancy, delivered through a private GitHub repository. Documents, data exports, analyses, and open questions lived there as plain files and issues.
Clients have always shared a lot of material. Everybody knows the Miro board full of PDFs: decks, exports, screenshots, all pinned somewhere, most of it unread. The format guarantees it stays unread. And the social contract of a normal engagement caps what gets shared anyway, because sending a document implies the other side owes it a close read, and no scope covers reading everything.
The repo dissolves both limits. Everything arrives as plain, machine-readable files, and we agreed upfront that agents do the first pass, on both sides. So raw exports, internal decks, and project histories flowed in, and nobody performed having read them.
The face-to-face sessions changed with it. Both sides knew preparation ran through agents working the repo. You arrive with different artifacts: synthesized positions, mapped contradictions, drafted options. Session time goes to judgment.
I read this as a foreshadowing of how services work will change. AI shifting the means of producing documents is one part. The other is new, structured data for areas of work that used to be unstructured. A glossy deck of punchy lines and imagery is fine when a full record exists behind it: transcripts of creating and presenting it, traces of agentic work sessions, the reasoning behind each decision condensed into narrative form. This legibility will be uncomfortable for many. It demands a real understanding of your own methods, portable from one engagement to the next, and clients who can operate systems that process this kind of data.