Skip to content
MirrorFirm

How do the stages of intake map onto an evaluation harness?

Each intake stage can be exposed as a tool action over a shared case store, with reference data, a state log and an answer key that the harness reads after the run.

A harness for this workflow needs four things: an inbound payload, reference stores, tool actions and a place to read the result.

**Inbound payload.** One case per task: channel, received timestamp, raw text or form fields, and attachment references. Messy forms and transcribed notes are expected inputs.

**Reference stores.** Read-only tables the agent can query: customers or policyholders, products, completeness policies with version dates, and the routing table. Keep them separate from the case so lookups are logged.

**Tool actions.** A sensible minimum is:

- `capture_fields(case_id, fields)` - `lookup_party(query)` and `search_cases(query)` - `check_completeness(case_id, policy_id)` - `request_information(case_id, items, recipient_role)` - `route_case(case_id, queue, reason)` - `add_handover_note(case_id, text)`

Each action writes to an append-only event log with the case identifier, actor and timestamp.

**Result surface.** After the run the harness reads the case record (status, queue, outstanding items, links) and the event log, then compares both with an answer key held outside the agent's reach.

**Reset.** The environment restores case and event tables to a stated snapshot between tasks so runs are independent.

A release can be scoped to supply any of these layers. Ask which parts you need in a pilot, because the tool names above are a starting point and can be adapted to your own harness.

Mapping stages to tool actions and a state log gives your harness clear inputs, observable side effects and an answer key to grade against.

Audience:
Evaluation teams
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Application intake