When 11/11 Cases Still Aren't Enough: Building an Outbreak Investigation Agent with FalkorDB

Eleven people fell ill, two ingredients appeared in all eleven cases, and two suppliers were neck and neck. Case counts narrowed the search but couldn't tell us which lot was responsible. Breaking the tie required evidence independent of exposure counts—and a clear path showing how the investigation reached its conclusion. That was the challenge of the BatchZero project, a Graph Hacks 2026 entry built for the FalkorDB track.

The outbreak and Port Meridian are fictional. BatchZero uses synthetic data to demonstrate an investigation workflow; it is not a real public health system.

Why model outbreak investigations as a graph?

Epidemiological investigation is fundamentally about tracing relationship chains: Person → Case → Exposure → Menu item → Ingredient → Lot → Supplier → Shipment. We need to ask not only "What do these cases have in common?" but also "Which facilities used this ingredient? Which lots did they receive? Where did those lots go? And what evidence ultimately pins down the source?"

A graph database lets us follow connection paths directly. In BatchZero, cases, supply chain data, hypotheses, evidence, agent sessions, and tool-call records all live in FalkorDB. A shared-ingredient query, for example, starts from cases, passes through people and exposure events, and reaches menu items and ingredients:

MATCH (c:Case)<-[:HAS_CASE]-(p:Person)-[:PARTICIPATED]->(e:ExposureEvent)
      -[:INVOLVES]->(m:MenuItem)-[:CONTAINS]->(i:Ingredient)
WHERE c.case_id IN $case_ids
RETURN i.name AS ingredient,
       count(DISTINCT c) AS cases
ORDER BY cases DESC, ingredient

This traversal gives a picture of shared exposures, but it does not prove which ingredient caused the outbreak.

Cypher is the property-graph query language introduced by Neo4j, and FalkorDB is compatible with its core syntax. It expresses graph traversals using ASCII-art-style pattern matching: (a)-[:REL]->(b) means node a points to node b via the REL relationship. The MATCH ... WHERE ... RETURN ... ORDER BY in the article's example has semantics similar to the corresponding SQL clauses, but it matches paths rather than table joins. Cypher's count(DISTINCT c) deduplicates cases so the same case isn't counted multiple times through different paths. Variable bindings (such as c, p, e) let a single pattern constrain multiple nodes and relationships at once, so multi-hop supply chain tracing can be expressed in a short statement. For outbreak investigations, this means "tracing from cases back to suppliers" requires just one readable path pattern rather than hand-written multi-table JOINs.

The tie that counts can't break

In the synthetic case, two ingredients appeared in all eleven cases, leaving two suppliers tied. Ranking based on exposure frequency alone cannot choose between them.

The next step was to look for independent evidence. BatchZero models isolates and genomic matches as graph nodes and relationships. A patient isolate matched an environmental isolate associated with lot MG-4417, with no more than 2 SNP differences. The competing lettuce lot LET-2210, by contrast, had no matching isolate in the scenario.

This evidence shifted the investigation: MG-4417 became the primary source hypothesis, and the competing hypothesis was ruled out. The key point of the demo isn't just the answer—it's the path from evidence to answer.

SNP (single nucleotide polymorphism) differences are a common metric in genomic epidemiology for assessing strain relatedness: after whole-genome sequencing of isolates, they are aligned and the number of positions where a single base differs between them is counted. The smaller the difference, the more recently they shared a common ancestor, and the stronger the epidemiological link. Public health practice often sets thresholds (such as ≤2 or ≤5 SNPs in outbreak investigations) to declare a "match," but the threshold depends on the pathogen's mutation rate, sequencing quality, and transmission chain length—it is not a universal constant. The article's use of "no more than 2 SNP differences" to link the environmental isolate with lot MG-4417 is exactly the use of molecular evidence independent of exposure counts to break the supplier tie. Note that SNP matching supports association but does not alone prove causation; it still needs to be interpreted together with time, place, and supply chain evidence.

Plausible-looking records can still be wrong

