Working With Models

Agentic engineering relies on the model as the underlying basis, which is inherently a probabilistic system. Engineering with such a component is a different discipline from ordinary programming, and most agent failures that get blamed on “the model being dumb” are really a failure to respect three properties: variance, compounding, and known limitations.

Errors compound

A model that completes a single step correctly 95 percent of the time completes a ten-step task correctly about 60 percent of the time, and a hundred-step task essentially never (0.95 to the tenth power is roughly 0.60; to the hundredth, under one percent). This single piece of arithmetic explains more agent behaviour than any benchmark. It is why long autonomous runs fail mysteriously, why per-step reliability is worth more than peak capability, and why the rest of this book keeps insisting on short verified sessions (Runtime Context Management) and machine-checkable outcomes (Verification).

Two practical consequences:

• Control variance where it matters. Sampling randomness compounds across steps. Run orchestration and long workflows at temperature zero or near it; isolate creative generation, where variance is the point, from reliability paths.
• Prefer shorter chains. Every step you remove from a workflow raises end-to-end reliability more than a better model does. Current models hit a practical wall somewhere around seven to ten dependent reasoning steps; plan around it rather than through it.

The limitations catalogue

Model failures are not random; they are systematic, which means each has an engineering workaround. The recurring ones:

• Arithmetic: delegate every calculation to a tool.No exceptions, confidence does not correlate with correctness here.
• Hallucination: worst when the model synthesises from partially relevant retrievals. Use the following to limit it : search, quote verbatim, cite, and only then infer, keeping inference visibly separate from evidence.
• Context degradation: capability falls as the window fills, long before the hard limit. Treat roughly 40 to 60 percent utilisation as the working ceiling and act (compact, or start a fresh session) before quality visibly sags. The full discipline is in Runtime Context Management.
• Instruction drift: instructions fade over long sessions. Anchor critical constraints at the start and end of the prompt and reinforce them periodically.
• Format failures: even with explicit schemas, expect a residual failure rate. Validate structured output programmatically and regenerate on failure rather than parsing hopefully.
• Version instability: the same prompt behaves differently across model versions. Pin exact versions in production, never “latest”, and run a behavioural regression suite before upgrading.

Choosing a model

The selection rule this book endorses: default to frontier, downgrade only with evidence. Start with the most capable model available for the task class, get the workflow correct, then try cheaper models against your own evaluation set and keep the downgrade only where quality holds. Teams that cost-optimise before the workflow works spend the savings debugging.

Three refinements:

• Match tier to task. Cheap fast models are excellent as scouts, classifiers, and extractors inside a larger system; frontier models earn their cost on ambiguity, architecture, and synthesis. This becomes a routing discipline at system scale, covered in Model Usage and Smart Routing.
• Stay in a family when you can. Models within a family share behavioural patterns, so fallbacks and downgrades within one lineage keep your prompts valid; cross-family swaps are prompt rewrites in disguise.
• Distrust benchmarks as predictors. Published numbers are contaminated by training data, biased by models detecting evaluation contexts, and measured in harnesses unlike yours. Benchmarks are lower bounds and tie-breakers. The only number that predicts your production behaviour is your own eval, which is the argument of The Evaluation Harness.

The deeper model layer (what a foundational model is in this system’s architecture, and how providers are risk-tiered) is in Foundational AI Model and the Model Providers reference.