From ReAct to Agent Teams: Verifiable Incremental Value in Medical System Development

The article uses a read-only clinical information summary service as a running example: lab results and vital signs for the last 24 hours, medications showing both active orders and administration records, allergies retaining historical valid records outside the 24-hour window. The page must display sources, timestamps, and items pending confirmation — no diagnoses, no order modifications, no write-back to the medical record.

Interface Contracts Before Agent Decomposition

Architecture starts with data flow and write boundaries. The summary service builds a read model for the workstation; it may cache results and keep provenance references but never becomes a new write entry for charts or orders. Development agents work in isolated branches with synthetic or approved de-identified test data, no production write permissions.

HL7 FHIR R4 semantics help validate mappings: Observation.effective[x] — clinical observation time/period Observation.issued — when the result version became available MedicationRequest — prescribed medication request MedicationAdministration — actual administration event

Key distinction: "Last 24 hours" filters by event occurrence time; "as of 08:00" constrains when results were knowable. An as_of parameter alone does not grant upstream historical query capability. To reproduce a historical page, the source record versions or query snapshots at that time must be stored.

The interface contract must fix at least these fields (illustrative):

patient_id / encounter_id
window_start / cutoff_time / timezone
effective_time / available_time / fetched_at
source_system / source_record_id / source_version
data_status / provenance

provenance

retains source references; data_status distinguishes has-data, query-returned-no-records, upstream-unavailable. Empty response only means "no records found this query", not "patient has no allergies". When upstream lacks record versions, saving response snapshots with fetch metadata provides audit trail.

Different upstreams lack cross-system transaction snapshots. When a source arrives late or is unavailable, the page can show retrieved data while flagging update time and missing items; whether to display an incomplete summary must be agreed in requirements and acceptance criteria, not left to model improvisation.

ReAct Loop: One Cycle at a Time

ReAct (Reasoning and Acting) alternates reasoning and action:

Goal & Context
  ↓
Decide next step
  ↓
Call tool
  ↓
Read real return
  ↓
Check if closer to goal
  ↓
Continue / Stop / Hand to human

Example: an agent fixes the lab adapter — reads field mappings and query contract, runs the test suite, discovers the 10:00-released report leaked into the 08:00 page, inspects filter logic, patches code, re-runs tests. Tool returns concrete assertion failures and raw inputs, grounding the next iteration.

However, passing tests only proves existing assertions hold. If tests omit report availability time, the agent may happily return a wrong implementation. ReAct provides a feedback loop; feedback adequacy depends on test and tool design.

Runtime controls permissions, allowed directories, network access, execution budget. Agents modify adapters and tests in isolated branches; merge, migration, release follow existing engineering pipelines. Prompt constraints need tool permission enforcement.

In multi-agent settings, each executor has its own context. One loop's output must pass through messages, task records, or external artifacts to be usable by the next loop. Information stuck in an agent's chat history leaves downstream collaborators with only "I checked it".

Define Responsibilities Before Splitting Agents

With contracts fixed, decomposition becomes meaningful. Lab and vital-sign adapters can be developed against the same contract version; if the contract is still fluid, letting implementation and acceptance each guess a definition causes rework. Task dependencies precede role naming.

Identity & Query Contract: Agent cross-references master patient index, encounter mapping, time definitions; lists open questions. Deliverable: field mappings, contract draft, boundary examples.

Lab & Vital Signs Adapter: Agent implements field transforms; adds unit, time, report revision tests. Deliverable: code changes, contract test report.

Medication & Allergy Adapter: Agent distinguishes orders from administration records; preserves missing/confirmation states. Deliverable: state mappings, negative-path tests.

Integration & Review: Agent replays same data batch; verifies page facts against source records. Deliverable: integration report, reproducible blockers.

Every artifact must trace back to code, inputs, and acceptance basis. When interface definitions are uncertain, the agent submits questions with evidence for engineers and domain experts to confirm; it must not default a pending item just to keep executing.

Example: a lab adapter handoff report includes field mappings, commits, failed/passed tests, and unverified upstream behaviors. Downstream reads the summary for progress; when verification is needed, they open the raw report. A single line "lab module done" leaves too much for the integrator to guess.

Anthropic's multi-agent research engineering summary recommends: sub-agents write reports, data, or code to an external artifact system, then return path, summary, and status to the coordinator. Context need not be copied wholesale; later humans can still reach original evidence.

Consistency Rests on Three Concrete Things

