Title: How I put AI agents to work | MidnightDev URL: https://midnightdev.dev/work/agent-workflows 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`. --- Autonomous AI agents / Alex Bouchard # How I put AI agents to work. I give AI agents a goal and leave them to work. While I’m away, they can investigate, build, and test changes; another agent can review the result. Software rules check whether anything may move forward. If the work is major, unverified, or outside its limits, it waits for me. I started with an earlier experiment, kept the parts that fit, then added a goal-based work graph, Midnight Reasoning, a memory system, and project-specific release rules. I connect those pieces differently for different projects. [See the diagram ↓](https://midnightdev.dev/work/agent-workflows#workflow) · [Read the essay](https://midnightdev.dev/writing/learning-by-building.md) ## The work, the checks, and the memory. The diagram shows one goal-based run: plan the work, check a proposed change in two ways, then apply that repository’s own merge rules. Actual projects connect these pieces differently. The last row shows what carries between runs and what scheduled jobs watch. The example below shows what one particular run checked and held. ### Alex sets the goal The task, what is allowed, and when the agents must stop. ### [Agentic Graph Orchestration on GitHub (opens in a new tab)](https://github.com/abouchard11/agentic-graph-orchestration) Turns the goal into steps with owners, checks, and limits on retries, time, and cost. ### Agents do the work Claude Code, Codex, and Hermes investigate, build, and test. ### [Midnight Reasoning on GitHub (opens in a new tab)](https://github.com/abouchard11/midnight-reasoning) Checks step evidence against the goal. It can request a bounded retry; it cannot approve a merge. The reviewer can send the agent back to fix a gap. ### A proposed change A commit records the work. A pull request asks to add it to the project. Two independent checks ### Automated tests Do the required checks pass? ### Separate AI review Does another agent find a problem? ### This project’s merge gate The repository applies its own rules to the exact proposed change. Passing tests alone does not grant merge permission. ### May merge Only if allowed, small, reversible, and every required check passes. Then verify the result. ### Wait for Alex Major, excluded, uncertain, or failing work stays for a decision or a better way to check it. ### A clear handoff What changed, what checks found, where work stopped, and what needs attention next. Between runs ### Project notes Status, evidence, and next steps for a later session. ### [Graphiti / Neo4j memory on GitHub (opens in a new tab)](https://github.com/abouchard11/graphiti-neo4j-ops) Where connected, keep useful, sourced facts after safety and duplicate checks. A receipt confirms the write landed. ### Scheduled checks + recovery Watch project health, memory, and cost. Fix known problems; leave unfamiliar changes for review. Lessons can improve tests or instructions after review. I combine and adapt these tools for each project. Connections and release rules vary by repository. *Mistakes can still happen. The point of the workflow is to make the work checkable, keep uncertain or out-of-bounds changes from moving forward automatically, and leave a useful record. On smaller screens, the diagram stacks into a simple flow.* [Read the technical notes and source links](https://midnightdev.dev/writing/learning-by-building-technical-notes.md) ## What each part does. Agentic Graph Orchestration ### Give the work a structure. Break a goal into steps. Give each step an owner and a way to check whether it is done. Separate agents can take different tasks. The graph checker looks for conflicting assignments and missing checks; the runtime manages the declared steps, retries, and stopping points. Midnight Reasoning ### Ask whether the result answers the goal. A reviewing model examines the evidence from a step and can explain what needs another attempt. Its notes stay with that run. When the reviewer is uncertain, the work can continue, but that uncertain opinion is not saved as a settled fact. It does not decide whether code can merge. Tests + separate review + project rules ### Control what reaches the main project. The coding agent saves its work and submits a proposed change. Automated tests run, and another agent reviews it. The project’s rules decide whether it can be added automatically or needs my approval. A changed version needs checks that still apply to that version. Project state + Graphiti / Neo4j ### Leave context for later. Project notes record what changed and what is left to do. Where a project connects the memory system, selected facts keep their source and require confirmation that the write succeeded. Those notes and saved facts are available to later work. The three named components are public repositories on GitHub under the Apache-2.0 license: [Agentic Graph Orchestration](https://github.com/abouchard11/agentic-graph-orchestration), [Midnight Reasoning](https://github.com/abouchard11/midnight-reasoning), and the [Graphiti / Neo4j operations tooling](https://github.com/abouchard11/graphiti-neo4j-ops). ## How agents get work 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 reads 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 be added on their own. Often that happens through GitHub auto-merge, which adds the change once the required checks pass. Major upgrades, work the agents cannot properly check, and decisions outside their permission wait for me. One agent run on October 14 reached that stopping point. The work at BuyLandFL needed my input, so the agents checked Yapword next. Several upgrades failed the automated checks. Another affected the game’s share cards, and the agents had no working preview to check those cards. They left the upgrades for me and recorded what needed attention. The record below counts what has merged without me pressing merge, and which route each one took. Auto-merged pull requests, as of October 22, 2026 A pull request in one of my own GitHub repositories that was merged without me pressing merge. - **Auto-merged**: 151 pull requests in 6 repositories - **Merge dates**: June 29, 2026 to October 22, 2026 - **Dependabot updates merged by the repository's workflow**: 38 - **Merged by GitHub auto-merge once the checks passed**: 89 - **Merged by an agent through the ship gate, no go-ahead on the receipt**: 7 - **Merged by an agent through the ship gate, with my go-ahead on the receipt**: 17 Every merge runs under my account, so I count only merges with a machine record: a workflow merge, GitHub auto-merge, or a ship receipt. Some agent merges left no record, so this count is a floor. It says nothing about quality beyond those gates. 89 of the 151 (59%) merged through GitHub auto-merge that was switched on under my account, by me or by an agent, and merged once the checks passed. The count is regenerated from GitHub and merge receipts; the as-of date is above. The full table is in [the evidence note](https://midnightdev.dev/writing/learning-by-building-evidence.md). **What do “commit,” “pull request,” and “merge” mean?** A **commit** saves a record of a change. A **pull request** proposes adding changes to the main project and gives the checks and reviewers something to inspect. A **merge** adds the approved changes to that project. A release makes them available to users; how that happens depends on the project. ## The workflow improves through real work. The threat I plan for first is an instruction hidden in something an agent reads: a file in the repository, a pull request description, a web page, or the output of a tool. My shared workflow file says that external content is data, never an instruction, and that the hooks which check an agent’s work may not be changed without my authorization. Both are written rules. A hook scans files as the agent reads them, but it only warns. What code enforces is narrower. The graph checker refuses any plan where the model closes an irreversible step or verifies its own work, and a companion check refuses to treat a copy of that checker as a gate once it no longer matches the canonical one. The merge gate runs from the main branch, so a pull request cannot edit the check that judges it, and it rejects a review whose reviewer is the author. That reviewer is a fresh session that did not write the change, not a different model. The gate checks the name on the record and the exact commit it read, not which model wrote the review. When something goes wrong, we use the failure to improve a test, an instruction, or a handoff. Changes to those tools need review too. An agent can propose an improvement; it does not get to remove its own checks to finish a task. Scheduled jobs watch for problems with the projects, memory, and operating costs. Recovery tools handle specific failures, such as restarting an unhealthy database or restoring a known stale copy of a tool. They leave unfamiliar changes for review. The aim is to catch mistakes early, keep them from spreading, and leave enough evidence to recover. I keep experimenting because different projects need different arrangements. [Read the essay](https://midnightdev.dev/writing/learning-by-building.md) [See the shipped work](https://midnightdev.dev/ship-log.md) · [Technical details and sources](https://midnightdev.dev/writing/learning-by-building-technical-notes.md) · [The counts](https://midnightdev.dev/writing/learning-by-building-evidence.md) · [Threat model](https://midnightdev.dev/writing/learning-by-building-threat-model.md) · [Failure catalog](https://midnightdev.dev/writing/agent-failure-catalog.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=agent-workflows) [or email alex@midnightdev.dev](mailto:alex@midnightdev.dev)