Slide 1 / Who is talking
Jeff James
26+ years at Microsoft, most of it making enterprise operations run at scale. Now building agent fleets in the open and helping teams become AI native, bringing decades of hard-won experience to small, dynamic companies that move too fast to learn it the slow way.
Today: what I built at Microsoft, what I run at home, and what might transfer to how you work.
Three decades, four chapters
Attachmate, then a startup
Attachmate, 1991 to 1998: support technician through program management, systems engineering, and product management. Drove engineering change from direct customer experience.
RevX.net, 1998 to 2001: the startup years, wearing every hat from support and IT to business development and product design while the company grew from six people to fifty, then shrank back to fifteen. First consulting gig at age 11: a Lotus 1-2-3 worksheet for my dad's marketing firm.
Enterprise operations at scale
GM on the Operations team and part of the core team that built Office 365: solution architect on MMS and BPOS with the first managed-service customers, then Global Black Belt closing the first productivity-cloud deals in Japan and US life sciences.
Built FastTrack Architects from concept to a global organization, including the Customer Health metric that now sits on an EVP scorecard. Most recently GM of New Commerce FastTrack: the modern-commerce transition for roughly 40,000 enterprise customers, influencing more than $34B in MCA-E cloud revenue last fiscal year.
Microsoft's Customer Success Engine within Engineering
FastTrack is the program that helps enterprise customers deploy, adopt, and get value from Microsoft cloud services. It is an engineering and operations organization, not a sales one: delivery PMs, feedback loops into the product teams, and the machinery that keeps thousands of engagements moving.
Agentifying FastTrack through E3
The last act at Microsoft: turning FastTrack operations from manual knowledge work into an agentified operating model. The path we took became the E3 model (Evangelize, Enable, Empower), covered in section 5.
Thirteen named agents, two human gates, one archive
The vault is my working archive: every thought I speak out loud gets captured, filed, linked, and surfaced without me touching a keyboard. Agents run the arrows. I keep the decisions that matter. First, the daily loop.
The overnight build loop and the back office
While I sleep, flagged ideas become specs, and approved specs become reviewed pull requests. The two gates stay human.
- Files are the message bus. No queues, no databases. Every agent reads and writes plain markdown in a git repo, so everything is inspectable and reversible.
- Agents advance, humans gate. The two decisions that matter, what gets built and whether it is right, are deliberately not agents.
- Only the agents burn tokens. Clerks and couriers are deterministic scripts that cost nothing. Model judgment is spent only where judgment is needed.
- Every run is a payroll row. Medici's ledger records every run, every provider, every cent, so the fleet's cost is a scan, not a guess.
The whole board: how they all work together
The roster: capture to surface
Every function is named so it can be measured, discussed, and upgraded as a thing with an identity. "Dewey keeps misfiling athletics captures" is a bug report with an owner; "improve the router" is a wish. Click any agent's name for its build page in the appendix.
| Agent | Purpose | Named for | Built on | Challenges along the way |
|---|---|---|---|---|
| Tiro | Voice ingestion. Phone captures and Teams recordings land as raw text. Hears everything, adds nothing. | Cicero's secretary, who invented Roman shorthand because his boss talked too fast. | iOS Shortcut + Python (ffmpeg, Whisper on Groq's free tier). ~$0. | Kept deliberately dumb. The temptation to give the courier judgment is constant; resisting it is the design. |
| Dewey | Files and routes every capture: cleans without sanitizing, three honest backlinks, four-way triage into note, content card, todo, or feature flag. | Melvil Dewey, the Decimal Classification. Gave every book an address. | Claude cloud routines (three shifts daily) + Claude Code skill and fallback. | Two independent models made the same misfiling rationalization: the bug was in the instructions, not the models. A routine prompt pasted into a UI fossilized while the system evolved. |
| Beck | Renders the glanceable picture: dashboard, kanban, the todo page, the fleet page. | Harry Beck, the 1931 London Tube map. Made a tangle glanceable. | Python script. No model, $0. | Windows CRLF vs LF silently broke checkbox ticks from the rendered page, and the first fix nearly emitted a literal line break into the generated JavaScript. |
| Wooden | Tends the todo list: stamps completions, archives the done, surfaces what is aging. No cheerleading. | John Wooden, daily discipline compounded into championships. | A duty inside every filing run. | Still folded into filing; whether he earns his own cadence is an open question. |
| Maxwell | The drafting partner: turns a dictation into a post in my voice, with me in the room. | Maxwell Perkins, the editor whose authors sounded more like themselves. | Interactive Claude Code skill. Never scheduled. | The one job that is never autonomous. Holding that line is the challenge. |
| Cody | The courier: carries flagged app features from vault captures into each repo's own punchlist. | Buffalo Bill Cody, Pony Express rider. | Python delivery script riding Emily's nightly shift. | Missed rides taught the ack pattern: the flag flips to delivered only after the delivery commit lands, so a failed ride is retryable instead of lost. |
The roster: the build loop and the back office
| Agent | Purpose | Named for | Built on | Challenges along the way |
|---|---|---|---|---|
| Emily | The spec writer: scans every repo's punchlist for feature items with no spec, drafts up to five a night, queues my review. | Emily Roebling, who took the Brooklyn Bridge's specs to completion. | Claude Code skill + Python guard (path allowlist, circuit breakers) + nightly task. | Her size breaker aborted runs while her own docs disagreed with the code about the limit. She aborted entirely whenever Hopper had a branch checked out in the same repo. And a review panel falsified three of her own claims: she had verified a reader and inferred the writers. |
| Hopper | The engineer: builds approved specs and triaged bugs on a branch to a fleet-reviewed PR, stops at my verify gate. | Grace Hopper, the compiler: human intent to running code. | Claude Code skill + Python guard (branch-only, review-proof gate) + nightly task. | Wide staging swept unrelated dirty files onto feature branches and blocked 13 runs across two repos before it was filed as the real bug. And the vault's own .gitignore silently defeated her review-proof stamp, marking every PR unreviewed. |
| Getty | Lands the night shift's branches into main and holds the cost gate: paid runs only when free ones missed something. | J. Paul Getty, who never spent an unnecessary dollar. | GitHub Actions workflow. | The payroll audit: when metered credits ran out, every wasted dollar traced to his gate asking "is anything unfiled?" instead of "is anything stale?" Age-aware and slot-aware gating fixed it. |
| Medici | The ledger: one row per run, every agent, every provider, every cent. | The Medici bank, whose double-entry ledgers ran Renaissance finance. | Python + CSV. | None. Clerks do not fail; that is why the ledger is a clerk. |
| Chadwick | The weekly box score: completions, filings, deliveries, spend by agent. | Henry Chadwick, who invented the baseball box score. | Python script, zero tokens. | Kept separate from the reflective read on purpose: one file to scan, one to sit with. |
| Marcus | The Sunday synthesis: holds the whole week at once, names themes, contradictions, and half-promises. | Marcus Aurelius, who examined himself weekly in writing. | Claude cloud routine on the top model tier, Sundays. | Cost discipline: one Sunday read on the metered API was $1.23, so he moved to the subscription. |
| Deming | The coach: weekly, reads the review-comment logs, names recurring patterns, proposes charter text. Proposes only; I approve every word. | W. Edwards Deming: when a defect recurs, the system is at fault, not the worker. | Claude Code skill, Sunday cadence. | Built before his inputs existed: one of his two required logs still is not written by anything, so he has never actually run. A standing lesson in building ahead of the data. |
The fleet-wide lesson that outranks any single row: the morning job once ran green for three days while filing nothing, because unattended CI had no human to approve writes. Since then the rule is verify outputs, never exit codes.
The Agentic Tapestry: the flow we built inside FastTrack
How the portfolio grew
- 1Design everything firstWe filled a room with concepts and ran out of whiteboard space. A false start we course-corrected.
- 2Just build somethingIf you aren't writing a prompt, you're doing the wrong thing.
- 3Demo Days, every FridayA culture of doing, not designing. Celebrate everything.
- 4Measure usageHow do we know these are working? The ROI dashboard became the unlock.
- 5Adjust for growthControl the tsunami without killing enthusiasm: the Garage.
E3: Evangelize, Enable, Empower
We did not start with E3 as a framework; we distilled it from what actually worked as FastTrack agentified its operations. It is now the recipe we run deliberately: the thing another team can take so they do not rediscover the path through trial and error.
Evangelize
Create belief and excitement by showing real agents solving real problems. Demand came from working examples in front of the people who own the work, and discussion about how their manual effort and repeatable processes had been solved with AI, not from slideware or generic training.
Enable
Help people do by direct coaching and solutioning their actual problems, with guidance on infrastructure, governance, telemetry, starter patterns, and learning cadences that let teams build safely. Enablement turned enthusiasm into governed, measurable outcomes.
Empower
Transfer ownership. Demo days, agent roadmaps, production agents, telemetry review, and reusable patterns that teams run without the Garage running every step. Leaders emerge and coach others.
What it produced, and what we learned
Reduction in manual work in under a year.
In real workflows, not pilots.
Real operational demand.
Capacity returned to the business.
More engagements, more impact.
Attrition absorbed, not backfilled.
- It ain't all AI. Roughly 80/20 to start with: most of the win is process clarity and plumbing, with the model on top.
- Teammates, not tools. Agents get names, owners, roadmaps, and reviews, and the language shift drives the behavior shift.
- ROI matters from day one. The Trailblazer dashboard treated every agent as an operational investment with telemetry. Evidence beat anecdotes.
- Process, not product. We were enabling our own team, not shipping an external product. Start small, then aggregate.
- Sustaining and scaling isn't a hobby. The Garage exists because someone has to own the operating model after the demo.
- Citizen development raises the water table. Business SMEs became builders, product owners, and continuous-improvement leads.
- Leaders go first. Teams follow 90% what leaders do and 10% what leaders say; AI requires leadership in both thought and adoption.
References
Everything in this walkthrough is public or one click away. Lessons from doing, not theorizing.
The hub: an overview of all the work, the app portfolio, and the SkillWorks library.
The fleet page: the big picture, the stage-by-stage board, and the full roster, animated.
The public repos: TokenTray, ReboundMan-WordMD, and ReboundMan-ReleaseToolkit.
The blog: AI agents and enterprise transitions, written from the operator's chair.
The spark for the whole system, and the one reference here that isn't my content. Everything else on this slide grew from the idea in this post.
AlgoMint Insight: the weekly digital-finance updates, researched, written, and published by an agent fleet of its own.
Fleet detail from the vault's own agent map, ledgers, and failure logs.
Tiro: the ears of the system
Why it got built
Every note system I owned died at the processing tail, never at capture. So capture had to stay effortless enough to survive a run or a drive: no app to open, no form to fill, just talk.
Two kinds of speech needed two paths: 30-second phone captures, and 20-minute think-out-loud dictations that overflow any voice memo.
How it's built
Phone path: an iOS Shortcut records, transcribes, and commits the transcript into inbox/raw/ through Working Copy. Long-form path: record a Teams meeting with yourself, drop the mp4 into a gitignored _incoming/ folder; transcribe.py strips audio with ffmpeg, transcribes on Groq Whisper, writes the transcript to inbox/raw/, archives the media outside git, and pushes.
The sweep runs inside the filing flow ahead of the census, so a waiting recording can never hide behind an "empty" inbox.
Build it yourself
- Media never enters git; transcripts do. Gitignore *.mp4 and friends from day one.
- Prime Whisper with your proper nouns. A misheard project name breaks routing downstream. Practical cap on the free tier: about 45 minutes of audio.
- Keep the courier dumb. No judgment, no cleanup, verbatim text in. The temptation to add smarts here is constant; resist it.
Dewey: the librarian
Why it got built
The design bet, written into the spec before any code: a working archive, not a second brain. Raw material has to become routed, linked notes without me in the loop, or the archive turns back into a guilt pile within a month.
How it's built
The behavior lives in the repo: a filing prompt plus a skill. Three cloud routine shifts, matched to my capture rhythm, each carry a thin prompt ("you are Dewey; read the skill and follow it"); one routine holds one trigger, so three shifts are three clones. A manual /file-now and a metered fallback complete the paths.
Every run must obey the scripted census (unfiled.py) before starting and before declaring done, and "filed" has exactly one definition: a file names the capture's source. Four-way triage on every capture: archive note, pipeline card, todo line, or punchlist flag. Three honest backlinks or an admitted link_debt.
Build it yourself
- Grant scheduled runs --permission-mode acceptEdits, then verify files appeared. A green run only means the process exited; ours ran green for three days while filing nothing.
- Never paste behavior into a routine's UI box. It fossilizes the moment the repo evolves. Identity plus a pointer; all behavior repo-side.
- Instruct honest failure. Unrouted beats a forced fit; a fabricated backlink corrupts the graph invisibly.
- When two independent models make the same mistake, fix the instructions, not the models.
Beck: the mapmaker
Why it got built
An archive nobody looks at is a warehouse. The files needed one glanceable picture: what arrived, what needs my eye, what is due, what it all cost. And then the pages needed to stop being read-only, because leaving the page to act on what it shows is friction that kills review.
How it's built
One Python script renders every surface (dashboard, kanban, todo page, fleet page) as self-contained static HTML: no server, no fetch, opens as the browser's start page. State lives in the notes' frontmatter; pages are disposable renders. A no-op hash guard skips rewriting when nothing changed; watch mode reruns on a four-second loop.
The pages also write back via the File System Access API (one-time folder grant, Chrome/Edge): dragging a kanban card rewrites status:, a ticked checkbox flips the line on disk, a reroute dropdown writes the decision plus a pending flag for the next filing run's bookkeeping.
Build it yourself
- The page captures the decision (one field write); the next filing run does the bookkeeping. Flag, then deliver.
- Hash the meaningful state; force a rebuild if conflict markers ever appear in a generated page. A regenerate-from-source file should never need hand-merging.
- Windows reality: compare with CR stripped, write back in the file's own EOL style, and verify the emitted artifact character by character once; a surviving escape sequence can kill a whole script silently.
Wooden: the list keeper
Why it got built
"Check the 401(k) hit the paycheck" is neither an insight nor a feature, and it was filing as thin, link-debt notes because there was nowhere else to go.
The diagnosis of every dead todo system I have owned: they die at capture friction, gardening burden, or missing pressure. The vault had already solved all three, for notes.
How it's built
One file, todo.md, checkbox lines in a todo.txt-style grammar: priority, dates, a project tag. The filing agents extract actions from captures, may infer completion when a capture says the thing is done (stamped with a robot marker so attribution survives), and surface due and aging items with day counts on the dashboard, the todo page, and the daily note.
Wooden is a duty inside every filing run, not a separate process; whether he earns his own cadence is still open.
Build it yourself
- A next action needs a list, not a lifecycle. Project work gets machinery (pipelines, punchlists); an action gets one checkbox line. That is the GTD distinction, mechanized.
- Stay thin: no per-item files, no sections beyond Done, no manual ordering. Every convenience is gardening you will eventually refuse to do.
- Seed the list from actions already in your vault. A todo system that launches empty is asking for faith, and faith killed the last four.
Maxwell: the editor in the room
Why it got built
A 20-minute dictation of a post's argument is not an insight to file; it is source material for a draft. And an unattended model erodes a writing voice one small smoothing at a time, which is the one place in this system where that cost is unacceptable.
How it's built
The overnight jobs only stage: recognize a post dictation (a spoken convention plus judgment), write a deliberately thin note pointing at the raw transcript, advance the pipeline card, raise a flag.
The /draft skill runs the writing as a live session: it reads the raw transcript (never the cleaned note; the rambling is the voice), the card and its feeds, and two or three published posts for calibration, then drafts whole and iterates with me in the room. Drafts land in my actual writing folder, outside the vault.
Build it yourself
- The line to hold: overnight stages, only a live session writes. Encode it in the skill, not in good intentions.
- Calibrate voice against published work, not cleaned notes; encode your voice rules explicitly in the skill.
- Keep drafts in your real writing workflow, not the archive. The vault points at them; it does not own them.
Cody: the last mile
Why it got built
Feature ideas were dying in the archive: filed, linked, and never seen again by the repo they belonged to. The cloud shifts can notice a buildable feature, but only the local machine can reach the 27 project repos.
How it's built
Flag, then deliver. Any filing run that sees a concrete, buildable feature adds punchlist: pending to the note's frontmatter; flagging needs no repo access. The delivery script (riding Emily's nightly shift as step 0, with /file-now as catch-up) resolves the repo path from the app's reference note, appends the item to that repo's spec/punchlist.md in the house format with a pointer back to the vault note, and only then flips the flag to delivered.
The commit is the ack: a missed ride retries instead of losing the item.
Build it yourself
- The bar is concrete-and-buildable. Strategy musings stay insights in the archive.
- The courier never runs git in the target repo. The working-tree edit is for your dev flow to commit.
- Contract with the flag, not the filer. Any agent that flags gets the same delivery; the queue is the interface.
Emily: item to spec, overnight
Why it got built
Once the punchlist bridge worked, the punchlists filled with unspecced features. The natural extension: a nightly agent that turns items into reviewable specs, with me gating what gets built. The first half of item-to-PR.
How it's built
A Claude Code skill plus a guard script between the agent and git. The guard enforces what the prompt only promises: a path allowlist (spec files and her run log), circuit breakers on size, pull-rebase-never-force. One instance covers every repo: she scans all tracked punchlists, drafts up to five specs a night into spec/features/, compares against the project's existing specs, queues my review, and reconciles finished lifecycles.
Runs as a nightly scheduled task, pushing with her own fine-grained GitHub PAT, never my login.
Build it yourself
- The guard is the contract. The model never runs raw git push; a stdlib script does, checking branch, paths, and diff size.
- One fine-grained PAT per agent, least privilege (Contents: read-write only), 90-day expiry with renewal on the todo list, stored as a user env var, read only at push time.
- Ledger every run and every refusal. Her run log is where a review panel falsified three of her own claims.
- Keep documented limits and code limits identical. Ours drifted (400 vs 1000 lines) and confused a week of triage.
Hopper: spec to pull request
Why it got built
The second half of item-to-PR: approved specs and triaged bugs becoming reviewed pull requests overnight, with the verify gate staying mine. The dinner-table test: mention a bug over dinner, find a reviewed PR in the morning.
How it's built
A skill plus hopper_guard.py: branch-only writes, a review-proof PR gate (no PR without recorded fleet review), diff breakers on lines and file count, guarded main writes. Two intake lanes: approved specs, and bugs with a repro first.
She builds on her own branch, runs the fleet's review personas over the diff, opens the PR, and stops. Nightly task after Emily, serialized behind her completion marker so they never collide in a shared repo. Branch protection on main is the backstop in every repo she touches.
Build it yourself
- Require-PR branch protection even with a guard. Defense in layers, each one cheap.
- Stage narrowly. Our git add -A swept unrelated dirty files onto feature branches and blocked 13 runs across two repos before it was filed as the real bug.
- Check .gitignore against your own gates. Ours silently ate the review evidence the PR gate depended on, stamping every PR unreviewed.
- Serialize agents that share repos. A checked-out branch aborted her sibling's entire run.
Getty: the night landing and the $0 gate
Why it got built
Cloud routines could not push to main, so the night's work landed on claude/* branches where nobody looks, and reported success. And after the metered API ran out of credits, the payroll audit traced every wasted dollar to one over-eager fallback gate.
How it's built
A GitHub Actions workflow sweeps about 20 minutes behind each cloud shift: fetch claude/* branches, merge to main (the append-only ledger union-merges via .gitattributes so no row is ever lost), rebuild the generated pages, delete the branch.
The cost gate: the paid fallback fires only for captures that already survived a free shift (unfiled.py --stale) and only on the overnight slot, the one time the next free shift is hours away. Every other slot defers with a loud warning, because a manual run is free.
Build it yourself
- Build the landing step before the first capture gets stranded. Work landing where nobody looks reports as success.
- Union-merge append-only files; rebuild generated pages after the merge rather than trusting their merge result.
- Gate by age and slot, not by "is anything unfiled." A gate that cannot tell slipped from next-in-line burns money on items a free run would have caught.
- Build for your own obsolescence. When branch-push permission ships upstream, the landing step finds nothing and retires itself.
Medici: every run, every cent
Why it got built
Cost was a vibe. The question every payroll eventually gets, "who spent this?", needed a ten-minute answer, and got one the day the metered account ran dry.
How it's built
Every agent run already reports its cost in its own execution log; the workflows just keep it. One row per run in metrics/runs.csv: date, job (the agent's name), trigger, provider, model, quantity, cost. Transcription and interactive sessions log their own rows.
The dashboard footer reads month-to-date; the weekly report groups spend by agent, which turns the cost report into a payroll. Union-merged, so two agents appending overnight can never lose a row.
Build it yourself
- The data already exists in the execution logs. Capturing ours cost five lines of YAML.
- Keep cost out of the no-op hash or every run rebuilds the dashboard.
- Never rewrite history in an append-only ledger. Retired job names persist forever; the ledger is the memory.
Chadwick: the weekly box score
Why it got built
The weekly reflective read dies the moment it becomes a list of counts; you stop reading it. The counts still matter. They just needed a free, mechanical author so the reflective document could keep its real job.
How it's built
A script, not a model, runs Sundays before Marcus: completed todos split by who closed them (agent completions carry the robot marker stamped at write time), filings, deliveries, board state, and the week's spend by agent from the ledger.
Pure scan-and-browse, zero tokens, deliberately separate from the synthesis so each protects the other's job description.
Build it yourself
- Generate counts mechanically; guard the reflective document's job in its prompt. The split is the feature.
- Stamp attribution at write time, not reconstructed later; that is what makes "who did what this week" a scan.
Marcus: the week, read whole
Why it got built
The one reading I structurally cannot do myself: holding the whole week at once. Themes, contradictions, half-promises with week counts. The accountability read is the reason the archive exists; the only success metric is whether I actually reread what the system writes me.
How it's built
A cloud routine, Sunday mornings, on the top model tier, billed to the subscription; the metered Action version survives as manual fallback. He reads Chadwick's box score first so he never recounts, then the week's notes, the pipeline board, and the open hypotheses.
Output is one file worth sitting with, plus the AUTO sections of the vault's CLAUDE.md (currently active, open hypotheses, recent decisions), so every next session starts already knowing what the week meant.
Build it yourself
- Put the strong model on the weekly read. It is one run, and it is the run that has to see across everything.
- The synthesis must say what only a model holding the whole week can see. The moment it recounts, it is an activity report, and you will stop reading it.
- Feed the output back into session context. A synthesis nobody re-reads is decoration; ours becomes the standing context of every future session.
Deming: improving the improvers
Why it got built
The same review comments kept recurring across Emily's and Hopper's work. Deming's namesake principle: when a defect recurs, the system is at fault, not the worker. And deliberately not self-improvement: no agent amends its own instructions, and their stateless runs carry no memory of the work being critiqued.
How it's built
Weekly, after Marcus: read the spec-review and PR-review comment logs, name patterns that recur across at least two independent comments, and propose at most ten per week, each with exact charter text, into spec/coaching/.
Proposes only. I approve every word before it lands verbatim in a charter's Standing-guidance section. His guard allowlist admits only his coaching files and run log.
Build it yourself
- Separate the improver from the improved. The coach proposes, the human approves, the workers never self-edit. That triangle is the design.
- Honest status: he has never actually run. Built before his inputs existed; one required log still has no writer. The lesson ships with the deck: build the data flow before the agent that reads it.