Triage Lab
A simulated emergency-department console for structured intake, prioritisation, and batch evaluation.
Triage Lab turns a sensitive, high-context simulation into a visible test of whether an agent can prioritise safely and explainably.
The situation.
Most agent demos make a single plausible answer look impressive; they reveal much less about what happens when several cases compete for attention. Triage Lab was built as a simulated emergency-department workflow so prioritisation, follow-up questions, and ordering errors could be inspected rather than hidden behind a chat response.
The domain is deliberately constrained. It is an engineering and evaluation environment, not a clinical device or a source of medical advice; the project’s value is in testing structured agent behaviour under pressure, not in making real-world care decisions.
What I did.
I created the product concept and open-source implementation: a console for free-text intake, manual cases, predefined batches, and archived episode review. The public repository documents the paired Next.js interface and Python/OpenReward environment.
I made inspectability a first-class part of the prototype. The interface separates intermediate activity, structured decisions, and evaluation so an evaluator can see the trajectory instead of trusting a polished final answer.
How the work unfolded.
Modelled a multi-case environment
Designed flows where agents assign each patient one KTAS level and must manage ordering, waiting, and under-triage risk rather than completing a one-shot classification.
Made runs reviewable
Connected the UI to archived rollout artefacts so tool activity, decisions, rewards, and per-patient evaluation can be examined after a run.
Kept product and benchmark together
Used a polished console to make the evaluation loop legible while retaining a runnable environment with deterministic dataset-backed labels.
What happened.
The result is a working open-source prototype with chat, batch, and manual evaluation workflows, plus an OpenReward listing. It gives evaluators a practical way to inspect how an agent prioritises simulated cases and where it goes wrong.
Separating the agent's intermediate activity, final decision, and evaluation made failure visible instead of hiding everything behind one polished answer. The project showed how the interface and benchmark can work together to make an agent easier to assess.
What I learned.
A benchmark needs observable failure
A final answer is insufficient for high-stakes evaluation; rollouts, tool calls, and scoring make incorrect reasoning discussable.
Constraints are part of the product
A useful agent environment makes valid actions and completion criteria explicit instead of asking an evaluator to infer safety from prose.
A clinical-looking interface needs careful framing
The more credible a simulation looks, the more clearly its non-clinical boundary must be stated.
Related links.
Repositories, demos, event pages, posts, and other places connected to this project.