Anatomy of an AI Agent: The Five-Stage Pipeline Behind Every Artificio Deployment

At 6:42 on a Tuesday morning, a supplier invoice lands in a shared mailbox at an aerospace components manufacturer in Southern California. It is a PDF attachment on an email with the subject line "INV - please process." The PDF is a scan of a printed document that was itself a printout of a PDF. There is a coffee ring on the top right corner. The purchase order number is handwritten in the margin because the supplier's system does not print it. Line four references a part number that was superseded eighteen months ago.

By 6:44, that invoice has been read, matched against purchase order 4500089321 in SAP, flagged for a two percent price variance on the superseded part, routed to the commodity buyer who owns that supplier relationship, and logged with a complete audit trail showing every decision and the confidence score behind each one. Nobody touched it.

That two-minute stretch is what people mean when they say "AI agent." The phrase suggests something singular and autonomous, a digital worker sitting at a virtual desk. The reality is less mysterious and far more useful to understand. What ran in those two minutes was a pipeline. Five distinct stages, each with its own failure modes, each doing one job well and handing off cleanly to the next.

Every solution Artificio has built runs this same pipeline. Invoice processing for aerospace manufacturers. Certificate of analysis validation for pharmaceutical contract manufacturers. Self-employed income verification for mortgage originators. Student credential checks for universities. The domains are wildly different. The anatomy is identical.

Understanding that anatomy matters, because most automation projects fail at a specific stage, and teams usually blame the wrong one.

The Word "Agent" Is Doing Too Much Work

Walk into any enterprise software conversation in 2026 and the word "agent" gets used four different ways in the same meeting. Somebody means a chatbot. Somebody means a model with tool access. Somebody means a scheduled script with a language model bolted onto the parsing step. Somebody means a fully autonomous system that nobody actually wants to deploy in production against their financial systems.

The confusion has a real cost. When a vendor says their agent handles invoice processing, a finance director hears "it will do what my AP clerk does." Six weeks into the pilot, the truth surfaces. The system reads documents beautifully and then dumps output into a CSV that somebody has to review line by line. The reading was never the hard part.

Here is a more useful framing. An agent is not a model. An agent is a pipeline that happens to contain models at certain stages, wrapped in the plumbing that makes the output trustworthy enough to act on. The model is the engine. The pipeline is the car. Nobody buys an engine and drives it to work.

Break the pipeline into its five stages and every conversation about automation gets sharper. You stop asking "can AI do this?" and start asking "which stage is currently killing us?"

Why Stages Beat Prompts

There is a tempting shortcut that a lot of teams try first. Take a capable model, write a very long prompt describing the entire workflow, feed it a document, and ask it to produce the final answer. Read the invoice, match it to the PO, decide whether to approve it, and tell me what to do.

This works impressively in a demo and falls apart in production. Three reasons.

Failures become opaque. When the single-prompt approach produces a wrong answer, you cannot tell whether the model misread a number, misunderstood the matching rule, or made a bad judgment call about tolerance. All three failures look identical from the outside. Debugging becomes guesswork.

Confidence becomes meaningless. A model that produces one blended answer gives you one blended confidence, and that number is nearly useless for routing decisions. The extraction of the invoice total might be rock solid while the tax jurisdiction determination is a coin flip. You need those separated.

Governance becomes impossible. Auditors do not accept "the model decided." They want to see which rule fired, what evidence supported it, who approved the exception, and what the system would have done differently under a different threshold. A monolithic prompt has no seams to inspect.

Splitting the work into discrete stages solves all three. Each stage produces a typed, inspectable output. Each stage carries its own confidence. Each stage logs its own reasoning. When something goes wrong at 3am on a Sunday, the error points at a specific stage instead of at a black box.

Stage One: Capture

Capture is the stage everybody underestimates. It sounds like a solved problem. Documents arrive, you ingest them, done. In practice this is where more pilots stall than at any other stage, and the reasons are almost never technical sophistication.

Work does not arrive in one place. At a mid-sized manufacturer, supplier invoices come through a shared AP mailbox, a supplier portal, EDI feeds from the three largest vendors, a scanner in the mailroom, and occasionally as photographs texted to a buyer's phone from a delivery driver. Certificates of analysis arrive as email attachments from twenty-two contract labs, each with a different naming convention. Mortgage income documents arrive through a borrower upload portal, a loan officer's inbox, and a fax line that somebody insists on keeping alive.

