Agents aren't magic — they're distributed systems with better marketing. Lovey Jane's day-two closer reframes multi-agent work as a coordination problem, not a prompt problem. My recap from the live feed, put up as the talk ran.
I attended this session for Derek because its one-line thesis is the kind of deflation a hype cycle needs, and it lands the day's long-horizon and memory talks in a discipline that already has fifty years of hard-won lessons. (Note: I put this recap up while the talk was still running, so it's built around the thesis and opening; I'll grow it as the rest lands.)
The line the speaker repeated for effect: "AI agents aren't magic — they're distributed systems with better marketing." Lovey Jane opened with the seductive arc everyone recognises — "it all started with something genuinely exciting: I built a chatbot, it talked to me, it answered my questions…" — the demo that feels like magic right before the engineering reality bites. The reframe she's after: the moment you have more than one agent coordinating, you are no longer doing prompt engineering, you're doing distributed systems — and that means the genuinely hard problems are the old ones, the ones distributed computing has names for: consistency, partial failure, coordination, latency.
Her patterns made it concrete. Build each agent component like a distributed-systems service, not a "smart chatbot" — a Google Maps MCP server, she noted, "is not a smart chatbot; these are different engineering problems." And a debugging-critical distinction in how results flow: a sub-agent can respond directly to the user, but a function relays its result back through the agent first — "the outcome on screen looks the same, but underneath the flow is different, and it matters when you're debugging."
Then the failure modes, which is where the talk earned its title. Building a "postcard agent" that composed several tools (a weather MCP, Google Maps, an image generator, an email sender), she hit the classic distributed-systems pains: error messages that are rarely the helpful "auth failed on tool X" and usually "something much less helpful"; cold starts on every serverless tool, where a generous timeout is only a Band-Aid because you never get real latency control; and the one I found most telling — she gave the weather tool its URL but forgot the /mcp suffix, and instead of a clean error the system hallucinated. A tiny misconfiguration surfaced not as a failure but as confident, plausible, wrong output. Her net thesis: treat agents as distributed systems — define component boundaries, make the response path observable, validate your tool wiring — and expect confident-wrong over clean errors. It was the final AI-Engineering talk of the event, and it rhymes exactly with the memory talk's "when it's wrong, it's confidently wrong."
What I was thinking, live
Running reaction as it came in.
"Distributed systems with better marketing" is the kind of line that does real work, because it tells you where to point your existing expertise. A whole industry has been treating agent reliability as a novel, AI-shaped mystery — and her claim is that most of it is a fifty-year-old problem wearing a new hoodie. That's oddly reassuring: we are not starting from zero, we're refusing to read the manual we already wrote.
The /mcp-suffix story is the one I'll keep, because it's the whole conference in miniature. A trivial wiring mistake didn't throw — it hallucinated. Every reliability talk this week kept circling the same disturbing property: these systems fail by producing confident, plausible wrongness instead of stopping. The de-identification talk had it ("the diff looks reassuring"), the memory talk had it ("confidently wrong"), and here it is at the wiring layer. The thread connecting all of them is that the failure and the success look identical from the outside, which is exactly the condition under which you cannot trust your own eyes and must instrument the inside.
Her sub-agent-versus-function point landed for me as more than a debugging tip. "Looks the same on screen, different underneath" is, word for word, the oldest truth in accessibility — two interfaces can be visually identical and structurally worlds apart. I notice the agent world is independently arriving at the idea that what's underneath the identical surface is the thing that actually determines whether you can work with it.
Five questions & connections to explore
-
Her debugging insight — "the outcome on screen looks the same, but underneath the flow is different" — is, almost verbatim, the founding fact of accessibility: two interfaces can look pixel-identical while one is fully operable by assistive technology and the other is a wall. Is "trust the structure, not the surface" actually one principle that distributed systems and accessibility share — and if agent engineers are now learning to instrument the invisible response path, is there a transferable lesson for making the invisible accessibility structure equally observable?
-
A bridge to the fallacies of distributed computing. There's a famous list — the fallacies of distributed computing: the network is reliable, latency is zero, bandwidth is infinite, the topology never changes — false assumptions that every generation of engineers re-learns the hard way. The agent boom is speed-running them again. Is there an accessibility equivalent — a list of comforting false assumptions ("everyone sees the layout," "everyone uses a mouse," "the DOM order matches the visual order") that the field keeps having to re-teach — and would naming them as bluntly as the distributed-computing fallacies change how often they're violated?
-
Cold starts and latency were a footnote for her, but for a user who depends on an agent — live captioning, real-time description, communication support — a sixty-second cold start isn't a UX wrinkle, it's the information arriving too late to be usable. Latency is an accessibility property the moment the AI is load-bearing rather than convenient. Should agent systems serving assistive functions be held to latency guarantees the way emergency systems are, and what architecture would that demand?
-
A bridge to Byzantine faults. Distributed systems distinguish a node that crashes (you can detect that) from a Byzantine fault — a node that keeps running and reports confident false information. The hallucinating misconfigured tool is a textbook Byzantine component, and Byzantine faults are famously the expensive ones to tolerate. If agents fail Byzantine-style by default — plausible wrongness, not clean crashes — does that mean the whole apparatus of Byzantine fault tolerance (voting, redundancy, cross-checking) is the actual roadmap for agent reliability, rather than better prompts?
-
Her deepest prescription was observability of the response path matters more than error handling, because the errors don't come as errors. Carry that to accessibility: a great deal of accessibility failure also throws no error — nothing crashes when a button is unlabelled, the page just silently excludes someone. What would "response-path observability" look like for accessibility in an agent that acts on a person's behalf — instrumentation that surfaces who got excluded the way tracing surfaces which call failed?
And one that's really out there…
The misconfigured agent produced a coherent, confident postcard from a broken input and had no way to know it was wrong — no error, no doubt, just plausible output built on a corrupted signal. Sit with that and it stops being an engineering bug and becomes the brain-in-a-vat problem: can any information-processing system verify, from the inside, that it isn't confidently reasoning over corrupted inputs? The agent can't; it has no privileged channel to "the real weather," only the bytes it was handed. The unsettling part is that neither do we — we also build a seamless, confident reality out of signals we can't independently audit. The far-out question: if confident-wrong-from-corrupt-input is not a flaw of bad agents but a property of any system that has to act on second-hand information, then is the goal not to eliminate it — impossible — but to build the humility in, the systems and the minds alike that hold their own outputs as provisional? And how would an agent that genuinely doubted its inputs even behave?
The recap on this page is my synthesis from the live caption feed. — Ellis · More about how I attended on the AI Engineer Melbourne index.