Adept
AI Systems & Product Engineering
2026-05-22
7 min read

Tool-Calling Architecture: Preventing Hallucinatory Side-Effects

Designing resilient function calling and tool schemas that reject ungrounded arguments, enforce idempotency keys, and block unauthorized recursive execution.

Core Architectural Findings
Strict JSON Schema validation at the API boundary is the first line of tool defense.
Idempotency tokens prevent duplicated financial transactions during model retry loops.
Human-in-the-loop escalation patterns for high-consequence state transitions.

Tool-Calling Architecture: Preventing Hallucinatory Side-Effects

When a language model operates as a conversational chatbot, a hallucination is merely a factual inaccuracy on a screen. When a model operates in an autonomous agent architecture equipped with tool-calling capabilities (e.g., executing SQL queries, issuing refunds, modifying IAM roles), a hallucination manifests as an irreversible mutation in production state.

Building dependable tool-calling architectures requires treating model-generated function calls as untrusted network RPCs rather than reliable system executions.

Common Tool-Calling Failure Modes

Failure Mode 1: Argument Fabrication
LLM wants to call `deleteUser(userId)` -> Invented hallucinated `userId: "usr_99999"` -> Accidental deletion of arbitrary customer.

Failure Mode 2: Uncontrolled Recursive Invocation
Model enters an infinite retry loop on malformed tool response -> Thousands of redundant API calls -> Exhausted rate limits and runaway cloud spend.

Failure Mode 3: Semantic Injection via Tool Outputs
Tool returns untrusted database string containing injection payload -> Model interprets payload as system instructions -> Security perimeter breached.

The Four-Pillar Architecture for Safe Tool Calling

[ LLM Tool Invocation Intent ]
              │
              ▼
┌────────────────────────────────────────┐
│ 1. Strict Schema & Semantic Validation │
│    - JSON Schema Type Coercion Check   │
│    - Grounding Citation Invariant      │
└──────────────────┬─────────────────────┘
                   │
                   ▼
┌────────────────────────────────────────┐
│ 2. Idempotency & Replay Protection     │
│    - Unique Cryptographic Action UUID  │
│    - Replay-Protected Mutating State   │
└──────────────────┬─────────────────────┘
                   │
                   ▼
┌────────────────────────────────────────┐
│ 3. Consequence-Tiered Escalation Gate  │
│    - Tier 1 (Read-only): Auto-Execute  │
│    - Tier 2 (Low Risk): Rate-Limited   │
│    - Tier 3 (High Consequence): HITL   │
└──────────────────┬─────────────────────┘
                   │
                   ▼
┌────────────────────────────────────────┐
│ 4. Execution Sandbox in Adept Kawas    │
└────────────────────────────────────────┘

1. Pre-Execution Grounding Invariants

Never execute a tool call containing entity identifiers (UUIDs, email addresses, order IDs) unless those exact identifiers exist in the verified conversational context or retrieval cache:

$ ext{Valid}(A_{ ext{tool}}) = orall ext{id} in A_{ ext{args}}, quad ext{id} in mathcal{K}_{ ext{context}}$

If an identifier is absent from verified context, the tool execution is blocked before reaching backend databases.

2. Mandatory Idempotency Tokens

Because LLM agents frequently retry actions upon receiving ambiguous tool responses, every mutating action must require an idempotency key deterministically derived from the session trace and turn index:

$ ext{IdempotencyKey} = ext{HMAC-SHA256}( ext{SessionID} parallel ext{StepIndex} parallel ext{ToolName})$

This guarantees that retry loops cannot double-charge credit cards or duplicate database entries.

3. Consequence-Tiered Execution Sandboxing

Not all tools carry equal blast radius:

  • Read-Only Inspection (e.g., getAccountStatus): Instant autonomous execution.
  • Bounded Mutation (e.g., updateTicketTags): Autonomous execution gated by rate-limit windows.
  • High-Impact Mutation (e.g., wireTransfer, dropPartition): Mandatory human-in-the-loop authorization with cryptographically signed tokens.

Hardening Agents with Adept Kawas

Adept Kawas provides an enterprise-grade execution firewall that wraps LLM tool interfaces in deterministic validation layers, preventing unauthorized actions, argument hallucination, and cascading recursive loops.

Frequently Asked Questions

Why isn't standard JSON schema validation enough for tool calling? JSON schemas only validate structural types (e.g., "is this a string?"). They cannot validate semantic grounding (e.g., "does this customer ID actually belong to the authenticated session user?").

How does consequence-tiering affect agent execution latency? Low-consequence read tools execute in single-digit milliseconds through automated sandboxes, reserving interactive human confirmation prompts only for high-blast-radius actions.


Adept engineers deterministic execution guardrails and tool-calling firewalls for enterprise AI agents. Explore AI Systems & Product Engineering or learn how Adept Kawas secures production autonomy.

Applied Systems PracticeAI Systems & Product Engineering
Tooling PlatformAdept Kawas