Agentic Workflows

A support ticket does not usually fail because every message was bad. More often, it fails because one reply arrived at exactly the wrong moment: the bot misunderstood a frustrated customer, repeated a stale answer, missed the escalation point, and then ended the interaction with something sterile enough to pass a benchmark but useless enough to make the customer leave. The average quality may look acceptable. The experience still feels broken. ...

Meetings are useful only when people listen. Anyone who has sat through a badly run management meeting knows the opposite version too: five smart people speak, nobody resolves contradictions, the loudest answer survives, and the final memo becomes a polished blend of everyone’s confusion. Congratulations. You have built an expensive consensus machine. ...

Enterprise agents usually fail in an undramatic way. They do not rebel. They do not suddenly become conscious. They do not announce, with cinematic timing, that humanity has been replaced by a spreadsheet. They simply lose the thread. A research agent searches once, finds something half-relevant, and keeps dragging that result through the rest of the task. A report-writing workflow collects too many fragments and then forgets which ones were actually useful. A coordinator delegates to sub-agents, receives noisy outputs, and treats every message as equally important because, apparently, all context is sacred now. By the final step, the system has not become more intelligent. It has become a very expensive meeting transcript. ...

The problem is not that LLMs cannot write code. It is that they write the wrong kind too confidently. A familiar scene: someone gives an LLM a task, receives a block of code that looks elegant, runs it, and discovers that it has invented an API, misunderstood the library, or solved a neighboring problem with excellent grammar. This is annoying when the target is ordinary Python. It is worse when the target is a specialized framework where the code is supposed to encode logic, constraints, and domain structure. ...

A review meeting has one obvious purpose: prevent one person’s mistake from becoming everyone’s plan. That sounds mundane until we remember how many LLM agent systems are currently designed like a one-person review meeting. The same model attempts the task, explains why it failed, writes advice to itself, stores that advice in memory, and then tries again. It is actor, evaluator, critic, therapist, and occasionally courtroom stenographer. Efficient, yes. Also a little suspicious. ...

Every office has the same tiny tragedy. Someone asks an AI system for a useful draft. The model produces five decent paragraphs and one mildly deranged sentence that sounds as if it escaped from a conference keynote. The user wants to fix only that sentence. Instead, the interface offers the usual bargain: copy everything into another editor and lose the live connection to the conversation, or ask the model to revise the answer and watch it “helpfully” disturb the parts that were already fine. ...

TL;DR for operators Enterprise AI will not become useful merely because someone bolts a chatbot onto a database and calls the result an “agent”. That is theatre with API keys. The paper behind this article proposes something more sober: a blueprint architecture for compound AI systems in the enterprise, where LLMs are important but not sovereign.1 The core idea is that enterprise AI should be built as a distributed system, not as a heroic model prompt. Streams carry data and control messages. Registries expose existing APIs, models, and datasets as searchable assets. Task planners convert user intent into executable workflows. Data planners work out which databases, documents, models, or transformations are needed. Coordinators execute plans while tracking cost, latency, and quality budgets. ...