Stop Sharing Context Between AI Agents. Start Sharing Contracts.

The team building OpenOrc has four roles.

I’m the Owner. ChatGPT is my Planner. Cline is our Producer. And a separate ChatGPT context serves as our Reviewer.

Only one of those roles is occupied by a human.

This isn’t an attempt to create synthetic employees. The roles describe engineering responsibilities, not positions on a corporate org chart. I’ve written separately about why AI agents shouldn’t be managed like employees.

But organizing the work this way has taught me something interesting about how AI systems should collaborate.

Our Planner needs to understand the entire product and its architecture. Our Producer needs to understand a specific engineering assignment. Our Reviewer needs to understand the requirements and the exact work being evaluated.

Each role requires different knowledge, different capabilities, and potentially a different model or execution environment.

What they don’t need is access to one another’s entire conversational history.

We’ve deliberately built our engineering process around transferring knowledge between AI agents without transferring all the context that produced it.

And that distinction has become one of the central architectural principles behind OpenOrc.

Two weeks of planning before our first GitHub issue

OpenOrc didn’t begin with code.

It began with roughly two weeks of architectural discussions between me and ChatGPT, before we’d even created a GitHub account for the project.

We explored what the product should do, which responsibilities belonged to it, and which should remain with existing engineering systems.

We debated workflow orchestration, agent isolation, runtime integration, authentication, persistence, failure recovery, and human authority.

We changed our minds repeatedly.

Some ideas survived. Others were discarded. Some started as elegant abstractions and eventually turned out to be unnecessary complexity.

The result was a nearly 36,000-word architectural grounding document.

That document became our working source of truth, describing the product’s intended behavior, architectural boundaries, and important engineering decisions.

It didn’t preserve every conversation. It captured the decisions we’d reached.

By the time implementation began, we had accumulated a considerable amount of strategic engineering knowledge.

Then we made a deliberate choice.

We wouldn’t give the grounding document to our coding agent.

Instead, we would translate the relevant knowledge into GitHub issues, repository guidance, formal contracts, and tests.

Why?

Because the Producer doesn’t need to understand everything we discussed while designing OpenOrc.

It needs to understand what we’re asking it to implement, which architectural constraints apply, and how to determine whether the work is correct.

Those are different information requirements.

Context is where decisions happen. Contracts are what survive.

Imagine spending an hour discussing two competing database architectures.

We explore their tradeoffs, identify failure modes, reconsider assumptions, and eventually settle on one approach.

That conversation might consume tens of thousands of tokens.

But the resulting engineering decision might fit into three paragraphs.

Those paragraphs are what the next engineer needs.

The entire discussion doesn’t have to follow them.

For humans, this distinction is familiar. A senior architect doesn’t normally hand a developer a transcript of every meeting that preceded an architectural decision.

They provide the resulting requirements and constraints.

For AI agents, the distinction is arguably even more important.

Conversational context is finite, expensive to process, and bound to particular sessions or runtimes. It contains useful reasoning, but also abandoned ideas, incorrect assumptions, intermediate attempts, and obsolete information.

Copying that context into another agent doesn’t automatically make the recipient better informed.

Sometimes it just transfers the confusion.

Our approach is to progressively transform working context into durable engineering artifacts:

OWNER ↔ PLANNER
Architectural exploration
Broad product context
          │
          ▼
GITHUB + REPOSITORY
Requirements
Architectural constraints
Dependencies
Acceptance criteria
          │
          ▼
PRODUCER ↔ REVIEWER
Implementation planning
          │
          ▼
REVIEWED PLAN
          │
          ▼
PRODUCER
Implementation and testing
          │
          ▼
COMMITTED GIT STATE
          │
          ▼
REVIEWER
Independent verification
          │
          ▼
OWNER
Merge decision

Each handoff carries information appropriate to the next responsibility.

The Planner’s conversation becomes an engineering specification.

The Producer’s reasoning becomes an implementation plan and eventually committed code.

The Reviewer’s judgment becomes a structured decision tied to a specific artifact.

The Owner’s authorization determines when consequential progression is permitted.

The system transfers engineering knowledge without requiring shared conversational memory.

That’s the important distinction.

Why our GitHub issues are unusually detailed

This approach places considerable responsibility on the engineering specification.

In a conventional software team, a GitHub issue might contain a brief feature description and a few acceptance criteria.

That can work because human developers bring substantial implicit knowledge to the task.