Adapter and test agents may disagree on implementation choices (e.g., filter late reports in adapter vs. summary layer). Discussion is valuable, but they must jointly confirm:

Same requirement version, same patient/encounter mapping rules.

Implementation and tests reference the same interface contract, replay data, and time conditions.

Sub-task status traces to engineering records; local completion ≠ overall acceptance.

Handoff state preserved (chat logs supplementary; fields adjust to task complexity):

global_task_id / sub_task_id
base_commit / commit_sha
schema_version / fixture_version
input_snapshot / query_contract_ref
confirmed_facts / assumptions
capability / constraints
artifact_refs / acceptance
status / version / attempt
lease_until / result_ref

fixture_version

identifies test input version; commit_sha identifies code commit; both stored with contract version. Patient, encounter, and query time live in the test input. This lets reviewers know exactly which code and which samples the report validates.

Result states need granularity: candidate, verified, conflict, rejected — at minimum. "Test command succeeded" and "deliverable meets requirements" cannot share a field. When a reviewer finds the 10:00 report in the 08:00 page, they submit a reproducible failing case and return the time-filtering task.

Messages delay, duplicate, reorder. First test call times out; retry reports success; the late first failure flips state back. Task records carry attempt and version; conditional state updates reject stale results — old messages cannot overwrite newer state.

Traditional CI already enforces this: test reports bind to commits; after code changes, old reports cannot prove new code is releasable. Agent collaboration follows the same rule to avoid carrying an expired "pass" into merge.

Information Flow Determines Collaboration Style

Two patterns:

Centralized aggregation: Coordinator dispatches adapter, test, source-verification tasks; collects code and reports; arranges integration. Permissions, budgets, ownership clear; but when members find interface issues, they must route through coordinator — context may be lost in translation.

Direct member communication: Adapter agent asks test agent for examples; frontend/backend agents discuss interface directly. Claude Code Agent Teams docs describe shared task lists and direct messaging, noting extra cost. Easier communication, but shared task list ≠ business database or release log.

Akihiro Nakamura compared Codex Multi-Agents vs. Claude Code Agent Teams, attributing differences to information flow: parent aggregation vs. direct member exchange. For R&D teams, the useful question is whether direct queries reduce rework, and where agreed contract changes are persisted.

Example: two agents agree a new null-handling rule in chat only; other adapters and tests keep the old definition — direct communication widened the mismatch. Discussion can happen between members; confirmed changes must enter versioned contract and flag affected tasks/tests for re-run.

Lab and vital-sign adapters can run in parallel on isolated branches; shared model and API contract changes suit a single explicit merge entry. Letting two agents edit the same file simultaneously often trades wait time for conflict resolution overhead.

Parallelism check via dependency graph: independent inputs? independent outputs? can merge be deferred? Agent count alone does not prove parallel gain.

Integration Tests Must Verify Business Meaning

Reusing the opening example, integration tests check final page compliance, not just HTTP 200:

Identity: patient_id, encounter_id match authorization scope
Time: 10:00-released report excluded from as-of-08:00 known info
Medication: active orders and actual administrations shown separately
Allergy: empty response does not generate "no allergy"; historical valid records not filtered by 24h window
Evidence: page facts trace to original records and versions
Missing: upstream unavailable, no records, result pending — each expressed distinctly
Boundary: no diagnoses, no order modifications, no clinical fact write-back
Audit: record caller, tool results, versions, human confirmations
Decision: test report binds code, contract, fixture versions; satisfies merge criteria

Implementing agent can self-test but cannot gate on its own "pass". CI validates fixed assertions; reviewer checks original inputs for omissions; engineer confirms disputed business rules. Adding a reviewer agent does not guarantee independence: if it generates expected results from implementation logic, the same misunderstanding may be confirmed twice.

When empty response becomes "no allergy", review report cites specific input, assertion, code location; returns state-mapping or summary-rendering task; adds regression test. This way the fix gets caught automatically in the next build.

Report revisions, discontinued orders, cross-encounter data leakage, missing units — all deserve regression cases. Each fix leaves a replayable test, far more reliable than repeating "please check carefully" in prompts.

On Failure, First Clarify What Happened

Tool calls in development also time out. Reading docs or querying test results usually retryable; creating merge requests, running migrations, triggering releases — timeout does not let caller assume remote didn't execute. Even when engineering pipelines initiate these, coordination system must recognize true status.

