Giving an AI agent more ways to act also gives it more ways to fail. A domain-specific language can reduce that execution space, but only when the domain is stable, repeated, and independently verifiable. For many systems, JSON Schema or a typed API is enough. The engineering decision is to choose the smallest constraint that makes errors visible before execution.
The real problem is verification space
General-purpose code gives an LLM enormous expressive freedom. Two programs can both compile and still differ in transaction order, permission scope, retry behavior, or business meaning. The model can choose among thousands of valid structures, and reviewers inherit the same large search space.
A domain-specific language, or DSL, deliberately gives up generality. SQL narrows work to relational queries. Kubernetes YAML narrows work to deployment configuration. Mermaid narrows work to diagrams. A DSL for an agent can restrict available verbs, legal sequences, data types, and side effects.
The key benefit is not shorter syntax. It is a smaller world with clearer failure signals.
This is an application of a broader constraint paradox: stronger capability exposes more failure modes. A DSL trades open-ended capability for a bounded language that can be parsed, diffed, validated, and executed by deterministic software. That trade can improve reliability. It can also create a new language, toolchain, migration burden, and semantic bottleneck.
What the evidence actually shows
Two recent sources provide useful evidence, with different levels of rigor.
Unmesh Joshi's article, DSLs Enable Reliable Use of LLMs, describes a two-phase workflow. During design, the LLM helps humans discover the domain model and vocabulary. After that vocabulary stabilizes, the LLM becomes a natural-language interface to a constrained language. Joshi's Tickloom example shows how named abstractions and deterministic simulation can reduce the choices an LLM must make.
That is an engineering account, not a general benchmark. Tickloom demonstrates a mechanism. It does not prove that DSLs improve every model or task.
The Anka preprint supplies a controlled comparison. Anka is a DSL for data-transformation pipelines. Across 100 benchmark tasks, Claude 3.5 Haiku reached 95.8% overall task accuracy with Anka, compared with 91.2% using Python. On multi-step tasks, the gap was much larger: 100% with Anka versus 60% with Python. GPT-4o-mini showed a similar directional result on multi-step tasks, 86.7% versus 60%.
The boundary matters as much as the headline. Anka showed no advantage on simple one-step and two-step tasks. It sometimes trailed Python on tasks that benefited from flexible conditional logic. The experiment covered two models, one benchmark suite, and one domain. It included no developer study. Anka also required roughly 6,400 lines of language implementation, including grammar, AST, interpreter, and tests.
The responsible conclusion is narrow: a well-designed DSL can reduce sequencing and state-management errors in repeated multi-step tasks. The evidence does not support a universal rule that DSLs make agents reliable.
The four-layer architecture
The strongest pattern separates four concerns that teams often collapse into one prompt.
| Layer | Responsibility | Primary failure | Deterministic check |
|---|---|---|---|
| Natural language | Capture human intent | Ambiguity and missing context | Clarification and explicit assumptions |
| Semantic model | Define domain objects, relations, and invariants | Wrong interpretation | Type and invariant checks |
| DSL | Store an executable, reviewable plan | Invalid syntax or illegal sequence | Parser, compiler, schema, linter |
| Runtime | Apply permissions and produce effects | Unsafe or incorrect execution | Dry-run, tests, logs, rollback |
Natural language stays useful because humans can state goals quickly. The semantic model converts those goals into domain concepts. The DSL records the plan in a form that both machines and reviewers can inspect. The runtime enforces permissions and executes approved operations.
This separation prevents a common mistake: treating successful parsing as proof of correctness. A parser can prove that TRANSFER account_a account_b 500 follows the grammar. It cannot prove that the transfer matches the user's intention, that the accounts are correct, or that the transaction is allowed. Those claims belong to semantic validation and runtime policy.
DSL, JSON Schema, typed API, or normal code?
Start with the least expensive constraint that closes the important failure modes.
| Option | Best fit | What it constrains | Main limit |
|---|---|---|---|
| JSON Schema | Structured output and simple tool calls | Fields, types, required values | Weak at multi-step semantics |
| Typed API | A small set of stable actions | Available verbs and parameters | Composition lives elsewhere |
| Rules engine | Explicit policy and decision tables | Conditions and allowed outcomes | Awkward for rich procedures |
| DSL | Repeated, multi-step domain programs | Vocabulary, order, invariants, composition | Language and toolchain cost |
| General-purpose code | Novel or open-ended implementation | Very little beyond language rules | Largest verification space |
A JSON object can already express many agent plans. If the workflow is only search, summarize, and send_for_approval, adding a custom parser creates work without reducing much risk. A typed API is often the next useful step because it closes the action vocabulary while preserving normal programming tools.
A DSL becomes attractive when composition itself is the problem. It can encode rules such as approval before payment, read before update, rollback after partial failure, or quorum before commit. These are domain sequences, not isolated function signatures.
A five-axis build decision
Score the proposed DSL on five questions.
1. Is the domain vocabulary stable?
A DSL freezes names and relationships into a language. Stable concepts such as invoice, approval, deployment, or replica are good candidates. A product still discovering its core objects will turn every insight into a breaking grammar change.
2. Is the error cost high enough?
The value rises when invalid actions must be blocked before execution. Financial changes, infrastructure deployment, access control, and regulated workflows justify stronger constraints. A one-off data exploration usually does not.
3. Will the structure be reused?
Language engineering is a fixed cost. Repeated generation, modification, and review can amortize it. A single script rarely can.
4. Can correctness be checked independently of the model?
The DSL needs a deterministic validator. Useful checks include grammar, types, permission rules, resource limits, domain invariants, golden tests, property tests, and dry-run diffs. If the only judge is another LLM, the system has changed the representation without establishing a trust boundary.
5. Will review become materially cheaper?
A strong DSL produces small, meaningful diffs. A reviewer should see REQUIRE two_approvers rather than inspect hundreds of generated lines. If reviewers must expand every statement back into implementation detail, the abstraction has failed to reduce verification work.
Build the minimum viable DSL
A useful first version is deliberately small:
- Five to ten domain primitives.
- One versioned schema or AST.
- A parser or constrained structured-output layer.
- A deterministic validator separate from the LLM.
- An adapter that calls existing, tested APIs.
- Golden, negative, and property tests.
- A dry-run mode, readable diff, provenance record, and migration rule.
Keep execution behind existing APIs. The DSL should describe legal plans; the adapter should invoke mature services. This keeps authentication, retries, idempotency, and transaction logic in deterministic code.
An agent loop can then remain simple:
intent -> semantic plan -> DSL candidate -> validate -> dry-run
-> approve if needed -> execute -> verify result -> record evidence
Validation errors should use domain language. Payment requires two approvers gives the model a repair target. A stack trace from generated integration code does not.
When a DSL is the wrong abstraction
Use ordinary code, a typed API, or a schema when any of these conditions dominates:
- The task is one-off or only one to two steps long.
- Domain rules are changing faster than a language can be versioned.
- Novel conditional logic is the main source of value.
- No independent semantic validator can be defined.
- Existing schemas and APIs already prevent the costly failures.
- The language, IDE, documentation, migration, and support cost exceeds repeated review cost.
Constraints remove some errors and expose new ones. A grammar can become stale. A validator can encode the wrong policy. An elegant abstraction can make unusual but legitimate work impossible. Version the semantic model, test the compiler, preserve provenance, and provide an explicit escape path for work outside the language.
This is where DSL design connects to broader AI-native workflow design. A DSL is one optional constraint and verification component inside the agent runtime. It is not a replacement for context, permissions, observability, human escalation, or result verification.
FAQ
What is a domain-specific language for AI agents?
It is a constrained language that lets an agent express plans using a fixed domain vocabulary. A parser and validator can reject illegal structures before the runtime executes them.
How is a DSL different from JSON Schema?
JSON Schema constrains data shape. A DSL can also encode composition, order, domain invariants, and reusable procedures. Start with JSON Schema when field validation is the primary need.
Can an LLM learn a new DSL without fine-tuning?
Yes, for sufficiently small languages. The Anka experiment achieved 99.9% parse success through in-context instruction, although its results cover a narrow data-transformation benchmark and two models.
Does a DSL guarantee correct agent behavior?
No. It can eliminate syntax errors and any semantic errors represented by its validator. It cannot detect an incorrect user intention, missing rule, faulty compiler, or invalid external data unless the system adds checks for them.
When should a team build an AI agent DSL?
Build one when the domain is stable, workflows repeat, errors are expensive, composition matters, and an independent validator can reject unsafe plans. Otherwise, prefer a schema or typed API.
References
- Unmesh Joshi. DSLs Enable Reliable Use of LLMs, 2026.
- Saif Khalfan Saif Al Mazrouei. Anka: A Domain-Specific Language for Reliable LLM Code Generation, 2025.
- Unmesh Joshi. Tickloom.
- Jordi Cabot et al. Exploring the Use of Large Language Models in Domain-Specific Language Development, 2025.
- Microsoft. AI Coding Agents and Domain-Specific Languages, 2025.