One of the bigger lessons from working on Enso, the assistant I’m building, has been how much I want to know about the work an agent has done. There’s code to review, sure, but what was it asked to do? What actually got checked? And why is this thing ready for me? I can dig through git commits and chat logs to work that out. I’d much rather have that context sitting with the task.

That’s been a useful place to start thinking about what people call an “agentic software development lifecycle”, or SDLC (us devs love our acronyms, don’t we).

The lifecycle itself is familiar enough, from planning and building through testing, shipping and maintaining software. We’re working out how that fits together when an agent can pick up a task and spend time on it without us sitting beside it. In Enso, we use workflows made up of stages, with jobs picking up the work at each stage. A job gives the agent instructions and access to the project, along with rules about how the work gets handed on.

The useful bit for me is what we keep at each handoff. We call these records receipts. They point to what changed, what checks ran and how they turned out, along with anything the next stage needs to know. A commit might be part of that, so might test output or a reason the task was sent back. Enso keeps the receipts with the task. When I open it for review, I can see why it’s ready for me, or if it’s blocked, what’s been tried and what decision it needs. I still have to read the code, of course, but at least I know where to start.

That visibility has been a big one for us.

We also use gate scripts before and after the agent runs. The first checks whether the job is ready to start, and the second checks the result against requirements we’ve chosen. These are ordinary scripts run by Enso, outside the agent’s conversation. The agent can run tests while it works, and Enso runs the required checks before allowing the task to move forward.

Say we’re fixing a page that crashes when a search returns no results. The task describes the empty state we expect to see, so the agent has a clear target. After it changes the code, a gate checks that case alongside tests for the existing behaviour. If the check fails, Enso sends the failure back to the agent for another attempt, up to a limit. Once it reaches that limit, the task stops and comes back to a human with the attempts and failures recorded. I can then look at whether the brief was unclear, the check is broken, or the agent needs help with the implementation. If the checks pass, the change goes to review with the results attached. Either way, there’s a record of how we got there.

There’s a similar idea in Stripe’s write-up of its coding agents. Its workflow mixes agent work with fixed steps written in code. Running required checks and enforcing a retry limit are things we can handle perfectly well with a script. We know how to do that part. It takes some plumbing, but it gives us a consistent way to decide what happens next.

Of course, we can still write a bad check. If we’ve described the wrong behaviour or missed an important case, a passing result won’t tell us. We still have to review the work and fix the checks when they miss something.

I’m also trying to keep the workflow itself from becoming a project of its own. Every extra stage adds another handoff to explain and maintain. Does it catch something useful? Is it a sensible place for a human to step in? For a small change, we should be able to keep that fairly short. In Anthropic’s experiments with long-running coding agents, improvements in the model let it remove some of the surrounding process. I expect we’ll keep revisiting ours too. Less is more here, provided I can still open a task and work out what happened.

We’re still tweaking the gates and retry limits. I expect we’ll change our minds about a few of them once we’ve used the setup more.