Every CIO who has integrated an AI capability into a system of record knows the quiet dread of the vendor changelog: “We’ve improved the model.” Improved for whom? A better model can rename a field, drop a null it used to send, tighten a format, or start returning a value it previously left blank — and any one of those can break a nightly load into a policy-admin platform that was written against last quarter’s output. The improvement is real; so is the 2 a.m. page.

The tension is structural. The team improving the extraction agent and the team consuming its output have different clocks. Underwriting operations wants to ship a sharper prompt the moment it is validated. The integration team wants the payload to look exactly the way it did when they wrote and tested their parser. If those two desires share a single version number, one of them always loses. InsightXtract’s answer is to give them two version numbers.

Two axes, not one

InsightXtract tracks two independent things that most tools conflate:

  • The agent version — the prompts, rules, glossaries, and model behavior that determine how well a document is read. This moves forward often. v14, v15, v16… each one a little more accurate.
  • The output contract — the field names, types, nullability, and structure of the payload a consumer receives: what shape the result arrives in. This moves rarely and deliberately, because things depend on it.

The key move is that a new agent version does not force a new output contract. A smarter agent can populate the same contract more accurately. The consumer sees better data in the exact schema it already parses. The contract only changes when someone intends a schema change — and even then, the old contract keeps running for consumers still pinned to it.

flowchart TB
    subgraph AV["Agent version axis (accuracy)"]
      direction LR
      A1["agent v1"] --> A2["agent v2"] --> A3["agent v3
better ACORD 131 prompt"]
    end
    subgraph OC["Output contract axis (schema)"]
      direction LR
      C1["contract v1"] --> C2["contract v2
stable field schema"] --> C3["contract v3
adds new fields"]
    end
    A3 -->|"produces values for"| C2
    A3 -->|"can also produce"| C3
    C2 -->|"pinned"| K["Policy-admin API key
pin: contract v2"]
    C3 -->|"opt-in"| N["New consumer
pin: contract v3"]
    K --> PA["Policy-admin system
schema unchanged"]

Read the diagram along the arrows out of agent v3. The same improved agent feeds two contracts at once. The policy-admin system, pinned to contract v2, receives v3’s better numbers in v2’s unchanged schema. A newer consumer that wants the additional fields opts into contract v3. Nobody is forced to migrate on the agent team’s schedule.

The Agent Versions tab: improve freely, publish deliberately

All forward motion on the accuracy axis happens on the Agent Versions tab. Each version is an immutable snapshot — its prompts, rules, and glossaries frozen at publish time — with a note on what changed and who approved it. Underwriting ops can iterate as fast as they can validate, because publishing a new agent version is a safe act: it never reshapes anyone’s payload by itself.

InsightXtract console — The Agent Versions tab in the InsightXtract console a timeline of published versions (v1 v3) with the better ACORD 131 prompt change note on v3, its author, publish date, and an active badge
The Agent Versions tab — each version is an immutable snapshot with its change note and approver; publishing v3 sharpens accuracy without touching any consumer’s schema.

Because each version is a snapshot, rollback is trivial and reproduction is exact. If v3 turns out to over-correct on a rare ACORD variant, an Admin re-activates v2 in one action, and every record produced under v3 still carries the stamp that says so. Nothing is lost and nothing is guessed.

Output Contracts: the promise to downstream systems

The Output Contracts screen is where the schema promise lives. A contract declares the fields a consumer will receive, their types, whether they can be null, and their format — the interface your integration team wrote code against. Contracts are versioned independently and, critically, old versions keep serving. Publishing contract v3 does not retire v2; it runs alongside it.

# Output contract v2 — the schema a consumer parses contract: acord_131_extract version: v2 # still served; not retired by v3 fields: named_insured: { type: string, nullable: false } policy_number: { type: string, nullable: true } effective_date: { type: date, format: "YYYY-MM-DD" } total_premium: { type: decimal, currency: USD } # contract v3 ADDS naics_code + sic_code — v2 consumers never see them
InsightXtract console — The Output Contracts screen contract acord_131_extract showing v2 and v3 side by side, with a field-level diff highlighting the two fields (naics_code, sic_code) added in v3 and both versions marked serving
The Output Contracts screen — a field-level diff between contract v2 and v3, with both versions actively serving so a v2 consumer is never disturbed by a v3 change.

Pinning: the consumer chooses its own stability

The two axes meet at the API key. When the integration team provisions a key for the policy-admin system, they pin it to output contract v2. From that moment, every response to that key conforms to contract v2 — regardless of which agent version is active behind the scenes. The pin is the guarantee, and it belongs to the consumer, not the vendor.

InsightXtract console — The API key detail in the console a key named policy-admin-prod with a Pinned to: output contract v2 setting, the active agent version (v3) shown separately, and a note that responses always match the pinne
A version-pinned API key — “policy-admin-prod” is locked to contract v2; the active agent may be v3, but every payload to this key matches the v2 schema.

This is what makes upgrades boring in the best sense. Underwriting ops publishes agent v3 with the better ACORD 131 prompt on a Tuesday. The policy-admin system’s nightly load runs Tuesday night against contract v2, exactly as it did Monday — same fields, same types, same nullability — only now the total_premium and effective_date values are more reliably correct because v3 reads the form better. No parser change. No emergency ticket. No coordination meeting.

A concrete P&C timeline

Put the pieces on a calendar to see how the two clocks stay independent:

  • Q1 — Integration team builds the policy-admin feed against contract v2, running on agent v2. Pins the production key to contract v2. Ships.
  • Q2 — Underwriting ops notices agent v2 mis-reads the endorsement effective date on a particular ACORD 131 layout. A Builder revises the prompt; an Admin publishes agent v3. The policy-admin feed is untouched — still contract v2, now with cleaner dates.
  • Q3 — A new analytics consumer wants NAICS and SIC codes. Rather than disturb the policy-admin feed, the team publishes contract v3 (v2 plus the two new fields) and pins the analytics key to it. Two contracts serve in parallel.
  • Q4 — When the integration team is ready — on their schedule — they test against contract v3 and migrate the policy-admin key. Not a minute before.

Why not just version everything together?

A single version number for “the whole thing” forces every accuracy improvement to look like a breaking change to downstream systems — so teams either stop improving the agent or start dreading every release. Splitting accuracy from schema lets the agent improve continuously while the interface stays as still as the consumer needs it to be.

Why this matters to the business

  • Improvement without breakage. The agent can get better every week while every integration keeps parsing the exact payload it was built for.
  • Migrations on the consumer’s clock. Because old contracts keep serving, downstream teams adopt new fields when they are ready — never under duress from an upstream release.
  • Reproducibility and clean rollback. Immutable agent versions plus pinned contracts mean any historical result can be reproduced and any regression reverted in a single action.
  • Fewer coordination taxes. The accuracy team and the integration team stop negotiating release windows, because their changes no longer collide on one version number.