A teammate posts in Slack: an order is stuck in a pending state, and a customer is waiting for an answer. I’m deep in something else and don’t see it.
About a minute and a half later there’s a reply in the thread. An agent has followed the code path, checked the order’s current state through a read-only view of the data, and explained in plain words why it stopped and what the teammate can tell the customer. If it looks like a bug, the agent reproduces it in a test environment and opens a Jira issue with the cause and a suggested fix. By the time I look, the investigation is done and the decision is mine.
A year ago, that question would have waited for me.
This is the first post in a series about what I learned putting AI agents to work in my own job. It’s not a vendor comparison or a list of prompts. It’s what changed, what it cost, and what I’d tell someone starting tomorrow.
Where I started: a better search box
I started using web chat for work around October 2025. Mostly for three things: first drafts, reviewing operating policies and contracts before they went out, and asking a question instead of searching for it.
It helped, and contract reviews most of all. Besides reading the clauses, it walked me through some of the legal questions behind them, and reviews that used to drag got done far faster. But the shape of my work didn’t change. My job at the time was to decide what should be built, ask the team to build it, and review what came back. The chat window made each of those steps a bit faster, and that was all. Every answer stopped at the edge of the window, and the actual work still happened somewhere else, done by someone else.
The choice: back to the code
By September 2026 I’d concluded two things. We had to adopt AI properly, as part of how the work gets done rather than a tool on the side. And if I believed that, I had to do it first myself, before asking anyone else to. So I decided to work in the code directly again. Nobody asked me to; it was my choice, and it only made sense because agents could now do much of the typing.
So I set up an environment for working through local coding agents: agents that read and edit the files in a repository, run commands with my approval, and show me what they changed. I stopped writing feature requests and started writing goals, constraints, and completion criteria for an agent, then reviewing its work the way I used to review a teammate’s.
That decision, more than any tool, is what changed my output.
What changed, in numbers
For the year before the switch I made a handful of commits a month, often none. That’s what you’d expect from someone who mostly requested and reviewed. In September it was 41. In October it was 429, across 17 repositories. Almost all of it, 723 of 734 commits from September through 15 November, was written with an agent. The chart counts every work repository, merges excluded.
Commits aren’t output, so here’s what they stand for. In those three months, working mostly alone:
- A documentation hub in a day. Before it, only one of our repositories had real documentation, and that one wasn’t even in version control. With an agent reading the code, I wrote 63 documents in a day, plus the first rules files telling agents where to look before they start.
- Three cooperating agents in three days. A Slack agent that answers the team’s questions, an investigator that reproduces suspected bugs, and a reviewer for feature ideas. Six people were using them by the third day.
- Monitors rebuilt in a day or two each. One of them found, on its first run, a problem nobody knew existed. Episode 2 is about how those are designed.
The change I care about most, though, is in first response.
The bottleneck that went away
One of my jobs is first response when something goes wrong in the running service. Someone reports it in Slack. I work out what it is: reproduce it, read the code. If it needs a fix, I open an issue and fix it, and along the way I tell people what’s happening and what to do in the meantime.
The problem was never that this work is hard. It’s that it waited for me. When I was heads-down on something else, I didn’t see the request or couldn’t get to it, and the person who asked was blocked until I did.
Now an agent does the first response. I named it kenny, after myself, because its job is literally the part of my job that people used to wait for. It takes the question, checks the docs and the code, looks up the current data, answers in plain language, and says how sure it is. When it’s a real bug, it hands the case to an investigator agent that reproduces it and writes up the cause and a suggested fix. Fixing it is still my call, and my hands.
Over two weeks in early November it answered about a hundred questions from five people, me included. Half got a first answer within a minute and a half, and nearly all within ten minutes. In its first month it filed two dozen issues from Slack requests, about six a week, each one investigated and written up.
It’s a small sample, and many of those questions were mine. These numbers show how fast an answer arrives, not how good it is or how many hours it saved. But speed was exactly the problem: the question no longer waits for me.
The time I used to spend finding, copying, and chasing now goes to deciding and reviewing. That isn’t less work. It’s different work, and it’s the part I’m actually useful for.
Episode 6 is about how kenny is built, and why it is deliberately narrow.
The path I took
Looking back, it happened in five steps, and each one started when the previous one ran out.
- Web chat (October 2025). Useful for drafts and questions, but the answers stopped at the chat window.
- Local agents (September 2026). The agent works in the files, not in a chat box. The new problem: every session started from zero, rediscovering the same things.
- Written context (September 2026). Docs and a rules file in every repository, so an agent starts from what we already know. Episodes 4 and 5 are about this.
- A Slack agent (October 2026). Once the context existed, an agent could answer other people’s questions, not just mine. That removed me as the bottleneck.
- Checks handed off (October to November 2026). The same checks every week became monitors that report, and the “remember to verify this” notes became reminders from my personal assistant, Hermes, that carry the exact check to run (episode 7).
What it costs
It would be dishonest to stop at the numbers.
- Review becomes the job. An agent can produce more than I can carefully read. The skill that matters now is reviewing well: checking the evidence, sampling the output, and saying precisely why something is wrong.
- Agents forget everything. Without written context, each session repeats yesterday’s mistakes. The docs hub wasn’t a side project; it’s what made everything after it work.
- Agents fail in new ways. One night an agent fanned out into sub-tasks, made about eight times its normal number of calls, and drained the API credit. A rule against it already existed; the model ignored it. The fix was to take the tool away. Episode 3 is about rules like that, enforced outside the prompt.
- Safety is your problem. An agent that can read your code can also paste it somewhere. I wrote about keeping our Slack agent from shipping source code.
Why I wrote it down
After a few months I wrote all of this up as a guide, so that other people could follow the same steps without rediscovering what I had. This series is that guide, rewritten for anyone and grounded in what actually happened: the numbers, the mistakes, and the designs that held up.
The series
- From doing the work to delegating it (this post)
- Let code decide, let the LLM explain
- The rules I never break
- Context is the job
- Agents forget, so I write it down
- kenny: an agent that does my job
- Hermes: reminders that carry the check
- How to start in two weeks
If you could hand one recurring part of your job to an agent tomorrow, what would it be, and what would you need to write down first?