The Garbage Collection

Agent-backed Systems

I'm starting to discover this sort of "agent-backed systems" paradigm of software that I think is a really interesting way to bring agents into a person's life. I've noticed the idea come up when I think about problems I have and my ideas for solving them. I think it's most useful when you have a specific aspect of your life that you want to have managed for you, but you're not sure if it's better to let an agent do it or have an agent build software to do it or something in between. For example. I'll show how this pattern of thought generally goes using my most recent example: River.

My most recent problem has been that it takes me a long time to tailor my resume to different job postings in a way that optimizes it for ATS. Layout, formatting, and keyword matching become a very tedious task. I take great care in tailoring my resume for these roles that I really want to land but are also maybe somewhat of a reach for me. Given how unlikely I feel I am to land some of these roles, I think I'm wasting too much time sorting through all the evidence of my qualifications and trying to recall the pieces that apply most directly to the role I'm applying for, and it's a whole process that needs to be streamlined. When I try to address the problem, that's when it all starts.

First, I try a simple agent. I connected ChatGPT to Notion as the backbone of my workflow. Notion is such a great tool for organizing information that is accessible to both humans and agents. I had ChatGPT read every version of my resume in my filesystem and extract every claim that I was already making about my qualifications.

Then, I had it comb through my dev directory and GitHub to understand the work I had actually done – it certainly wasn't the whole of my work as a developer, but it did have a lot of my best work in recent history. All of the information found was put into a Notion "evidence bank". I told it to go through all of the items in my rudimentary application tracking database (also in Notion) and prepare a brief on each one containing things like:

I think this helped, but I couldn't have had the agent write the whole resume because I didn't like mass applying totally blind, and I didn't want to risk getting filtered out for obvious slop on these jobs. Nevertheless, I wanted to take this further. It was clear that this job market for early-career software engineers was going to require me to pick up the pace and broaden my application reach.

Then I thought that if I knew exactly what I wanted, I could make a more deterministic tool. What I wanted was to be able to sit down and assemble a resume in 15 minutes that's ATS-optimized and doesn't look or read like slop to humans. To do this, I needed to stop wasting time finding the information and have it come to me heuristically ranked and sorted by relevance. Then all I have to do is pick from the short list. That's how the idea for the River Resume Builder was born. Soon thereafter, I began development.

This next stage is where I think things get interesting. I get this jolt of ambition that says, "You can do better now. We have agents. Build bigger." Okay, maybe it's more hubris than ambition. Either way, I would've ignored this signal a couple of months ago because I believed that restraint was the makeup of a good engineer (Also, I can't afford the tokens). Frustrations with job searching have somewhat driven me to push harder to develop something, anything that will get a recruiter's attention. It's their market after all, so I need to make myself stand out.

I liked how my new system was developing, but I didn't want to give up the ability for agents to help me out. The application had some complexity that gave me great customizability, but managing it was incredibly tedious. Anyone else who wanted to use my tool would probably take hours preparing their content libraries before the application could deliver anything of quality. I ended up exposing an API so that agents can still interact to help manage things within the application.

I started to wonder if I could make the system a little more agentic. Perhaps if I force the agent to work through the more deterministic API, I can trust it to do the things I was hesitant about before, like creating full resume drafts or updating my evidence library to stay up to date with my accomplishments. It would be like having a professional resume writer on my personal staff, and I could trust they could do the job because they're just using deterministic tools. I'd be willing to bet that an AI agent backing this system would still be better than some super fancy heuristic workflow that tries to do it programmatically.

This is the point I've reached with many other similar problems. First, I see if the agent can do the thing well. Then, I consider if an agent is needed to do the thing well (sometimes these steps are reversed). In the end, I decide that a system can give me the dependability and control that I want from a software tool while the agent acts as a custodian that manages the system in the background. I think there are a couple of reasons I converge on this:

  1. Agentic software without the tired chat box – I get to use a real UI fitted to the domain that still fulfills the agentic promise of taking care of things for you. I believe this experience can feel truly magical. But if you somehow prefer always using the chat, you can always talk to the agent to use the API.
  2. Predictable, but still capable - The API is the boundary that separates what can happen inside of the system from the chaos of all of the random things the agent could do on its own. This can often result in the application enabling the agent to do more dependably.
  3. Managing token costs - A good API can abstract a lot of the work that an agent would have to figure out and repeat to accomplish a task. A skill can only really save on the initial reasoning about how to do the task.

While I've done a lot of experimentation with this pattern, I'll admit that I haven't had experience with this paradigm in production. I just shipped River, so I hope to discover more about how well it all works and whether or not the system justifies additional engineering effort. Any feedback is much appreciated. :)