Most enterprise AI agent failures do not start with the model choosing a tool.

They start with a weak contract around what that tool means. A function schema says send_email(to, subject, body). It does not say who is allowed to send, whether the recipient is external, what approval state is required, whether the operation is idempotent, how retries behave, what evidence must be logged, what happens on partial failure, or how the action is reversed.

That missing contract is where a helpful assistant becomes an uncontrolled production actor.

The practical question for CIOs, CISOs, enterprise architects, AI platform engineers, and product teams is:

What must a tool contract define before an enterprise AI agent is allowed to call business systems, write records, send messages, trigger workflows, or touch privileged APIs?

The answer is not “better prompting.” Treat every agent tool as a governed interface with five parts: a typed schema, an authority model, execution semantics, evidence requirements, and failure behavior. The model may propose a call. The tool contract tells the runtime what must be validated, authorized, approved, executed, logged, retried, compensated, or denied.

This article complements the broader safe tool registry, policy-as-code, Zero Trust delegation, agent audit logs, human approval patterns, and access reviews. The registry says which tools exist. Policy says whether an action is allowed. The contract defines exactly what a valid action is.

The Contract In One Paragraph

An enterprise AI tool contract is a versioned runtime specification for a tool an agent may request. It defines the input and output schema, allowed operations, actor and resource attributes, data classes, side-effect level, approval requirements, idempotency behavior, retry rules, timeout budget, rate limits, compensation path, audit fields, and contract tests. A tool contract should be enforced by the orchestration or broker layer before execution. It should never rely on the model to interpret a natural-language tool description correctly.

Function Schemas Are Not Enough

A narrow function schema is useful. It gives the model and runtime a structured shape:

1
2
3
4
5
6
7
8

{
  "name": "crm.update_case_status",
  "parameters": {
    "case_id": "string",
    "status": "string",
    "reason": "string"
  }
}

That shape is not a production contract.

It leaves out the questions that matter when the call changes enterprise state:

The OpenAPI Specification is a useful reference because API descriptions let humans and machines understand service capabilities without reading implementation code. JSON Schema is useful because validation should be explicit, machine-checkable, and versioned. But enterprise AI agents need additional control semantics around authority and side effects. A JSON object can be valid and still unsafe.

A Useful Contract Has Five Layers

Think of the tool contract as five layers around the downstream API.

1
2
3
4
5
6
7

agent proposal
  -> interface contract
  -> authority contract
  -> execution contract
  -> evidence contract
  -> failure contract
  -> brokered tool execution

This split prevents teams from burying production controls in tool descriptions. The model receives enough description to propose valid arguments. The runtime receives enough contract metadata to enforce the boundary.

The Minimum Tool Contract

A practical contract can start with this shape:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

