cat agents.md
Engineering with agents
Since 2025 most of my work has been making AI agents genuinely useful on products they could not touch before. Three things had to be true at once, and none of them are prompt engineering.
- 01
Reach
An agent that cannot reach the platform cannot do the work. I build harnesses that provision and drive Windows virtual machines so agents can build a two-decade-old desktop CRM and validate tests against it, and I instrument physical iPad hardware so they can install and debug iOS builds.
- 02
Context
Reach without context is guesswork. A central knowledge base covers every product in the portfolio, consolidating documentation inherited through acquisition into one structured source, and it is wired into the agents so they answer from real product knowledge. It cut onboarding onto an unfamiliar product by roughly 70 percent.
I wrote the bulk migration tool that moves legacy documents in with AI-proposed structure, and the per-product context layer each agent loads before it touches a codebase.
- 03
Trust
An agent will happily write a regression test that passes against the broken code, which proves nothing. So every test has to be observed failing before the fix goes back in, enforced by a validation agent that rejects any test never seen to fail.
Without that check the throughput is worth nothing, because you cannot tell a fixed defect from one that was merely closed.
What runs on top
Serverless pipelines take an incoming defect ticket, reproduce the failure, analyse crash dumps on remote machines, implement a fix, open a pull request, run the tests and review the result. Engineers handle only what the agents cannot resolve.
What changed
My own merged output went from 41 changes in the second half of 2024, to 131 in 2025, to 179 so far in 2026, while closing 580 of 591 assigned defects. The pipelines are used across the team now rather than just by me.