They know the architecture. They’ve participated in previous discussions. They understand team conventions and can consult colleagues when something is unclear.

Our Producer has none of that background.

Each executable Task begins with a fresh, isolated context.

The Producer hasn’t participated in our strategic planning. It doesn’t have the grounding document. And it isn’t supposed to initiate free-form discussions with the Owner whenever an implementation detail becomes ambiguous.

Consequently, our GitHub issues are more detailed than typical engineering tickets.

An implementation-ready issue normally establishes the required behavior, applicable architectural constraints, existing interfaces, dependencies, acceptance criteria, and necessary tests.

But there’s an important balance.

We don’t want to specify every helper function, SQL statement, or internal algorithm.

The Producer has access to the actual repository and is often better positioned to make those implementation decisions.

The Planner defines what must be correct.

The Producer determines how to make it correct.

Our goal isn’t maximum specification detail. It’s minimum sufficient specification for reliable autonomous implementation and independent review.

The distinction matters economically, too.

Every unnecessary requirement can multiply into additional planning, code, tests, and review cycles.

But every missing architectural requirement creates an opportunity for the Producer to implement something entirely reasonable that happens to be wrong for the system.

Finding that balance is one of the Planner’s most important responsibilities.

The repository is our organizational memory

Some knowledge belongs in individual GitHub issues.

Other knowledge needs to survive across hundreds of Tasks.

For example, OpenOrc has architectural rules about Workspace isolation, authorization, application-service boundaries, database transactions, and external-operation recovery.

We shouldn’t have to restate those rules in every issue.

Nor should each new Producer session have to rediscover them by inspecting the entire codebase.

Instead, we preserve durable guidance in the repository’s AGENTS.md hierarchy, placing instructions near the code they govern.

We’ve explored that approach in detail in AGENTS.md at Scale: A Practical Guide to Nested Instructions.

The principle is straightforward:

Engineering knowledge shouldn’t depend on a particular agent remembering a previous conversation.

A model can change.

A runtime can change.

A Task session can end.

The repository’s contracts remain.

And where correctness matters, instructions alone aren’t sufficient. Critical invariants must also be enforced through application logic, authorization checks, database constraints, and tests.

An AGENTS.md can instruct an agent to preserve Workspace isolation.

It cannot guarantee that isolation.

The implementation must.

The Reviewer doesn’t need the grounding document either

This was a particularly interesting realization.

If our Reviewer is responsible for protecting architectural correctness, shouldn’t it have access to our entire grounding document?

We concluded that it shouldn’t need it.

The Reviewer’s job is not to reconstruct every architectural discussion we’ve ever had.

It’s to determine whether a specific proposed solution satisfies the established engineering contracts.

During implementation planning, the Reviewer evaluates the Producer’s proposed strategy against the GitHub issue, repository guidance, and existing interfaces.

If it identifies a material problem, it returns actionable findings.

The Producer revises the plan.

They iterate until the plan is technically acceptable or the workflow requires human intervention.

After implementation, the review subject changes.

The Reviewer now evaluates actual committed code.

In OpenOrc’s intended workflow, that review is bound to the canonical pull request and its exact head commit.

If the Producer pushes another commit, the previous acceptance no longer applies to the new version.

That distinction is important because an agent’s description of its work isn’t authoritative evidence of what exists in the repository.

GitHub is.

The Reviewer must evaluate the actual implementation, not merely the Producer’s claim that it completed the task successfully.

This Producer–Reviewer relationship was the original inspiration for OpenOrc. I’ve described how it emerged from a manual workflow in OpenOrc Started as Copy and Paste Between Two AI Models.

What’s relevant here is that independent review doesn’t require shared conversational history.

It requires shared requirements and verifiable artifacts.

There’s also a useful test of whether our planning process has succeeded:

Could a fresh, capable Reviewer correctly evaluate this work using only the issue, repository, and submitted implementation?

If not, we may have failed to make an important requirement durable.

The solution generally isn’t to provide more brainstorming history.

It’s to improve the specification.

Different jobs need different context lifetimes

This separation also affects how we manage agent sessions.

Our Planner operates across the entire project.

It may spend weeks discussing architectural decisions that affect multiple repositories and dozens of implementation tasks.

Resetting that context whenever we create a GitHub issue would be counterproductive.

The Producer and Reviewer operate differently.

They need continuity throughout an individual Task, including planning revisions, implementation, remediation, and final review.

But they don’t need to carry that private history into unrelated Tasks.

OpenOrc’s intended execution architecture follows a simple rule:

