How I use AI to build without handing over the decisions

By SimonSeptember 16, 2026

Hermes handles research, coordination and review; Codex is my default for coding. The important part is a bounded brief and evidence that the result works.

Two tracks of research cards and geometric parts stop at a gate operated by a hand.

AI-generated conceptual illustration of bounded delegation, not a photograph of Simon or an actual workflow interface.

I use Hermes for research, review and coordination, and Codex is my default for coding. I keep decisions about what the business should offer and who should have access to it with the people responsible for them. There is plenty for the agents to do within those limits.

If you run a brand or creator business, deciding those limits will do more for you than picking a favourite model. A change to a member page can affect paid access. A cleanup can remove something another part of the business still needs. Before delegating, I want to know how much authority the task requires and how I will check the result.

How the work moves from Hermes to Codex

In Hermes, I research options, inspect what is already there and coordinate the work. I also use it to review results. Codex is where I usually go for implementation. That division suits my workflow; it does not describe the limits of either tool.

OpenAI's best-practice guidance includes running checks, confirming behaviour and reviewing changes before accepting Codex's work. Hermes supports delegating work to child agents with fresh, isolated conversations. Their roles overlap, so I make the handoff explicit rather than expecting the tools to sort it out, especially when a business decision affects the implementation.

The implementation agent needs the problem, relevant project context, an agreed scope and acceptance checks. I also want the source or file behind a research summary included in the handoff. However confident the summary sounds, the next agent needs a way to inspect the evidence.

Independent research questions can run in parallel. But if one agent is still working out the access policy, another should not be implementing access checks against a guess. Faster responses do not make that rework worthwhile.

Conceptual workflow separating research and implementation, with an owner deciding scope and release — Conceptual workflow: separate research and implementation, then bring evidence back to the person responsible for the decision.

Be specific about what the agent may change

Suppose a creator business wants a better explanation on the page shown when someone cannot open a members-only video.

I would not brief that as "fix the member experience". The agent would have to choose between changing the copy, the login flow, membership rules or the paywall itself. For this hypothetical task, the brief could look like this:

Part of the brief: Outcome

Example instruction: Explain why access is unavailable and show the appropriate next step.

Part of the brief: Existing rule

Example instruction: Preserve the approved access policy. Retrieve it before proposing a change.

Part of the brief: Allowed changes

Example instruction: Message copy and presentation on the specified page.

Part of the brief: Outside scope

Example instruction: Billing, membership eligibility, access enforcement and unrelated pages.

Part of the brief: Required evidence

Example instruction: Show the behaviour for a signed-out visitor, an eligible member and a signed-in person without access.

Part of the brief: Stop condition

Example instruction: If the policy or expected behaviour is unclear, return the conflicting evidence before editing.

Part of the brief: Release authority

Example instruction: Prepare and verify the change in the approved test environment. Do not publish it.

A business owner can read this brief and approve the scope. A developer may need more detail, but that technical plan still has to preserve the business rule.

I would keep the last row even for a small copy change. Preparing something and releasing it are separate permissions, just as drafting a newsletter differs from sending it, or recommending a refund differs from issuing the money.

Keep procedures separate from today's instructions

My setup separates stable user facts, reusable procedures and project rules. Stable facts about me belong in memory. Procedures belong in skills. Rules about a particular project belong in project context. SOUL is reserved for identity, not tone preferences or operational instructions.

That is how I organise my setup, not a universal rule. When something goes wrong, I want to be able to find the instruction that caused it and correct it.

Hermes describes skills as knowledge documents loaded when needed, which makes them a sensible place for a verification procedure I will use again. OpenAI's guidance likewise recommends AGENTS.md for repository rules and skills for repeatable work, rather than continually pasting the same instructions.

A launch checklist can be reused. "This launch goes to this audience on this date" belongs to the current task. A rule about which customers can access a product belongs with the project, where it can be checked against the implementation. Put them all in the same place and a one-off exception can end up being applied to the next launch.

Check the result, not just the agent's report

I do not accept "done" on its own. If the task involves commands or code, I expect them to have run. If the agent lacks information, it should retrieve it or report the gap rather than guess.

OpenAI's testing guidance covers relevant tests, lint or type checks, checking behaviour against the request and reviewing the diff for regressions. Those checks are useful, but they still have to tell you something about the task you assigned.

For the member-page example, a formatting check would tell me nothing about whether an eligible member still has access. A screenshot of the new message would not prove it either. I would want results for each state named in the brief.

For a saved record, read back the exact record. For a published page, open the actual URL and inspect the result. For an access rule, try an allowed and a denied case in a safe test environment. Choose checks that could expose a wrong result, rather than just confirm that the agent completed a step.

Verification table pairing a code change, saved record and published page with evidence from the actual target — Match the evidence to the claim. A successful request is not the same evidence as the resulting record or page.

The completion report should tell me what changed, what ran, what passed and what is still uncertain. If a service was unavailable and a test could not run, say so. A prediction about what would have passed is not a test result.

Give the reviewer something to examine

An agent can usefully review another agent's work if it gets the original brief and the evidence. Asking whether an implementation summary "looks good" is a much weaker check. The reviewer may simply agree with the summary.

Give the reviewer a specific job: find scope changes, compare the acceptance checks with the actual results, inspect the changed files and identify anything the tests don't cover. If a change introduces a new assumption about customers, pricing or access, bring that assumption back to the owner.

I would add a second reviewer only if it examines something the first pass might have missed. Two agents agreeing on an incomplete summary does not reassure me if neither has checked the underlying work.

This is how I divide the work between Hermes and Codex for Stackmodo. You can use the brief above with other tools. Before delegating your next change, write down what must remain true when it is finished and how you will check it. If you cannot answer those questions yet, settle them before implementation starts.