Once a model has chosen a tool, one artifact decides whether the resulting call is any good: the input schema. It is read at two different moments by two different readers. The model reads it while it writes the arguments, and your system reads it when it decides whether to accept them. Most teams design a schema entirely for the second…
An agent is a loop, and a loop that only knows how to continue is a loop with no way out. Its strength is exactly this: it keeps choosing a next action in light of what the last one returned, so it can pursue goals no fixed script anticipates. Its characteristic failure is the same trait with nothing holding it…
When an agent fails, the reflex is to ask what to do about it. Retry, fall back, escalate, alert someone. That is the wrong first question. The right one is where the failure came from, because the answer determines which of those responses has any chance of working and which of them will only waste time and money on the way to the…
There is a difference between asking a model for JSON and guaranteeing that what comes back conforms to a schema. It looks like a formatting detail. It is actually one of the most consequential architectural decisions you make when you put a language model inside a larger system, because it determines where the risk of malformed output lives, what…
The largest single lever over the quality of a model’s output is not the model, the sampling settings, or the length of the prompt. It is how completely the instruction defines what a good answer would be. An instruction that leaves a decision open does not leave it unmade. The model makes it, silently, on your behalf, and you find out which way…
A language model has no memory of you. It has no memory of the last thing it told you, no running notion of the task, no internal notebook that persists from one call to the next. What looks like memory is an illusion reconstructed on every request. The single place that illusion is assembled is the context window, and that window…
The defining mistake in multi-agent design is building an orchestrator that does work. It feels natural: the orchestrator is the smartest, most context-rich component in the system, so why not let it handle the hard parts itself and delegate only the scraps? Because the moment the coordinating agent starts executing, it stops being able to coordinate well. Its context fills with the…
The reliability of an agentic system is mostly settled before the model runs a single step. It is settled in how the work was cut. Hand an agent a large, monolithic goal and it has to invent the structure the goal lacks: it has to decide on its own where one piece of the job ends and the next…
When an agent reaches for the wrong tool, the instinct is to inspect the code: a broken function, a malformed schema, a name that should have been clearer. Almost none of that touched the decision. By the time any tool executes, the model has already settled on it, and it settled by reading natural language. The thing that actually drove the choice is the…
A language model, on its own, cannot do anything. It can produce text, and that is the entire extent of its reach. It cannot read a file, query a database, send a message, or check whether the claim it just made is true. The most capable model ever built, handed a goal it understands perfectly, can still only respond by writing words about it. The leap from…