PaxLabs Research
Andres G. and the PaxLabs Research Team · PaxLabs Inc.
The Intent Compiler: Typed Intermediate Representations for Reliable Agentic Systems
Andres G. and the PaxLabs Research Team PaxLabs Inc. Correspondence: legal@paxeer.app
We propose the Intent Compiler, an architectural pattern in which natural language instructions are transformed through a series of well-defined stages into typed, closed-vocabulary intermediate representations (IRs) before execution. Current agentic systems typically map user intent directly from prose to tool calls, producing brittle pipelines that are difficult to inspect, correct, or replay. We argue that the reliability of agentic systems depends on the quality of the interface between natural language intent and executable action. A typed IR with a closed operation vocabulary, typed operands, and content-addressed serialization converts intent from ephemeral prose into structured data that can be validated, debugged, and audited. We formalize the intent compilation pipeline, analyze the design space for intermediate representations, present the closed vocabulary argument for bounded operation sets, and outline an evaluation protocol for measuring compilation fidelity. We do not claim that this architecture eliminates hallucination or guarantees correctness; rather, we claim that it makes failures inspectable and localizable, which is the precondition for reliable human-agent collaboration.
closed vocabularies, intent compilation, tool-use agents, LLM reliability
Large language models (LLMs) have demonstrated strong capabilities in following natural language instructions and producing structured outputs [1, 2]. When deployed as agents, they must translate user intent into sequences of tool calls, API invocations, and state mutations [3, 4]. The prevailing architecture treats this translation as a single-step mapping: the model receives a prompt, generates a tool call (often as JSON), and the runtime executes it [5, 6]. This design is expedient but fragile. When the model produces an incorrect tool call, the failure is opaque. There is no intermediate artifact that a human or automated system can inspect to determine where the error was introduced.
We propose that this problem is best understood through the lens of compiler design. In conventional compilers, source code is not translated directly to machine code. Instead, it passes through intermediate representations (IRs) that allow optimizations, validations, and error detection at each stage [7, 8]. We argue that agentic systems need an analogous pipeline: natural language intent should be compiled through typed intermediate representations before execution.
The core thesis of this paper is as follows: the reliability of agentic systems depends on the interface between natural language intent and executable action, and a typed intermediate representation with a closed operation vocabulary, typed operands, and content-addressed serialization is the architectural primitive that makes agents debuggable and trustworthy.
We make the following contributions:
(1) We formalize the Intent Compilation Pipeline, a multi-stage architecture in which natural language is parsed into a typed IR, validated against a closed vocabulary, compiled into an execution plan, and then executed with full provenance tracking.
(2) We analyze the design space for intent IRs, identifying the key axes along which IR designs vary: open versus closed vocabularies, structural versus content-addressed identity, and the depth of type systems.
(3) We present the Closed Vocabulary Argument, demonstrating why bounded operation sets produce more reliable agents than open-ended classification schemes.
(4) We outline an evaluation protocol for measuring compilation fidelity, including metrics for parse accuracy, IR validity rates, and execution correctness.
We wish to be precise about what this paper does and does not claim. We do not claim that the Intent Compiler eliminates hallucination. LLMs may still produce incorrect parses, and the IR itself does not prevent the model from misunderstanding the user's intent. We do not claim that a typed IR is sufficient for correctness; type safety is necessary but not sufficient. We do not claim that our specific IR design is optimal; we claim that the general pattern of typed, closed-vocabulary IRs is a sound architectural direction. We do not present empirical results in this paper; we present a design, a formalization, and an evaluation protocol.
The concept of intermediate representations is well established in compiler theory. Aiken and others have shown that multi-pass compilation with IRs enables separation of concerns: parsing, optimization, and code generation can be developed and validated independently [7]. Three-address code, static single assignment (SSA) form, and abstract syntax trees (ASTs) are all IRs designed for different purposes [8]. The key property is that an IR is both machine-readable and human-inspectable, and that transformations on the IR preserve semantic properties that matter for correctness.
LLM compilation has itself become an active research area. The TVM compiler [9] and related work on MLIR [10] demonstrate that IRs for neural network computation can be layered, with each layer serving a different purpose in the optimization pipeline. Our work extends this thinking from model compilation to agent compilation: the thing being compiled is not a neural network but an intent.
The dominant architecture for LLM-based agents follows the ReAct pattern introduced by Yao et al. [3]. In ReAct, the model alternates between reasoning (generating text that explains its plan) and acting (producing tool calls). The model's output is a free-form interleaving of thought and action, and the runtime parses the action portions for execution.
Subsequent work has refined this pattern. Toolformer [11] trains models to insert tool calls into their text generation. Gorilla [12] and ToolBench [13] focus on expanding the set of tools an agent can invoke. The OpenAI function calling protocol [6] and Anthropic's tool use protocol [5] standardize the format of tool calls but do not introduce intermediate representations.
In all of these architectures, the mapping from intent to action is direct. The model generates a tool call, and the runtime executes it. There is no stage at which the intent is represented in a structured, typed form that is independent of both the natural language input and the tool call format.
Qin et al. [13] provide a taxonomy of tool-use capabilities: tool selection, argument filling, tool chaining, and error recovery. Each of these capabilities is relevant to the Intent Compiler. However, our analysis differs from existing taxonomies in one respect: we treat the intermediate representation as a first-class object with its own validation rules, rather than treating tool use as a property of the model's output.
Schick et al. [11] demonstrate that models can learn to invoke tools during generation, but their work does not address the question of whether the generated tool call is a faithful representation of the user's intent. We argue that faithfulness can only be assessed when there is an intermediate representation that can be checked against the original intent.
We define the Intent Compilation Pipeline as a four-stage process. Each stage has well-defined inputs, outputs, and validation criteria.
Definition 1 (Intent Compilation Pipeline). An intent compilation pipeline is a tuple (P, V, C, E) where: - P is the parse stage, mapping natural language to typed IR - V is the validation stage, checking IR well-formedness - C is the compilation stage, mapping validated IR to execution plans - E is the execution stage, running the plan and recording provenance
Definition 2 (Typed Intent IR). A typed intent IR is a directed acyclic graph G = (N, E) where each node n in N has a type t(n) drawn from a finite type system T, and each edge (u, v) in E represents a data or control dependency.
The parse stage takes natural language input and produces a typed IR. We model this as a function P: NL x Context -> IR, where NL is the space of natural language utterances, Context represents the conversation history and system state, and IR is the space of well-typed intent graphs.
The parse stage is where the LLM performs its primary work. The model must identify the user's intent, decompose it into operations, and assign types to operands. This is the most error-prone stage, and it is precisely because it is error-prone that we need the subsequent stages.
Proposition 1. If the parse stage produces a well-formed IR (one that passes validation), then errors in execution can be localized to either the parse stage (the IR does not reflect the user's intent) or the compilation stage (the IR is correct but the execution plan is not). If the parse stage produces an ill-formed IR, the error is unambiguously in the parse stage.
This localization property is the primary motivation for the IR. Without it, an execution failure could be caused by a parse error, a compilation error, or an execution error, and there is no way to distinguish these cases.
The validation stage checks the IR against structural and semantic constraints. We define validation as a function V: IR -> {valid, invalid} x Diagnostics.
Structural constraints include: - All nodes have types from the declared type system T - All edges connect nodes whose types are compatible - The graph is acyclic (no circular dependencies) - All required operands are present
Semantic constraints include: - All referenced operations belong to the declared vocabulary V - All referenced entities are resolvable in the current context - Resource limits are not exceeded (e.g., maximum plan depth)
Definition 3 (Closed Operation Vocabulary). A closed operation vocabulary is a finite set O = {o_1, ..., o_n} of operations, where each operation o_i has a fixed arity, a fixed set of typed parameters, and a formal specification of its pre-conditions and post-conditions.
The validation stage checks that every operation node in the IR references an operation from O. This is a critical design choice, and we discuss its implications at length in Section V.
The compilation stage maps a validated IR to an execution plan. We define this as a function C: ValidIR -> ExecPlan, where ExecPlan is a sequence of concrete API calls with fully resolved arguments.
The compilation stage performs several tasks: - Operand resolution: replacing references with concrete values - Ordering: determining the execution sequence from the dependency graph - Optimization: merging redundant operations or reordering for efficiency - Serialization: producing the final execution plan as a replayable artifact
Definition 4 (Content-Addressed Serialization). A serialization scheme is content-addressed if the identifier of each serialized object is a deterministic function of its content. Formally, for an object o, its identifier is id(o) = H(serialize(o)) where H is a collision-resistant hash function.
Content addressing has a specific benefit for agent systems: if the same intent is parsed twice, the resulting IRs have the same identifier if and only if they are structurally identical. This enables deduplication, caching, and replay verification.
The execution stage runs the compiled plan and records full provenance. We define execution as a function E: ExecPlan x State -> State x Provenance, where State is the current system state and Provenance is a complete record of what was executed, what the results were, and how long each step took.
The provenance record is itself a typed, serializable artifact. Combined with the content-addressed IR, it creates a complete audit trail: given an execution result, one can reconstruct the IR, the parse, and the original input that produced it.
IV. DESIGN SPACE FOR INTENT IRs
The design space for intent IRs has several axes. We analyze three that we consider most consequential.
An open vocabulary allows the model to propose arbitrary operation names, potentially including operations not present in the system. A closed vocabulary restricts the model to a predefined set of operations.
We argue (in Section V) that closed vocabularies are preferable for reliability. However, we acknowledge that open vocabularies have advantages for extensibility. A hybrid approach is possible: the vocabulary is closed at validation time, but the system can be extended by adding new operations to the vocabulary through a controlled registration process.
Definition 5 (Vocabulary Extension). A vocabulary extension is a pair (o, spec) where o is a new operation name and spec is its formal specification, including arity, parameter types, pre-conditions, and post-conditions. An extension is admissible if spec is type-consistent with the existing vocabulary.
The choice of identity scheme for IR nodes affects several system properties. Reference-based identity (pointer equality) is simple but does not support serialization or comparison across sessions. Name-based identity (string labels) is human-readable but risks collision. Content-based identity (hash of serialized content) supports deduplication and replay but is opaque to humans.
We recommend content-based identity for machine operations and name-based labels for human inspection. The IR should carry both: a content hash for system use and a human-readable label for debugging.
The depth of the type system is a design choice with significant consequences. A shallow type system (e.g., distinguishing strings from numbers) provides basic safety. A deep type system (e.g., distinguishing user IDs from order IDs even though both are strings) provides stronger guarantees but requires more sophisticated parsing.
We propose a stratified approach: - Level 0: primitive types (string, integer, float, boolean) - Level 1: domain types (user_id, order_id, email_address) - Level 2: semantic types (read_operation, write_operation, idempotent_operation)
The LLM must produce IRs with at least Level 1 types. The validation stage checks type consistency. The compilation stage can downgrade types when necessary for API compatibility, but the downgrade is recorded in provenance.
We now present the central argument for closed operation vocabularies. This argument is theoretical, not empirical; we present it as a proposition with supporting reasoning.
Proposition 2 (Closed Vocabulary Reliability Bound). Let O be a closed vocabulary of size n, and let P_correct(o_i) be the probability that the model correctly selects operation o_i given that o_i is the correct operation. Let the operations be ordered by decreasing prior probability. Then the expected error rate for operation selection is:
E[error] = 1 - sum_{i=1}^{n} P(correct | o_i) * P(o_i)
For a closed vocabulary, this sum is well-defined and bounded. For an open vocabulary, the model may propose an operation o' not in any training distribution, and P(correct | o') is undefined.
The argument has three parts.
Part 1: Bounded search space. When the vocabulary is closed and of manageable size (we suggest n <= 200 for current LLMs), the model's task is classification, not generation. Classification tasks have well-understood error profiles [14]. The model can be prompted with the complete list of available operations, eliminating the possibility of inventing operations that do not exist.
Part 2: Type checking as error detection. When each operation has typed parameters, the validation stage can detect many errors that would otherwise reach execution. If the model selects the correct operation but provides an argument of the wrong type, the error is caught at validation time. If the model selects the wrong operation, the type mismatch between the intended arguments and the selected operation's signature often produces a validation failure. This is a property of typed systems generally [7], but it is especially valuable in the agent context because the alternative (untyped tool calls) provides no such safety net.
Part 3: Enumerability enables coverage testing. A closed vocabulary can be exhaustively tested. For each operation, one can construct test cases that verify the parse, validation, and compilation stages. An open vocabulary cannot be exhaustively tested because the set of possible operations is unbounded. This is not merely a testing convenience; it is a precondition for making any reliability claims about the system.
We do not claim that closed vocabularies are always superior. For exploratory tasks where the user's intent is genuinely novel and does not map to any existing operation, a closed vocabulary will fail. Our claim is bounded: for tasks within the declared scope of an agent's capabilities, closed vocabularies produce more reliable systems than open vocabularies.
Closed vocabularies interact favorably with model confidence calibration. When the model must select from a fixed set, it can assign probabilities to each option. If no option receives high confidence, the system can defer to the user rather than guessing. This is a form of selective prediction [15], and it requires a bounded output space to be meaningful.
With an open vocabulary, the model's confidence is spread over an unbounded space, and the probability of any specific operation is typically low even when the model is correct. This makes confidence-based deferral unreliable.
We now present a case study to illustrate the Intent Compilation Pipeline, and we outline an evaluation protocol for measuring compilation fidelity.
Consider an agent designed to manage e-commerce orders. The closed vocabulary might include operations such as: lookup_order, update_status, issue_refund, send_notification, generate_report, and create_ticket.
A user says: "The customer in order 4582 wants a refund for the damaged item, and please let them know it's being processed."
The Intent Compiler produces the following IR:
Intent: composite Children: 1. Operation: lookup_order Parameter: order_id : OrderId = "4582" Result binding: @order 2. Operation: issue_refund Parameter: order_ref : OrderRef = @order Parameter: reason : RefundReason = "damaged_item" Depends on: 1 3. Operation: send_notification Parameter: recipient : EmailAddress = @order.customer_email Parameter: template : NotificationTemplate = "refund_processing" Parameter: context : OrderRef = @order Depends on: 1 (can run in parallel with 2)
Note that the IR does not contain the natural language text. It contains typed operations with typed parameters. The dependency graph is explicit. The content hash of this IR is deterministic and can be used for replay and deduplication.
If the model had hallucinated an operation (e.g., "escalate_to_manager" which is not in the vocabulary), the validation stage would reject it. If the model had passed a string where an OrderId was expected, the type check would fail. These are the reliability properties that the IR provides.
We propose the following metrics for evaluating an Intent Compiler:
Metric 1: Parse Fidelity. Given a set of (natural language, expected IR) pairs, measure the fraction of cases where the parse stage produces an IR that is structurally equivalent to the expected IR. Structural equivalence means the same operations, the same dependencies, and compatible types.
Metric 2: Validation Pass Rate. Measure the fraction of parsed IRs that pass validation without errors. This metric captures both parse quality and the robustness of the validation rules.
Metric 3: Type Error Catch Rate. Inject type errors into correctly parsed IRs (e.g., swap the types of two parameters) and measure the fraction caught by validation. This metric isolates the contribution of the type system.
Metric 4: Execution Correctness. Measure the fraction of validated IRs that produce the correct execution result. This metric captures errors introduced at the compilation stage.
Metric 5: Provenance Completeness. Verify that for every execution result, the full chain from result to IR to parse to original input can be reconstructed from the provenance record.