the engineering log

Why AI coding agents need an engineering harness

A category thesis for the layer around coding agents, with current Skyflo behavior separated from the complete architecture that remains a target.

Read the full page:What is an engineering harness?
·12 min read·harnessmissionsmemoryverification

Update, September 18, 2026. Since Skyflo 1.1.0, memory the evidence supports is kept without a click, and a workflow proven in two repositories can become a Skill. Correcting a suggestion before keeping it now ships; the "Dreamer" capability described below did not. Skyflo Improves How It Improves describes what did. The essay below is kept as written.

The Bottleneck Moved

Something important happened over the past few years: writing code became much faster.

A competent engineer with a modern coding agent can produce working file-level changes at a pace that would have looked unusual a decade ago. Scaffolding, refactors, test suites, and glue code all became cheaper. The surrounding work did not disappear.

The bottleneck moved to everything around the code: deciding which systems a change touches, keeping parallel edits consistent, reviewing the combined result, and recovering the reasoning later.

Coding agents increasingly include orchestration, memory, checkpoints, and multi-agent execution of their own. Even then, a broader engineering objective needs a boundary around the workers. We call that boundary an engineering harness.

This article describes the complete engineering-harness architecture. Some capabilities discussed below are Planned in Skyflo. The current implementation is listed on the status page.

A Definition

An engineering harness is the layer around coding agents that owns the objective, boundaries, evidence, review, and continuity around their work.

The word "harness" is chosen deliberately. It does not replace the coding agents or the engineers using them. It connects the work, constrains it, and keeps the result attached to the objective.

Concretely, a complete harness has four load-bearing properties.

Property One: The Unit of Work Is the Objective

The target unit is a mission: a persistent object that owns an objective across sessions. It should carry the approved plan, workers, review, evidence, and useful context for as long as the objective remains open.

Skyflo currently persists missions across registered Git checkouts and local execution surfaces. The current product does not claim automatic discovery of infrastructure, CI, and production scope, or evidence-gated completion. Those connectors and the broader completion state are Planned. (See the illustrative mission.)

Property Two: Delegation With Pinned Boundaries

A harness should not scale by making one agent's context indefinitely larger. It can decompose the objective into bounded work with explicit contracts.

Skyflo currently delegates focused specialists into isolated worktrees under one approved plan. A shared interface contract can be included in each specialist packet. Continuous contract conformance checks on every push should remain described as target architecture until they are implemented and registered as Available.

The underlying idea is old: interfaces are how humans coordinate large changes. The harness should make the approved contract explicit and checkable instead of leaving each session to infer it again.

Property Three: Completion Requires Evidence

In the complete architecture, "done" is a provable state rather than a final message. An independent reviewer should inspect the work, and the completion record should eventually include the relevant tests, CI, delivery, and runtime evidence.

Skyflo currently ships the independent reviewer: a separate profile can read files, search, and report but cannot mutate the workspace. CI, canary, deployment, telemetry ingestion, and completion gated on that end-to-end chain are Planned. "Done" is a claim; evidence is the standard.

Property Four: Outcomes Compound

A complete harness should let useful outcomes compound without turning every agent summary into truth.

Skyflo currently lets a mission propose source-linked personal memory. The user accepts or dismisses each candidate, and only accepted memory is retrieved later. Organization-wide memory is Planned; Dreamer and inline correction are Preview.

What a Harness Is Not

Definitions sharpen at the edges:

  • Not merely a coding agent. A coding agent executes development work. An engineering harness owns the objective, boundaries, evidence, review, and continuity around that work.
  • Not a CI/CD system. Pipelines execute predefined steps on predefined triggers. A complete harness should use pipeline results as evidence without pretending to replace the pipeline.
  • Not an autonomy play. A harness is an accountability structure. Approval and review boundaries keep human judgment attached to consequential work.
  • Not a model bet. The harness should outlast changes in model choice. Skyflo currently supports signed-in coding harnesses and configured Moonshot or Z.ai keys; managed inference remains Planned.

Why This Category Now

Models became capable enough that coordination, verification, and continuity are often the limiting system problems. Products also began adding their own orchestration, checkpoints, and memory, which makes precise category boundaries more important rather than less.

The constraint is increasingly coordination across systems, agents, and time.

The target architecture is one objective, bounded work, explicit approval, independent review, evidence, and continuity. Skyflo currently ships the local mission, registered repositories, specialist worktrees, execution surfaces, reviewer boundary, and accepted personal memory. The status page marks the rest.

That is the whole idea. The rest is engineering.