Coding agents and harnesses
- Primary Responsibility
- Organize agent work through context, tools, permissions, and feedback.
- Relationship To Cohesive
- Agents can edit semantic source and use compiler diagnostics and connected system context.
Vision
Start with the overview, then choose the lens you need.
Cohesive in Context
Coding agents, harnesses, software factories, and verification tools change how software gets built. Cohesive supplies a language for the system meaning that this work accepts and carries forward.
The tools overlap, and a single product can cover several responsibilities. The useful comparison is what each contributes to a change and what remains explicit after the work is complete.
A harness gives a model a working environment. For example, OpenCode's agents have configurable tools and permissions for different kinds of development work. That environment can also give an agent access to a language compiler and the files it consumes.
Consider a request to require approval for refunds above a threshold. In the intended Cohesive workflow, the agent inspects the refund definition, its authority rules, and the process that submits the payment. It proposes an edit to semantic source, invokes the compiler, and reviews the resulting diagnostics and affected definitions. Supported projections are regenerated; integration work and tests address the remaining implementation.
The harness manages the agent's work. The semantic system graph connects the accepted rule to the behavior and artifacts it affects. Review can ask whether approval is now required at the right boundary, as well as whether the code compiles.
This example describes how the responsibilities fit together. It is not a claim of a packaged OpenCode integration. Available compiler outputs and bindings depend on the building block and target in use.
Historically, software factories captured a family's common structure and planned variation in reusable assets, models, and generators. In an agent-driven development workflow, the factory idea can also describe agents coordinating implementation, tests, reviews, and delivery from a specification. Those approaches differ in how much variation their production machinery can handle.
Cohesive's contribution is the representation that production works from and leaves behind. Definitions preserve accepted behavior across later changes, including changes to the implementation strategy. A factory can use that source, run its compilers, and check its outputs as part of its workflow.
From Software Factories to Semantic Systems develops the historical argument and the lessons about variation, model drift, and continued evolution.
A prose specification can express intent, examples, uncertainty, and tradeoffs before a decision is settled. As decisions become precise, Cohesive gives selected facts defined semantics: which transition is permitted, which invariant it preserves, who may authorize it, and which effects it requires.
Shared identities let a compiler connect those facts across definitions and report conflicts within its supported rules. Authored source remains versioned and reviewable. Compilation derives connected graph state and supported artifacts from it.
This adds language design, tooling, and maintenance costs. An informal feature sketch may be sufficient for a small experiment. Semantic source becomes more useful when a decision affects several parts of a system and must survive successive changes.
Agents can recover substantial understanding from code, documents, and runtime evidence. That ability helps with adoption: an agent can propose candidate definitions for an existing system and identify the evidence behind them.
The decision to accept a definition still matters. An implementation may contain a deliberate rule, an obsolete compromise, or a defect. Cohesive gives the accepted interpretation a durable identity and lets supported tooling derive consequences from it on the next change.
The test is whether maintaining that explicit source reduces reconstruction, contradiction, and repeated translation enough to justify its cost. A graph that merely duplicates the repository without changing those economics adds little value.
The representation determines which properties are natural to state. A refund model can name the remaining refundable amount, the approval requirement, and the point at which a payment obligation becomes durable. These facts give analysis, tests, and formal verification concrete subjects.
A proof establishes a property under its formal assumptions. Tests exercise selected cases. Runtime observations record particular executions. Connecting that evidence to a definition also requires checking that the running implementation realizes the model being checked.
Cohesive's deterministic compilation makes supported transformations repeatable. Its broader aim is to keep these claims, mappings, and their evidence connected. It does not make an incorrect requirement correct or establish a guarantee that a target cannot provide.
Stronger models can make discovering, authoring, and migrating semantic source easier. They can also make working directly over conventional code more effective. Cohesive has to earn its place against that improving baseline.
The question is whether explicit system meaning improves the cost and reliability of continued change. That can be evaluated through successive changes to working systems, including comprehension effort, defects, drift, and the work needed to validate each result.
Examine the pressures behind patterns and how their implementations change when more work can move into tooling and infrastructure.
Follow the two uses of shared system meaning: agentic development and agentic interaction with a running system.