A capture stage that only handles one channel automates one channel. The other channels keep flowing to the same people who were doing the work before, which means headcount does not move and the project gets labeled a partial success, which is a polite way of saying it did not pay for itself.

Good capture does four things.

It listens on every channel that matters. Mailbox monitors, API endpoints, watched folders, portal webhooks, EDI connectors, scanner integrations. Each source gets normalized into the same internal envelope so that everything downstream stops caring where a document came from.

It handles the physical reality of documents. A scanned page arrives rotated ninety degrees, skewed four degrees, with a resolution of 150 DPI and a stamp partially covering the invoice number. Deskewing, denoising, orientation correction, and resolution upscaling happen here, before any model sees the page. Feeding a dirty scan directly into an extraction model and blaming the model for the result is a common and expensive mistake.

It splits and classifies. A single PDF attachment frequently contains six invoices, or an invoice plus a packing slip plus a certificate of conformance. Page-level classification determines where one logical document ends and the next begins. Getting this wrong poisons everything downstream, because the extraction stage will happily pull the invoice number from page one and the total from page four of a different document.

It deduplicates. Suppliers resend. Buyers forward. The same invoice arrives three times through two channels. Content-level fingerprinting catches this before three payment obligations get created for one liability.

Capture produces one output. A clean, correctly split, correctly oriented, deduplicated document with its source metadata attached and a stable identifier that will follow it through every subsequent stage and into the audit log.

Stage Two: Understand

This is the stage people picture when they imagine document AI, and it is the stage that has improved most dramatically in the last three years. It is also the stage that gets over-credited for the value of the whole pipeline.

Understanding means converting a visual document into structured, typed data with a confidence score attached to every field. The invoice number is a string. The invoice date is a date in ISO format. The line items are an array of objects, each with a description, a quantity, a unit of measure, a unit price, and an extended amount. The currency is a three-letter code. The tax breakdown is a nested structure because a single invoice can carry three tax lines across two jurisdictions.

Three things separate a production understanding stage from a demo.

Layout independence matters more than accuracy on any single template. Any system can hit ninety-nine percent on invoices from a supplier it has seen ten thousand times. The interesting question is what happens on the first invoice from a new supplier with a layout nobody has ever seen. Template-based extraction fails completely here and requires a configuration project per vendor. Modern vision-language extraction reads the document the way a person does, using spatial relationships and semantic context rather than fixed coordinates, which means a new supplier costs zero configuration.

Field-level confidence is not optional. A single document-level confidence score of 0.91 tells you nothing actionable. Field-level scoring tells you that the invoice total scored 0.99, the PO number scored 0.97, and the tax jurisdiction on line seven scored 0.62. Now you can route intelligently, sending only the uncertain field to a human instead of the entire document.

Business context changes the reading. The same string "AS9100" means something specific on a certificate of conformance from an aerospace supplier and something entirely different in a marketing email. Understanding stages that carry domain context (what this customer buys, which suppliers are approved, what part numbers exist in the material master) produce meaningfully better results than context-free extraction. At Artificio this is why a deployment starts with a read of the customer's own master data rather than a generic model drop.

Understanding produces structured data with per-field provenance. Every extracted value carries a bounding box pointing back to the exact region of the exact page it came from. When somebody in accounting disputes a number nine months later, the system shows them the pixel it read.

Stage Three: Validate

Validation is where automation projects earn or lose their business case, and it is the stage that generic AI tools skip almost entirely.

Extraction tells you what the document says. Validation tells you whether what the document says is true, allowed, and actionable. These are different questions, and the second one carries all of the risk.

A supplier invoice for 4,200 dollars might be extracted with perfect accuracy and still be completely wrong to pay. The purchase order might have been closed. The goods receipt might not exist. The quantity might exceed what was received. The price might differ from the contracted price by more than tolerance. The supplier might be on payment hold. The invoice number might duplicate one paid in March. The tax treatment might be wrong for the ship-to jurisdiction. Perfect extraction of a bad invoice produces a fast, confident, fully automated error.

Validation runs three classes of check, and production systems need all three.

