In AWS’s published sample, a purchase order arrives from a retailer the system has never seen. The total is $14, 931.54. The date is January 2, 2026. One line carries the SKU SB-004. The internal catalog expects something like AB-SB-004. This is a synthetic bike-shop demonstration. It does not benchmark the approach against a conventional document system, and it does not report a general accuracy rate. In a template shop, that mismatch becomes a ticket, a rule change, and a delay. In the design AWS published, it becomes a training run that writes the rule once, then tries not to ask again.
That is the pitch for a sample built on Amazon Bedrock AgentCore: AI agents that classify a document, extract structured fields, check them against business rules, and reuse what they learned. The useful version still has a supervisor.
The filing cabinet that bills you every year
Finance, procurement, insurance, and operations teams do not lose days to one bad PDF. They lose them to hundreds of suppliers, each with a layout that can change without notice. Template-based intelligent document processing was supposed to fix that. In practice it often trades data-entry labor for configuration labor. Every new vendor format needs extraction rules, validation logic, and someone to notice when the footer moves.
The AWS how-to, written by solutions architects Erik Cordsen, Vivek Mittal, and Sourabh Jain, cites IDC research that document-related challenges cost organizations $19, 732 per information worker a year and account for a 21.3 percent productivity loss. The citation exists. A secondary write-up that repeats the same figures points to an IDC PDF on a path dated November 2013. The report itself is not in the materials behind that citation. Do not put a 2013 industry average into a 2026 business case. Use your own cycle time, exception rate, and cost per invoice.
The business point survives the dated statistic. If an AI for business program cannot get clean fields out of invoices, purchase orders, contracts, and claims, the models downstream are reasoning over a junk drawer. Agents do not fix a process that still lives in unscanned paper and one-off spreadsheets. They need a document layer that produces data an ERP or CRM can trust.
What the sample actually showed
The walkthrough uses a synthetic purchase-order schema and a mock product database. Read it as a demonstration of instruction reuse. Do not treat it as measured production performance.
The first document is a purchase order from Two Wheel Store, number PO-2026-0102-2584, dated 2026-01-02, totaling $14, 931.54. Extraction runs. Validation fails because the vendor SKU SB-004 does not match the internal rule. In this sample, internal SKUs have to look like AB-SB-004, not SB-004. An instructions fixer adds a rule to prefix the vendor’s codes with AB-, and the job is run again. End-to-end time in the how-to: 3 minutes 49 seconds.
Here the write-up cracks. The narrative says seven line items validated on that second pass. The JSON it displays shows two. The sample’s own account is not internally consistent. Ask for the full job record before treating either count as evidence.
A later document of a known type is a cleaner story, and a narrower one. The matcher scores it 3.946 against a threshold of 3.7. AWS never says what that score measures. Do not read it as a confidence rate. Stored transforms apply, including EL-002 to AB-EL-002. Three line items validate on the first pass. The order total is $5, 979.19. Time: 1 minute 30 seconds, against 3 minutes 49 seconds on the first run.
That pair shows a known layout skipping retraining and finishing faster in this sample. It does not prove that accuracy climbs on a production corpus. The how-to says the loop improves accuracy over time. What it published is one before-and-after on synthetic paper.
Two workflows, and a person at the gate
Instead of static templates, AI agents analyze each document, generate extraction instructions, validate results, and learn from corrections automatically.
That is the how-to’s own framing. The design behind it is more supervised than the sentence sounds.
AWS’s solution documentation clears up a muddle in the how-to, which says “two workflows” and then narrates three paths. There are two workflows. Identification is routing. It does not make a third pipeline.
A document arrives by email or direct upload. An orchestrator names the type and the sender and checks whether processing rules already exist. A match starts automation: extract with the stored instructions, validate, and send clean data downstream. No match starts training, which builds a blueprint, the set of extraction instructions for that format. On a known format, if validation fails, a troubleshooter can correct the extraction against the source document and the rules without rewriting the stored instructions. A person can open a dashboard and ask what failed.
In this design, a new blueprint waits for human review before automated processing is turned on. After three failed automation attempts, the document goes to a person. The same pages talk about minimal human intervention. Both can be true. Neither means an unattended back office.
Under the hood, the graph is built with Strands Agents, an open-source SDK, and runs on AgentCore. Text comes off the page with Amazon Textract. Similar documents and stored instructions are found by vector search over embeddings in Amazon S3. The control that matters is the boundary around the tools: workload identity, short-lived tokens, and an AgentCore Gateway. The gateway exposes those tools through the Model Context Protocol, a common protocol for giving a model a defined action instead of letting it invent an API call. The agent does not wander the account.
If someone on your team is going to stand the sample up, confirm the repository path first. The how-to’s clone URL and the linked tree do not match. The public overview does not say which is authoritative. The how-to puts deployment at roughly 15 to 20 minutes.
The bill is mostly the models
AWS estimates about $58 a month to train on 10 documents and process 1, 000 more in US East (N. Virginia). The how-to also says foundation-model inference is about 85 percent of that cost, and roughly $0.055 per document. Those unit figures do not sit cleanly together. Eighty-five percent of $58 is about $49. Spread across the 1, 000 processed documents, that is about $0.049 each, not $0.055. At $0.055 each, 1, 000 documents would be $55, nearly the entire monthly estimate rather than 85 percent of it. Treat both numbers as rounded figures from the same AWS estimate, not as a reconciled invoice. The estimate is not an independent audit.
Model assignments sit in a config file, and the authors say actual spend depends on which model each agent uses. Nova and Claude both have to be enabled in Amazon Bedrock for the sample as published. AgentCore Evaluations is the check AWS recommends before you change models. A cheaper model that misses SKUs is not cheaper.
The authors also say you pay only for what you use, because the sample runs on serverless, on-demand resources with no idle costs. That fits this architecture. It is not a total cost of ownership. It leaves out the schema work, the validation rules, the review queue, the ERP integration, and whatever you spend when a model swap quietly hurts extraction quality.
Where this earns a pilot
The pattern fits high-volume, semi-structured documents that share a business meaning and refuse to share a layout. Purchase orders, invoices, claims, and contracts are the obvious list. The sample ships with a purchase-order schema and a validator aimed at a mock vendor table. Yours will not. You replace the schema, the prompts, and the rules that check a real system of record.
AWS suggests training on 5 to 10 documents per type, including the ugly edge cases, not the cleanest PDF in the folder. A blueprint learned only on perfect scans will fail the first time a supplier exports from a different system. Templates are still the right tool when you have a handful of stable layouts. They get expensive when every supplier is a new dialect and the footer moves without notice.
Before this touches production files, three decisions belong to a leader, not to the deployment script. Which fields are allowed to leave the account. Who may approve a new blueprint. What a model swap is allowed to change. Amazon Bedrock Guardrails and the OWASP Top 10 for large language model applications are sensible references for filtering and grounding, especially on claims and loan files. They are not a control matrix you can paste into an audit. The gateway, the tokens, and the approval gate are the parts of this design worth keeping on purpose.
Questions worth asking before a pilot
- Does this replace the people who fix bad documents? No. In this design, a new blueprint waits for human review before automated processing is turned on, and a document goes to a person after three failed automation attempts. Schemas and business rules are still yours to write.
- What did the sample prove about speed? On one synthetic purchase-order pair, a first-time format took 3 minutes 49 seconds and a later known format took 1 minute 30 seconds. That is instruction reuse in a demo, not a measured accuracy gain or a vendor bake-off. The how-to’s claim of seven validated lines on the first job conflicts with the two lines in the displayed JSON.
- What would 1, 000 documents a month cost? AWS estimates about $58 in US East (N. Virginia) for 10 training documents plus 1, 000 processed ones, and says inference is about 85 percent of that bill, near $0.055 per document. Those two unit figures do not reconcile: 85 percent of $58 is about $49, closer to $0.049 per processed document. Your number moves with the model on each agent, and the estimate is not an independent audit.
- Why not keep the template tool we already paid for? Templates work when formats are few and stable. They get expensive when every supplier is a new dialect and layouts change without notice. This design tries to learn a format once. It does not remove validation against your own product and vendor master.
- Can we trust the $19, 732 figure in a business case? Only as an IDC citation, repeated through secondary write-ups and tied to a document path from 2013. Use your own cycle time, exception rate, and cost per invoice. Those numbers will survive a finance review. A decade-old industry average will not.
- What has to be decided before this touches the ERP? A schema that matches how you post transactions, a validator that checks a real system of record, and three controls: which fields may leave the account, who may approve a blueprint, and what a model change is allowed to alter. Gateway-mediated tools and short-lived tokens are a boundary, not a finished security review. Integrate after that. Not before.
Agentic document processing is one of the more practical AI-agent patterns on offer, because the job is bounded: read the page, fill the fields, check the rules, remember the format. Done well, finance can post the result, and sales operations can reconcile an order against what was promised, without a later agent inventing a SKU. The companies that get that value will treat the learning loop as an apprentice program with a sign-off, not as a promise that the inbox will run itself. Skip the sign-off and a wrong SKU, stored as policy, scales just as well as a right one.
One record that sat outside the walkthrough
The sample, the cost math, and the approval gate are the operational story. This is the external record that did not fit that argument cleanly.