Putting the Agents on Kairos
Last week I wrote that I wanted to get the agents working on actual Kairos tickets, and that the next post would either have results or another pile of postmortems. I'm happy to say it has results. It has a few postmortems too, but the results came first this time.
What actually landed
The one I care about most is a release gate.
Kairos releases were not gated on a vulnerability scan of the bundle we actually ship. It is fiddlier than it sounds, it touches release CI, and it is exactly the kind of ticket I put off until it hurts enough to force my hand.
It landed this week in kairos#4300, together with clearing the 23 fixable advisories it immediately surfaced. A monthly repository access audit landed too, in community#31.
The rest is dependency bumps, CI plumbing and version pins across nine repositories, and honestly that's fantastic. This is maintainer work. Keeping dependencies current, keeping the release pipeline green and keeping the CVE count down is the job, and it's exactly the kind of work you want to delegate. It's also the part that quietly eats the time I'd rather spend elsewhere.
One caveat: shipped is not released. 4.2.0 is still blocked on a separate problem as I write this.
There's another category I nearly left out, because it isn't code. A good chunk of this week was developer relations: conference admin, keeping track of what is worth writing or posting about, the small things that pile up. That work used to happen by hand, in the gaps between other things, and it was the first thing to slip when I got busy. Now it gets a ticket like everything else, and it mostly gets done without me.
The numbers
Same caveats as last time. These count both my own account and the agent's.
| Activity | 20 Jul – 6 Aug | 7 – 15 Aug |
|---|---|---|
| Changes shipped to Kairos | 0 | 19 |
| Changes to the agent factory itself | 22 | 26 |
| Changes to this website and the homelab | 9 | 20 |
| Architecture decision records written | 6 | 11 |
| Postmortems filed | 5 | 2 |
| Internal board: issues opened / closed | 20 / 15 | 99 / 33 |
The first row is the one I'd point at. It was zero when I published the last post, and I said then that anyone comparing tables should read that row first. It's 19 now: 18 pull requests across nine kairos-io repositories, plus one to edgevpn, which ships inside every Kairos release.
The last row is my own board, the private one where I file work, not the Kairos issue tracker. Ninety-nine issues opened against thirty-three closed, up from twenty and fifteen. Roughly: 23 about Kairos, 18 about the homelab, 11 about this website, and about 42 about the factory and its rules. So it's filling about three times faster than it drains. I'll come back to why that isn't purely bad.
What broke
Halfway through the week I changed how sessions are organized. They used to be scoped by project: one for Kairos, one for my own repos, one for planning. Now a session is defined by who it acts as and which machine it runs on. They're lanes, and a lane picks up whatever ticket is labeled for it, Kairos one hour and this website the next.
The design is better and I'd do it again. But a lot of things that had been working quietly stopped working the moment it landed, and nobody warned me. The agents applied a migration to a running setup without surfacing what it would break. Then, when things did break, I got confident answers about the cause that turned out to be guesses rather than assessments.
A clean example, while writing this post. I asked which of my posts were published. The agent read a local checkout sitting on an old draft branch and gave me a date ten days off, without saying which branch it had read. There was nothing for me to catch it on. That's now a rule: fetch first, read the published branch, say which branch you read.
Old habits die hard
I have a talk recording next week, and I handed part of the preparation to Claude. Not through the board, just me in a chat window, the old way. The analysis and the suggestions were good. The slides still need work.
None of it is measured, because none of it went through the system. It won't show up in any of the tables above, and I only noticed afterward.
This suits the way I think
Something I didn't anticipate.
My brain jumps from topic to topic. That usually leaves me two options, both bad. I chase the tangent and end up yak shaving three levels deep in something unrelated to what I sat down to do. Or I write it down, and the note joins a backlog that grows until it's unmanageable and I stop opening it.
There's a third option now. I can write the ticket and have someone start on it. The tangent gets captured and worked without me following it.
That reframes the 99 against 33 above. Part of it is a board filling faster than it drains, which is a real problem. Part of it is that writing something down finally has a payoff instead of being deferred guilt.
Reviews, and the thing that makes them hard
Everybody says reviewing AI output is the bottleneck, and I couldn't agree more. What I didn't expect is the specific way it fails.
It's about time, obviously. But not only time. When the reviews are long and there are many of them, I stop reading them at the same level of attention. It creeps. I catch myself skimming a diff I would have read line by line two weeks ago, not because I decided it was low risk, but because it's the eleventh one today. The gate is still there on paper. The attention behind it is not.
I have a data point on that. Of the 18 changes that reached kairos-io, I reviewed 13. One merged with no review from me at all: an external maintainer approved and merged it eight seconds apart, on a pull request the agent had opened without the draft flag that exists precisely to keep other maintainers out of the loop until I've looked. Nothing bad shipped, the change was correct, but the gate wasn't there.
Two things make it worse, and they need different fixes. The agents write a lot, and a long explanation is not a better one. I've started asking for concision, which I can do today. The other is throughput, and I don't have an answer: the better the system gets, the more there is to review, so every improvement makes this harder.
What I'm leaning toward is a separate agent doing a first pass, and finding a way to skim that doesn't quietly become rubber-stamping. Whatever I replace line-by-line reading with has to keep the slop out of a project other people depend on. That's the only thing the gate is for.
More time on my phone
The last thing, and I'm genuinely of two minds.
I spend more time on my phone now, because that's where the board is. I can go downstairs, make coffee, unblock an agent from the kitchen and come back. That's good for me. Long stretches at my desk give me back pain and make me tense, and this week I got real work done while not sitting at it.
The other side is obvious. Things being on my phone means I'm more likely to look at them when I'd rather not. Reviewing a pull request while I'm with my family isn't a win just because it's efficient. I don't have a rule for this yet. I'm writing it down before it becomes a habit I stop noticing.
Where that leaves me
A good week. The thing I said I'd start, started, and it produced work I actually care about instead of more scaffolding.
As before: this post was drafted by the system it describes, and I reviewed, edited and merged it myself. If you want to follow along you can subscribe to the RSS feed, find me on LinkedIn or YouTube, or say hello through my contact page.