One Agent Is a Bottleneck: When Genomics QA Finally Went Multi-Agent

Databases are where elegant AI demos go to develop a limp.

A model can sound fluent about biology, medicine, finance, or law. Then someone asks a question that requires the latest record from a specialized database, a second lookup from another source, a formatted API call, a large HTML response, and a final answer that does not forget the original question halfway through. Suddenly the “AI assistant” becomes a very expensive intern copying URLs into the wrong field.

That is the real setting of the paper From Single to Multi-Agent Reasoning: Advancing GeneGPT for Genomics QA.¹ It is not simply another “multi-agent beats single-agent” story. That version is too easy, and therefore not very useful. The sharper point is that GeneGPT’s single-agent architecture had become a bottleneck because one model was asked to do too many operationally different jobs at once: understand the question, choose the database, format the API call, parse the response, preserve the original intent, and synthesize the answer.

GenomAgent, the system proposed in the paper, wins by refusing that job description.

The failure was not that GeneGPT was weak; it was that GeneGPT was overloaded

GeneGPT mattered because it moved genomic question answering beyond static model memory. Instead of expecting a language model to already “know” biomedical facts, it connected the model to domain tools such as NCBI E-utilities and BLAST. The model generated API calls, retrieved structured biomedical information, and used the results to answer questions from the GeneTuring benchmark.

That was a serious step forward. It also created a fragile operating model.

In GeneGPT, a single model loop carries most of the burden. The prompt contains instructions, API documentation, examples, the user question, retrieved results, and continuing generation. A special stop-token mechanism is used to detect when the model has produced an API call. The system extracts the URL, calls the API, appends the result to the prompt, and asks the model to continue.

This design works when every moving part behaves politely. The problem is that real tools do not behave politely. API responses can be too large. HTML can be structurally awkward. Model outputs can fail to match the expected URL format. A database may not contain the answer. Retrieved text may drown the question that triggered the retrieval in the first place.

The authors’ reproduction of GeneGPT is useful precisely because it shows the failure modes before presenting the new architecture. They reimplemented GeneGPT using newer tooling and models, including GPT-4o-mini and LangGraph for the ReAct-style configuration, because the original model choices had become deprecated. This reproduction is not just a ceremonial baseline. It is a diagnostic test.

The diagnostic result is clean enough to be operationally interesting. The authors categorize the reproduced system’s mistakes into three types:

This is the first useful mechanism in the paper: the bottleneck is not “the LLM is not smart enough.” The bottleneck is job mixing. One agent is being asked to be router, API engineer, parser, long-context reader, and judge. Of course it eventually drops something. The surprise is not that it fails. The surprise is that we keep acting surprised.

GenomAgent fixes the workflow by separating jobs, not by worshipping “many agents”

The lazy reading of the paper is: multi-agent systems are better than single-agent systems. That is not what the paper proves, and it is not the lesson businesses should take from it.

The mechanism is more specific. GenomAgent decomposes the genomic QA workflow into specialized agents, each responsible for a narrower operational task. The architecture includes a Task Detection Agent, an MCP Agent for multi-source coordination, a Response Handler Agent, a Feature Extractor Agent, Code Writer and Code Executor agents, and a Final Decision Agent.

The important part is not the number of agents. The important part is the division of labor.

This is why the paper is better read mechanism-first. The architecture is not decorative modularity. Each module corresponds to an observed failure mode.

The Task Detection Agent routes the query. The multi-source coordination layer dispatches relevant database requests in parallel. The Response Handler decides whether the returned material is JSON or HTML and processes it accordingly. Large JSON responses can be summarized through a Feature Extractor. HTML responses can trigger generated extraction code, which is then executed and cached for reuse. Finally, the Final Decision Agent synthesizes answers across sources.

That workflow sounds less magical than a single all-knowing model. Good. Magic is hard to debug.

The main evidence is the performance-cost result, not the agent diagram

The paper evaluates GenomAgent on nine tasks from the GeneTuring benchmark, grouped into nomenclature, genomic location, functional analysis, and sequence alignment. The headline result is that GenomAgent reaches an average score of 0.93, compared with 0.83 for the best GeneGPT baseline reported in the comparison. Total cost falls from $10.06 for GeneGPT Slim to $2.11 for GenomAgent, a 79% reduction.

