From AI Council to Delivery System

How I Supervise Three Engineering Workflows at Once

Three Workflows, One Operator

Right now, I have three engineering workflows open.

One is under council review. Four AI roles are challenging an architectural proposal, and I will need to decide which objections actually change the plan.

The second is already in implementation. That one does not need me at the moment. The specification is approved, the boundaries are clear, and the executor can keep moving.

The third has come back from audit. The findings are valid, but corrective work is paused. A remediation plan exists, and someone other than the executor needs to review it before any more code changes.

This is the part that still feels new: I can move between all three without reopening old chats and rebuilding the story in my head.

A few months ago, even one workflow could take most of my attention. I carried context between every stage: rewriting role prompts, moving decisions between conversations, tracking the current document, and turning audit findings into the next round of work.

The AI council itself was already useful. It produced strong reasoning and exposed assumptions I would probably have missed. But I was still the glue around it.

The council improved the decisions. The system around it made those decisions easier to carry into implementation, audit, and correction without losing control.

Conversations Were No Longer the Workflow

The main change was simple to describe: I stopped treating the workflow as a series of conversations.

Chats are good for thinking. They are not a good place to keep authority.

Before this change, a decision might exist somewhere in a long discussion. The next agent had to interpret it, and I had to remember whether it was final, provisional, or already replaced.

Now the state of the work lives in a small set of artifacts.

Evidence becomes a source-grounded brief. Decisions become an approved specification. The specification becomes bounded implementation. The implementation is audited independently. Audit findings become a remediation plan, and that plan must be reviewed before corrective work begins.

That sequence gives me a clear answer to one question: what controls the work right now?

The approved specification is the clearest example. If its status says approved, the executor can treat it as the source of truth. If it still says draft, the executor stops rather than beginning with the parts that look settled.

The executor also receives clear limits: what it may change, what it should avoid, when it must stop, and how the result will be checked. Sometimes the specification already contains enough detail; sometimes a separate handoff is needed. Either way, the executor should not have to guess.

This is what keeps the three workflows separate.

The council workflow is waiting for my judgment. The implementation workflow can continue because I have already made the relevant decisions. The audited workflow stays blocked because the proposed fix has not been approved.

When I switch between them, I look at the current artifact and the next decision point. I do not replay the full conversation.

I Stopped Rebuilding Prompts

I also stopped rebuilding role prompts every time I needed an agent.

The prompts are long because the roles are narrow. The executor should not redesign the architecture. The auditor should not start fixing code. The architect should separate what the codebase proves from what it merely suggests.

So I put each role behind a stable command:

/source-architect

/spec-executor @workflow-folder

/execution-auditor

The benefit is not less typing. It is that the role behaves more consistently each time I call it.

The command loads the same boundaries and stop conditions. Role drift drops substantially, and I spend less time shifting my own mindset. I am starting a known role against a known workflow state, not rebuilding both from memory.

Audit Fixes Became Their Own Workflow

The biggest operational lesson came after audit.

The tempting flow is obvious:

implementation → audit findings → executor fixes them

I used to see that as efficient. The audit found the problems, so why not send them straight back?

Because a correct finding can still lead to the wrong fix.

The executor is already deep in the implementation. That context is useful, but it creates momentum. It may patch each symptom separately, expand the scope, or undo an earlier design decision while trying to make the audit pass.

So the corrective path now looks like this:

implementation

→ independent audit

→ remediation plan

→ independent plan review

→ corrective implementation

→ re-audit

The extra review happens before more code changes. It asks: Is this the right fix? Does it stay within the approved design? Is it solving the cause, or only making the finding disappear?

I saw the value of this in a governance skill that had accumulated inconsistencies across several releases. The audit found conflicting status terms, overloaded fields, and unclear closure rules.

The executor could have patched them one by one. Instead, the remediation plan was reviewed first. The reviewer caught one proposed fix that would have reversed an existing directory convention and affected other workflows in the repository. The plan was narrowed before any source was touched.

A later round found seven remaining seams. It started from the earlier brief, execution report, and audit result. I did not need to reconstruct why every previous choice had been made.

The audit did not turn directly into a patch list. The proposed fix had to survive review first.

I Needed Synthesis to Judge the Disagreement

The council introduced another problem I did not notice immediately.

When several reviewers disagree, ordinary synthesis tends to make the final answer cleaner than the discussion really was. It groups similar views, softens the conflict, and often gives more weight to the majority.

That can hide the claim that matters most.

Imagine three reviewers support a design, while one points out that a shared migration has no clear owner. A normal synthesis might record “general agreement with some concern around ownership.” It sounds balanced, but it does not answer the real question: does the missing owner block the plan?

Counter-synthesis treats each objection as a claim to be tested.

The claim has to hold against the original goal, the actual source behavior, known constraints, prior decisions, and the reviewer’s own role. A minority objection may change the design. It may also be rejected if the evidence does not support it.

What matters is that the result ends somewhere concrete: a decision, an assigned owner, a documented default, an open question, or a clear reason not to act.

The point is not to preserve every disagreement. It is to stop agreement, confidence, or polished wording from deciding what survives.

When I return to the workflow later, I do not need the full debate. I need to know which claims held, which did not, what is still open, and what happens next.

What Changed for Me

So when I say I can supervise three workflows at once, I do not mean the agents are running freely while I watch from a distance.

One is paused because it needs my decision. One is moving because those decisions have already been made. One is blocked because the proposed correction has not passed review.

That is where the extra capacity comes from.

I am still making the important calls, but I am no longer manually managing every handoff. When I return to a workflow, I need to know only a few things: What stage is it in? Which document controls the work? Is something waiting for my judgment? What must happen before the next role can proceed?

The answers are in the workflow, not in my memory.

The Trade-Off

This system probably uses more model compute than a simpler agent loop. It keeps the council, independent synthesis, implementation, audit, and remediation review. Stronger reasoning models also cost more.

I am comfortable with that trade-off.

For this kind of work, minimizing tokens is not my main goal. Preventing structural rework matters more. A code-level mistake is usually visible and relatively cheap to fix. The expensive mistake is discovering after implementation has started that the problem was framed badly, the ownership boundary was wrong, or an important objection was never resolved.

I have not measured a precise reduction in structural rework, so I cannot claim one. What I can say is that, in repeated use, I have been less likely to reach implementation and then realize the design itself needs to be reopened.

The shift is simpler than the system around it. I did not give the agents more freedom. I made the work easier to pause, resume, challenge, and govern without starting over.

Capable agents are not the scalable unit. The scalable unit is the governed workflow around them.