← All case studies Case study · Agentic AI

Clinical Evidence Coordinator: agents analyze, rules decide

A governed multi-agent workflow that checks whether a clinical-study evidence package is complete and traceable, then hands it to a person. The model proposes. Deterministic rules decide. A human always makes the call.

Runtime Local FastAPI and Amazon Bedrock AgentCore Model Claude on Bedrock, behind a provider Method RepoGenics

validation-result.json

{
  "status": "NOT_READY_FOR_HUMAN_REVIEW",
  "human_review_required": true,
  "missing_requirement_ids": ["REQ-003"],
  "blocking_findings": [
    "No complete evidence available
     for REQ-003"
  ],
  "rules": {
    "all_required_..._complete_evidence": false,
    "no_blocking_quality_findings": false,
    "human_review_required": true
  }
}

Scenario 3: four PDFs uploaded, but the adverse event record says DRAFT. The package is stopped, and the reason is named.

Bounded workflow steps, each with its own read permissions and artifact

1 of 6

Steps that call a model. The other five are plain, testable rules

Automated tests passing, including every bad-model-output case

Ways for the system to emit “approved”, “safe” or “clinically valid”

The request

“Show me an agent we could trust in a regulated workflow.”

Agents analyze. Rules validate. Humans decide.

Before a clinical-study package reaches a qualified reviewer, someone has to check the basics: is the protocol there, are the device verification results there, is the adverse event reconciliation record there and signed off, is the site completion summary there? It is tedious, easy to get wrong, and a natural job for AI, if the AI can be kept on a short leash.

The brief was a reference implementation an enterprise could reuse, with firm boundaries:

Read real uploaded documents, and say which requirement each one is evidence for, and whether it is final.
Never let a model decide readiness. Rules decide, and they fail closed.
Leave an audit trail: one structured record per step, every verdict traceable to a requirement and a document.
Keep cloud code behind adapters, so the same workflow runs locally, in Docker and in Amazon Bedrock AgentCore.
Synthetic data only. No PHI, no diagnosis, no treatment advice, no regulatory decisions.

How it was delivered

The Repogenic Loop, applied to an agent

The repository carries the intent, the rules, the fixtures and the proof, so the next agent starts from what already works.

Intent

intents/Feature.md set the agent roles, their “must not” lists, six release rules and the only two allowed verdicts before any code was written.

Variation

AI-assisted engineering produced the orchestrator, five workers, the intake prompt, the upload page and the AgentCore entry point, each scoped to its permission list.

Selection

Tests decided what stayed: three synthetic PDF scenarios, plus malformed replies, bad statuses, provider errors, invented IDs and duplicates.

Inheritance

Every step writes a JSON artifact. Docs record what is verified, what is not, and the order of the next work, so nothing is rediscovered.

Guardrails

A fail-closed validator, a response model that only allows two statuses, document text treated as data, and synthetic data only.

The agentic workflow

State travels. Agents do not remember.

One orchestrator owns the workflow state. It builds each agent’s input by hand from that agent’s read permissions, records what comes back, and moves on. No agent sees another agent’s working notes, a chat history, or anything it was not given.

MODEL

0 · Document Intake

One call per PDF. Proposes which requirement the document is evidence for, and whether it presents itself as final.

Reads requirements, one document’s textWrites document-intake.json

Never sets readiness

RULES

1 · Requirements

Normalizes the protocol requirements into a structured checklist the rest of the run can count against.

Reads protocol requirementsWrites requirements.json

Never invents or rewords a requirement

RULES

2 · Evidence

Maps every requirement to the documents that claim to support it, carrying source file and status.

Reads requirements, evidence itemsWrites evidence-map.json

Never assumes absent evidence exists

RULES

3 · Quality

Raises blocking findings for missing evidence, drafts, duplicate evidence IDs and unknown requirement IDs.

Reads requirements, evidence items, evidence mapWrites quality-findings.json

Never waives a gap

RULES

4 · Review

Prepares the handoff: coverage counts, unresolved issues, and the decision boundary in plain words.

Reads requirements, evidence map, findingsWrites review-summary.json

Never makes a medical or regulatory call

RULES DECIDE

5 · Validator

The only code that sets the status. Ready only if every required item has final evidence and nothing is blocking.

Reads requirements, evidence map, findingsWrites validation-result.json

Two outcomes only, human review always required

One run, traced

Scenario 3, from upload to verdict. Every step below left a file on disk that a reviewer can open.

