AI Engineer World's Fair 2026
Why We Killed Our Multi-Agent Pipeline — Subbiah Sethuraman and Abhilash Asokan, ZS Associates
Read the talk
Why We Killed Our Multi-Agent Pipeline
A pharmaceutical analytics pipeline found the right cause but recommended the wrong action. The redesign separated statistical detection from investigation and used a domain graph to constrain the search.
From a talk by Subbiah Sethuraman and Abhilash Asokan
Before you start: Familiarity with language-model agents, database queries and basic graph concepts will help; the pharmaceutical workflow is introduced in the article.
Why are prescriptions falling?
Why are doctors writing fewer prescriptions for a drug, and what should the company do about it? That is a commercial analytics question: after drug discovery and clinical trials, the work shifts to getting treatments to patients. At ZS, Subbiah Sethuraman, who introduces himself as head of AI Engineering, and Abhilash Asokan, Director of AI Engineering, work in a setting that includes brand performance across markets, sales-rep engagement, patient adoption and therapy switches.
An analyst moves through four connected steps:
- Signal: Detect a change, such as a drop in prescriptions.
- Why: Investigate whether a competitor entered the market, payer coverage declined or sales reps failed to communicate the drug’s benefits.
- Action: Choose an intervention that addresses the cause—for example, increase rep coverage if a region is underserved.
- Outlook: Estimate how the intervention could affect brand or sales performance.
The steps form a causal chain. The action depends on the explanation, and the outlook depends on the action.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Turning the workflow into agents
ZS initially translated this human workflow into specialized agents. An orchestrator connected the stages, while the explanation step split into two distinct jobs: locating the decline and identifying its driver.
| Agent | Responsibility |
|---|---|
| Signal detection | Identify changes worth investigating |
| Source localization | Locate a national decline within a region or payer |
| Driver attribution | Identify why performance declined |
| Synthesis | Propose an action and its outlook |
| Orchestrator | Connect the agents |
This division mirrored the analyst’s sequence, but it also divided responsibility for understanding the result.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The right cause led to the wrong action
The pipeline produced an information packet with a signal, a reason, an action and an outlook. In Sethuraman’s illustrative packet, brand prescriptions fall 18% in a territory over roughly four weeks. The explanation identifies a payer coverage change that makes the drug more expensive for patients. Yet the recommended action is to send more sales reps to doctors, followed by a forecast of improved sales.
The packet looks complete until its parts are read together. More rep visits do not address the identified affordability problem. Because the action fails to address the cause, the recovery outlook loses its foundation too. Locally plausible outputs did not produce a coherent recommendation. No single agent owned the complete connection between evidence, cause, intervention and expected result.
Sethuraman attributes the failure to how the work was divided, rather than to the language model itself. Three architectural problems emerged in sequence:
- Unnecessary model judgment: A sales drop can be detected with statistical methods; a language model need not decide whether it exists.
- Context lost at handoffs: Driver attribution found the coverage problem, but synthesis failed to preserve its significance for patient affordability.
- Missing shared domain knowledge: The agents lacked a common understanding of business metrics, their relationships and why they rise or fall. Even a metric such as
TRx, total prescriptions, needs that context to be useful in an investigation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Observe the investigation before redesigning it
The first instinct was to redesign the topology, skills, tools, handoffs or schemas between agents. Instead, Asokan’s team opened an empty directory, ran Claude Code with Bash and database access, supplied an actual signal they had already identified, and watched how it investigated. The experiment began with the work itself rather than a new arrangement of agent roles.
The shell entry point for that kind of observation is small. Database access must already be available in the environment; the prompt gives the agent an investigation rather than asking it to discover a signal:
bash
mkdir pharma-investigation
cd pharma-investigation
claude 'Investigate the supplied prescription-decline signal using the available database. Examine where the decline is concentrated and which evidence supports or contradicts possible causes.'
The important output of this exercise is the sequence of operations the agent chooses, which can reveal where a dedicated tool or a deterministic process belongs.
Signal detection was the first responsibility to move out of the agent. The team had observed inconsistent behavior: sometimes the agent applied statistical methods, sometimes it barely inspected the data, and sometimes it confused noise with a signal. They replaced that judgment with an automated statistical workflow.
The new pipeline scans each KPI for anomalies and broken trends, applying guardrails, thresholds and prioritization before any investigator starts. It places selected signals on a queue; arrival of a signal wakes the agent. The agent investigates a detected change; it does not decide whether the change qualifies as a signal. This boundary gives the investigation a defined starting point.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Keep parallel work, centralize judgment
To address incoherent recommendations, the team consolidated the investigation around one main agent. Observing Claude Code also exposed repeated operations—writing a function and querying the database—that they packaged into a tool. The redesign reduced the number of reasoning handoffs without requiring all work to run serially.
Claude Code sometimes launched subagents dynamically for focused tasks, and ZS retained that pattern. A main investigator could delegate a question such as whether rep activity had changed in a particular region, then use the returned findings in the larger investigation. Subagents may reason within their tasks; the architectural rule is that the main agent retains final judgment about how their findings fit together.
That produced a lighter architecture, but consolidation alone did not supply business knowledge. A single agent could still misunderstand the relationships among entities and metrics. The remaining problem required an explicit domain model.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Make domain relationships explicit
The agent had been inspecting database tables and inferring relationships from them. Asokan describes that approach as difficult to scale and prone to producing relationships that did not exist in the data. ZS brought in its commercial analytics domain experts to map the domain into a knowledge graph.
The graph connects geographic entities to payers and accounts, connects those entities to brands, and connects brands and payers to KPIs. It also represents relationships among primary, secondary and tertiary KPIs, including which metrics can drive others. This supplies more than entity definitions: it gives the investigator a structured account of which relationships deserve examination.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Use the graph to bound the investigation
The graph’s operational role is a control plane: it determines what the agent can examine, which paths it can take and which hypotheses it can evaluate. It is not simply another source from which to retrieve facts.
Consider a national decline in TRx. The first question is where the decline is concentrated. It might be in a region, a territory or a combination involving a territory, payer or account. Exploring every combination creates a large search space. The graph guides source localization through the relevant dimensions.
Once the agent narrows down the location, it investigates why the decline occurred. KPI relationships provide the next candidate explanations: which metric could be driving the observed change? In Asokan’s design, each edge is a hypothesis the agent can evaluate, and the investigation stays within that graph-defined surface. An edge supplies a candidate explanation, not evidence that the explanation is true.
The resulting loop ties graph navigation to the underlying data:
- Start with an entity and inspect its graph neighborhood.
- Treat the neighboring edges as candidate hypotheses.
- Query the original data and examine the actual numbers.
- Reason about whether the evidence supports or contradicts each hypothesis.
- Follow a supported relationship and repeat the process.
- Stop when the available hypotheses are exhausted or a root cause is found.
The graph bounds the search, while the data determines whether a proposed path deserves further investigation.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
An architecture derived from the work
Asokan reports that investigations taking 50-plus turns and substantial tokens could produce analysis in roughly 20–30 minutes that might take an analyst three or four weeks. This is an approximate comparison from their pharmaceutical commercial analytics work; the talk supplies no evaluation dataset, quality criterion or cost breakdown. The shorter turnaround still involved a long investigative loop.
The closing design principle is to let the observed work shape the architecture instead of imposing the human workflow’s boundaries on it. In this system, deterministic operations establish the signal, and agentic work investigates it. One agent owns the reasoning end to end while invoking subagents, tools or skills for particular tasks. The graph then governs navigation and the next investigative decision. That places responsibility for the complete explanation in one agent while keeping its search grounded in explicit domain relationships.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Current guidance for delegating focused tasks to Claude Code subagents with separate contexts, tool access, and permissions.
Further reading
- Understanding formulary tiersDocumentation
Medicare’s explanation of drug formularies, tier levels, and their relationship to patient copayments.
Read the transcript and explore slides
Loading transcript and slides…