Everything I’ve built.

What I did

• Around 10 Rovo agents across QM, workflow management and audit processes. Another 10 later at Uhlmann. Not all of them made it into production.
• A meta-agent that lets non-technical teams build their own agents
• Audit automation: a multi-hour process down to 10 minutes
• 2 live-coding talks at ACE events, 55+ practitioners incl. C-level

The agent that builds agents

Teams knew what they wanted but not how to ask for it, and a badly written system prompt produces a badly behaved agent. So the meta-agent runs the prompt engineering itself, in the background. It interviews the user until it has what they actually meant rather than what they first said, checks those answers against the internal wiki, and links the pages that matter straight into the system prompt. The agents built this way outperformed the standard configuration, and what made the difference was the context, not the wording.

The audit

The old version was a person reading through the wiki looking for gaps. The agent reads the documentation, flags what is open and what is missing against ISO, turns each finding into a Jira ticket and assigns it to whoever owns that area. The output is not a report, it is work with a name on it.

What I took away

Nobody was hiding anything. The findings were sitting in the wiki the whole time, in prose, across hundreds of pages, and nobody had hours to read all of it. Documentation is not knowledge until something reads it.

The nightly loop

Five stages: a scout decides which workflows are due, the workers run, an inspector judges the output, a report card is written, and a set of checks runs over the result. The scout uses no model at all. It reads the schedule and whether the machine is online, and skips anything that needs the network when there is none, so an offline day does not poison the report card.

• Every workflow carries a goal written in plain prose, including what explicitly does not count as failure. No new Strava activities is a success, not a miss. Without that line the inspector always finds something and you iterate against noise.
• Models are picked per job rather than per taste: Haiku for research calls inside the workers, Sonnet for the work, Opus for the judgement. The expensive model only ever sees the verdict.
• Vault maintenance and the Strava sync run daily, the job scan too, a discovery pass on Sundays. The deep evaluation only runs when I click it, because that one is worth paying for and should not fire at three in the morning.

Checks that do not trust the loop

Six checks run outside the agents and answer to nobody: does today's log exist, do files touched in the last day have valid frontmatter, has the loop itself completed in the last 26 hours, are there Syncthing conflict files sitting in the vault. They are plain shell, no model involved. An agent reporting its own success is not evidence, and the heartbeat check is the one that catches the failure mode everything else misses, which is the loop silently not running.

Two commands I run myself

• /orchestrate turns a request into a goal, three to six falsifiable acceptance criteria each with a way to check it, and an explicit list of what is not a failure. That brief goes to a file, so it survives a context compaction. The artefact itself is allowed into my context exactly once, at acceptance. It also routes: for small or taste-driven work it sends itself back, because running the full loop to prove diligence is theatre.
• /handoff writes the honest state of a session to a file so a fresh one continues without me re-explaining anything: what is done, the next concrete step, which files to read first, and which approaches were already tried and rejected. This page was built across several of those.

How it works

• MediaPipe Pose reads 33 joint keypoints per frame. No object detection, just the skeleton of one person.
• Ankle height over time gives the top and bottom dead centre of the pedal stroke. At those points it measures knee, hip, elbow and torso angles and averages them across several crank revolutions.
• Out comes a traffic light per angle plus a saddle height recommendation in centimetres, derived from leg measurements and knee angle, verified against a real video.
• Videos never go to a cloud. Processing runs on my own Mac mini, the phone reaches it over Tailscale.

Each angle gets its target range, the spread across crank revolutions and the measurement uncertainty. Where the uncertainty is larger than the deviation, the app says so instead of giving advice.

What I took away

MediaPipe hands you 3D world coordinates, which look like the obvious thing to use. They are not. I measured two real 4K phone videos across all three model sizes: in 3D the knee angle moved by 19 degrees depending only on which model I picked, while the plain 2D pixel angles stayed within 2 degrees. The z axis carries the error, and 3D angles use all three. For a target window 10 degrees wide, the model choice alone would have decided the diagnosis.

Why it can run without sending anything anywhere

A support zip is a customer's production system in a file. Whether that may be sent to an AI provider is not the tool's call to make, so the provider is a setting. It defaults to a local model through Ollama, and in that mode the only request that ever leaves the machine goes to the Atlassian Marketplace with an add-on key in it, nothing else. Where a hosted model is allowed and better output is worth it, the same analysis runs against Claude instead. On top of that sits a metadata-only mode that leaves script source out of the request entirely.

How the model gets its context

• A layer of hard migration rules, kept as files rather than in the prompt: API and automation limits, data residency, what ScriptRunner does and does not survive, which third party apps shift time zones or keep their data outside Jira.
• A layer of learnings from assessments already done, so the same surprise does not have to be discovered twice.
• The instance itself, parsed out of the zip.

Separating those three matters more than the model choice. The rules are the part that must not drift, and keeping them in files means they can be corrected without touching the application.