Robust states: not-executed, executing, completed, failed, unknown. On unknown, query remote first; only re-issue if safe replay confirmed. Write operations use idempotency keys; duplicate requests blocked by DB unique constraints or downstream interfaces.

Failures scoped to sub-task. Two adapters passed acceptance; only allergy test fails due to environment — re-run that item. But if fix changes shared contract, affected integration tests must re-execute. Local retry assumes dependencies unchanged.

Scheduler restart handles task reclamation. Leases and heartbeats help decide takeover, but lease expiry doesn't auto-stop old agent. Artifact/state receivers must check execution attempt, reject late writes from stale executor; otherwise old and new agents may both submit results. For small-scale R&D collaboration, isolated workspaces, versioned task records, and CI suffice — no need to build a full distributed scheduler upfront.

Weigh Parallel Gains Against Costs

Multi-agent benefits have clear applicability conditions. Anthropic internal eval: Claude Opus 4 coordinating Sonnet 4 sub-tasks improved 90.2% over single-agent Opus 4. Another observation: multi-agent systems consume ~15× tokens of regular chat. Different baselines; neither directly translates to medical R&D metrics.

Google Research on 180 agent configurations: on parallel-friendly Finance-Agent tasks, centralized multi-agent beat single-agent baseline by 80.9%; on strictly sequential PlanCraft tasks, all multi-agent variants dropped 39–70%. Better for checking task decomposition, not for promising efficiency gains.

Cedric Chee's K2.5 Agent Swarm on Kimi Code CLI: naturally parallel, high-download/output deep research fits; software dev needs refined sub-agent prompts, parallel coordination, workflows. He explicitly states still experimenting — this boundary more useful than vague "multi-agent better for dev".

Back to this task: independently adapting multiple upstream interfaces offers parallel space. Repeated contract tweaks, waiting for domain confirmation, fixing shared models — easily blocked on dependencies. I would compare delivery time, rework count, valid defects found, total invocation cost for the same task batch; raw code volume hardly indicates whether the round was worthwhile.

Choose an Architecture You Can Explain

Compressing scenarios into a few choices supports initial design:

Single adapter change, verifiable feedback → Single-agent ReAct loop. Rationale: centralized context, small blast radius.

Fixed steps, clear dependencies → Fixed workflow or state machine. Rationale: readable control flow, easy replay.

Need extra quality gate → Separate generation and evaluation. Rationale: reviewer can return concrete task.

Multiple adapters independently developable → Coordinator + executors. Rationale: branches and artifacts independently verifiable.

Members need continuous cross-questions → Agent Team. Rationale: direct communication shows clear benefit.

Multiple people editing same artifact, dense dependencies → Single agent or serial collaboration. Rationale: lower merge and sync cost.

In practice, fixed workflow can orchestrate multiple tasks, each executor still runs internal ReAct loop; parallel tool calls don't necessarily require more agents.

For this medical R&D, I would first lock one interface contract version and replay suite, have a single coordination entry schedule independent adapter development on isolated branches, deliver via CI and engineer integration acceptance. If members frequently need to supplement each other's field and test context, then try direct communication and observe whether it actually reduces translation loss and rework.

Whether adding an agent is worth it depends on whether it brings verifiable incremental value. For instance: did it catch the previously missed "report not yet available", add the "order valid but administration missing" test, and pass the same regression suite after fix? If it only produces another similar-looking report, a single agent working with engineers remains perfectly adequate.

References

Yao et al.: ReAct: Synergizing Reasoning and Acting in Language Models (https://arxiv.org/abs/2210.03629)

Anthropic: How we built our multi-agent research system (https://www.anthropic.com/engineering/multi-agent-research-system)

Google Research: Towards a science of scaling agent systems: When and why agent systems work (https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/)

Claude Code: Agent teams (https://code.claude.com/docs/en/agent-teams)

Akihiro Nakamura: X post on Codex Multi-Agents vs. Claude Code Agent Teams information flow differences (https://x.com/akihiro_genai/status/2026078844814586041)

Cedric Chee: X post on K2.5 Agent Swarm applicability boundaries in Kimi Code CLI (https://x.com/cedric_chee/status/2016722086925053960)

HL7 FHIR R4: Observation (https://hl7.org/fhir/R4/observation.html)

HL7 FHIR R4: MedicationAdministration (https://hl7.org/fhir/R4/medicationadministration.html)

HL7 FHIR R4: AllergyIntolerance (https://hl7.org/fhir/R4/allergyintolerance.html)