{
  "contract_version": "ai.tool.contract.v1",
  "tool_id": "crm.update_case_status",
  "tool_version": "2026.09.21",
  "owner": {
    "business_owner": "customer_operations",
    "technical_owner": "crm_platform",
    "security_owner": "application_security"
  },
  "purpose": "Update the lifecycle status of a support case.",
  "risk": {
    "tier": "tier_3_customer_visible",
    "side_effect": "write",
    "reversibility": "compensating_action_available",
    "data_classes": ["customer_pii", "commercial_confidential"]
  },
  "authority": {
    "allowed_agents": ["support_resolution_agent"],
    "allowed_human_roles": ["support_manager", "case_owner"],
    "execution_identity": "brokered_delegation",
    "proposal_only": false,
    "approval_required_when": [
      "customer_visible == true",
      "case_value_eur > 10000",
      "policy_exception == true"
    ]
  },
  "input_schema": {
    "type": "object",
    "additionalProperties": false,
    "required": ["case_id", "new_status", "reason_code"],
    "properties": {
      "case_id": { "type": "string", "pattern": "^case_[0-9]+$" },
      "new_status": { "enum": ["pending_customer", "resolved", "escalated"] },
      "reason_code": { "enum": ["customer_confirmed", "duplicate", "requires_engineering"] },
      "customer_visible": { "type": "boolean", "default": false }
    }
  },
  "execution": {
    "idempotency_key": "required",
    "idempotency_scope": "case_id + approved_action_hash",
    "automatic_retries": "validation_errors_never_side_effects_once",
    "timeout_ms": 3000,
    "rate_limit": "30_per_hour_per_agent",
    "dry_run_supported": true
  },
  "evidence": {
    "required_before_execution": [
      "trace_id",
      "human_user_id",
      "agent_id",
      "policy_decision_id",
      "approval_id_when_required",
      "argument_hash"
    ],
    "required_after_execution": [
      "business_object_id",
      "before_state_hash",
      "after_state_hash",
      "result_class",
      "downstream_request_id"
    ]
  },
  "failure": {
    "on_policy_denial": "return_denied_no_side_effect",
    "on_validation_error": "return_correctable_error",
    "on_downstream_conflict": "return_pending_manual_review",
    "on_partial_success": "emit_incident_event_and_compensate_if_safe"
  },
  "contract_tests": [
    "denies_unknown_status",
    "requires_approval_for_customer_visible_update",
    "rejects_retry_without_idempotency_key",
    "logs_before_and_after_state"
  ]
}

This is intentionally more than a model-facing tool schema. Some fields guide the model. Most fields guide the runtime, policy engine, approval service, audit pipeline, and reviewer.

Separate Proposal From Execution

The safest enterprise pattern is to treat model output as a proposal:

1
2
3
4
5
6
7
8
9
10
11
12

model proposes:
  tool_id: crm.update_case_status
  arguments: {...}
  evidence: sources and explanation

runtime decides:
  schema valid?
  actor authorized?
  approval present?
  idempotency key valid?
  downstream state still matches?
  evidence emitted?

That distinction matters because the model should not decide whether its own call is allowed. OWASP’s AI Agent Security Cheat Sheet calls out least privilege, tool authorization, high-impact action controls, monitoring, and adversarial validation for agents. My engineering interpretation is direct: a model-facing schema is the request surface, not the authority surface.

For Tier 0 and Tier 1 tools, proposal and execution may happen in one brokered step. For Tier 3 and Tier 4 tools, the proposal should become a pending action with a narrow approval scope.

The contract lets useful AI work continue while keeping the final authority in deterministic systems.

Idempotency Is A Safety Control

Retries are one of the places where agent systems become quietly dangerous.

An agent runtime may retry because the model asked again, the network timed out, a queue redelivered a message, the user clicked twice, or the orchestrator recovered after a crash. If the tool contract does not define idempotency, the same apparent request can create duplicate tickets, send duplicate emails, issue duplicate refunds, or apply a state transition twice.

RFC 9110 on HTTP Semantics is a useful baseline because it distinguishes safe and idempotent method semantics. Do not assume those semantics survive once an AI tool wraps a business workflow. A POST /send-email tool is not safe because the agent call is JSON-shaped. A crm.update_case_status tool may be idempotent only if the contract binds the call to a stable action hash and downstream state.

Use explicit retry classes:

For any side-effectful tool, the contract should define:

• required idempotency key;
• idempotency scope;
• duplicate-call behavior;
• timeout reconciliation path;
• downstream correlation ID;
• whether a retry is allowed after unknown execution status.

If the runtime cannot tell whether an action happened, do not let the model “try again.” Move the action into reconciliation or human review.

Validate Inputs, Then Normalize Outputs

Input validation gets most of the attention. Output contracts matter just as much.

An AI agent often feeds one tool result into the next step. If the first tool returns an ambiguous object, raw HTML, untrusted instructions, excessive data, or a downstream error disguised as success, the next model call may treat it as trusted context.

Use a normalized output envelope:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