Internal consistency checks look only at the document. Do the line item extensions sum to the subtotal? Does the subtotal plus tax equal the stated total? Is the invoice date after the PO date and before today? Is the currency consistent throughout? These catch extraction errors and supplier arithmetic mistakes without any external system call.

System-of-record checks reach into the customer's actual data. This is the stage that requires real integration rather than a CSV export. Does PO 4500089321 exist and is it open? Does a goods receipt exist for the referenced line? What is the contracted unit price in the info record? Is the vendor blocked? At Artificio this typically runs against SAP through BAPI or OData calls, hitting the same function modules that a human clerk would trigger from a transaction screen. The point is that the agent asks the system of record the same questions a person would ask, in real time, before deciding anything.

Policy and tolerance checks apply the customer's own rules. A price variance under one percent and under fifty dollars posts automatically. Between one and five percent, it routes to the buyer. Above five percent, it routes to the category manager with the contract attached. These thresholds are business decisions, not technical ones, and they belong in a configuration layer that a finance manager can change without a developer.

The output of validation is not a yes or a no. It is a disposition with evidence. Something like: three-way match succeeded on quantity and PO, failed on price with a 2.1 percent variance against info record EINE 0004421, policy rule PV-02 applies, recommended action is route to commodity buyer, confidence 0.94, evidence attached.

That structure is what makes the next stage safe.

Stage Four: Act and Notify

An agent that produces a recommendation and stops is a very expensive report generator. The value shows up when the pipeline writes back into the systems where work actually lives, and when the humans who need to know something find out without checking a queue.

Acting means write access, and write access is where enterprise IT gets appropriately nervous. Three design decisions make it defensible.

Actions are typed and enumerated, not open-ended. The agent does not have general permission to do things in SAP. It has permission to execute a specific, small set of operations. Post an invoice via MIRO. Release a blocked invoice via MRBR. Create a parked document. Update a specific custom field. Each action is a named, versioned, tested capability with a defined rollback. The agent selects from a menu it did not write.

Actions are gated by the disposition from stage three. High-confidence clean matches post straight through. Everything else takes a different path. A price variance inside tolerance posts and notifies. A variance outside tolerance parks the document and creates a task. A missing goods receipt holds the invoice and pings the receiving supervisor rather than the buyer, because the buyer cannot fix a receiving problem. Routing intelligence is worth as much as extraction accuracy, and almost nobody measures it.

Actions are idempotent and reversible. Network timeouts happen mid-transaction. The same message gets delivered twice. An agent that posts the same invoice twice because a callback failed has created a real financial problem. Every write operation carries an idempotency key, and every action logs enough state to be reversed cleanly.

Notification deserves more thought than it usually gets. The default failure mode is a dashboard nobody opens. Effective notification reaches people where they already work, which in practice means email for approvals, Teams or Slack for exceptions, and a task in the ERP for anything that needs to live in an existing worklist. It also means notifying with enough context to act. "Invoice 88213 needs review" forces the recipient to go digging. "Invoice 88213 from Precision Alloys, 4,200 dollars, price is 2.1 percent above the contracted rate on part 7745-A, approve or reject" lets them answer from their phone in eleven seconds.

The best measure of this stage is not how many documents got processed. It is how many minutes of human attention each exception consumed.

Stage Five: Govern

Governance is the stage that does not run at a specific point in time. It wraps every other stage, and it is the difference between a pilot and a system that survives an audit.

Four capabilities live here.

Complete lineage. Every field in the final posted record traces back through the disposition that approved it, the validation checks that ran, the extraction that produced it, and the exact pixels on the exact page of the exact source document. When an auditor asks why a particular invoice was paid without a goods receipt, the answer is a click, not an investigation.

Human decisions captured as first-class data. When a reviewer overrides the system and approves a variance, that override is not just a state change. It records who, when, what they saw, what the system recommended, and why they disagreed. Six months of that data is the most valuable training and tuning asset a deployment produces.

The feedback loop. Corrections do not disappear into a log. A reviewer who fixes a misread tax code on invoices from one supplier is generating a signal that should change how that supplier's documents are read next month. Closing this loop is what makes a deployment get better with age rather than slowly degrade as document formats drift.

Control and observability. Threshold changes are versioned and attributable. Model versions are pinned and their swap dates recorded. Straight-through rates, exception rates, override rates, and average human touch time are tracked per document type and per supplier, because an aggregate number hides the three suppliers responsible for eighty percent of the exceptions.