New Task, new role sessions. Same Task, persistent role sessions.

Producer and Reviewer maintain separate contexts throughout the Task’s lifetime.

Strategic planning remains outside that lifecycle.

This also explains why we don’t require every role to use the same AI model or harness.

Today, our Planner and manual Reviewer use ChatGPT, while our Producer uses Cline.

In the intended OpenOrc v1 execution workflow, Producer and Reviewer will use independently configured Cline sessions, potentially backed by different models.

The role is the responsibility.

The model and harness are implementation choices.

That separation allows us to optimize each responsibility without redesigning the engineering workflow whenever a better model or runtime becomes available.

The economics have been surprising

Our actual inference consumption provides an interesting illustration.

Over a recent 30-day period, our Cline Producer processed approximately 2.72 billion tokens through OpenRouter using GLM-5.3 Flash.

The usage figures were:

These figures exclude my engineering time, infrastructure, hosting, and other development expenses.

They are direct AI inference and subscription costs, not the total cost of building OpenOrc.

Still, the scale surprised me.

We’ve had individual implementation tasks consume more than 100 million tokens. I explored one of them in “Implement Account Deletion” Cost 100 Million Tokens.

Effective caching and inexpensive inference can make enormous workloads surprisingly affordable.

But that doesn’t mean processing more tokens is inherently productive.

A poorly specified task can waste millions of tokens.

An excessively prescriptive task can generate unnecessary complexity.

And an overzealous Reviewer can turn an acceptable implementation into an endless exercise in hypothetical improvements.

We’ve encountered all three.

This has made us increasingly disciplined about scope, architectural contracts, and what constitutes a material review finding.

It also reinforces why different roles should be able to use different models.

A more expensive Planner may save considerable implementation effort by producing better requirements.

A strong Reviewer may prevent costly defects.

An inexpensive Producer may be extremely effective when given precise engineering assignments and a capable execution harness.

The objective isn’t to minimize inference spending in isolation.

It’s to maximize reliable engineering outcomes per dollar and per hour of human attention.

And context management is part of that equation.

Building the infrastructure around the organization

There’s something recursive about this entire project.

We’re using our four-role engineering workflow to build the software that will eventually automate much of it.

Today, I still spend time coordinating ChatGPT, Cline, and GitHub.

The AI systems perform substantial engineering work, but I remain the message courier and workflow coordinator.

OpenOrc is intended to remove that mechanical overhead.

Its initial scope deliberately begins with an executable GitHub issue.

It governs Task-scoped Producer and Reviewer sessions, structured review loops, implementation authorization, PR creation, commit-addressed review, remediation, and human merge decisions.

GitHub remains the durable engineering record.

Agent runtimes retain ownership of their execution environments and conversational context.

OpenOrc owns the workflow state and authority boundaries connecting them.

Our broader Owner–Planner brainstorming stage remains separate from the initial execution system.

That separation is intentional, not an omission.

Strategic planning is exploratory and cross-Task. Implementation execution is bounded and governed by specific engineering contracts.

They require different kinds of context and different interaction models.

And throughout the process, the Owner retains accountability.

The Planner can recommend an architecture.

The Producer can implement it.

The Reviewer can accept it.

But technical acceptance doesn’t automatically authorize implementation or merge.

Those consequential decisions remain with the human Owner.

The goal is maximum useful autonomy between decision points, not an endless succession of approval dialogs.

Share the knowledge, not the entire conversation

Our approach isn’t a claim that AI agents should never share context.

They obviously need shared information.

The Producer and Reviewer must understand the same requirements. They need access to relevant architectural constraints, existing interfaces, and verifiable implementation artifacts.

But they don’t need identical conversational histories.

The Producer doesn’t need two weeks of architectural brainstorming.

The Reviewer doesn’t need the Producer’s private reasoning.

And the Planner doesn’t need every terminal command executed during implementation.

Each role needs the knowledge necessary to fulfill its responsibility.

The artifacts connecting those responsibilities must be sufficiently precise, durable, and independently verifiable.

That’s the architectural principle we’re exploring with OpenOrc.

Rather than building one enormous AI engineering brain, we’re building a system where specialized AI capabilities can collaborate through explicit engineering contracts while remaining accountable to a human Owner.

The Planner explores intent.

The Producer implements it.

The Reviewer verifies it.

The Owner remains accountable.

The important innovation isn’t making every agent know everything. It’s building an engineering organization where they don’t have to.