# How I put AI agents to work: technical notes

By Alex Bouchard · October 14, 2026

Companion to [Let the agents work](https://midnightdev.dev/writing/learning-by-building) and the [workfolio overview](https://midnightdev.dev/work/agent-workflows).

The public page shows one assembled workflow. These notes describe the code, local setup, and one reported agent run behind it. I took selected ideas from an earlier BB1 experiment, then added and connected other pieces. BB1 is not the single runtime protecting every action. The graph runner, reasoning reviewer, memory service, repository checks, scheduled jobs, and recovery tools have separate roles. Each project connects the pieces it needs.

The run report and the scheduled upkeep details come from local instructions and configuration. The links below are to the reusable public components.

## One agent run, with a clear stopping point

The instructions for the October 14 run limited work to one repository at a time, allowed up to eight pull requests, and required work to stop after two consecutive failed fixes. The agents could propose and test changes, request a separate AI review, and merge only changes that were small, reversible, and allowed by that repository's rules. Money, external messages, deletion, credentials, legal terms, and changes to public figures or claims were outside the agents' permission.

The October 14 report shows how that boundary worked. The BuyLandFL work needed Alex's input, so the agents moved on to Yapword. Several proposed upgrades failed the automated checks. Another passed a test but changed how the game creates share cards, and there was no working preview to check the cards. That change stayed with Alex. **Nothing merged in that run.** The report recorded what had been checked, what stopped, and what needed attention.

## The work graph gives a task structure

[Agentic Graph Orchestration](https://github.com/abouchard11/agentic-graph-orchestration/tree/a77b7a49f28f090bf481c451c1d1242402de7473) turns a goal into steps with dependencies, an owner, and a way to check completion. Its linter looks for missing completion checks, conflicting ownership, unbounded retries, and consequential actions assigned to a model. Its reference runner respects human or policy steps and limits on retries, time, spending, and progress.

That graph is a reusable component, not proof that every model action in every project passes through it. The application that connects the runner still supplies its step handlers and the authority for closing steps. A graph file cannot enforce its own rules if the surrounding application gives another route around them.

## Midnight Reasoning reviews step evidence

[Midnight Reasoning](https://github.com/abouchard11/midnight-reasoning/tree/0706df98f7eb869dd7c307c70b414b2405de81df) records a review beside the active run. A critic compares a step's evidence with its goal and can point out what needs another attempt. An uncertain result can leave the current work moving, but it does not qualify as a settled fact for longer-term memory. That review is a work aid; it does not give permission to merge code.

The production memory connection is supplied by the application, so this library is not automatically active in every agent session. Its repository also records gaps still being worked on: no documented live task has yet demonstrated retrieval of a saved fact and successful use of it; handling conflicting writers and memory expiry also need more work. A malformed reviewer response has a defined fallback, so the reasoning result must not be treated as a perfect detector of mistakes.

## A pull request faces project-specific rules

A commit is a saved change. A pull request proposes adding that change to a project. Tests and a separate code review examine it; the repository's own rules determine whether it can be merged. Merge permission is separate from a model's view that its task is done. Later changes to the proposal need checks that still apply to the new version.

Those rules differ across projects. Some repositories require a pull request and hosted checks; others permit particular content changes through a shorter route. Local Git hooks can scan staged changes for credentials, but they are not a check for hallucinations or product correctness. Source code can describe a repository's gate; hosted settings and real run evidence have to be checked separately before claiming that a given gate is enforced.

The wider toolkit also includes [Caduceus](https://github.com/abouchard11/caduceus/tree/2b4d2cd72584cef07e740a4426cc575d6274f6fb), which gathers separate drafts, compares disagreements, and keeps dissent visible. It is useful for decisions that benefit from explicit debate; it is not a required step in every coding run.

## Memory and scheduled upkeep carry the work forward

Project notes preserve current status, evidence, and next steps. Where the memory system is connected, its write path checks that an event is useful, properly sourced, safe, in the right project, and not a duplicate. A receipt confirms that Graphiti accepted the write. A separate AI review may be supplied, but the current write instructions do not require one. Midnight Reasoning's memory promotion also requires an explicitly supplied Graphiti connection. These controls make it possible to keep useful context; they do not prove that every later task has retrieved or used it.

Scheduled jobs watch separate parts of the system: project and tool drift, memory and service health, and operating cost. Recovery is limited to known cases. For example, a repair can restore a tool when its installed contents match a known older version, while making a backup; unfamiliar edits are left for review. A service restart can restore availability, but it cannot establish that the data or product behavior is correct.

## What this can and cannot establish

The system gives work a goal, an owner, completion evidence, and a stopping point. Other agents can challenge parts of the work. Tests and repository rules provide separate release checks. Project notes and confirmed memory writes help later sessions recover context. These controls make unsupported claims easier to catch and keep uncertain or out-of-scope work from moving forward automatically.

They do not guarantee that agents never make mistakes. Tests can miss a product problem, an agent can misunderstand evidence, and a project can connect a tool incorrectly. That is why the workflow leaves unverified or high-impact work for a human and treats each project's release path as its own engineering decision.

Three further notes carry the evidence behind these claims: the [evidence note](https://midnightdev.dev/writing/learning-by-building-evidence.md) with dated counts and the report format, the [threat model](https://midnightdev.dev/writing/learning-by-building-threat-model.md) that separates enforced controls from written policy, and the [failure catalog](https://midnightdev.dev/writing/agent-failure-catalog.md).

## Start small

The full arrangement is more machinery than most projects need on day one. The smallest useful version is the [coding loop](https://github.com/abouchard11/agentic-graph-orchestration/blob/a77b7a49f28f090bf481c451c1d1242402de7473/examples/coding-loop.md): four nodes, where a person closes the plan and the merge, the model implements, and a script verifies. It runs with one coding agent, one test command and a repository that requires a pull request. Add the other layers when a specific failure asks for them.

| Layer | Add it when |
| --- | --- |
| Separate review of record | A merged change had no review, or the review was a bot message. |
| Graph runtime with declared limits | Two agents worked the same files, or a retry loop ran without a ceiling. |
| Reasoning critic | Steps were marked done with evidence that did not answer the goal. |
| Confirmed memory writes | A later session repeated a decision, or inherited a wrong one. |
| Scheduled checks and recovery | Something stayed broken for more than a day before a person noticed. |

Each row is a failure I had before I added the layer. The catalog records most of them.

## Outside coding

The same irreversible-edge rule runs work that is not software. [Dozen](https://midnightdev.dev/work/dozen) is a creator marketplace whose graph keeps accept, post and pay outside the model, with fail-closed gates for disclosure and payment. Research and operations runs use the same scope list: a weekly capped search routine, portfolio analytics and search-visibility audits, and an incident report on a lead pipeline, each with money, messages and credentials held for a person. The pattern is the graph and the scope list, not the programming language.

## License and reuse

The code is public to read at the links below. Each repository states its own license in its root; check the file at the commit you are reading, because the terms are being revised in October 2026.

## Public source code

- [Agentic Graph Orchestration, source snapshot](https://github.com/abouchard11/agentic-graph-orchestration/tree/a77b7a49f28f090bf481c451c1d1242402de7473)
- [Midnight Reasoning, source snapshot](https://github.com/abouchard11/midnight-reasoning/tree/0706df98f7eb869dd7c307c70b414b2405de81df)
- [Caduceus, source snapshot](https://github.com/abouchard11/caduceus/tree/2b4d2cd72584cef07e740a4426cc575d6274f6fb)
- [Graphiti and Neo4j operations, source snapshot](https://github.com/abouchard11/graphiti-neo4j-ops/tree/1db0b4889e27ead76b5b181bf5f9af6e3416e33b)
- [Agent skills and integration patterns, source snapshot](https://github.com/abouchard11/midnight-agent-skills/tree/c14e49f627796691ba41775be4602b7666535a0d)
- [Midnight Reasoning, known gaps](https://github.com/abouchard11/midnight-reasoning/blob/0706df98f7eb869dd7c307c70b414b2405de81df/KNOWN-GAPS.md): what the production path has and has not proven