Intake4 PDFs classified. The adverse event record says draft, so it is mapped to REQ-003 as incomplete.

Requirements4 required items, REQ-001 to REQ-004.

EvidenceEvery requirement has a document. REQ-003’s only one is incomplete.

QualityBlocking: “No complete evidence available for REQ-003”.

Review4 of 4 have evidence, 1 blocking issue, human review required.

ValidatorNOT_READY_FOR_HUMAN_REVIEW, naming REQ-003.

The guardrails

The model proposes. The rules decide.

The model is the one step that can surprise you, so its boundary is where the design is strictest. Anything the intake agent cannot trust becomes “no requirements, incomplete”. A model that invents a requirement is not quietly corrected: the made-up ID is passed through so the Quality step blocks it in plain sight.

Six failure modes flow into two guards, DocumentIntakeAgent parse and QualityAgent, then into the validator's six release rules; any failed rule produces NOT_READY_FOR_HUMAN_REVIEW — Unparseable replies, invalid statuses, provider errors, invented IDs and duplicate IDs each have a test that expects `NOT_READY_FOR_HUMAN_REVIEW`.

The output

Three packages, three verdicts

Drop a folder of PDFs on the upload page and get a verdict with its reasons. These are the real results for the three synthetic scenarios that ship with the repository.

Coverage grid: scenario 1 has final evidence for all four requirements and is ready; scenario 2 has no document for REQ-003 and is not ready; scenario 3 has a draft for REQ-003 and is not ready — The unrelated parking memo in scenario 1 maps to nothing and does not disturb the verdict.

The evidence

Proven where it is proven, and honest where it is not

21 tests passing	VERIFIEDThe full suite passes in mock mode with no credentials: the workflow, the three PDF scenarios, the upload endpoint, both runtime adapters and the AgentCore entry point.
Fails closed on bad model behavior	VERIFIEDTests feed the intake agent non-JSON, a wrong field type, an “approved” status, an invented REQ-999 and a provider exception. Every one ends in `NOT_READY_FOR_HUMAN_REVIEW`.
Same answer locally and in AgentCore	VERIFIEDA test runs the local and AgentCore adapters on the same package and checks that the domain result is identical.
AgentCore package builds	VERIFIED`agentcore package` produces a CodeZip that serves `/ping` and `/invocations` correctly on Linux ARM64 with Python 3.12.
Real Bedrock error path	VERIFIEDA live Bedrock call that AWS rejected was caught per document, and the package was marked not ready.
Claude classification quality	NOT YETThe Bedrock provider is code complete, but model access is not enabled on the AWS account, so accuracy has not been measured. A labeled evaluation set is the next step.
AWS deployment	NOT YETThe deploy dry run needs CloudFormation permissions for the deploying identity. Nothing is claimed as deployed until it is.

The architecture

Cloud lives behind one door

Only agentcore_app.py imports the AgentCore SDK, and only the Bedrock provider imports the Bedrock client. The clinical workflow depends on small platform contracts, so moving to another runtime or model vendor is an adapter, not a rewrite.

Three layers: the domain (intent, workflow, prompt, rules, fixtures, tests), the platform contracts, and swappable adapters for local, AgentCore, Bedrock and future clouds

Engineering view of how a review runs, from upload or AgentCore through the orchestrator's six steps to the human reviewer, including deploy-time resources — The engineering view from the repository: how requests arrive locally and in AWS, and what a deploy creates (one AgentCore Runtime, one IAM role and policy).

Why it matters

An agent template, not a one-off

Judgment where it helps, rules where it counts

The model does the one thing rules cannot: read an unfamiliar document and say what it is. Everything that decides an outcome stays deterministic, testable and explainable.

An audit trail by default

Six JSON artifacts per run tie every verdict to a requirement ID, an evidence ID and a source file. A reviewer or an auditor can follow the reasoning without asking the AI to explain itself.

Agent #2 should be config

Orchestration, providers and runtime adapters are shared. The next use case should bring only its requirements, an intake prompt, its rules and labeled test documents, not a new platform.

Python 3.12+FastAPIPydanticpypdfpytestClaude on Amazon BedrockAmazon Bedrock AgentCoreAWS CDKTerraformDockerGitHub ActionsIntent-driven engineering

Need an agent your reviewers can trust?

From a written intent to a governed, tested multi-agent workflow, with fail-closed rules, an audit trail for every run, and a clear line where the human takes over.

Talk to Repogenic

Reference implementation on synthetic data only. It checks package completeness and traceability; it does not make clinical, safety or regulatory decisions.