← All work

Independent work

Jarvis: A Personal Harness for AI Coding Agents

AI coding agents that plan, wait for approval, work in isolation and prove their results. I designed and built Jarvis, and use it to deliver changes across my projects.

Context

Status: in use. Jarvis is my personal harness for AI coding agents. I describe a task in a GitHub issue; Jarvis has an agent plan it, waits for my approval, carries it out in isolation, checks the result and opens a pull request for me to review. It works across several of my repositories.

Problem

I wanted to hand tasks to AI agents and come back to finished work I could review, and eventually have several agents build larger systems together. First, I needed to be able to trust them.

My contribution

I designed and built Jarvis end to end, using AI coding agents to help build it, and I run it day to day.

  • Workflow: GitHub issues as the task queue, with a written plan that must be approved before anything changes.
  • Isolation: each task runs in its own git worktrees, and builds and tests run in a disposable virtual machine with no credentials and restricted network access.
  • Verification: outcomes are classified from evidence, not from the agent finishing.
  • Recovery and memory: interrupted work is kept for the next attempt, and lessons are proposed as reviewable pull requests.

Technical approach

  • Plan, approve, execute. The agent first writes a plan with explicit acceptance criteria. Execution starts only after I approve that exact plan; any change to the request or the rules needs a fresh plan.
  • Evidence over claims. Each run ends with a structured report: every criterion marked met, not met or unknown, with evidence. Jarvis runs its own checks on the changed files, so a run is completed only if every criterion is met and the checks pass; otherwise it is partial, blocked or unverified.
  • Pull requests, never merges. Jarvis commits and opens a pull request, treats my review comments as new input, and never merges or force-pushes. Merging stays my decision.
  • Safe by default. Agents get only the tools a task needs. Build work runs in a microVM with deny-by-default networking, read-only git metadata and no credentials.
  • Durable state. Task state and outgoing comments are recorded locally before they are sent, so a crash cannot silently repeat or lose an action. If something uncertain happens, Jarvis stops and waits for me.
  • Memory with review. Agents can propose project notes, which arrive as pull requests I accept, edit or reject.

It is written in Python using only the standard library, with an automated test suite.

Challenges and trade-offs

Most of what I learned came from things that went wrong in real use:

  • Stopped runs lost their work. A build was cut off at its time limit with an hour of changes stranded. Jarvis now keeps interrupted work and the next attempt continues from it, and agents are told their time budget so they report before the limit.
  • Agents gave up too early. An agent set short timeouts on slow package installs and concluded the network was blocked. Clearer instructions about expected install times fixed it.
  • Strict reports matter. A run that did good work was marked unverified because its report was malformed. Rather than loosen the check, I made the instructions clearer and made sure unpublished work is kept.
  • Process notes leaked into content. Agents wrote their own working rules onto this website's pages, so the site now has tests and written rules that keep that text out.

Outcome

Jarvis has delivered reviewed, merged changes across this portfolio, the Dare To Dream Africa website and the Sollou Realtors website. The first version of this site was planned and built through it.

Reflection

Making AI agents useful is less about the model and more about the system around it: clear plans, isolation, honest evidence and a human who decides what ships. I keep evolving it as I learn what helps agents do reliable work over longer tasks, which connects to the questions I am exploring in Memory Lab.