How do model capabilities differ from harness infrastructure in agents?

Talking about "agent code" as one thing obscures three distinct elements that the code-as-harness survey separates. First, model-internal capabilities: the reasoning, perception, planning, simulation, and evaluation abilities baked into the model's weights. Second, system-provided harness infrastructure: the predefined tools, APIs, sandboxes, memory systems, validators, permission boundaries, telemetry, and workflows that connect model outputs to external actions and feedback — this is the main focus of harness engineering. Third, agent-initiated code artifacts: the interactive code objects an agent itself creates, executes, observes, revises, persists, and shares within the execution loop. These three are coupled but governed by different design levers.

The decomposition is useful because each element fails and improves differently. You strengthen model-internal capability by training; you strengthen the harness by engineering infrastructure; you strengthen agent-initiated artifacts by shaping how the agent generates and reuses its own code. Confusing them leads to misattributed failures — blaming the model for what is really a harness gap, or vice versa. The counterpoint is that the boundaries blur in practice: a skill the agent writes once may be promoted into harness infrastructure, and harness validators shape what the model learns to emit. But as an analytical frame it clarifies where to intervene. This matters because it gives harness engineering a vocabulary for separating the controllable layers of an agentic system.