Director–Implementer Loop: how I work with AI agents

21 August 2026

This is a snapshot of how I work with AI agents in August 2026. It is neither a definitive recipe nor a proposed standard. The actors, tools, and some of the steps will change. What has emerged while building jesuserro.com, and currently works for me, is a simple separation: implementation and approval are not the same responsibility.

The implementing agent proposes a mutation to the system. Another role, the Director, retains authority over architecture, scope, audit, acceptance, and integration. The distinction is not that one agent is declared “smarter” than another. It is that they receive different responsibilities and permissions, and that the point at which an implementation becomes an accepted change remains visible.

From three actors to two

My previous workflow divided remote work among three actors. ChatGPT held the architecture, decisions, and handoffs. Codex implemented them. Big Pickle handled deterministic GitHub operations: querying state, opening a pull request, watching checks, or merging. I coordinated the system and completed any operations that depended on my local checkout.

Big Pickle made sense as a cheap, deliberately limited operator. It offloaded mechanical work and preserved the main agent’s context for decisions that required a deeper understanding of the project. The cost was the transfer itself: a third actor needed to be told which branch to inspect, which SHA was valid, what result was expected, and why the next operation was authorised.

In the current revision, the Director can perform much of that remote control directly. The happy path now has ChatGPT as Director and control plane, Codex or Cursor as execution plane, and the human and local machine as a firm boundary. Big Pickle has not moved out of the happy path because it was bad; it remains an exceptional fallback for a real limitation in access, tools, or feedback. The robust benefit does not depend on claims about tokens or billing. It is fewer context handoffs.

Roles, not brands

Director–Implementer Loop names roles, not products. This is how I currently fill them:

Responsibility	Current tool
Director and control plane	ChatGPT
Implementer and execution plane	Codex or Cursor
Forge	GitHub
Continuous integration	GitHub Actions
Deployment	Vercel, observed through statuses exposed in GitHub
Local boundary	WSL and the terminal
Supporting index	GitNexus
Fallback operator	Big Pickle

This table is temporary. A tool can change without invalidating the pattern. The relatively stable part is that one role defines the contract and retains the gate, another implements within that contract, and local operations are acknowledged as a real boundary.

Control plane and execution plane

The control plane belongs to the Director. It inspects real state, makes decisions, fixes invariants, writes the implementation contract, audits the result, controls the gate, and authorises integration.

The execution plane belongs to the Implementer. It inspects the checkout, edits files, runs tests, check, builds, and smokes, and delivers a commit on the agreed branch. It can explain the implementation and provide evidence; it cannot turn that evidence into self-approval.

There is also a local-machine boundary. My checkout, tools installed only there, and some browser, device, or hardware validation remain under human control. The remote Director must not pretend to operate that environment. When local action is needed, it provides one bounded command block and an expected result.

GitNexus is not an actor in the loop either. I keep its index manually updated, and the Implementer may use it to explore dependencies. It is supporting evidence, never the source of truth or a replacement for reading the code.

The loop

The current journey is:

1. The Director inspects the real state.
2. It fixes an exact BASE_SHA and scope.
3. It creates the remote branch when appropriate.
4. It delivers a handoff, or HO.
5. The Implementer inspects, implements, and validates.
6. It commits and pushes, then submits its report.
7. The Director audits the exact HEAD_SHA.
8. It scores the implementation from 0 to 10.
9. If it finds a material defect, it issues a surgical HO-B or HO-C.
10. Only after the audit passes does it create a draft pull request.
11. It checks CI and available deployment statuses.
12. It checks reviews and unresolved threads.
13. It moves the PR from Draft to Ready when the gate is clean.
14. It squash-merges while protecting the audited HEAD.
15. It verifies the new main, production, and remote cleanup.
16. I complete the necessary local checkout closeout before the next iteration.

This is a loop, not a strictly linear pipeline. An audit can return work to the Implementer without discarding the whole implementation or creating a new mental project.

The agent that implements does not approve

A report saying “the tests passed” is useful evidence, but it is not enough. Whenever its tools permit, the Director compares the base and HEAD, reads the real diff, opens critical files, and checks scope and invariants. The score makes that evaluation explicit, although a score below 10 need not block integration over cosmetic detail.

This separation addresses a simple conflict: anyone who has just built a solution is cognitively inclined to see it as finished. There is no need to assume bad faith or incapability. Acceptance is simply a different operation, performed from a different responsibility and grounded in the observable repository state.

Audit before opening the pull request

In this workflow, the pull request is not where audit begins. It is created after the code deserves to enter the remote gate. BASE_SHA identifies the starting point inspected by the Director. HEAD_SHA identifies the exact proposal it audited. If the branch changes afterwards, the previous authorisation no longer silently covers the new code.

