Tom Johnell

Everything's a repo, everything's an agent

It’s May 1, 2026, and we’re nearing the half-way point of the year. I believe we were all chanting “Year of the agents!” when this year kicked off. Actually, I think 2025 was when we started saying that, but 2026 for me has truly been the year of the agents. This blog post is my attempt to to introspect around how my workflows have changed. I am beginning to think of my repos and agents as one-in-the-same, and I’m beginning to want one for everything.

Repos and Agents are the same thing

Late 2025, early 2026 I was still thinking of my Claude Code session inside of a repo as two distinct things:

  1. The code & version control
  2. The agent & brain

I would liken this to thinking about companies as two distinct things:

  1. The brand, buildings, and assets
  2. The people & values

A company without either is not really a company, though I will say, it’s more likely one could create an accurate image of a company if they have the same people, but not vice versa. With that perspective, it really excites me on how much more room there is to explore in having agents truly embody the spirit of a particular codebase.

I’ve begun to touch the surface of this mental shift. My mental image of my repos/projects no longer exists as soulless repositories of code. They now include an agent who is caretaking and commanding that repo and taking the load off me. Additionally, these "responsibilities" I have as a nerd, like administrating a media server or cleaning up my Mac, I’ve begun to delegate to specialized repository/agent combinations.

An Agent is the subject matter expert (SME) of the repo

What does this actually look like in practical terms? Right now I have two main use-cases for SME-agents:

  1. A SME of a particular product or workflow and its associated codebase
  2. An orchestrator over SMEs and its associated codebase
    1. This is really just a version of (1) but for orchestrating.

The typical flow prior to my thinking shifting was to cd into a project directory, fire up Claude Code, and mentally imagine I’m working with an intern who just joined the company, doesn’t know anything about the product, needs to be directed at every step, but has a lot of spunk. Without much investment in creating an SME-agent, this is a very accurate mental image, and boy is it exhausting to work with a spunky intern.

Here’s where my thinking pattern has shifted. I now use continually running agents that I can access via Telegram. Each agent is associated to a particular git repository with its own CLAUDE.md. I only have a single agent running per repo. I no longer stare at impending compaction with horror in the bottom right of my terminal - I just speak casually to the agent perfectly oblivious. I am no longer tied to my computer in order to continue working on a particular project.

Examples of agents:

  1. Scout - Online Shopping Assistant
    1. This is a repo that was created for the purposes of improving an agent, not for version-controlling code per se.
    2. I like to research products extensively before purchasing by reviewing real user feedback in niche forums and subreddits. I do not like Top 10 blog spam, sponsored ads, and products with very little feedback. Obvious things.
    3. A blank-slate agent does not understand how I like to research. I think a common trend is folks have spun up a “thread” in ChatGPT or Claude where they’ve provided that context and they just return to that same thread, however, you’re not able to refine the spirit of that “agent” over time.
    4. With a specific repo - I have effectively version-controlled “Shopping Research Tom” who perfectly embodies how I like to research and choose products.
  2. Frank - Orchestrator
    1. Similar to Scout, this is a repo that was created for the purpose of refining an agent who acts as my assistant.
    2. Frank has his own heartbeat (crons) and goals (a markdown file) that we align on.
    3. Frank can talk to ANY of my other agents, and I often talk with Frank directly as opposed to my other agents because I have given Frank extra responsibilities that he will automatically take care of if I work through him. For example: PR reviews, making small decisions, and ensuring agents stay on task (via goals).
  3. Dorso - Mac App
    1. This is a more traditional agent who lives within the repo. The codebase was created (with the help of LLMs), and the Dorso agent was crafted later over time.
    2. This is the closest to the traditional “hop into a directory and fire up a spunky intern” however I have aggressively fine-tuned the CLAUDE.md so that I don’t have to hand-hold core workflows or design philosophies.
    3. I’ve, so far, avoided trying to create knowledge bases for repos dedicated to a product and prefer agents build their context naturally through discourse. They start off as a spunky intern and as the context matures, they turn into an SME. I actually have found for these smaller projects, I prefer the continually running agent who is inching along on context than starting fresh each time. The compacted context does a better job than I do and it automatically evolves as the project evolves. Too much investment in the CLAUDE.md is akin to writing too much documentation in an organization that is continuing to evolve.
  4. MacSetup - Mac Restore Workflow
    1. This is a repo that was created with the intent of creating the perfect marriage of agent and code. Meaning, the repo doesn’t exist just for the agent or just for the code. Both must work in tandem.
    2. This repo was created to automate and simplify completely restoring my entire Mac workflow from a blank slate install of MacOS. It is a combination of rote tasks executed via shell and more complex tasks that are executed via the associated agent.
    3. I have gotten into the practice of restoring my Mac on a nearly monthly cadence, for a few reasons:
      1. Applying the cattle, not pets mentality to my machine at home
      2. It’s fun to perfectly capture the essence of my “home machine” and see how far I can actually take it. This is the dotfile repo taken to the logical conclusion with agents.
      3. I’m experimenting with this repo == agent mentality
  5. MediaServer - Server orchestration agent
    1. This is a repo that originally started as the docker-compose hub for many of the services running on my home media server on a separate linux machine.
    2. It includes services like PaperlessNGX and n8n among other things
    3. I have captured all of my workflows across this machine within the CLAUDE.md and I no longer administrate this server directly. All actions are performed by the MediaServer agent through the direction I give on Telegram.
    4. MediaServer helps with:
      1. Ensuring services are kept up-to-date (of course with a minimum release age)
        1. This includes creating backups, working through backwards breaking changes, etc.
      2. Through coordination with Frank, deploying new versions of my own, selfhosted software. This is mostly just git pulling the docker-compose repo, but there’s smoke tests and other things.
      3. Spinning up new, open-source services to test drive
      4. Managing SOPs version-controlled secrets
    5. This is my riskiest agent as it is fully administrating another machine. I run daily backups of core configuration files and important documents to be less on edge. Again, I treat this machine mostly as cattle through docker compose, but I’m not ignorant to the fact that this is next-level risky.
    6. Lastly, the agent lives on my Mac Mini and communicates with its server over SSH.

