Title: Let the agents work | MidnightDev URL: https://midnightdev.dev/writing/learning-by-building Description: I set the goal. AI agents make the changes. Another agent and automated tests check the work. Only permitted changes can be released automatically. Generated from the live page on 2026-10-22. Do not edit by hand; run `pnpm twins`. --- 14 October 2026 · Alex Bouchard · Working with agents # Let the agents work. I’ve set up AI agents to work on a project on their own. They make changes, test them, and have another AI agent review the work. Here’s how that works, what they can release themselves, and what waits for me. ## I want the agents to move the work forward I don’t want to approve every commit. I want to give the agents a goal and let them get on with it: investigate the problem, make the change, test it, and bring in another agent to review it. Small changes can sometimes go all the way through without another approval from me. Bigger decisions come back to me. These are autonomous AI agents using software tools, often working on their own. That freedom comes from the setup around them: a plan for the work, separate roles, checks on the result, limits on what can happen next, and memory that carries useful context into the next session. I started with a few useful ideas from an earlier prototype, then kept building. Agentic Graph Orchestration turns goals into steps and checkpoints. Midnight Reasoning questions the evidence as work proceeds. Memory, scheduled jobs, and each project’s release rules fill in the rest. It is a toolkit I assemble for the project, not a ready-made package. ## First, give the work a shape A goal such as “fix the first-run experience” needs to become work someone can actually do. What needs investigating? What can be changed? How will we know whether it works? Which parts can different agents handle at the same time? Agentic Graph Orchestration is the part of my toolkit that makes those questions explicit. It describes the steps, their dependencies, who owns them, and what counts as completion. Its checker can reject a plan with missing checks, conflicting assignments, or a consequential action assigned to an agent that should not control it. For work run through that graph, the runtime tracks the steps and the declared limits on retries, time, and spending. A step needing a human or policy decision stays open until the appropriate decision arrives. That structure lets agents divide up the work while keeping responsibility for the next step clear. ## Then, check what actually happened An agent saying “done” is a claim we need to check. Depending on the task, the evidence might be a test result, a code change, a source, or something we can see working in the product. Midnight Reasoning adds a review of that evidence against the goal. A reviewing model can explain what is missing and ask for another attempt. Its notes stay with the run. When that reviewer is uncertain, the work can continue, but the uncertain conclusion does not qualify to become settled memory. Releasing code has its own checks. The working agent saves changes as commits and submits a pull request—a proposed change to the main project. Automated tests run, and a separate agent reviews the code. Adding the approved change to the project is called merging. Making it available to users is a release, which depends on that project’s setup. A change an agent proposes can be merged without me when it is permitted and reversible, the required tests and the separate review have passed, and the repository’s own rules allow it. Often that happens through GitHub auto-merge, which adds the change once the required checks pass. If the project requires a human approval, it waits. The reviewer has to check the version being merged; changes made afterward need checks that still cover them. ## One agent run shows where the boundaries are Here is how a change gets merged today. An agent makes a change and submits it to the project as a proposed change. Automated tests run on it, and a separate AI agent reviews it. Then the repository’s own rules decide what happens next. Small changes that can be undone, and that the agents have permission to make, can merge on their own. Major upgrades, work the agents cannot properly check, and decisions outside their permission wait for me. One agent run on October 14 shows that stopping point. It worked in one project at a time, could open no more than eight pull requests, and had to stop working on a change after two consecutive failed fixes. Money, messages to other people, deletion, access keys, legal terms, and changes to public numbers or claims were outside its permission and needed my input. The useful work at BuyLandFL needed my input, so the agents moved on to Yapword. Several pending upgrades failed the automated checks. One passed, but it changed how the game creates share cards, and the agents had no working preview to see whether those cards still worked. They left those upgrades for me. Nothing merged in that run. It ended with a report of what had been checked, what was blocked, and what needed my attention. The project notes were updated so another session could pick up the work. Other changes do merge without me. As of October 22, 2026, 151 pull requests in six of my repositories had been merged without me pressing merge, between June 29 and October 22. That count is a floor, and the workfolio page keeps it current. ## Keep the context, and check the lessons too A fresh agent session should be able to find out where the project stands. Project notes carry the current work. The memory system I built around Graphiti and Neo4j preserves selected decisions and useful facts, along with their sources. A write has to be confirmed before the agent can report it as saved. Midnight Reasoning separates working notes from conclusions eligible for longer-term memory. The memory checks matter because an unsupported conclusion can outlive the session that produced it. I want later agents to inherit useful context with evidence attached. The same principle applies to improving the workflow. A repeated failure can reveal a missing test, a confusing instruction, or a broken handoff. The agents can propose a change, but changes to the tools and rules need review and a record of what changed. Completing a task does not give an agent permission to loosen its own checks. Scheduled jobs keep an eye on project state, memory health, and costs. Recovery tools deal with specific problems: restarting an unhealthy database, for example, or restoring a known stale installed tool. A repair that would overwrite unfamiliar work needs closer attention. ## You learn this by putting it to work There isn’t one workflow that fits every project. I connect these tools differently depending on the work and what could go wrong. The aim is to give the agents useful freedom, catch mistakes early, and keep a clear account of what happened. The only way I’ve found to learn how to use this stuff is to experiment with real work. Find the weak point, improve it, and check the result. That is how this setup keeps changing—and how I can let the agents keep moving without sitting beside them all day. ## For a closer look For readers who want the details, the notes explain the release checks, memory system, recovery tools, and scheduled jobs, with links to the supporting code. [Read the technical notes](https://midnightdev.dev/writing/learning-by-building-technical-notes.md) [The counts, dated, with the method](https://midnightdev.dev/writing/learning-by-building-evidence.md) [Threat model: enforced, policy, open](https://midnightdev.dev/writing/learning-by-building-threat-model.md) [Failure catalog: ten entries](https://midnightdev.dev/writing/agent-failure-catalog.md) [Back to the workfolio](https://midnightdev.dev/work/agent-workflows.md) [Public ship log](https://midnightdev.dev/ship-log.md) [Tuesday’s count and method](https://midnightdev.dev/writing/a-very-crowded-tuesday-technical-notes.md) Next step ## Want to talk it through? Book a 30-minute call. I will tell you plainly whether I can help and what I would test first. [Book a call](https://calendly.com/alex-midnightdev/30min?utm_source=midnightdev&utm_medium=site&utm_campaign=essay-learning-by-building) [or email alex@midnightdev.dev](mailto:alex@midnightdev.dev)