claude-agents, & How I'm Using LLMs inside of Emacs as of Fall 2026

While I suspect vanishingly few people will ever actually stumble upon, let alone get use out of, a post like this, it’s exactly the kind of thing that I found really helpful when getting started with Doom way back when. Unlikely though I think it is, it seems to me that one possible good outcome for the age of the LLM is that people like me (who are curious, but also lazy) are able to more easily explain and share their ideas and workflows because we’re now able to cut out so much of the unproductive time-wasting that goes into the process of managing a personal website. Social media sites like X & Bluesky may have their uses (like generating infinite CSAM, in the case of the former, or having someone explain your joke to you, in the case of the latter), but ultimately they are poor media for transmitting useful information that should persist over time, rather than be discarded the moment the thumb scrolls across the timeline.

Let’s get into it then.

The main idea is this: I’m working on some project, like the numerical code for my dissertation. Lots of tasks can come up along the way: write a unit test for this function, document that feature, re-generate figures after finding a bug. Claude Code is a fantastically useful tool for dealing with all of these tasks, but of course it’s not such a good idea to try to tackle every problem all at once in a single chat thread. For one thing, this eats up agent context, and burns through tokens, so it’s at a minimum economically inefficient. But for another one, and one which I think is much more important, it’s actually quite bad scientific practice. Now caveat emptor that I myself am no paragon of scientific behavior. But, if I were a paragon, one thing that I would be doing is assiduously tracking my accomplishments: what I tried, what works, what fails, what still needs to be fixed, so on and so forth. You can get part of the way to carrying out that scientific directive by keeping a good To Do list, or a research journal of some kind. But I’m a bit on the lazy side, and have never been great at journalling. I’ve tried a couple of times, and I’ve even made attempts at integrating Org Agenda into my life before, with some success. But tasks pile up, and then putting tasks on the task list becomes its own task, and then if I knock out a bunch of stuff on the list, making sure the list is up to date — yet another task! It takes discipline to keep it all spic and span. But we’re living in The Future now, and we have agents. So I think I can compensate for my organizational deficiencies by leveraging technology.

The heart of this workflow is turning Org Agenda into a living Agentic To Do list, to which agents write atomic tasks with well-defined goals. Not all problems in life are built out of atomic tasks (e.g., writing this blog post), but plenty of them are, especially when you work in a technical domain.

The Agenda is just a nice display buffer for a big nasty file called agents.org, which is where all the actual information lives. In principle, agents.org may get quite large, but it’s all plaintext, so no big deal, at least for now. A task is stored as an item in agents.org (path specified in the Emacs config). A task has certain properties, which the agenda displays in a nice format (more on this below), and in particular, the agenda file automatically tracks when tasks are proposed and when they get marked done. This way, if I wake up on Thursday but need a refresher of what was accomplished on Wednesday, or what’s been accomplished so far this week, a tidy little report can be presented.

Here’s a view of my agenda. It’s broken into 5 categories, which I think are self-explanatory: Ready for review, Agents working, Proposed by agents, To do, Blocked. Then, a task has a collection of properties: the associated project, a difficulty & associated model, and a headline. A greyed task indicates that the task is dependent on some other task, and cannot be handled until the upstream issue is marked as done.

From the agenda, tasks can be dispatched to a new agent, which will handle it in the background. When we dispatch a task to an agent, the agent reads the prompt off the agents.org file, and executes. If it comes up with some follow-up tasks (e.g., it wrote a function f, so f should get documentation and a unit test), it can propose a task on the agenda and mark it PROPOSED. The user then looks at the proposal list, and either moves the task to the TODO pile, or rejects it and marks it CANCELLED. Of course the user can themselves propose a task (or really, put it directly into TODO), and write a corresponding item in the agents.org file.

We can view a list of the live agent sessions (even those running outside of Emacs) from the agent management buffer, which I modeled after Ibuffer. This lets me easily check in on an agent, or answer it if it requires permissions, further task specification, etc., or otherwise encounters some kind of an issue. Via an Emacs minor mode, there’s a little tracker in the corner, persistent across buffers, which tells me how many agents are waiting for input, and how many are idling.

Not all tasks are agent tasks of course. For example, this blog post: I don’t want to maintain a website that just gets filled up with Claude-isms (what would even be the point?). But when I have non-agent tasks, I do want to track them on my agenda view, and when I make a thing, I do want to write about it on the website. So I myself can put “Write Claude Agents Blog Post” into the agenda, and specify myself as the task owner, so that if I then try to dispatch the post-writing tasks, I get a little message back that says “hey now, that’s a you job — do it yourself”.

Once a task is done, the agent writes a summary of its work, & the task is then moved to the REVIEW pile. The summary lives in the agents.org file, and I can review the agent’s summary of their work, as well as git diff for any files they’ve edited along the way. This is one place where I personally need to get better — there’s lots of places where I think the agents probably don’t need rigorous diff checking, but that’s not a universal rule, so figuring out how to manage review with my limited mental resources is important. But, here’s the cool thing: if I review a task, and am dissatisfied (e.g., the function doesn’t behave how I wanted it to, the website looks a little funky after making some change), claude-agents tracks the session responsible for the work, and I can re-dispatch the task, trying to work out the issue with the chat that made the original edits (so no need for some other agent to come in and reverse-engineer or analyze from scratch).