Investing in CLAUDE.md (or AGENT.md)

I hope this goes without saying that none of the above would be possible without carefully curating a CLAUDE.md that encapsulates my values, methodologies, workflows, and preferences with regard to a particular repo. Any time I am wrapping up a long session (on Telegram), I will retrospect on what could have gone better and ask the agent to capture that preference and commit it to the repo. These compound over time and the agent begins to possess a true spirit of the repo.

Downsides

Wasted Context

Working with LLMs through dedicated agents has pros and cons. The most obvious con is that I am wasting precious context across discrete working sessions. However, as I said before, I generally avoid “knowledge base” documentation for my smaller repos and I prefer to talk to the SME, not the spunky interns, so talking to a pre-warmed agent is much more enjoyable. Additionally, compaction has improved enough to the point where I don’t feel the pain of the spunky intern after the "refresh". However, this will not scale to a larger codebase. Whoever solves creating SME agents for large codebases without minutes of grepping and exploring will make a LOT of money.

Single-threaded

For now, I have only created a single Telegram thread per agent/repo. If I’m aggressively trying to create a prototype for a product, I would not use this workflow, as having multiple Claude Code instances will be faster and more effective. However, as a project matures and rapid iteration is no longer necessary (e.g. Scout), there will never really be a need for multiple instances. I would rather invest in training my agents to kick off sub-agents than to talk to multiple distinct Telegram threads. I have already done that with Frank.

Always plugged in

So, I may not be at my desk for hours at a time, but that doesn’t mean I’m not glued to my phone talking with my agents. “Tom away from the desk” no longer means he’s not in AI-mode. I recall one afternoon at the beach when I was on my phone and my wife’s friend asked “What are you looking at?” - and I was neck-deep in improving a data pipeline powering my Pike app. I find the productivity gains from AI more addictive than social media. Still trying to figure this out.

Security Risk

The obvious risk with this flow is I have opened up another attack vector for my home machines. For now, this is a risk I’m willing to take to “live in the future” as we continue to improve LLM resistance to prompt-injection and the like. This is not for the faint of heart.

Conclusion

I don’t believe this is a groundbreaking take, but it certainly has been a mindset shift for myself. I no longer want to work in codebases that do not have a dedicated caretaker and SME. I want to offload the workflows and preferences to an agent. I want there to be a “spirit” embodied into the codebase as opposed to the repo being a lifeless collection of files. For non-coding related functions like searching for products to buy, I will continue to invest in this idea that everything is a repo, and everything is an agent. I can offload more and more rote tasks to an ever-improving embodiment of myself so I can focus on other things (like building more agents - uh-oh, this is sounding recursive).