The Danger of Losing Focus

One of the easiest ways to derail a software project is to make a series of perfectly reasonable decisions.

That sounds backwards, but we nearly did exactly that while building OpenOrc.

OpenOrc is an open control plane for governed agentic software development. The basic idea is straightforward: coding agents do the engineering work, while OpenOrc owns the workflow around them: tasks, planning, independent review, human authorization, GitHub state, audit history, and progression from issue to merge.

Our first supported agent runtime is Cline.

That gave us a very simple near-term objective:

Figure out how current Cline actually works, then build a reliable Cline adapter in OpenOrc Core.

Everything else was secondary.

Then we started thinking about infrastructure.

The original problem

To develop and validate the Cline adapter, we needed somewhere to run Cline.

For our own hosted dogfood environment, DigitalOcean was the obvious choice. So we created a research track in the OpenOrc Cloud repository.

The initial plan was deliberately boring:

1. Provision a DigitalOcean Droplet.
2. Install and configure Cline.
3. Validate the current Cline SDK and remote-runtime behavior.
4. Determine how sessions, authentication, provider configuration, approvals, reconnects, and failures actually work.
5. Feed those facts back into OpenOrc Core.
6. Build the Cline adapter.

That was the mission.

Then came the first reasonable optimization.

A clean Droplet takes time to provision and hydrate with repositories, dependencies, toolchains, and runtime configuration. Recreating one constantly during research seemed wasteful.

So we asked:

Should the runtime persist between tasks?

Reasonable.

Then:

If it persists, should we be able to shut it down when idle?

Also reasonable.

DigitalOcean Droplets cannot simply be “paused” while retaining their full machine state, so that became:

Could we shut down the Droplet, snapshot it, destroy the compute, and restore it later?

Still reasonable.

Now we had gone from:

Get Cline working.

to:

Design a resumable managed runtime lifecycle.

Not disastrous yet, but the direction had changed.

Then DigitalOcean launched Managed Agents

At almost exactly the wrong moment, DigitalOcean released its Managed Agents / Harness Runtime.

And it looked extremely relevant.

It provides isolated execution environments, persistent agent sessions, pause/resume, checkpoints, secrets, approvals, event streams, usage metering, and first-class support for coding agents including Codex and Claude Code.

The overlap with infrastructure we had been discussing was substantial.

Suddenly a much bigger question appeared:

Why are we building our own managed runtime lifecycle at all?

Maybe OpenOrc Cloud should use DigitalOcean Harness Runtime.

Maybe Cline should run inside Harness.

Maybe OpenOrc could integrate with Harness itself and gain Codex, Claude Code, and other agents through a common platform.

Maybe our runtime abstraction should sit above DigitalOcean Managed Agents instead of directly above Cline.

All of these were legitimate architectural questions.

And that was precisely the danger.

We were making increasingly good decisions about the wrong problem

None of the individual reasoning was obviously bad.

Persistent Droplets were better than rebuilding constantly.

Hibernation could save money.

Snapshot restore could preserve expensive Workspace hydration.

Managed Agents appeared to solve hibernation much more elegantly.

Harness also appeared to solve parts of agent isolation, permissions, secrets, telemetry, and multi-runtime support that OpenOrc would eventually need.

If we had evaluated each decision in isolation, we could have justified every one of them.

Collectively, however, we had quietly stopped solving the original problem.

The original problem was:

Build an infrastructure-independent Cline adapter for OpenOrc Core.

We were drifting toward:

Determine the ideal DigitalOcean-managed agent infrastructure, then shape OpenOrc around it.

Those are not the same project.

The prime directive

We already had a rule designed specifically to prevent this:

Core must never depend on Cloud.

openorc/core is the complete open-source product.

openorc/cloud is a deployment of that product. It contains hosted infrastructure, production configuration, managed runtime operations, billing, and other hosted concerns.

The dependency points in one direction:

openorc/cloud
      ↓
openorc/core

Never the other way around.

We hadn’t introduced an import from Cloud into Core. No package dependency had been reversed.

But we were beginning to violate the rule conceptually.

We had started asking:

How should Core work given the capabilities DigitalOcean Harness provides?

The correct question is:

Does DigitalOcean Harness satisfy a runtime contract that Core already defines?

That is a much more important distinction than it initially appears.

Architectural dependencies can reverse long before a compiler notices.

Back to the main quest

We eventually stopped and reset the research program.

The purpose of our Cloud research track is once again explicit:

Learn enough about real, current Cline to build the Cline adapter in Core.

A plain persistent DigitalOcean Droplet is sufficient to do that.

We still kept our small hibernation experiment, because it is useful infrastructure. We can shut down a research Droplet, snapshot it, destroy it, and restore it later.

But the meaning changed.

Hibernation is now a capability, not a requirement.

If Cline credentials survive snapshot restore, excellent.

If they do not, we record that fact, leave the Droplet running, and continue the research.

If a Cline session survives, interesting.

If it does not, that does not block the Cline adapter.

We are no longer required to solve every inconvenience we discover in the Cloud environment before Core can progress.

That sounds obvious when written down.

It was less obvious while each inconvenience arrived one at a time.

What happens to DigitalOcean Managed Agents?

Nothing. That’s the point.

It is still extremely interesting.

But it is a separate integration.

The intended architecture remains:

OpenOrc Core
    │
    ├── ClineAdapter
    │      └── Cline
    │
    └── DigitalOceanHarnessAdapter
           └── DigitalOcean Managed Agents
                ├── Codex
                ├── Claude Code
                ├── OpenCode
                └── ...

The Cline adapter should work regardless of whether Cline happens to run on a laptop, a persistent Droplet, a resumable VM, or some future hosting system.

A DigitalOcean Harness adapter can later implement the same OpenOrc runtime contract against DigitalOcean’s managed-agent API.

One does not replace the other.

The broader lesson

“Stay focused” is usually useless advice.

Engineering work constantly reveals adjacent problems. Sometimes those problems genuinely invalidate the original plan. Ignoring them merely because they were not on the roadmap would be equally foolish.

The more useful rule is this:

New possibilities should be tested against your architectural boundaries before they are allowed to redefine your current objective.

In our case, we already had the boundary.

Core defines OpenOrc’s workflow and runtime contract.

Cloud provides infrastructure around it.

Agent runtimes implement the contract.

Once we remembered that, the decision became easy.

DigitalOcean Managed Agents can be exciting without being urgent.

Snapshot hibernation can be useful without becoming a product requirement.

Cloud can experiment without defining Core.

And Cline can remain the first adapter without becoming the definition of what an adapter is.

A good architecture does not prevent interesting new possibilities from appearing.

It lets you say:

“Interesting. Later.”

And then get back to work.