That combination matters because it pushes against a common assumption: multi-agent systems are assumed to be more expensive because they involve more calls, more coordination, and more moving pieces. Sometimes that assumption is correct. Anyone who has watched agents debate the obvious for ten turns has seen computational theater with invoices attached.

Here, however, specialization appears to reduce waste. GenomAgent does not simply ask one long-context model to swallow everything. It routes work, extracts relevant evidence, caches reusable code, and synthesizes only after the upstream mess has been partially organized.

The reported results are:

The strongest category-level gain is sequence alignment: 0.85 for GenomAgent versus 0.66 for GeneGPT Slim, reported as a 28.8% improvement. That is the category where single-agent tool use is most likely to suffer from long responses, cross-source ambiguity, and extraction burden. In other words, the largest improvement appears where the mechanism should matter most.

That alignment between mechanism and result is more persuasive than the average score alone.

The reproduction study is a warning about brittle AI infrastructure

The reproduction section deserves more attention than it will probably receive.

Many AI papers treat replication as a formality. Here, it functions as a quiet audit of architectural brittleness. The original GeneGPT depended on model choices and orchestration assumptions that aged quickly. The authors note that original models such as code-davinci-002 and GPT-3.5-turbo-16k had been deprecated, so the reproduction required newer alternatives.

That is not a minor implementation inconvenience. It is exactly what enterprises face when they build workflow automation around a model behavior rather than around a robust system boundary.

In the reproduced turbo setting, performance degradation is linked to stop-token incompatibility with general-purpose LLMs. The model does not reliably produce the API-call format expected by the pipeline, causing loops or failed retrieval. In the reproduced lang setting, performance improves in several tasks, but the dominant problems shift toward incomplete source coverage and context loss.

This distinction matters.

A parsing failure is a control problem. A coverage failure is an information architecture problem. Context loss is a representation and workflow problem. These are different problems, so treating them all as “prompt quality” is managerial laziness wearing a hoodie.

The paper is strongest when read as a systems diagnosis. The GenomAgent result matters because the reproduction surfaces the practical reasons why a predecessor architecture breaks.

Why lower cost is plausible despite more moving parts

The cost result is the part that many readers will read too quickly.

A multi-agent system can be more expensive. More agents can mean more prompts, more intermediate messages, more coordination overhead, and more opportunities for verbose nonsense. The paper does not prove a universal law that “multi-agent equals cheaper.” It shows that, in this workflow, a carefully specialized architecture can cost less because it avoids sending the wrong material to the wrong reasoning step.

The cost reduction is plausible for four reasons.

First, routing limits unnecessary work. If the system can classify task intent early, it does not need to push every query through the same oversized prompt-and-tool loop.

Second, extraction reduces context waste. Large API responses are not automatically useful. They are often noisy containers around a small amount of evidence. A Response Handler and Feature Extractor can shrink the input before synthesis.

Third, code generation can be amortized. When the Code Writer creates extraction scripts for complex HTML responses and those scripts are cached, future processing can reuse structure instead of rediscovering it.

Fourth, parallelism can reduce sequential drag. Sequential tool use forces each step to wait and can expand prompts repeatedly. Parallel query coordination lets the system gather evidence more cleanly before final synthesis.

This is the business-relevant version of the result: cost efficiency did not come from making the model cheaper in isolation. It came from reducing architectural waste around the model.

That distinction is important because many companies still treat LLM cost as a unit-price problem. They compare model prices, trim prompts, and celebrate a smaller bill while the workflow remains fragile. The paper points toward a different lever: organize the work better.

The business lesson is expert workflow design, not genomics trivia

Genomics is the domain. Expert data access is the transferable problem.

Many business workflows look suspiciously like genomic QA. A user asks a natural-language question. The answer lives across several specialized systems. Some sources are structured; some are semi-structured; some are updated constantly; some are incomplete. The system must retrieve evidence, reconcile conflicts, and produce an answer with enough discipline to be useful.

This pattern appears in biomedical research desks, regulatory intelligence, patent search, clinical knowledge support, legal due diligence, financial compliance, insurance operations, procurement, and enterprise knowledge management.

The operational lesson is straightforward:

