Peter’s July: Stop Chasing Model Rankings. Build an Agent System.

Peter Steinberger’s July posts can look scattered: GPT 5.6, Fable, parallel QA with Codex, Claude CLI, workflow graphs, and product details from OpenClaw. Read one by one, they invite the wrong question: which model does he like most? Read as a body of work, they argue almost the opposite. Models are increasingly replaceable parts. The durable advantage is the system that turns those parts into dependable delivery.

This is not a model-ranking article. Peter’s posts are field notes from particular products, repositories, and release cycles—not a universal evaluation suite. Their value is not that they make a purchasing choice for every team. They reveal a better order of judgment: first ask whether a task was completed reliably; only then ask whether a model is leading. Speed, quality, cost, recoverability, and verifiability all belong in the answer.

One sentence can organize his July practice: do not treat an agent as a better chat partner; treat it as an action-taking production system. The model is its reasoning engine. The harness defines its working environment. The loop determines how it learns from results. The graph coordinates multiple units of work. Verification tells the system when it deserves trust.

First: stop searching for the universally strongest model; define the role the task requires. Peter reported that moving ClawSweeper code review to Terra High improved speed and reduced cost with little quality loss. Those numbers belong to a specific workload and configuration, not a leaderboard. But the evaluation method travels well: run comparable real tasks through the same flow, then record completion time, acceptance rate, rework, and unit cost. Compare delivery, not a composite score.

That is also the right way to read his different uses of GPT 5.6, Fable, and Codex. GPT 5.6 may improve understanding and expression in a complicated collaboration; Fable can advise on design direction; Codex can carry high-throughput execution. This is not a permanent intelligence hierarchy. It is role design. A single model asked to plan, implement, operate tools, and certify its own work is expensive and difficult to tune. Clear responsibilities make a system replaceable where it needs to be.

His design advice makes the point concrete. When exploring visual design with GPT, he suggested generating an image first and iterating from it. The important move is not simply image generation. It turns an ambiguous aesthetic request into an inspectable intermediate artefact. “Make it distinctive” is hard to critique in text; an image can be reviewed, changed, and inherited by the next step. For agents, a good intermediate artefact is often more valuable than a longer prompt.

Benchmarks can filter candidates, but they cannot finish integration for you. Peter observed that API implementations may handle reasoning tokens differently, already enough to distort a comparison. The model, serving layer, tool protocol, context trimming, system instruction, and sampling settings all participate in an agent run. A surprising number of claims that model A beat model B are actually comparisons between two different systems.

Second: the harness is the agent’s working world. Peter’s ongoing effort to build a ‘dream harness’ carries a straightforward lesson. Models will change and the surrounding discourse will swing; the assets that accumulate are task environments. What files can the agent see? What tools can it invoke? Where do permissions end? How are project rules retrieved? What logs arrive after a failure? How is work accepted, saved, and recovered? Those are the conditions in which an agent actually works.

Stronger models make this engineering more important, not less. A weaker model often makes a local mistake. A stronger one can travel farther—and can therefore amplify vague boundaries, broad permissions, or unreliable test signals across a larger surface. Better capability is not a reason to relax control. It is a reason to turn manual oversight into explicit system constraints.

The loop is that constraint operating over time. It is not ‘try again.’ Each action must consume new evidence: inspect a failing test, make a change, verify behaviour; classify a timeout as a retry, a new path, or an escalation. Peter’s small suggestion to restart Codex when a process is stuck carries a serious lesson. More explanation does not necessarily change system state. Restarting, rebuilding context, or changing the tool path can be the real correction.

A good loop is defined by knowing when to stop. It needs checkpoints, failure classes, retry budgets, and escalation thresholds. It must distinguish evidence that supports completion from a run that should begin again, or a risk that requires a human decision. Autonomy is not continuing forever. It is continuing when evidence permits and stopping when risk rises.

A graph handles the larger organisation of work. Peter amplified a practical idea: sketch a workflow, then ask Codex to implement it as a script that takes input and runs the flow. The value is not a prettier diagram. The graph forces implicit rules into view: where input starts, which work can happen in parallel, where human approval waits, where failure returns, and how outputs converge. Drawing the flow before automating it is often more useful than adding another agent.

Harness, loop, and graph are not competing buzzwords. A harness answers where an agent works. A loop answers how it corrects from consequences. A graph answers how work branches, coordinates, and converges. A graph node can be an agent with a complete harness, and that node can run several loops. The design question is never which label to adopt; it is who carries uncertainty and what guarantees certainty.

Third: the practical goal is not ‘more agents.’ It is replaceable execution and independent verification. Peter noted that an agent can call Codex, Claude, or another CLI directly; he also described adding a direct Claude CLI path to OpenClaw to solve a real execution problem. The common principle is to avoid locking the system to one SDK, tool route, or model provider. A CLI is a composable execution interface, not just a chat window for manual use.

The collaboration pattern can stay simple. A lead agent holds the objective and state. Specialist tasks search, implement, test, or review. An independent verifier looks for disconfirming evidence. In Peter’s use of Codex for large-scale parallel QA, the standard is not whether an agent can produce a plausible patch. It is whether it understands intent, finds complex behavioural issues, and remains honest in a long process. Implementation output is only a candidate answer; tests, QA, and human sampling supply distinct forms of disproof.

That is why giving unconstrained generation and proof to the same role is so risky: it often produces a coherent story that nobody has actually tested. Peter’s example of one agent reporting a bug and another fixing it the same evening only becomes valuable with an engineering contract around it. The defect must be describable, verification runnable, permissions bounded, changes reviewable, and rollback possible. Without those conditions, agent-to-agent work merely moves errors faster.

Product experience belongs inside this system, too. Once work spans minutes, tools, and models, users need to see what happened, which context was used, where cost accumulated, where failure occurred, and how they can intervene or recover. A clever but opaque agent makes people anxious spectators. An agent that exposes state, evidence, and takeover paths starts to earn delegation.

The operating model is concise: choose models on real tasks, not a single board; split planning, execution, and verification into replaceable roles; make files, tools, permissions, logs, and acceptance criteria part of the harness; ensure every loop consumes fresh evidence and has a stop rule; draw parallelism, approval, rollback, and convergence before handing the flow to agents; expose history, provenance, cost, and recovery in the product.

So Peter’s July should not be reduced to ‘GPT 5.6 is better’ or ‘Fable is strong.’ Frontier rankings and benchmarks will keep moving. The lasting asset is an agent system that can host different models, recover from failure, make complicated collaboration explicit, and let people understand, audit, or take over at any point. Models will become better engines. Reliable arrival still depends on the vehicle’s structure, instruments, and brakes.