Extend

Outbound reach is real and documented per mechanism. The External Data Validation Step at docs.extend.ai/workflows/workflow-steps/external-data-validation-step calls a customer's own system mid run to check an extracted value, an outbound call inside a running process and the clearest form of tool use here.

Webhooks push run outcomes into the customer's systems, with configuration and an event catalog documented. A GitHub App integration is documented under Workflows. UI Components let Extend's review interface be embedded in a customer's own product. The platform is reachable by REST API, SDKs and a CLI, so a customer wires it wherever needed.

The gap is categorical. Extend publishes no catalog of prebuilt business connectors: no Salesforce, Workday, NetSuite or SharePoint connector list appears in the documentation. It is document processing infrastructure a customer's engineers integrate, not a platform pre wired to their estate, and the named counterparties are file types (a Supported File Types page) rather than applications. The agent acts on documents and hands structured data back to the caller; the Edit API, which fills forms and generates documents, acts on a document, which is not a system.

Sourcedocs.extend.ai Workflows, Webhooks and General navigationread 2026-09-12

The workflow section documents step types individually, and the list makes this orchestration rather than a pipeline: Parse Step, Validation Step, Router Step, Conditional Steps, External Data Validation Step and Conditional Extraction Step, each with its own page at docs.extend.ai/workflows/workflow-steps. A router and conditional steps are branching primitives: the run takes different paths depending on what the previous step found. Formulas at /workflows/formulas add computation between steps.

External Data Validation reaches outside mid run: a workflow pauses to check an extracted value against the customer's own system of record before continuing, holding state across a call the platform does not control.

Durability and versioning are first class. Workflow Versioning has its own page, Reviewing Workflow Run gives per run inspection, and Async Processing and Batch Processing are documented separately, so a run survives beyond a request, at volume. Multifile Extraction in Workflows handles one logical document arriving as several files.

The five APIs compose rather than stack: Parse, Extract, Split, Classify and Edit work alone or together, and Extend's writing contrasts this with rivals where "multi-step workflows require custom engineering since capabilities are bundled into a single endpoint." The participants are distinct: the pipeline, the Review Agent correcting low confidence extractions, the human reviewer at the confidence gate, and the customer's external system answering a validation call.

Sourcedocs.extend.ai Workflows navigation with extend.ai/resources document processing APIs writingread 2026-09-12

The product sits upstream of retrieval. Extend's homepage calls it "document processing infrastructure for AI agents," and its job is to "convert unstructured documents into structured, LLM-ready markdown." It produces the grounding material that someone else's retrieval system consumes, and manufacturing the corpus is not the same as being grounded in one.

Extend's work is per document. The five capabilities (Parsing, Extraction, Splitting, Classification, Editing) operate on the file in front of them. There is no index, semantic search surface, vector store, accumulated corpus a customer queries, or citation back to source anywhere in the documentation. Multifile Extraction handles one logical document arriving as several files, a batching concern rather than a corpus.

What persists is configuration, not knowledge: extraction schemas, workflow versions, evaluation sets and processors are versioned, but they describe how to read a document rather than what the organization knows. Evaluation sets are labeled ground truth for scoring, and the Optimization section has its own Memory page. The documentation navigation lists every capability by name, and none of these appears.

Sourcedocs.extend.ai Capabilities navigation with extend.ai homepageread 2026-09-12

The review gate is documented across three surfaces, each with its own page. Confidence Scores at docs.extend.ai/extraction/confidence-scores are the signal the gate fires on. A Review Agent at /extraction/review-agent uses vision language models to review and correct low confidence extractions. And Reviewing Workflow Run at /workflows/reviewing-workflow-run is the human facing surface where a run is inspected before its output is accepted. Extend's own writing names a human in the loop review UI alongside confidence scoring and LLM-as-a-judge scoring.

The gate is on the agent's own output. An extraction below the confidence threshold does not flow downstream; it is routed to a person who inspects and corrects it. For a product whose value is that extracted data is trustworthy enough to write into a finance or healthcare system, the hold before acceptance is the product.

Two validation steps are workflow primitives, extending the gate to anywhere in a pipeline: /workflows/workflow-steps/validation-step and /workflows/workflow-steps/external-data-validation-step. The second validates an extraction against the customer's own system of record before accepting it, an automated check that can block a run, placed where the customer chooses. Confidence threshold routing fires on a measured signal rather than a rule someone remembered to set.

Sourcedocs.extend.ai extraction and workflows navigation, with extend.ai/resources document processing APIs writingread 2026-09-12

Security and Compliance is a three page section of the documentation site at docs.extend.ai, which is built on Fern.

The SOC 2 claim carries a hedge. Extend states: "We maintain controls aligned with SOC 2 Type II requirements. Reports and security documentation are available in the Trust Center," with a trust center at trust.extend.ai. Aligned with sits below certified. The other two claims are unhedged, and one is contractual: "Extend is HIPAA compliant...

