AI log, day 12: what changes when more than one model is involved

Day 11 ended with a debt of its own: everything from cost (day 07) to trust boundaries (day 09) to trajectory evals (day 11 itself) was implicitly written about one model making decisions in isolation. That assumption stops holding the moment a second model enters the picture, whether that’s a multi-agent handoff or a single agent whose tool call quietly resolves to another model behind an API. I spent this entry finding out how much of the first eleven days survives that change intact, and how much doesn’t.

Two different ways a second model shows up

There are two shapes worth telling apart, because they break differently. The first is a handoff: model A finishes its work and hands the result to model B as input, the way a planning step might hand a draft to a review step, or one agent in a pipeline hands its output to the next agent in the chain. The second is a nested call: model A’s tool use resolves to an API that happens to be another model, the way a “summarize this document” tool might just be a second, smaller model running underneath, invisible to model A’s own reasoning about what it just did.

Both put two models in the same trajectory. Neither shows up as “two models” in the trace unless you go looking, which is exactly the problem.

The handoff problem: ground truth with no warning label

Day 09’s whole argument was that a model can’t reliably tell the difference between an instruction and data, so anything it reads has to be treated as untrusted content, not as an instruction source. A handoff between two models breaks that discipline in a specific, quiet way: model B doesn’t see model A’s output as “untrusted content from another model,” it sees it the same way it sees a retrieved document or a tool result, as something to reason over and probably trust. If model A hallucinated a detail, hedged badly, or just misformatted its own output, model B has no signal that anything is wrong. It inherits the mistake as a premise, not as a claim to verify, and everything model B produces downstream is now built on a foundation nobody actually checked.

This is worse than a single model hallucinating on its own, because a single model’s mistake at least has one obvious point of failure to inspect. A two-model chain’s mistake can originate in model A and only become visible in model B’s very different, very confident-sounding output three steps later, by which point the actual error is buried in an intermediate hop nobody’s looking at.

The cost and latency problem: hops don’t parallelize for free

Day 07’s argument was that an agent loop re-sends its growing context every turn, which trends toward quadratic cost as the loop gets longer. A model-to-model hop adds a second, independent version of that same problem: every hop is its own billed call, with its own context, and if model A’s tool use is “ask model B,” that’s not a cheap function call, it’s a full request with its own latency floor stacked on top of model A’s own thinking time. Two sequential model calls aren’t twice the latency of one, they’re worse than twice, because the second call can’t start until the first one’s full output exists, and a lot of real pipelines have model B call model C, sequentially, deeper than anyone planned for when the pipeline was three lines of glue code between “the AI part” and “the other AI part.”

Failures compound the same way costs do. A timeout or malformed response from model B isn’t a flaky HTTP call you retry and move on from, because retrying it means re-running whatever expensive context model A already built to get to that point. Treating a model-behind-an-API failure the same way you’d treat a database connection blip undercounts what a retry actually costs here.

What day 11’s checks have to grow to cover

Day 11 landed on trajectory-level checks: bound the tool-call count, gate destructive calls behind confirmation, catch stuck loops, confirm the expected tool actually got used. None of those checks currently know that some “tool calls” are actually calls into a second model with its own failure modes, its own cost, and its own chance of quietly being wrong in a way that looks like ground truth to whatever called it. The fix isn’t a new eval framework, it’s widening what a trajectory check treats as a hop worth scrutinizing: a call to another model needs the same budget accounting as any other tool call, and its output needs the same “untrusted until verified” treatment day 09 already argued for external data, not the implicit trust a same-process function return would get.

The trust boundary from day 09 doesn’t stay put once you add a second model. It multiplies, once per model boundary the data actually crosses, and nothing about the first eleven days’ framing made that multiplication visible.

What’s next

No fixed day 13 topic yet, same as day 10 and day 11 both left it. The open thread I’m most drawn to right now is what a guardrail actually needs to communicate when it stops an action, since day 09’s “least privilege, confirm before anything destructive” argument has mostly been about whether to block, not about what blocking should feel like to whoever’s on the other end of it.