How do you make an AI agent return null when a value is missing from the document?

Comparison: missing-data behavior by architecture

The problem: why LLMs invent values for missing fields

In autonomous-agent architectures, autoregressive language models naturally maximize the probability of the next token based on prior training. That introduces three critical failures in document flows:

┌────────────────────────────────────────────────────────────────────────┐
│  THE FAILURE OF FREE INFERENCE ON EMPTY FIELDS                         │
│                                                                        │
│  PDF contract with no due date ──► LLM without strict validation       │
│                                                  │                     │
│                                                  ▼                     │
│          The model tries to complete the semantic pattern              │
│                                                  │                     │
│                                                  ▼                     │
│       Returns: "due_date": "1 year from the signing date"              │
│                                                  │                     │
│                                                  ▼                     │
│    DATABASE ERROR: Type failure on DATE column (ISO 8601)              │
└────────────────────────────────────────────────────────────────────────┘

Completeness hallucination (semantic closure)

If the schema asks for "penalty_type" and the document never mentions penalties, the LLM often assumes typical legal-industry conditions instead of leaving the field empty.

Type pollution in the database

Answers such as "unknown", "not applicable", or "unspecified" break database schemas that expect strict integer, float, or date types.

Loss of flow control in agents

An agent that must run a conditional action (for example: "If the delivery note has no signature, notify the carrier") cannot evaluate the condition deterministically if the output is ambiguous text instead of a typed or boolean null.

The solution: deterministic validation in Claix

Claix solves this by enforcing schemas at the processing layer:

┌────────────────────────────────────────────────────────────────────────┐
│  DETERMINISTIC VALIDATION FLOW IN CLAIX                                │
│                                                                        │
│  Document (PDF/Excel/Doc/Img) + Schema ──► Claix multimodal engine     │
│                                                   │                    │
│                                                   ▼                    │
│                        Is there explicit textual evidence?             │
│                                ├── YES ──► Emit a typed value          │
│                                └── NO  ──► Emit native null            │
│                                                   │                    │
│                                                   ▼                    │
│  Typed JSON output: { "iban": null, "total": 1250.50 }                 │
└────────────────────────────────────────────────────────────────────────┘

1. Structured extraction against schemas

On Claix extraction endpoints (/api/pdf-json, /api/excel-json, /api/doc-json, /api/img-json, /api/txt-json), properties defined on the schema_id that are not found in the file are returned automatically as null:

{
  "success": true,
  "schema_utilizado": "Standard Invoice",
  "total_registros": 1,
  "data": [
    {
      "numero_factura": "F-2026-901",
      "fecha_emision": "2026-03-01",
      "fecha_vencimiento": null,
      "recargo_equivalencia": null,
      "total_factura": 1200.00
    }
  ]
}

2. Context-window and knowledge-space queries

On multi-question queries at document level (POST /document-context/{document_id}) or multi-document space level (POST /space-context/{space_id}), the ia_response array stays 1:1 with the user_ask questions. If the answer does not exist in any active document, the corresponding item is programmatic null:

{
  "user_ask": [
    "What is the total invoice amount?",
    "What penalty applies for late payment?"
  ],
  "ia_response": [
    "€1,200.00 according to invoice-901.pdf",
    null
  ]
}

Integration with the Agent-to-Agent (A2A) protocol

The Agent-to-Agent (A2A) protocol — an open standard under the Linux Foundation for interoperability between agents across frameworks and clouds — formalizes communication through Agent Cards, Tasks, and typed JSON-RPC 2.0 messages over HTTPS.

┌────────────────────────┐      A2A Task Request (JSON-RPC)      ┌────────────────────────┐
│  Orchestrator agent    │──────────────────────────────────────►│   Claix A2A agent      │
│  (LangGraph / CrewAI)  │◄──────────────────────────────────────│   Document specialist  │
└────────────────────────┘      Artifact with native null        └────────────────────────┘

When you delegate document tasks to Claix over A2A:

• Capability discovery: the orchestrator agent reads Claix’s Agent Card and learns the exact input and output schemas the document agent can process.
• Task handling: communication happens through structured tasks. The client agent requests a document extraction and receives a strictly typed Artifact.
• Clean contracts between agents: because missing fields travel as null, the receiving agent can continue the multi-agent chain without intermediate text-cleanup or validation steps.

Technical matrix: how to handle null fields in agents