OpenOrc Started as Copy and Paste Between Two AI Models

OpenOrc did not start with an orchestration architecture.

It started with copy and paste.

For a long time, my most effective way to use coding agents has been to give different jobs to different models. One model produces the work. Another reviews it. The producer plans and implements; the reviewer attacks the plan, finds omissions, inspects the implementation, and sends it back when necessary.

The important part is that they are genuinely different models.

At the time of writing, my current pairing is GLM-5.3 running through Cline as the Producer and GPT-5.6 Sol in ChatGPT as the Reviewer. That combination has consistently produced better results for me than asking one model to produce and then effectively review its own style of reasoning.

This is not a benchmark result, and I do not think there is a universal best pairing. It is an observation from using these systems to build real software over long periods of time.

The pattern that kept repeating was simple: independence helped.

A reviewer should disagree differently

At first, the obvious way to improve an agentic coding workflow seems to be to use a stronger model.

If one model is good at coding, use a better one. If its plan is weak, ask it to reconsider. If the implementation has problems, give the same agent another pass.

That works up to a point.

What worked noticeably better for me was separating production and review.

The Producer has one job: move the task forward. It needs to understand the repository, form a plan, make concrete engineering decisions, edit code, run tests, and finish the implementation.

The Reviewer has a different job. It does not need to preserve the Producer’s momentum. It can ask whether the plan is solving the right problem at all. It can notice that an invariant was never tested, that a migration only works on a fresh database, that a failure mode has been classified incorrectly, or that a seemingly sensible abstraction is hiding an architectural mistake.

Those roles benefit from different perspectives.

I have tried versions of the same pattern using closely related models, including having GPT-5.6 Sol review work produced by GPT-5.6 Luna. Sol is the stronger reviewer, but in my experience the result is still not as effective as pairing it with a genuinely different Producer model.

That was the surprising part.

The value was not simply:

stronger model reviews weaker model

It was closer to:

one capable model produces; another capable but different model tries to prove it wrong

The distinction matters.

Two systems with similar tendencies can converge on the same assumption. A reviewer with different tendencies is more likely to question it.

Sometimes the Producer is right and the Reviewer is being overly cautious. Sometimes the Reviewer catches something important. Sometimes they need several rounds before the design settles.

That disagreement is useful.

The workflow worked. Operating it did not.

Once I had found the pattern, I kept using it.

And using it was ridiculous.

A typical task looked something like this:

Cline produces a plan
        ↓
copy plan into ChatGPT
        ↓
ChatGPT reviews it
        ↓
copy findings back into Cline
        ↓
Cline revises the plan
        ↓
copy revised plan into ChatGPT
        ↓
review again
        ↓
approve implementation
        ↓
Cline implements
        ↓
copy implementation result into ChatGPT
        ↓
review the pull request
        ↓
copy remediation back into Cline
        ↓
repeat until accepted

For a small task, this is mildly annoying.

For a serious task with multiple plan revisions, implementation cycles, test failures, pull-request remediation, and long-running agent sessions, it becomes a job in its own right.

The models were doing the engineering work. I was operating the message bus.

That was the problem OpenOrc originally needed to solve.

Not how to invent another coding agent.

Not how to wrap a single model in a bigger prompt.

Not how to replace Cline.

The problem was how to coordinate an existing Producer and an independent Reviewer without making a human manually shuttle state between them.

Copy and paste was hiding a protocol

The manual workflow looked informal, but over time it became increasingly structured.

The Producer did not just send arbitrary prose. It produced recognizable things:

• a plan;
• a revised plan;
• an implementation result;
• a pull-request proposal.

The Reviewer did not just chat about them. It returned outcomes:

• accepted;
• changes requested;
• another review after revision.

And I was making explicit decisions between stages:

• approve this plan for implementation;
• allow the pull request to be opened;
• merge this reviewed revision;
• stop and resolve something manually.

Once those distinctions became clear, the copy/paste workflow stopped looking like two chat windows.

It started looking like a state machine.

A simplified version is:

Task
 ↓
Producer plan
 ↓
Reviewer evaluation
 ↙             ↘
revise        accepted
  ↑              ↓
  └────────── implementation approval
                   ↓
              Producer implementation
                   ↓
               pull request
                   ↓
              Reviewer evaluation
               ↙          ↘
          remediate      accepted
               ↑             ↓
               └──────── merge decision

The human still matters, but in a different role.

The Owner should decide when consequential transitions are authorized. The Owner should not need to remember which plan revision is current, which pull-request head was actually reviewed, whether a response belongs to the planning loop or the implementation loop, or which browser tab contains the latest version.

That is control-plane work.

The agents are not OpenOrc

This distinction became important early.

Cline is already good at being a coding runtime. It owns sessions, tools, filesystem access, terminal execution, model configuration, MCP integrations, and the mechanics of doing the work.

ChatGPT is already good at being an independent reasoning and review environment.

OpenOrc does not need to absorb either of those products.

Its job is to coordinate roles.

Today my Producer happens to be GLM-5.3 in Cline and my Reviewer happens to be GPT-5.6 Sol in ChatGPT. Those choices can change.

The useful abstraction is not:

OpenOrc = Cline + ChatGPT

It is:

Producer
    ↓
governed workflow
    ↑
Reviewer

The runtimes and models occupying those roles are configuration.

The workflow between them is the product.

That is why OpenOrc treats Producer and Reviewer as logical roles rather than model identities. A runtime adapter should provide the execution/session capabilities OpenOrc needs without turning the runtime itself into the control plane.

The distinction sounds obvious now.

It was much less obvious while I was manually copying 20,000-character responses between two applications.

Independence needs structure

Using two models does not automatically make a system reliable.

They can still misunderstand the task. They can disagree forever. They can review an outdated revision. They can produce malformed output. A task can change underneath them. A pull request can receive another commit after the Reviewer accepted it.

The manual workflow had an uncomfortable advantage here: I was implicitly keeping track of all of that.

If the process is going to become autonomous, those implicit checks have to become explicit.

That leads quickly to requirements that have little to do with prompting:

• persistent Producer and Reviewer sessions;
• exact revision identities;
• structured results;
• bounded review loops;
• explicit Owner authorization;
• stale-operation rejection;
• durable workflow state;
• authoritative GitHub reconciliation;
• recovery when an external operation has an uncertain outcome.

This is where OpenOrc stopped being a convenience script.

The copy/paste problem was small.

The state-management problem underneath it was not.

Why keep the human in the loop?

The goal is not to turn every interaction into an approval dialog.

Most engineering work should proceed without interruption.

The Producer should resolve ordinary implementation questions. The Reviewer should review independently. They should be able to iterate without waiting for a human after every message.

But some transitions carry authority.

Starting implementation from a reviewed plan is one.

Publishing a pull request is another.

Merging reviewed code is another.

Those boundaries are useful places for an Owner to decide whether the system should continue.

That gives us a workflow where agents can be highly autonomous inside a stage without silently acquiring authority over the whole process.

The original manual producer-reviewer loop already had those boundaries. I was just enforcing them with copy and paste.

OpenOrc makes them explicit.

The original experiment is still visible

The system has grown considerably since those first manual loops, but the core idea has not changed.

There is a Producer.

There is an independent Reviewer.

They retain their own working context.

They iterate when review finds problems.

The Owner controls consequential transitions.

And the system keeps track of which exact artifact each decision applies to.

Everything else is machinery required to make that pattern reliable at scale.

In that sense, OpenOrc is still doing the same thing I was doing manually.

It is just much better at remembering which window to paste into.