{
  "tool_id": "crm.update_case_status",
  "contract_version": "ai.tool.contract.v1",
  "trace_id": "trace_01K...",
  "execution_status": "success",
  "result_class": "business_state_changed",
  "business_object": {
    "type": "case",
    "id": "case_91283",
    "state_hash": "sha256:..."
  },
  "safe_summary": "Case status changed from pending_customer to resolved.",
  "model_visible_fields": {
    "case_id": "case_91283",
    "new_status": "resolved"
  },
  "not_model_visible": {
    "downstream_request_id": "crm_req_781",
    "raw_response_location": "secure-log-ref"
  }
}

The output contract should decide what the model may see. Raw downstream responses may contain sensitive data, system prompts, support notes, legal content, customer identifiers, or HTML/script fragments. Treat tool output as untrusted input unless the contract normalizes it.

The NCSC secure AI system development guidance is useful because it frames secure design, development, deployment, and operation as a lifecycle concern. Tool contracts are one place where that lifecycle becomes executable: validation, secure defaults, logging, update management, and operations are not separate afterthoughts.

Evidence Belongs In The Contract

If a tool can change business state, its contract should define the evidence emitted before and after execution. Do not leave audit fields to each product team.

At minimum, log these fields for side-effectful tools:

OpenTelemetry’s logs data model is a useful reference for trace IDs, timestamps, severity, resources, instrumentation scope, attributes, and event names. You do not need every AI event to look like every infrastructure log, but you do need correlation. Agent tool execution should be visible in the same operational universe as application traces, policy decisions, incidents, and downstream API calls.

The NIST Generative AI Profile reinforces the broader point: generative AI risk management has to account for lifecycle, actors, measurement, and controls. A contract that cannot produce evidence cannot support governance, incident response, or access review.

Failure Modes To Design For

A serious tool contract names failure modes instead of collapsing everything into error.

This table is often where teams discover that a “simple tool” is actually a workflow boundary. Good. That discovery should happen before production, not during an incident.

Contract Tests Before Production

Every high-risk tool contract should have automated tests that exercise the controls, not only the happy path.

Useful test cases include:

• unknown enum value is denied before execution;
• additional JSON property is rejected;
• user from wrong region cannot delegate the tool;
• agent can propose but not execute a privileged operation;
• customer-visible action creates pending approval;
• approval expires and cannot be reused;
• idempotency key prevents duplicate side effects;
• automatic retry is disabled after uncertain timeout;
• before/after state evidence is emitted;
• raw downstream response is not passed back into model context;
• contract version change triggers review;
• policy denial cannot be bypassed by choosing an adjacent tool.

These are not model evals in the narrow sense. They are contract tests for the execution boundary. They should run when the tool schema changes, when policy changes, when the downstream API changes, when the agent version changes, and after incidents.

How To Roll This Out

Do not start by writing a universal contract specification for every possible tool. Start with the tools that can cause the most damage.

1. Inventory side-effectful tools: external messages, writes to customer records, financial actions, IAM changes, production changes, deletes, and bulk exports.
2. Add contract metadata to the existing tool registry: risk tier, side effect, reversibility, idempotency, approval, evidence, and owner.
3. Put a broker in front of execution if agents currently call APIs directly.
4. Convert the top five high-risk tools to proposal-first execution.
5. Add idempotency keys and uncertain-timeout reconciliation.
6. Normalize tool outputs before they re-enter model context.
7. Write contract tests for denial, approval, retry, logging, and partial failure.
8. Feed contract fields into policy-as-code and audit logs.
9. Review contract drift during AI access reviews.

The first milestone is not elegance. It is removing ambiguous authority from the highest-risk tool calls.

The Line I Would Draw

If an AI agent can call a tool that reads restricted data, writes enterprise records, sends external messages, triggers money movement, changes permissions, modifies production systems, or affects a customer-visible workflow, that tool needs a contract stronger than a function schema.

The model should understand the interface. The runtime should enforce the contract. Security should review the authority. Operations should see the evidence. Business owners should own the risk. And retries should never be allowed to invent a second side effect because the first one was poorly specified.

That is the practical boundary: AI agents can be useful production actors only when their tools are designed like production interfaces.