Agent Harness

Terminology

Prompt Engineering - is the craft of writing instructions that steer a model toward a desired output within a single inference call. It focuses on wording, structure, and few-shot examples inside the prompt itself, independent of what tools or files surround it. A well-written prompt compensates for what the model cannot infer on its own, while a poorly written one wastes the surrounding context no matter how well curated.

Context Engineering - is the practice of curating what the model sees at inference time to produce better results. It spans both the project and domain layers - deciding what goes in AGENTS.md, which MCPs to enable, how to structure skills, and what to keep out of context to avoid noise. Good context engineering is additive and incremental. Start minimal. Add constraints when the agent fails, not preemptively.

Harness Engineering - (a term formalized in early 2026) is the broader discipline of designing the full agent harness system—not just prompts or context, but the structural environment the agent operates in. It treats agent failures as system design problems to solve permanently, not prompts to retry. If an agent consistently misuses an Elements component, the harness engineering answer isn't a better prompt—it's an lint rule that makes the failure impossible.

Agent Harness Architecture

An agent harness is the complete system that wraps a raw LLM model and makes it useful for sustained, autonomous work. The model itself only generates text—the harness provides everything else: tools, memory, context, constraints, and feedback loops. Every lint rule, type constraint, and structural test that runs outside the model is a guarantee that doesn't depend on non-deterministic token prediction. The more the harness enforces in a deterministic way, the narrower the space where the model can produce inconsistent results and the more predictable output quality becomes.

Where Elements Fits

Elements lives entirely in the Project Harness as horizontal infrastructure that serves many domains - AV, Infra, Robotics, Research - without coupling to any of them. Each domain team layers their own domain specific harness on top. The CLI and MCP expose the same API - one for humans, one for agents.

Where should you invest?

Not every layer of your teams agent harness deserves equal effort. The model and execution layers are commodities you select, not build. Your leverage comes from the project and domain layers where you encode what makes your codebase and organization unique.

Domain-Driven Design

The agent harness onion appears to invert DDD, the domain sits at the outside, not the center. This is not a contradiction. They measure different things along different axes.

• DDD axis: dependency direction. Domain at the center means nothing depends on the domain model - infrastructure adapts to it, never the reverse. The domain is the stable core.
• Agent harness axis: context flow. Domain at the outside means business intent wraps and informs everything inward at runtime. An agent without domain context builds technically correct code for the wrong purpose.

Ubiquitous language encoded in types and names give an agent far more structure to navigate and respect than a loosely organized codebase. DDD and harness engineering are mutually reinforcing disciplines.