What Is an Abstract Data Type?

What Is an Abstract Data Type?

An abstract data type (ADT) is a mathematical model of a data structure defined entirely by the operations it supports and the rules those operations obey — never by how it is laid out in memory. A stack is the canonical example: push, pop, and peek with last-in-first-out ordering. A map is another: get, put, delete with key uniqueness. Two implementations (array-backed vs linked) can satisfy the same ADT and be swapped without breaking callers. The concept matters in LLM systems because every tool schema, JSON-output contract, and agent memory interface is, formally, an ADT.

Why It Matters in Production LLM and Agent Systems

When an LLM calls a tool, it does not see the implementation — it sees the schema. The schema is the ADT. If the model returns a book_flight(flight_id, passenger_name) call but the schema expected passengerName (camelCase), the underlying execution fails regardless of how reliable the storage layer is. The ADT contract is the only thing the model can be wrong about.

The pain shows up across roles. A backend engineer rolls out a new tool version that adds an optional field — the LLM, fine-tuned on the prior version, starts emitting calls that violate the new constraints 6% of the time. A platform engineer finds an agent’s memory layer corrupted because two agents wrote to the same key with conflicting types — neither validated against the ADT. A compliance reviewer reads a structured medical record and finds the model populated age with a string (“forty-two”) instead of an integer, and no checker caught it.

In 2026 agent stacks built on Model Context Protocol or OpenAI Agents SDK, every tool exchange is an ADT contract. Multi-step pipelines amplify violations: a malformed output at step two breaks step three’s parser, and the trace is full of half-successes that look like task failures. Treating the schema as an enforceable ADT — not a hint — is what separates a prototype from a production agent.

How FutureAGI Handles Abstract Data Types

FutureAGI’s approach is to treat every tool schema, JSON-output spec, and structured-output contract as an enforceable ADT and run validators against it on every trace. The SchemaCompliance evaluator checks that LLM outputs match a declared JSON schema — required fields present, types correct, enum values respected. TypeCompliance runs a lighter type-only check (numbers are numbers, strings are strings) for cases where you only care about the type discipline. FieldCompleteness verifies optional fields obeyed their conditional-presence rules.

Concretely: a customer-support agent on traceAI-openai-agents calls a refund_order tool. FutureAGI captures the tool span, runs FunctionCallAccuracy to confirm the function name and parameters match the schema, then runs JSONValidation against the parameters payload. When a model swap drops parameter_validation_pass_rate from 99.4% to 91.2%, the regression eval against the canonical golden dataset triggers a model fallback in Agent Command Center: traffic shifts back to the prior model until the schema-violation rate clears threshold.

The same mechanism applies to agent memory ADTs. When an agent reads from agent-memory, the value comes back as a typed object; FutureAGI’s JSONSchema evaluator confirms the read honored the schema before passing it to the next step. Without this layer, ADT violations silently corrupt downstream reasoning and surface as “agent gives weird answers” hours later.

How to Measure or Detect It

ADT compliance is observable directly in traces — pick the evaluator that matches the surface:

• SchemaCompliance: returns 0–1 score against a JSON schema; surfaces required-field violations and type errors.
• TypeCompliance: type-only check, faster than full schema validation; useful for permissive schemas.
• FunctionCallAccuracy: composite score for function calls — name, parameters, types — over an entire trajectory.
• JSONValidation: boolean validity check against a schema; the cheapest gate.
• field_completeness_score (dashboard signal): per-field success rate; identifies which schema field the model struggles with.

from fi.evals import SchemaCompliance, FunctionCallAccuracy

schema_eval = SchemaCompliance()
fn_eval = FunctionCallAccuracy()

result = schema_eval.evaluate(
    output='{"flight_id": "AA123", "passenger_name": "Pareek"}',
    schema={"type": "object", "required": ["flight_id", "passenger_name"]},
)
print(result.score, result.reason)

Common Mistakes

• Treating the schema as documentation. If nothing validates the LLM output against the schema, the schema is wishful thinking.
• Validating only the top-level fields. Nested objects fail more often than flat ones; recurse into sub-schemas.
• Tolerating unknown fields by default. A loose schema masks model drift; use additionalProperties: false where the contract is fixed.
• Mixing ADT-violation alerts with content-quality alerts. They have different on-call paths — pipe SchemaCompliance failures to platform, content failures to ML.
• Skipping schema versioning. When the ADT changes, the dataset that trained the model didn’t know — track schema version and run regression eval per version.