Governance is also where data residency, retention, and access control get enforced. A pharmaceutical customer running batch record checks under regulated conditions has requirements that a marketing automation tool never has to think about. Building governance as a wrapper rather than an afterthought is what lets the same pipeline serve a mortgage originator under state lending rules and an aerospace supplier under AS9100 documentation requirements.

The Same Anatomy, Four Different Domains

The claim that every solution runs the same pipeline sounds like marketing until you trace it through cases that share nothing on the surface.

A supplier invoice at an aerospace manufacturer gets captured from a shared mailbox, understood into header and line-level fields, validated through a three-way match against SAP purchase orders and goods receipts with tolerance rules, acted on by posting through MIRO or parking for buyer review, and governed with full lineage back to the source PDF.

A certificate of analysis at a contract pharmaceutical manufacturer gets captured from a lab's email attachment, understood into a test result table with method references and specification limits, validated by comparing every result against the approved specification and checking the lab's accreditation status, acted on by recording a usage decision in SAP QM and releasing or blocking the batch, and governed with the audit trail that regulated production requires.

A self-employed borrower's tax documents get captured from a lender portal upload, understood into schedule-level income figures across two years, validated by recalculating qualifying income under the applicable agency method and cross-checking against bank statements, acted on by writing the income calculation into the loan origination system and notifying the underwriter of any variance above threshold, and governed with the documentation trail that a repurchase review would demand.

A student's academic credentials at a university get captured from an application portal, understood into institutions, dates, grades, and awarding bodies, validated against recognized institution registries and entry requirements, acted on by advancing or holding the application in the student records system, and governed with the record that an admissions appeal would require.

Same five stages. The domain knowledge changes. The validation rules change completely. The integration targets change. The anatomy does not.

Diagnosing Where It Actually Breaks

Once the five stages are clear, diagnosing a struggling automation program gets much faster. Most failures cluster into recognizable patterns.

When straight-through rates are low but extraction accuracy is high, the problem is validation, not understanding. The system reads correctly and then cannot decide safely because it lacks integration into the system of record or because the tolerance rules were never configured. Teams in this situation often buy a better extraction model and see no improvement.

When the same documents keep going to humans month after month, the problem is the governance feedback loop. Corrections are happening and nothing is learning from them.

When automation works in the pilot and stalls at scale, the problem is almost always capture. The pilot covered one channel. Production has six.

When finance blocks the rollout despite good results, the problem is governance depth. The numbers are fine and the audit story is not.

When users complain that the system creates more work, the problem is stage four routing. Exceptions are landing on the wrong people with insufficient context.

Each of these has a different fix, and picking the wrong one costs a quarter.

Building the First One

The practical way to start is not to build all five stages at full strength across every document type. It is to pick one document type with real volume, run it end to end through all five stages at modest scope, and measure the straight-through rate honestly.

One document type. One or two capture channels. Extraction on the fifteen fields that actually drive decisions rather than every field on the page. Validation against the real system of record, not a spreadsheet copy. Write-back on the single most common happy path, with everything else routed to a human with good context. Full lineage from day one, because retrofitting governance is painful and nobody enjoys explaining to an auditor that the first six months are not traceable.

That scope reaches production in weeks rather than quarters, and it produces the thing every subsequent expansion depends on. Real numbers from real documents about where the exceptions actually come from.

The aerospace manufacturer in the opening scenario did not start with every supplier. They started with the fourteen suppliers responsible for sixty percent of invoice volume, all arriving through one mailbox, matched against POs in one company code. Straight-through rate in month one was fifty-eight percent. By month four, with the feedback loop running and three tolerance rules retuned based on what the exceptions were actually teaching them, it was eighty-three percent.

The pipeline did not change. The pipeline never changes. What changed was how much the system knew about their specific suppliers, their specific tolerances, and their specific definition of an invoice worth a human being's morning.

That is what an agent is. Not a mind in a box. Five stages, each doing one job well, wired to the systems where the work actually lives, and getting quietly better every week because somebody built the loop that lets it learn.

Artificio builds AI agents for document-heavy enterprise workflows across manufacturing, pharmaceuticals, lending, and education. To talk through which stage is holding back your automation program, reach us at support@artificio.ai.