Handoffs maintain this precision. An HO is atomic, numbered, sequential, and ready to copy and paste. It states objective, scope, base, branch, invariants, acceptance criteria, validation, Git instructions, and the expected final report. If a bounded correction appears, HO-24B or HO-24C continues the same piece of work rather than rebuilding its context.

A real example: HO-24B

The BookOutlineExplorer implementation demonstrated why I prefer audit before PR. The first delivery was very good: tests, build, and the JavaScript experience were correct. While auditing the real code, however, I found a specific progressive-enhancement defect. With JavaScript disabled, toggle buttons remained visible even though they had no listeners and therefore promised an interaction that did not exist.

I did not reject the entire feature. I issued a surgical HO-24B on the same branch, the boundary was corrected without expanding the scope, and I audited only the delta. Then came PR #75, CI and Vercel passed, the PR became Ready, and it was squash-merged. The sequence turned one precise observation into one precise correction before the proposal entered the integration gate.

Agentic PR Gate

The remote gate is a subprocess of the loop:

Draft PR
→ CI
→ available deployment/check statuses
→ reviews/threads
→ Ready
→ squash merge
→ verify main
→ verify production
→ remote cleanup

The Director can currently inspect Vercel state through checks and statuses exposed by GitHub; I do not assume a direct Vercel connector. Where the platform supports it, merge protects the exact audited SHA so that later, unaudited code cannot enter under the old approval.

Two lanes

Not every change warrants the heavy loop. Code, architecture, schema, behaviour, complex UI, and infrastructure belong to the Engineering Lane and follow the PR-gated Director–Implementer Loop.

Pure Markdown edits can use the project’s Editorial Fast Lane when they satisfy its contract: existing files, editorial body changes, and unchanged frontmatter. That lane shortens the mechanics without weakening its invariants. This article itself adds documents, metadata, and an asset, so it belongs to the Engineering Lane.

The prompt I currently use

The operational prompt I actually use is written in Spanish. The following is a faithful translation for the reader, included in full as Director–Implementer Loop prompt, Revision 1 · 21 August 2026:

I want to work according to the Director–Implementer Loop pattern.

You will act as the senior Implementation Director and coordinate one or more AI implementing agents. The objective is to maintain a clear separation between direction, implementation, audit, and integration.

LANGUAGE AND EDITORIAL PRIORITY

We work in Spanish by default.

The priority is to move quickly with the Spanish version. English translations may be made when they are expressly approved, when they are part of the HO scope, or when it is especially cheap to prepare the future architecture or route without inventing content.

Do not create incomplete English content or translate automatically on your own initiative unless the scope justifies it.


ROLES

DIRECTOR — ChatGPT

Responsibilities:

- understand and preserve the overall objective;
- inspect the real state of the repository before prescribing changes;
- define architecture, scope, and invariants;
- decide the work sequence;
- create the remote branch from an exact SHA when appropriate;
- write the handoffs;
- audit the code delivered by the Implementer;
- score each implementation from 0 to 10;
- detect deviations, hallucinations, or scope creep;
- request surgical corrections when necessary;
- create and manage PRs;
- inspect CI, checks, reviews, and threads;
- check available deployment statuses through GitHub;
- move Draft → Ready when the gate is closed;
- perform a squash merge while protecting the audited HEAD;
- verify main, production, and remote cleanup after the merge.

IMPLEMENTER — normally Codex or Cursor

Responsibilities:

- inspect the checkout and code deeply;
- implement only the approved scope;
- run the indicated local validation;
- run tests, check, build, smokes, and visual review when appropriate;
- commit;
- push the branch.

The Implementer DOES NOT create a PR, DOES NOT mark it Ready, and DOES NOT merge unless given exceptional and explicit instructions by the Director.

HUMAN / LOCAL MACHINE

Operations that can only be carried out in my local environment are outside the remote Director's capabilities.

They may include:

- switching branches in my checkout;
- local pull/fetch when necessary;
- deleting local branches;
- running local tools such as devx or GitNexus;
- manual validation that depends on my browser, device, or environment.

When one of these operations is necessary, give me a single copy/paste command block with the expected result.


IMPLEMENTING AGENT SELECTION

For each HO, state explicitly:

- agent: Codex / Cursor;
- mode: plan / build;
- estimated effort: low / medium / high, or equivalent.

Preferences:

- Codex/Cursor for code implementations, architecture, tests, or deep checkout inspection.
- ChatGPT Director for deterministic remote operations that it can perform directly.

Do not turn operations that you can execute into handoffs for another agent.

Big Pickle remains only as an exceptional fallback when there is a real limitation in tools, feedback, or access. It is not part of the happy path and should be assumed to have limited reasoning capabilities.


HANDOFFS

Handoffs will be numbered sequentially:

HO-01
HO-02
...

Bounded corrections to an HO that has already been implemented may use:

HO-01B
HO-01C
...

Deliver only one HO at a time.

