Agents your other systems can call

Most document-AI tools want to be the front door. You log into their portal, drag in a PDF, wait, and come back for the answer. That is fine for a pilot and a disaster for production. In a real P&C carrier or MGA, the document rarely arrives at a portal — it arrives inside a workflow that is already running in your policy-admin system, your claims platform, or your ingestion service. What that workflow needs is not another destination to babysit. It needs an API it can call, get a clean answer from, and move on.

That is the design principle behind InsightXtract’s Extraction API. Every agent you build in the console — a submission agent tuned for excess casualty, a loss-run agent, an FNOL agent — is automatically callable over HTTP by any system you authorize. Your architecture team stops treating extraction as a silo to integrate around and starts treating it as a capability they invoke from within the systems that already own the work.

The shape of a call

Concretely: a system on your side holds a scoped API key. It sends a document (or a pointer to one) to a specific agent version, names the output contract it expects, and gets back structured JSON it can map directly into its own schema. No screen scraping, no polling a portal, no human in the loop for the request itself.

sequenceDiagram
    participant PAS as Policy-Admin System
    participant API as InsightXtract Extraction API
    participant Agent as Submission Agent v3
    participant DB as PAS Database
    PAS->>API: POST /extract (API key, doc, agent=submission_v3, contract=v2)
    API->>API: Authenticate key, check scope
    API->>Agent: Run pinned agent version on document
    Agent-->>API: Structured fields per output contract v2
    API-->>PAS: 200 OK — JSON result (contract v2, _version metadata)
    PAS->>DB: Map fields to submission record, insert
    Note over PAS,DB: Caller owns the write; extraction is just a function call
                    

The important part of that sequence is what the caller does not have to do. It does not manage a session in someone else’s UI. It does not guess at a response format that might change next release. It names an agent version and an output contract version, and it gets exactly that shape back — every time.

A real P&C example: the policy-admin system asks for a submission’s fields

Picture a mid-market carrier writing excess casualty. A broker submission lands and a clearance clerk creates a shell record in the policy-admin system (PAS). Historically, that clerk would then re-key the named insured, the FEIN, the requested limits, the underlying schedule, and a dozen other fields off the ACORD 131 and the broker cover email — a slow, error-prone tax on every single submission.

With the Extraction API, the PAS does the asking. When the shell record is created, the PAS fires a call: “Here is the submission packet. Run the submission_v3 agent and give me the result in output contract v2.” Seconds later it has the named insured resolved to the actual insured (not the broker), the FEIN, the requested per-occurrence and aggregate limits, the underlying-limits schedule as line items, and the target effective date — all keyed to the field names the PAS already maps. The clerk reviews a pre-filled record instead of typing a blank one.

Because the request names the agent by version and the shape by contract, the PAS integration is stable. When the extraction team improves submission_v3 into submission_v4, the PAS keeps calling v3 until an architect deliberately re-points it — the mapping never breaks underneath a running system.

Scoped, version-pinnable API keys

An API this deep in your stack has to be governed like any other production credential. In InsightXtract, an API key is not a master password — it is a scoped grant. When you mint a key you decide exactly what it can reach: which projects, which agents, and whether it may pin to a specific agent version or float to the latest approved one.

• Project and agent scope. A key issued to the claims platform can be limited to the FNOL and loss-run agents and denied access to the underwriting submission agents entirely.
• Version pinning. A key can be locked to submission_v3 so a downstream integration never silently receives output from a newer, differently-behaving agent. Upgrading is an explicit, reviewed decision — not a surprise.
• Rate and quota limits. Each key carries its own ceiling, so a runaway batch job on one integration can never starve another team’s live traffic.
• Revocation without collateral damage. Because keys are per-integration, rotating or killing one has no effect on the others.

A versioned response you can build against

The response is where the “service, not silo” philosophy pays off. Every result is stamped with the agent version and output-contract version that produced it, so the caller — and any auditor later — knows exactly what logic generated each value. Downstream code can assert on those version fields and refuse to write anything it was not built to handle.

Per-call usage, tracked and attributable

When extraction becomes a shared service, you need to know who is using it and how much. Every call is logged against the key that made it: which system called, which agent and version ran, which document, how long it took, whether it succeeded, and the request ID that ties back to the exact result. That log is the backbone of three very practical things: chargeback across business units, capacity planning before a renewal-season surge, and forensic answers when someone asks “where did this value in the PAS come from?”

Because usage is attributed per key, an architecture team can see at a glance that the claims platform ran 4,200 FNOL extractions last month while the underwriting workbench ran 11,000 submission extractions — and can spot the moment a misconfigured retry loop starts hammering the API before it becomes a bill or an incident.

Why this matters to a CIO

• No new silo to operate. Extraction lives behind an API your existing systems call, so it fits your current architecture instead of demanding a parallel one with its own logins and its own queue to watch.
• Stable integrations. Version-pinned agents and versioned output contracts mean an extraction improvement never silently changes the data your PAS or claims system receives.
• Governed access. Scoped keys give each integration exactly the reach it needs and nothing more — and can be rotated or revoked in isolation.
• Full attribution. Per-call usage tracking supports chargeback, capacity planning, and end-to-end traceability from a value in your database back to the request that produced it.