Building My Agentic Setup

Published October 27, 2026

I've been spending a lot of time figuring out how to work with coding agents. The fun part is obvious: you can describe an idea and watch software start to take shape. The less glamorous part is making sure the work still makes sense when the conversation ends, another task starts, or an agent confidently solves a different problem than the one you had in mind.

My setup is still evolving, but I wanted to write down what I'm building and what I'm learning. Think of this as a snapshot, not a finished blueprint.

Start with a workspace, not a blank chat

I use Codex against the repositories and files on my computer. That means an agent can inspect the actual project, run commands, make changes, and check its work. It also means it needs to know which project it's in and what should be left alone.

Repository instructions live in AGENTS.md. They explain things like how to work in the project and how to handle resources. I also keep longer-lived context in Markdown: decisions, things I want to remember, and the dates that make those notes useful. A chat is great for talking through a problem; it's a pretty fragile place to keep the only copy of a decision.

Give the work a place to live

I'm interested in agents that can take on more than a single edit. A task might start with an issue, continue through an isolated Git worktree, and end with a change I can review alongside the checks that were actually run. Separate worktrees help keep parallel work from stepping on the same files. They don't remove the need to understand the existing checkout or preserve changes that were already there.

I've also been exploring what the layer around that work should look like: how an issue becomes a bounded task, how execution state is recorded, and how an operator can see what happened. Linear is useful as a place to organize work; it isn't a substitute for the evidence in the repository or for a person deciding whether the result is right.

Make the agent show its work

One project I've been working on, Orca, explores the audit and inspection side of this. The idea is to capture useful evidence around Codex activity and make it easier to inspect what a run did. The local work includes a Go service, typed contracts, and a browser-based inspector. Some of the interface uses synthetic preview data, so a nice-looking screen shouldn't be mistaken for a live view of every agent.

This is the part I keep coming back to. An agent saying “done” is useful as a notification, but I want to know what changed, which checks ran, and what still needs a human decision. If something failed, I want the failure to be visible instead of quietly turning into the next step.

Keep the human in the loop where it matters

I'm trying these ideas outside of coding, too. For a daily job search, the agent can look for roles and help prepare an application, but I want to review the details and submit it myself. The useful boundary isn't necessarily “never do anything” or “automate everything.” It's deciding which parts benefit from speed and which parts need my judgment.

This website gave me a good reminder. I wanted the existing site updated, and the first pass changed the design instead. The code could build and the site could deploy while still being the wrong result. That's a different kind of failure than a broken test, and it's why seeing the actual output matters.

What I'm still figuring out

I don't think the answer is an ever-growing collection of agents talking to each other. I'm more interested in a setup where each piece has a clear job, work has a home, and it's easy to tell the difference between an experiment and something I can rely on.

For now, I'm treating this as an ongoing build. I'll share more as the tools and the workflow take shape—and probably revise some of these opinions as I learn where they break.