The agent monitors the inbox directly rather than waiting for anyone to forward anything.
Law-Enforcement Request Intake
Requests arrive as letters with scanned attachments. The agent reads the mailbox, extracts the identifiers, verifies them against core banking, works out what is being asked, and routes it — leaving a trail behind every step.
What it was like before
Law-enforcement requests do not arrive as structured data. They arrive as an email with a scanned letter attached, often a photograph of a printed page, naming people by national identity number and asking for something specific: produce records, block an account, unblock one.
Each one is time-sensitive and consequential. Blocking the wrong account is a serious error; missing a request is a different kind of serious error. The work is reading, transcription and lookup — exactly the work people are worst at doing repeatedly and quickly.
What the reviewer sees
The scan, what was pulled out of it, and whether each identifier checked out — before anything was routed.
What it does
Scans and photographs are read, not skipped. This is where most of the information actually lives.
National identity numbers are pulled from the text, including from awkward layouts and imperfect scans.
Every extracted identifier is checked against core banking before anything is acted on.
A model decides what the letter is asking for — records, block, unblock — and routes it accordingly.
Every step lands in a portal with the full trail: what was read, what was extracted, what was verified, what was decided and by whom.
In production
Verification is the whole design
An agent that reads a letter and acts on what it thinks it read is a liability. The step that makes this safe is boring: every identifier the model extracts is checked against the bank's own record before it reaches a decision.
That is also why the false-positive block count is the number worth quoting. Speed is easy to achieve and easy to regret; the point is that going faster did not mean blocking the wrong person.
Tech stack
- Fastify
- Gemini
- Microsoft Graph
- AWS S3
- Prisma
- PostgreSQL
- Node.js
Delivered under AI Agent Development.
Other things we have built.
Sanctions Screening Agent
Watchlist alerts arrive all day and most are false matches. The agent clears the obvious ones against a rule engine backed by an LLM and sends every disagreement to a person with the evidence already assembled.
Read itInternal Policy Assistant
Staff ask a policy question in plain language and get an answer drawn strictly from approved documents, with the source named. Nothing leaves the bank, and the assistant says so when the documents do not answer.
Read itCTR to goAML Conversion
A compliance team spent hours a week turning Currency Transaction Reports into goAML XML by hand. Parser, XML builder, schema validator and audit trail, behind a interface officers actually use.
Read itRegulatory Reporting Engine
A registry of every periodic return a bank owes. The engine pulls the data, builds each report against the mandated template, then schedules and submits it behind a maker-checker step.
Read itAutonomous Social Media Agent
A ReAct loop that researches, reads its own history to avoid repeating itself, writes a strategy memo, critiques its own drafts, publishes, and learns from every rejection.
Read itMulti-Agent Marketing System
Two agents on one platform with a person approving everything before it ships. One researches and takes a position; the other plans a week of posts reviewed as a batch.
Read itWhatsApp Booking Agent
Patients book on the number a clinic already advertises, at any hour, in the language they normally write. Only genuinely free slots are offered, and anything clinical goes to a person immediately.
Read itHave something like this?
Describe the process and we will come back with whether it is worth automating, roughly what it would take, and what we would build first — or tell you plainly if it is not a job for us.