Andrew James00 / INTRODUCTION

00Software engineer / 2026

From idea
to system.

I build agent systems and workflows, drawing on my background in software and systems engineering. My work is about how agents get useful work done: how tasks are split up, how changes are checked, and how the system handles failures.

AGENTS → WORKFLOWS → SYSTEMS

GitHub ↗LinkedIn ↗Email ↗
One idea, connected across a complete software systemAn original isometric drawing connects a product interface, stacked services, durable data, and agent workstations. Moving signals trace the connections. SERVICES / API PRODUCT / INTERFACE DURABLE STATE ENGINEERAGENT
FIG. 00The interface, the services, and the work behind them.
FROM THE GROUND UP01 / ASSEMBLE ONE REQUESTONE SYSTEM
Try the steps and see what changes.
FIG. 01Where the work backs up.

Build from durable data to the interface, then follow a request through the system.

Select an object. Ask a question. Follow the evidence.

01Software architecture

Get the software
working early.

I like getting changes into a working environment early. A prototype answers some questions. Connecting it to the rest of the system usually raises a few more.

I’d rather find those problems while the work is still easy to change. The dev setup, tests, and everyday tools matter too. They should make it easier to move around the codebase.

How I design systems

I make service boundaries, data ownership, and failure paths explicit. APIs give each part a clear contract; background jobs keep longer work separate from the request.

When I think about scale, I look at the workflow as well as the software. Where does the work run? What becomes a bottleneck as more work happens at once? I’m interested in moving beyond setups that depend on one machine, while keeping the approach practical for what the system actually needs to do.

02Verification

Break the work
into smaller pieces.

I’ve designed a delivery platform where agents implement changes, review the work, and help fix CI failures. I break larger jobs into smaller tasks for research, implementation, and checks. Smaller changes are easier to keep focused.

I use linting and tests for the repeatable checks, then take a fresh look at the work. Did the change do what was asked, and does it fit the rest of the code?

How I work with agents

I design and share agent workflows that others can reuse, with a clear owner for each task, separate review, and CI checks.

I decide what needs building, where the boundaries go, and how we’ll know it works. An agent needs that context too.

Tests catch specific failures. Review asks whether the change solves the right problem and fits the surrounding system. Both belong in the workflow.

PARALLEL WORK / SHARED STANDARD02 / ROUTE CLEAR GOAL INTERFACE SERVICES CHECKS TEST / REVIEW ONE CHANGE
Try the steps and see what changes.
FIG. 02Break it down. Check it before it goes through.

Send three bounded tasks along separate routes, then bring the work together for verification.

Select an object. Ask a question. Follow the evidence.

FAILURE IS PART OF THE DESIGN03 / RECOVER WORKER / A DURABLE CHECKPOINT2 STEPS KEPT / 1 TO GO WORKER / B SAME OPERATION KEYONE RESULT
Try the steps and see what changes.
FIG. 03Keep what’s done. Pick up what’s left.

Two steps are saved. Interrupt the worker and watch the remaining step recover.

Select an object. Ask a question. Follow the evidence.

03Reliable execution

Keep what’s done.
Retry what isn’t.

Once work spans a few services, failures and retries can leave a mess to sort out. A worker can disappear after doing the work but before reporting it. A retry can arrive while the first attempt is still running.

I keep track of what finished, who’s doing the next part, and what a retry should do. The next attempt should know what’s already done and what’s left.

How I handle interruption

A checkpoint records completed work. A lease establishes who owns the next step. A stable operation key lets a retry recognize an existing result instead of creating it twice.

Releases have their own version of this problem: old and new code can be running at the same time. Compatibility checks and repeatable migrations make those transitions easier to reason about.

REPEATABLE EVALUATION04 / INSPECT SAME TASKS / SAME CONDITIONS TASK GRIDINSPECT / RERUN
Try the steps and see what changes.
FIG. 04Run the same task. Look at what changed.

Scan the task grid to reveal a pattern of passes and failures. Illustrative results.

Select an object. Ask a question. Follow the evidence.

04Learning from results

Look at what
actually happened.

I look at the patch and the run that produced it. Did the change do the job? Did the tests cover what matters?

When something fails, I look at why, change the workflow, and run the same tasks again. That gives me something to compare, instead of guessing whether it got better.

How I learn from a run

I start comparisons from a known revision, give runs the same task, and check the resulting patch. Critical requirements and verification matter alongside the outcome.

Traces connect model steps, tool calls, errors, and delivered results. They also show when evidence is incomplete.

05Engineering practice

Make the next
change easier.

I want someone else to be able to pick up the work without having to piece the whole thing back together.

That includes the code, the setup, the tests, and the notes I leave behind.

How I make the process reusable

I make useful context part of the handoff: the goal, the decisions, the actual change, and the evidence behind it.

The result is something another engineer can inspect, continue, and improve.