We also planted a temporal trap: one exposure record was dated later than the patient's symptom onset. If the agent treated every retrieved record as valid, that meal would become a misleading lead.

BatchZero checks exposure dates against each case's onset time and the pathogen's incubation window. Records outside the window are excluded from the valid exposure set rather than treated as source evidence. This reflects the distinction we wanted to explore: retrieval can find a record, but an investigation must judge whether that record is plausible.

Four agents, each with a distinct role

BatchZero models the workflow as four roles:

1. Intake Officer: builds the initial case profile.
2. Cluster Analyst: compares cases and develops candidate hypotheses.
3. Supply Chain Tracer: traces ingredients, lots, suppliers, and shipments.
4. Briefing Officer: prepares findings and response actions.

Each role runs in its own MCP server subprocess with its own tool set. Capability design helps enforce process order: for example, the Cluster Analyst cannot draft a recall because that action isn't exposed in its tool interface. We use MCP so that available actions are part of the runtime setup, not just instructions in a prompt.

MCP (Model Context Protocol) is a protocol proposed by Anthropic and open-sourced in late 2024 to let LLM applications connect to external tools and data sources in a standardized way. Its architecture includes a host application, MCP clients, and MCP servers; servers expose three kinds of capabilities over JSON-RPC: tools (callable functions), resources (readable data), and prompts (predefined prompt templates). BatchZero launching a separate MCP server subprocess for each role means each role's tool list is isolated at the protocol layer—operations a role isn't authorized for won't appear in its tool list, so the model can't call them even if prompted to. This is more reliable than simply writing "do not perform X" in the system prompt, because the constraint lives at the runtime capability boundary rather than the language instruction level.

Preserve the reasoning, not just the answer

Review is far easier when conclusions can be traced back to evidence. BatchZero records tool calls and sessions in the graph, with evidence linked back to the tool call that produced it. This forms a path: Hypothesis → Evidence → ToolCall → Session. The graph also stores agent memory, including investigation hypotheses and distilled facts. This means the system can represent both the outbreak itself and the reasoning built up during the investigation.

Agent memory refers to state that an agent persists and can retrieve across sessions, usually divided into short-term (the conversation within the current context window) and long-term (written to external storage and reused across sessions). Common implementations include vector-retrieval memory stores, fact tables in structured databases, or entities and relationships in a knowledge graph. BatchZero stores investigation hypotheses and distilled facts as graph nodes, making the memory itself queryable via graph traversal and connected to evidence and tool calls. Compared with plain-text memory, graph-structured memory has the advantage of expressing provenance relationships like "which tool call produced this fact, and which hypothesis does it support," making the agent's reasoning auditable and reconstructable in later sessions rather than leaving only the final answer.

Making the demo reproducible

Live demos can fail for ordinary reasons: a missing API key, a network glitch, or model rate limits. BatchZero keeps the agent interface swappable. With a Groq API key, Groq can drive the tool loop; without one, deterministic replay executes the same workflow against FalkorDB. The repository documents a benchmark command that runs the replay three times:

python -m batchzero.demo.replay --benchmark 3

The project reports that it correctly identified the source across all three benchmark runs. The demo and implementation are available in the BatchZero repository, and the walkthrough video shows the investigation running in the UI.

What we learned

A few lessons stood out:

• Model the relationships that drive decisions. The value of the graph isn't the diagram shape—it's the ability to traverse exposure, supply, and genomic relationships as part of the investigation.
• Treat counts as a starting point. Shared exposures narrow the candidates, but independent evidence is needed to break ties.
• Validate records before reasoning over them. A record can exist and still fall outside the relevant time window.
• Keep provenance close to conclusions. Linking evidence to the tool call that produced it makes results easier to reconstruct.
• Reinforce process with capabilities. Role-limited tools make certain invalid operations unavailable to the agent at a given stage.

In this synthetic scenario, the source was lot MG-4417. The graph helped us explain not only which hypothesis won, but also the evidence supporting it and how the investigation got there. If you're building systems that need to trace evidence across many connected entities to make decisions, we'd love to hear which representations and audit trails work for you.