First Principles for Shipping Agents: Less Conversation, More Tools

Over the course of my recent AI Agent development work, I took a winding path from chasing an “all-powerful digital employee” back to plain “automated scripts.” At first, I tried to solve the Agent’s autonomous learning and management problems once and for all at the architecture level. I even built “department-manager-grade” Agents modeled on a company’s functional org chart, hoping they could understand complex intent and coordinate autonomously like human employees. Reality pushed back fast: today’s large model technology is nowhere near capable of supporting that kind of anthropomorphic management role. In essence, these so-called Agents are still just “intelligent scripts.” This architectural over-design trapped me in a deeply painful loop — I used a high-end model to develop lower-tier models, expecting the lower-tier models to summarize information and report back to me. But the comprehension errors and hallucinations they introduced in those reports forced me to keep pulling the high-end model in to fix bugs that should never have existed. This “reporting to fix the reporting” made management costs far exceed the output, and it taught me a hard lesson: in internal efficiency scenarios, once you lose determinism, even the most elegant architecture is a castle in the air.

This process also led me to a core reflection: the “omnipotent agent” concept may actually be an excellent ToB product strategy, because it gives external customers the premium feel — and the commercial emotional value — of “taking delivery of a digital employee.” But for ToC productivity tools or internal enterprise scenarios that pursue maximum output-per-input, that anthropomorphic complexity is a disaster. Internal scenarios demand the shortest possible path; every extra logic hop is a potential point of failure. This made me re-examine the positioning of heavyweight frameworks like LangGraph: they are by no means a universal silver bullet — they were designed for the rare, specific cases that genuinely require multi-turn state backtracking. For the vast majority of business logic that simply needs to work, forcibly introducing such a heavy framework not only increases the system’s entropy but amounts to serious over-engineering, leaving developers swallowed by the architecture’s own complexity before they ever get to solving the actual problem. Fundamentally, in ToB or internal enterprise domains, what we need is “intelligent work” paired with “precise expression,” whereas ToC scenarios tend to chase “intelligent expression.”

The core of this shift is returning from “simulating a human organization” to “the essence of software engineering.” We no longer need to conceive some omnipotent, once-and-for-all underlying architecture. Instead, we go back to the most pragmatic demand-driven approach: for each concrete pain point, build one corresponding atomic tool, then chain those tools together with deterministic logic. On the interaction side, we also have to admit that “conversation” is often an efficiency burden in internal scenarios. If clicking one script button completes the task instantly, then spending tens of seconds crafting a prompt, waiting for the model to stream out tokens, and digging the result out of a pile of filler text is simply pointless. This return from conversational interfaces to automated actions actually puts the LLM exactly where it belongs: as a “translation plugin” for unstructured data. It is no longer the master of the entire pipeline, just one specific stage along it, responsible for extracting messy raw information into a clean, regular format. Everything after that is handed to traditional, deterministic code — and this kind of “dumb but fast” logic is far more useful than the “slow but clever” alternative.

The deepest lesson of all was putting an end to “essay-writing collaboration” between models. Having a lower-tier model write “work reports” for a high-end model is, from an engineering standpoint, both inefficient and dangerous. A natural-language report is inherently a lossy compression laced with subjective embellishment and hallucination risk. When the high-end model issues instructions based on these half-true summaries, errors get amplified layer by layer, and you end up in a death loop where you and the high-end model keep fixing bugs. The reliable approach is to end this “chat-style reporting” entirely and force lower-tier models to output only structured JSON data. The lower-tier model is no longer a reporter; it is a data cleaner, turning unstructured requests into standard parameter fields. The high-end model doesn’t need to hear a story — it just reads those parameters and precisely invokes the tool library you’ve already built. This shift to “passing data, not chatter” is the only way to end collaborative chaos and close the engineering loop.

Finally, we have to recognize that for internal systems built for efficiency, observability matters far more than the model’s raw intelligence. Rather than obsessing over making an Agent more human-like, put that effort into building end-to-end pipeline monitoring. Internally, a system that “occasionally glitches but lets you see exactly where it glitched” is far more valuable than one that is “usually quite smart but leaves you completely in the dark when something goes wrong.” Wiring up the observability stack means you can trace the flow of every field and the rationale behind every decision in real time, pulling AI development back onto the predictable, maintainable track of software engineering. This transition from “anthropomorphic fantasy” to “engineering monitoring” is the right path to making AI productivity truly land at this stage.