Skip to content
MirrorFirm

Which systems and links does an intake agent work across?

An intake agent typically touches a submission store, case system, party records, document store and policy rules, and a realistic environment models the keys that link them.

An agent working on intake usually touches five systems, and a realistic environment models the links between them rather than a single table.

- **Submission store:** raw payloads from portal, email and phone notes, each with a channel, received timestamp and attachment list. - **Case system:** one record per case with `case_id`, `status`, `queue`, `owner_role` and `opened_at`. - **Party records:** applicants and existing customers, linked to cases by `party_id`, with fields that can match, partly match or conflict. - **Document store:** items with `doc_id`, `doc_type`, `legibility`, `expiry_date` and the `case_id` they were attached to. - **Policy rules:** completeness and routing rules with identifiers such as `POL-INT-04`, so decisions can cite the rule applied.

The agent's tool surface is typically small: read a submission, search parties, list documents, set status, assign queue, add a note, and send a request to the submitter. Each write action should be logged with the before and after state.

For evaluation, the useful hook is a final-state comparison. After a run, the environment exports case and note records so a grader can compare them with the expected outcome. Reset returns every store to a known snapshot, so the same task can be run repeatedly across agent versions.

Scope the exact schema in a pilot, because field names and system boundaries differ between organisations.

Modelling the links between systems, not a single table, lets you test whether an agent acts correctly across the whole process.

Audience:
Agent developers
Content type:
Integration
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Application intake