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.

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.