← All work

Autonomous agents · AI Builder · Dataverse

Autonomous Document Triage

High volume, low judgement filing that accumulates in a shared mailbox until month end.


The problem

Invoices, delivery notes, and signed change orders arrive as email attachments and scans. Someone opens each one, works out what it is, types four fields into a system, and files it. The work is high volume, low judgement, and unpleasant, which is why it accumulates in a shared mailbox until month end.

The errors are not random either. They cluster at the end of the backlog, when whoever is clearing it is going fast.

Why an autonomous agent rather than a chat agent

Nobody is asking a question here. A document arriving triggers the work. The aim is to handle most documents without manual intervention. A conversational interface would be a step backwards.

Architecture

Autonomous Document Triage architectureA document arriving in SharePoint triggers an autonomous agent, which classifies it, extracts fields and scores its confidence. Results above the configured threshold are written to Dataverse and filed automatically. Results below it go to a human review queue.Document arrivesSharePoint libraryno human involvedAutonomous agent — event triggered, no conversationClassifyinvoice, delivery note,change orderExtractfields relevant tothe document typeScoreconfidence returnedper extractionConfidence threshold — a business decisionabove thresholdProcessed unattendedDataverse record writtendocument routed and taggednothing deleted or overwrittenbelow thresholdHuman review queuea first class workflow with an owner,not a shared inboxcorrectly declining to guessAutonomous agents consume credits per run rather than per conversation, so volume forecasting belongs in the commercialconversation before deployment. Extraction accuracy is sampled and audited in the first weeks to set the threshold against real data.The threshold is set per document type, with the client, against what an error costs relative to what a review costs.
The confidence threshold is a business decision, not a technical one

A document landing in SharePoint triggers the agent. It classifies the document type, extracts the fields relevant to that type, writes a Dataverse record, and routes the document to the right library. Low confidence results go to a human review queue instead.

The constraint that drives the design

The confidence threshold is a business decision, not a technical one.

Every extraction returns a confidence score. Setting the auto-process threshold low pushes more documents through unattended and lets more errors into the finance system. Setting it high sends everything to review and the automation achieves nothing.

The right threshold depends on what an error costs relative to what review costs. That balance differs for a fifty dollar delivery note and a signed change order. So the threshold is configurable per document type, set with the client rather than for them, and revisited once real volume has run through it. Anything below the line is not a failure; it is the system correctly declining to guess.

Delivery considerations

Human review needs to be a real queue with a named owner. Route exceptions into a workflow someone is accountable for, or they become the new backlog.

Extraction accuracy is measurable, so measure it. A sample audited against source documents in the first weeks gives a real number to set thresholds against.

Autonomous agents consume credits per run, not per conversation. Volume forecasting belongs in the commercial conversation before deployment, not in a surprise invoice after it.

Nothing should be deleted or overwritten automatically. Route, tag, and record. Destructive actions stay manual.