The lesson is not that every company should build seven agents. The lesson is that expert QA systems need explicit workflow architecture. The system should know when it is routing, retrieving, extracting, validating, synthesizing, or answering. Those are different verbs. Systems that confuse them tend to become expensive and hard to trust.

What the paper directly shows, what we can infer, and what remains uncertain

The paper directly shows that GenomAgent outperforms GeneGPT baselines on the selected nine GeneTuring tasks under the authors’ evaluation protocol. It also directly reports a lower total computational cost across those tasks: $2.11 for GenomAgent versus $10.06 for the best-performing GeneGPT baseline in the comparison.

The paper also directly identifies three bottlenecks from the GeneGPT reproduction: incomplete data coverage, stop-token/API parsing failures, and context loss. These are not abstract criticisms. They arise from implementation behavior observed during the reproduction.

Cognaptus can reasonably infer that modular agent design is valuable when domain QA requires multiple sources, heterogeneous response formats, large retrieved outputs, and reusable extraction logic. This is a systems inference, not a universal theorem. The strongest business implication is for workflows where the bottleneck is not natural-language fluency but controlled interaction with messy tools.

What remains uncertain is causality inside the architecture. The paper itself acknowledges that the 12% average improvement cannot be cleanly attributed to specific architectural choices without systematic ablation analysis. We do not yet know how much of the gain comes from multi-source retrieval, how much from response handling, how much from cached code extraction, and how much from scoring protocol or implementation differences.

That boundary matters. Without ablations, GenomAgent is best interpreted as a successful integrated system, not as proof that every component is equally necessary.

The evaluation details are not decorative; they affect interpretation

The paper’s evaluation protocol includes task-specific metrics. Nomenclature and genomic location tasks use exact matching. Gene-disease associations use recall based on exact gene matches. Cross-species DNA alignment uses vocabulary mapping, such as mapping Latin species names to common names. Human genome alignment uses partial scoring, awarding credit for partially correct chromosome and position information.

The authors also state that expanded vocabulary mappings and enhanced partial scoring were applied to both GeneGPT and GenomAgent to ensure fair comparison.

That is a reasonable choice, but it should be read correctly. These evaluation adjustments are not a second thesis. They are an implementation detail and fairness boundary. They make the benchmark more compatible with updated annotations and partially correct sequence answers, but they also mean the reported numbers should be understood under this evaluation protocol.

This is especially relevant for sequence alignment, where GenomAgent shows the largest improvement. The gain is still meaningful, but readers should avoid treating the exact percentage as a timeless property of the architecture. It is a measured result under a specific benchmark, task subset, and scoring design.

In business terms: the direction of improvement is more transferable than the exact number.

The quiet shift is from prompt engineering to operating systems for agents

The paper’s most useful contribution is not that it adds more agents to a diagram. The useful contribution is that it treats tool-using LLMs as workflow systems.

That shift changes how we should evaluate enterprise AI.

A weak evaluation asks: “Can the model answer the question?”

A better evaluation asks:

1. Did the system route the question correctly?
2. Did it choose the right sources?
3. Did it detect when one source was incomplete?
4. Did it parse each response format appropriately?
5. Did it preserve the original user intent after retrieval?
6. Did it reduce irrelevant context before synthesis?
7. Did it produce an answer whose evidence path can be inspected?
8. Did the cost scale with task difficulty rather than with prompt chaos?

GenomAgent is interesting because it moves toward that second evaluation style. It is not simply a better answer generator. It is a more organized answer-production process.

That matters because the future of AI deployment in expert domains will not be decided by demos where a model writes a plausible paragraph. It will be decided by whether systems can survive changing tools, incomplete databases, large responses, and evaluation rules that punish vague confidence.

One agent can still be useful for simple tasks. The paper even suggests future hybrid approaches that combine single-agent efficiency for simple queries with multi-agent coordination for complex tasks. That is the right instinct. Multi-agent architecture should be invoked because the workflow needs decomposition, not because “agent” looks nice in a product deck.

Still, the direction is clear. As expert workflows become more tool-heavy, the bottleneck moves from language generation to coordination.

GeneGPT showed that an LLM could reach into biomedical databases. GenomAgent shows that reaching is not enough. The system also has to route, parse, compress, reconcile, and decide.

One agent is a bottleneck when the job is no longer one job.

Cognaptus: Automate the Present, Incubate the Future.