We can execute Business Associate Agreements (BAAs)," available across all three deployments. A signable BAA is a legal instrument accepting liability as a business associate, and HIPAA has no certificate to hold. "Extend is GDPR compliant" is stated flatly alongside it, with a documented complaint procedure carrying named service levels: acknowledgment within 3 business days and a response within 30.

User roles and permissions have their own page, docs.extend.ai/general/user-roles-and-permissions, alongside API authentication documentation and a Data Handling page covering storage, retention and deletion. Per region deployment isolation adds a data boundary control.

The SOC 2 wording is the weak link; the stronger assurance comes from HIPAA with executable BAAs and GDPR compliance, backed by a trust center with reports.

Sourcedocs.extend.ai/security/compliance with the docs navigationread 2026-09-12

A run level record is a documented page: Reviewing Workflow Run at docs.extend.ai/workflows/reviewing-workflow-run. A surface for inspecting an individual run of a pipeline is a record of what the agent did, which output quality reporting alone does not provide.

Workflow Versioning sits beside it at /workflows/workflow-versioning, so a run can be read against the configuration that produced it, which is what makes a run record usable months later. Evaluation adds Publishing Processors, a documented promotion step, so what changed and when is itself recorded.

The quality layer corroborates it: field level and document level accuracy reports, confidence scores per extraction, and regression detection across evaluation sets. Extend runs a public status page at status.extend.ai and documents webhook events, so a customer's own systems are notified of run outcomes rather than polling.

What a run record contains (step level timing, inputs, model version, retention, export) is not spelled out.

Sourcedocs.extend.ai workflows and evaluation navigationread 2026-09-12

A memory feature has its own page, docs.extend.ai/optimization/memory, under Optimization beside Composer, the background agent that refines extraction schemas across runs. Placed in the section about improving over time, it describes retained state rather than a session buffer.

Its scope, lifetime and access rules are not spelled out. The state appears to be written by the system from its own runs: Composer is described as a background agent that experiments with prompt and schema variants and refines them. User roles and permissions and per deployment isolation exist, though the scope of memory itself is not stated. No lifetime or purge path is published for memory; a Data Handling page covering storage, retention and deletion exists at /security/data-handling. Whether the API, SDKs, CLI or MCP server expose the memory object is not stated.

A documented, agent written, cross run store goes beyond a database doing the job of memory.

Sourcedocs.extend.ai Optimization navigation with extend.ai/resources Composer writingread 2026-09-12

Extend publishes a named region list: deployments are enumerated as us1, us2 and eu1 in the compliance documentation, with an API reference page at /api-reference/deployments, so the region is a parameter a customer sets.

The EU region is specified to the datacenter: "eu1 stores and processes customer document data within the EU (primary infrastructure in Frankfurt, AWS eu-central-1)." Naming the cloud region rather than the country is what a GDPR bound buyer's procurement team asks for.

The disclosure is candid about its own limit: "Operational telemetry that does not include document content (for example, error and performance monitoring) may be processed by vendors outside the EU." Separating document data from telemetry and saying which leaves the region describes a real boundary.

A separate deployment models page at docs.extend.ai/security/deployment-options is referenced from the compliance page as covering deployment models beyond the three regions, and HIPAA compliant processing is stated as available across all of them. Whether those models include a self hosted or private cloud tier is not stated.

Sourcedocs.extend.ai/security/complianceread 2026-09-12

Generation is the opposite of a catalog, and it is Extend's deliberate position. Composer takes a few of the customer's own sample documents, generates the extraction schema and refines it in background optimization loops. The unit a customer ends up with is built for their documents, not selected from a library, and the vendor sells that as the advantage on the messy documents the product exists for.

Nothing in the documentation is a browsable set of adoptable units. The Capabilities section lists five APIs, which are product surfaces; workflow steps are primitives a customer assembles; processors under Evaluation are the customer's own configurations being promoted; UI Components are embeddable interface elements. None is a working unit a buyer selects and runs on day one.

No industry or document type packs appear, the most conspicuous absence given the product. Extend serves finance, healthcare and logistics and names Brex, Square, Checkr and Flatiron Health as customers; an invoice, claims or bank statement pack would be the obvious thing to ship, and none is offered. Supported File Types is a compatibility list. No schema gallery, document type template library or shareable processors are published, and the dashboard at dashboard.extend.ai sits behind login.

Sourcedocs.extend.ai overview and full navigation, with extend.ai/resources document processing APIs writingread 2026-09-12

Event driven coverage is documented as its own section: Webhooks at docs.extend.ai/webhooks, with Configuration, Events and Best Practices pages. The event catalog comes with delivery configuration, so a customer's systems are notified when a run completes or fails rather than polling.

Async and batch processing each have their own page, which is how long running document work is invoked at volume: submit and be called back. A GitHub App integration under Workflows is a second invocation path, with a commit or pull request event in the customer's repository driving a document pipeline.

Invocation surfaces are several but developer facing: the REST API, the CLI, the MCP server, the Studio dashboard at dashboard.extend.ai, the GitHub App, and embeddable UI Components that put Extend's review interface inside a customer's own product, so a reviewer working in the customer's application reaches Extend without knowing it.

