Multi-agent-systems

A single agent failing is an incident. One specialist among nine drifting is not an incident, it is a slow change in a number, and the system keeps producing confident decisions throughout. The three properties that determine whether a panel actually contains a bad member, why shared infrastructure makes independent specialists fail together, and why architectural containment beats behavioural containment every time.

The orchestrator diagram is clean, and every arrow on it is a billed network call to a model. A panel multiplies cost and floors latency at its slowest member; a pipeline adds latency and compounds error. Budgeting fan-out per specialist across three levers - model tier, call frequency, and cacheability - and the cases where the cheapest correct answer is not to fan out at all.

"Give it more context" is the default answer to every memory problem in an agentic system, and it is not a memory architecture. Cost grows with length, relevance decays, and nothing survives the session. Separating the four stores that get collapsed into the word memory - working context, the ledger, derived state, and retrieval - and what each one is actually for.

Hardcoding one model provider into agent logic is the same mistake as hardcoding one database vendor into business logic, and it is newer, so fewer people have been burned by it yet. What a model abstraction should hide, what it must not hide, why per-specialist model selection beats one default, and the gap between a swap being a config change and a swap being safe.

Ask an agent why it decided something and it will tell you, fluently, and the answer is worthless as evidence. It describes a system in its current state, not the one that made the decision. What has to be captured at decision time instead, why corrections belong as new events rather than edits, and why the record is not a debugging convenience but the precondition for everything else in an agentic system.

Giving an agent a tool sounds like a scoping decision, and usually is not. A tool expressive enough to do everything is expressive enough to do the one thing you did not want, and no amount of instruction closes that gap. The case for bounding what an agent can express rather than checking what it produced, why bounded form does not imply bounded effect, and how to bound an agent whose output is prose.

Tests check whether code does what it was written to do. They have nothing to say about whether a judgement was any good. Scoring a non-deterministic system means comparing recorded predictions against observed outcomes, and most systems already emit both without recognising that they have the raw material for an eval harness. Why calibration matters more than accuracy, what bucketing is for, and the two problems - outcome lag and correlated error - that make this harder than it looks.

Most agentic systems ship with autonomy as a global switch: a human approves everything, or the system acts alone. Both settings are wrong, because reliability is never uniform across the decisions a system makes. The case for granting autonomy per decision type, what "earned" has to mean in numbers, why the demotion path matters more than the promotion path, and the decisions that should never be automated at all.

The first structural decision in any agentic system is how many agents there are and what each one owns. One capable agent given the whole problem is the fastest route to a working demo and the slowest route to a system you can improve. The case for splitting into narrow specialists under a thin orchestrator, the two shapes that split takes, the contract that holds it together, and the real bill for paying it.