This is how I set up my new desktop machine for coordinating multiple AI agents. My workflow is particular to the Juju project.
Goals
Simplicity. I want to be able to move between agents performing different tasks very efficiently. I could have used VMs or containers, but I just want to switch tmux panes.
I don’t want to use IDE tools. The IDE is for me to read and write code. Agents don’t need colour coding, auto-completion, brace matching etc. Using the IDE also leads to using agents through the prism of the code in front of me. I want to work at the scope of requirements, functionality and architecture.
I want each agent to tend independent builds of Juju and independent bootstrapping, tear-down, current working model etc.
Set-up
Agent Choice
I am using OpenAI’s Codex, for which I have a subscription. I have found that using Copilot with Codex as the agent does not give the same experience as the Codex CLI. I don’t have specifics on this; just an impression that the Codex CLI gives better results. I only use the xlarge model for deepest reasoning.
Structure
I have my normal directory (juju), which builds into the default location, and stores metadata for clouds, controllers etc in the default place (~/.local/share/juju). In addition I cloned Juju into three different directories, so that it looks like this:
├── juju
├── juju1
├── juju2
├── juju3
These are individual Git repositories. I could have used worktrees, but as mentioned, I’m going for brutal simplicity.
I open a tmux window for each of these directories, and carve those up into panes, one running the Codex CLI and others for building, running, status and log observation as required.
Independence
There are two problems to solve here.
- I don’t want builds from one window to overwrite those from another.
- I want to be able to bootstrap simultaneously, and have each window with its own view of the current controller and model.
To achieve this I am using direnv. My .envrc file in each agent directory looks like this:
export JUJU_DATA="$PWD/.juju-data"
export GOBIN="$PWD/.bin"
PATH_add "$GOBIN"
This redirects Juju metadata and build artefacts to local directories, achieving the desired separation described above.
In addition to enabling direnv in each of the agent directories, I had to add this snippet to my .zshrc:
eval "$(direnv hook zsh)"
The .envrc is sourced automatically each time I cd into the directory, ensuring the sand-boxing.
Usage
I can now tend multiple tasks throughout the day, ranging from investigations and planning, through to discrete patches and reviews.
As I go, I’ve been adding both architectural and domain knowledge, available via AGENTS.md. This is very powerful in being able to direct the agents in terms of Juju esoteria, and assume they “understand” much like a counterpart familiar with Juju terminology would.
If my computer should crash I can rely on the agents themselves to interrogate their logs and metadata. I just instruct them to load the last session in that directory.
This is a manifold boost to productivity, but it does come at a cost. This an exhausting way to work. I’ve never felt more powerful professionally, but I feel completely spent each day due to the context switching and ensuring the agents are kept active.
Things are moving fast, and can see how this will require us to re-imagine the software engineering process completely.