A parser can read every word of a contract and still miss whether it was signed. Traditional OCR treats a stamp or a signature as noise, or as an unlabeled image blob. So a system can transcribe a permit or a certificate of origin end to end and never register whether it was signed, stamped, or sealed. For teams processing regulated paperwork, that is the one answer that matters. Agentic Document Extraction (ADE) closes the gap with attestation detection. At the parse stage, it finds these marks, assigns each a type, transcribes the text inside, and records where it sits on the page. Every mark comes back as one of four labels: SIGNED, E-SIGNED, STAMPED, or SEALED. Labels stack when a mark carries more than one, so an official filing stamped and signed in the same spot returns as [STAMPED][SIGNED]. The result is a queryable field, with grounding coordinates down to the line. "Is this document signed?" becomes a value your code can read, which lets you gate straight-through processing and route missing marks to a human automatically. One note for builders: attestation detection runs on DPT-3 Pro. Full breakdown, plus two real document examples, in the comments.

The documents worth automating are the ones you cannot afford to leak. A loan file carries income, identity, and account numbers on one page. A claims packet carries diagnosis codes. A utility contract carries pricing terms and counterparty data. Finance, insurance, healthcare, energy, and legal teams automate these workflows anyway. The volume leaves them no other option. Every vendor in that pipeline becomes another place your data lives. Security review starts there, long before anyone opens the accuracy benchmark. Agentic Document Extraction (ADE) is built for that review. Zero Data Retention, available on Team and Enterprise plans, processes your files in memory. Nothing is stored at rest. Nothing goes into model training. Your data stays in the region you pick, AWS US East or AWS EU. Encryption runs TLS 1.2 or higher in transit and AES-256 at rest. Enterprise teams can deploy ADE inside their own VPC. Every value ADE returns links to its place in the source document. That traceability is what a compliance reviewer actually asks for. Full detail on how we handle your data:

Every API call gives you a choice: wait for the result now, or collect it later. Agentic Document Extraction (ADE) works both ways when you run a Parse or Extract. The first way is synchronous. You send the request and wait on the line until the result comes back. Simple, and right when someone needs the answer immediately. The second is asynchronous. You submit the work, get a ticket, and pick up the result once it is done. Nothing sits waiting on an open line. The result is identical either way. Same Markdown from Parse, same fields from Extract. You are only choosing how long you wait. So why ever hand it off? Two reasons. Big jobs need it. A single asynchronous Parse Job takes files up to 1 GB or 6,000 pages, far more than one live request can hold. It also costs less. Waiting on the line runs at the top rate, since something is blocked on it. Hand the job off and you drop to a cheaper tier for the same result. The rule of thumb is one question. If a person or an agent is waiting on the answer, run it synchronously. If nothing is waiting, submit a job and pay less. Full breakdown, plus the service tier companion, in the comments.

Agentic Document Extraction (ADE) Parse returns three components: Markdown, structure, and metadata. Markdown is the full document as one string in reading order. Structure is a document tree of typed blocks with inline grounding. Metadata is a receipt tracking page counts, billing, and more. Five optional config options shape that output, each with a sensible default if you leave it out: page selection, table format, dropping a block from the Markdown string, per-line bounding boxes, and node-level Markdown. The video breaks down each one:

Your document parser is blind to what it is parsing! A loan packet lands as one PDF carrying pay stubs, bank statements, tax returns, and IDs. The parser reads every page the same way, so it pulls fields that fit none of them. The parser needs to know what it is reading before it reads it. The fix is classification before extraction, not after. Each page needs a label before any schema gets applied to it. Agentic Document Extraction (ADE) fixes this. ADE Classify evaluates every page concurrently and assigns a label per page. Pay stubs route to the pay stub pipeline. Bank statements route to their own. Pages that do not fit get flagged with a suggested class. ADE Extract then applies the matching Pydantic schema per type. A pay stub returns employee name, pay period, gross pay, and net pay. A bank statement returns bank name, account number, and balance. The schema follows the page, not the other way around. Every value comes back with a chunk reference and a page-level bounding box, so each number traces back to its source. Full working notebook example in the comments.

The hard part of RAG isn't finding the right chunk! When you chunk a document for RAG, each chunk lands in the index on its own, disconnected from the section it came from. So two chunks with identical text, but from completely different parts of the document, look exactly the same to a flat index. That becomes a problem the moment a question needs context from more than one section. The chunks come back, but how they relate to each other gets lost. ADE Section fixes this. It reads the parsed document, builds the actual hierarchy, and figures out where every chunk falls within it. That gets attached to the chunk before it's embedded. Once that's in place, a broad question can stay at the section level. A specific one can drop into a sub-chunk. You can scope a search to one part of a document instead of the whole thing. Citations get more accurate too. The model knows exactly which section a fact came from. Run ADE Parse, then run ADE Section.