No schedule class is documented: no cron, recurring run or scheduled batch appears in the General or Workflows pages. Extend is invoked by its customer's systems rather than waking itself, a coherent design for infrastructure. There is also no Slack, Teams or email surface, because the buyer is an engineering team.

Sourcedocs.extend.ai Webhooks, General and Workflows navigationread 2026-09-12

Extend discloses routing across more than one model. Its own writing describes "an agentic OCR pipeline with intelligent routing through vision AI and custom-trained VLMs," an ensemble of frontier models combined with proprietary context engineering, and a Review Agent that uses vision language models to check low confidence extractions. The platform runs several model classes and chooses between them per document.

Customer control exists over mode and version, not provider. Multiple performance modes, tuned for low latency, bulk cost efficiency or maximum accuracy, are toggled per job. Model versioning is a top level section of the documentation at docs.extend.ai/model-versioning, beside Documentation, API Reference and Changelog, so model change is something customers manage; pinning a version is real control over which model runs.

Control of the model itself stays with Extend. A customer can pin Extend's version and pick a speed, cost and accuracy profile, but nothing published lets them nominate a provider, bring their own model or route a step to a named external LLM. The models are Extend's own, including custom trained VLMs, and accuracy claims in the mid to high nineties rest on Extend controlling the ensemble.

Sourcedocs.extend.ai primary navigation with extend.ai/resources document processing APIs writingread 2026-09-12

Extend's developer site has a Dev Tools section listing four surfaces, each with its own page: SDKs, CLI, MCP Server and UI Components, at docs.extend.ai/sdks, /cli, /mcp and extend.ai/ui. A published MCP server plus SDKs plus a CLI plus a REST API is an unusually wide external surface.

The API is documented at reference depth. docs.extend.ai carries a top level API Reference beginning at /api-reference/authentication, a /api-reference/deployments page for region selection, a Webhooks section covering configuration, events and best practices, and a versioned documentation build stamped v2026-02-09. Rate limits, async processing and batch processing each have their own page.

The site is built for machine readers as well: "For AI agents: a documentation index is available at the root level at /llms.txt. Append /llms.txt to any URL for a page-level index, or.md for the Markdown version of any page." That shows a structured developer surface exists. A GitHub App integration is documented under Workflows, and UI Components let a customer embed Extend's review interface in its own product, an extension surface few vendors offer.

The MCP server exposes Extend to a customer's assistant, while the External Data Validation step reaches the other way, calling a customer's own systems mid workflow. The SDK, CLI and MCP surfaces are named in the vendor's navigation rather than enumerated tool by tool.

Sourcedocs.extend.ai Dev Tools navigation, API Reference and Webhooks sectionsread 2026-09-12

Evaluation is a documented product section rather than a claim. The Evaluation section has six pages: Overview, Processors, Publishing Processors, Creating Evaluation Sets, Running Evaluation Sets, and Calculating Array Accuracy, at docs.extend.ai/evaluation.

Evaluation sets are the core artifact: a customer assembles documents with known correct answers, runs a configuration against them and reads a score. That is a change under test with a readable comparable result.

Publishing processors is the gate that separates this from a metrics dashboard. A processor is a configuration and publishing is a promotion step, so a change is measured before it reaches production rather than monitored after. Workflow Versioning at /workflows/workflow-versioning gives the rollback side, and a Test Environment Guide at /general/test-environment-guide gives a separate place to run against.

The results are readable and specific: field level and document level accuracy reports, regression detection across runs, confidence scores per extraction, and a page on calculating array accuracy, how to score an extraction that returns a list, which is the hard case in document extraction. Extend's own writing adds LLM-as-a-judge scoring alongside automated accuracy reports.

The optimization loop is controlled. Composer, a background agent at /optimization/composer, experiments with prompt and schema variants and refines them, measured against the evaluation sets rather than left to drift. A self improving loop with a published scoring surface is different from absorbed learning.

Sourcedocs.extend.ai Evaluation and Optimization navigation, with extend.ai/resources document processing APIs writingread 2026-09-12

Every path in is an API call, an SDK, the CLI, the MCP server, a webhook or an upload, and every path out is structured data, markdown or a filled document returned to the caller. There is no interface for an agent to drive because the input is a file, so how often it breaks when interface elements change is not a question that applies.

None of the three modalities appears across a documentation navigation that lists every capability, tool and workflow step individually: no hosted or local browser, desktop session, remote computer control, RPA, recorder or extension. The Dev Tools section's UI Components are interface elements Extend ships for a customer to embed, the reverse relationship.

Two adjacent items fall short of computer use. The Editing capability, with its Detect Form page at docs.extend.ai/editing/detect-form, detects fields in a document and fills them; that is form field detection inside a file, not an agent operating a form in a browser. Vision language models and an agentic OCR pipeline read the pixels of a scanned page, which is ingestion rather than computer use: a model that can read a degraded scan is not a model that can click a button. Extend is infrastructure other products build on, integrated by API precisely so that no screen is involved.

Sourcedocs.extend.ai full navigation including Capabilities, Dev Tools and Editing sectionsread 2026-09-12