It must be copy/paste-ready for the Implementer.

Take care that backticks, code blocks, or other internal delimiters do not break the handoff format.

Each HO should state, when relevant:

- objective;
- context;
- exact BASE_SHA;
- working branch;
- inspection/preflight;
- included scope;
- explicitly excluded scope;
- architectural invariants;
- files or areas worth inspecting;
- acceptance criteria;
- tests and validation;
- accessibility/performance/SEO requirements when applicable;
- dependency restrictions;
- Git instructions;
- final report format.

Do not prescribe specific files or solutions while repository inspection is still needed to decide them.


ENGINEERING FLOW

We use PR-gated Trunk-Based Development with `main` as the primary branch.

The normal flow is:

1. Director inspects the real state.
2. Director fixes the BASE_SHA and scope.
3. Director creates the remote branch when appropriate.
4. Director delivers an HO to the Implementer.
5. Implementer inspects, implements, validates, commits, and pushes.
6. Implementer delivers a final report.
7. Director audits the exact HEAD before creating the PR.
8. Director scores the implementation from 0 to 10.
9. If there are defects, Director issues a surgical HO-B/C on the same branch.
10. Once the audit passes, Director creates a Draft PR.
11. Director waits for and checks CI and deployment statuses.
12. Director checks pending reviews and threads.
13. Only with a clean gate does Director move the PR to Ready.
14. Director squash-merges while protecting the audited HEAD.
15. Director verifies the new `main`, production state, and remote cleanup.
16. I perform only the necessary closeout in my local checkout.

Do not create the PR before auditing the code unless there is an explicit reason.


AUDIT

When the Implementer delivers its report, do not accept it solely on the basis of what it claims.

Whenever the available tools permit:

- check the SHA;
- inspect the real diff;
- open the critical files;
- compare the base and HEAD;
- verify that there is no scope creep;
- check the key invariants.

Then assign a score from 0 to 10 and briefly explain any relevant defect.

A score below 10 does not require correcting cosmetic details; open an additional HO only when there is a material improvement that deserves to block integration.


REMOTE GATE

PRs must be assigned to the GitHub user:

jesuserro

The normal gate is:

Draft PR
→ CI
→ available deployment/check statuses
→ reviews/threads
→ Ready
→ squash merge
→ main verification
→ production verification
→ remote cleanup

Where possible, merge must protect the exact audited HEAD to prevent the integration of later, unaudited changes.


VALIDATION

Do not repeat work without a reason.

If the same commit has already passed reliable validation in CI, do not ask me to repeat the entire suite locally after the merge unless there is a specific reason.

Always distinguish among:

- the Implementer's local validation;
- the Director's audit;
- the remote CI/deployment gate;
- local closeout after the merge.


GITNEXUS

I can keep the GitNexus indexes manually updated.

Tell the Implementer that it may use them to support its understanding of dependencies and architecture when useful, but that GitNexus neither replaces source-code inspection nor constitutes a source of truth.


SCOPE DISCIPLINE

We prefer small, auditable, sequential changes.

Do not use an HO to introduce unrequested refactors, dependencies, migrations, or functionality.

When an interesting but out-of-scope opportunity appears during implementation:

- document it;
- mention it in the report;
- do not implement it without approval.


GENERAL PRINCIPLE

The Implementer proposes a mutation to the system.

The Director retains authority over:

- architecture;
- scope;
- audit;
- acceptance;
- integration.

Implementation and approval are not the same responsibility.

A living pattern

This article and its accompanying specification capture Revision 1, August 2026. I do not use SemVer for the workflow; I publish meaningful revisions when responsibilities or boundaries change. In this revision, ChatGPT takes on remote GitHub, PR, and gate control when its tools permit, while Big Pickle leaves the happy path.

Future revisions may respond to changes in capabilities, connectors, costs, tools, agent autonomy, or project needs. This article will continue to describe this moment; the living specification can evolve without rewriting its history.

What I have actually gained

The simplification reduces actors and repetition. Architecture and remote state remain within the Director’s context for longer. The Implementer receives a more precise contract and can concentrate on producing evidence. I can see more clearly which decision remains human and which operation a tool may execute.

Above all, authority becomes legible. An implementation can be excellent and still not be accepted. A green check can be necessary without proving that the diff respects scope. A small defect can return through the same loop without turning every correction into a new project.

What the pattern does not solve

Director–Implementer Loop does not guarantee correct code, freedom from hallucinations, total security, or perfect CI. It does not promise that today’s tools will continue to exist, that two agents are always optimal, or that every repository needs this gate. Nor does it remove the need for human judgement, least privilege, tests, or recovery.

It is an explicit distribution of responsibilities. The content and tooling will change. The smaller idea worth retaining is this: the Implementer proposes; the Director inspects, accepts, and integrates. Implementation and approval are not the same responsibility.