Engineering Practice

Attachment download: Agent Interview Questions.pdf — handy for printing or offline reading Why Would You Need Multiple Agents # An opening question to separate people who have “read the articles” from people who have “actually built one”. The bad answer: “Multi-agent enables parallel processing, which improves system throughput and robustness.” Every word of that is correct, but if you follow up with “so after splitting into two agents, did throughput actually double?”, they stall. The reality: inter-agent communication has overhead, coordination has complexity, and after the split total throughput may well drop. Adding agents is not like adding CPU cores.

Packing multiple probabilistically sampled large language model instances into a single codebase or production pipeline is, fundamentally, constructing a distributed system over an unreliable network using stochastic state machines. The axiomatic foundations of classical distributed computing—deterministic state transitions, reproducible failure modes, Byzantine fault tolerance, and atomic commits—collapse almost entirely when applied to modern generative models. Tech social media abounds with utopian product demos: one agent searches documentation, another implements business logic, a third writes unit tests, and a fourth conducts code review, while an orchestrator agent glides over the process like an infallible engineering manager. Yet anyone who has pushed such topologies into a 500,000-line monolithic repository or a high-concurrency production environment knows the reality: the system rapidly degenerates into distributed chaos. Unsynchronized modifications cause silent overwrites and split-brain states; non-deterministic rollouts cause cognitive divergence; token consumption explodes in a positive-feedback avalanche; and parent and child processes lock each other in cognitive livelocks.