Syntactically Valid, Semantically Wrong
A Constraint-Based Approach to Safe AI-Agent Execution
Founder & CEO
Predictika.ai
Email: sanjay@predictika.com
Executive summary
AI agents are moving from drafting text to taking actions — provisioning cloud infrastructure, pushing a change to a live network, executing the next step of an incident-response runbook, or creating a valid quote. That shift quietly removes something worth naming: when a human was still the one deciding whether to execute, that human was doing a check nobody had to design, because it's simply what supervision is — holding a proposed action up against everything else they already knew before acting on it. As agents take over more of that execution loop, the check doesn't get replaced by anything. It disappears.
That matters because of which failures scale with autonomy and which don't. A hallucinated fact or a malformed tool call isn't more likely just because an agent is trusted with more independent action. An agent's decision being individually fine and wrong only in combination with decisions it already made is more likely, because more of those decisions get made per human glance as autonomy increases. This is the failure mode autonomy itself makes worse — not a new category of bug agents introduce, but the exact check human supervision used to provide, now missing.
An agent can get every field right — the right resource type, the right command, the right API call — and still produce something that's wrong once you look at how it relates to everything else already true about the system it's about to touch. A security group with no ingress rules is syntactically fine on its own; the same security group, referenced by a public-facing load balancer, is a live vulnerability. Neither Terraform's validator nor most policy engines catch this, because both were built to check one resource, or one rule, at a time. The gap between 'individually valid' and 'jointly correct' is where this failure mode already shows up in isolated but serious incidents, and it's a gap that widens, not narrows, as agents move from suggesting actions to executing them — closing it is fundamentally a constraint-reasoning problem, the same kind of problem we've spent years solving in product and pricing configuration, now aimed at the systems AI agents operate on.
Two Different Questions, and Only One Gets Asked
Every mature engineering discipline eventually separates 'is this well-formed' from 'is this right.' Linguistics drew this line first: Noam Chomsky's 'Colorless green ideas sleep furiously' obeys every rule of English grammar — correct parts of speech, correct agreement, correct word order — and still means nothing, because grammaticality and sense are different axes. A syntactically valid database record can still violate a business rule; a compilable program can still have a bug. Configuration software learned this lesson decades ago: a wizard that lets you pick options one screen at a time, each screen individually valid, can still hand you a final product that doesn't actually work, because the choices on screen three were never checked against the choice you made on screen one. That's why complex product configuration moved to constraint-based reasoning — modeling every option and every relationship jointly, so a conflict is caught the moment it becomes true rather than downstream at assembly.
AI agents that take real actions — booking a trip, provisioning infrastructure, changing network state, executing a multi-step remediation — are running into exactly the same lesson, on a compressed timeline. An agent choosing several related parameters is solving a configuration problem whether anyone designed it that way or not, and when those parameters are checked one at a time and never checked jointly against everything else the agent has already decided, the result looks correct at every individual step and is wrong as a whole. The diagram below shows where the check belongs: not inside the model's own reasoning, and not as an afterthought once the action has already reached the outside world, but as an independent layer the proposed action has to clear before it executes.
Six Places It's Already Happening
A personal agent planning your trip. Ask a travel-planning agent to book a long weekend and it will happily confirm a flight, a hotel, and a rental car — each of them, individually, a perfectly valid booking. The failure shows up in the relationships: the rental car return time is after the flight home has already left, or the hotel is booked in the wrong city because an earlier leg changed and nothing re-checked the rest of the itinerary against it. No single booking was wrong. The three of them, held jointly, weren't consistent — and a booking API has no reason to know that, because it only ever sees one reservation at a time.
A smart-home agent that connects things that don't actually work together. Consumer smart-home ecosystems publish compatibility lists — this camera works with that hub, this bulb works with that switch — and an agent assembling a setup checks each pairing against those lists and calls it done. What the checklists don't capture is a step removed: a camera and a light can each be individually ‘compatible’ with the hub while not being interoperable with each other for the one thing the owner actually wanted — the light turning on when the camera sees motion. That's a three-way relationship (camera, light, hub, and the automation rule connecting them), and a pairwise checklist structurally can't express it.
A coding agent that deleted a production database during a code freeze. In July 2025, an AI coding agent operating on a live SaaS build was told, explicitly and repeatedly, not to touch the production database while a freeze was in effect. It deleted it anyway, then initially reported that rollback was impossible when it wasn't. Every individual command the agent issued was syntactically valid — it was a real, well-formed destructive operation the platform was fully capable of executing. What was missing wasn't the agent's understanding of the freeze; by its own account, it understood the instruction and did it anyway. What was missing was anything in the execution path that treated the freeze as a boundary rather than as one more line of context to weigh against the task at hand. A restriction that lives only in the prompt is advice; the same restriction enforced as a hard constraint the agent's plan is checked against before anything executes is a wrapper, and it doesn't care how persuasive the agent's reasoning for the exception was.
Cloud infrastructure that passes every existing check. Infrastructure-as-code tools let an AI agent generate infrastructure as text, and “policy-as-code” tools check whether that text is allowed before it's applied. Neither is built to catch a configuration that is syntactically valid and individually permitted while being relationally broken — a security group with zero rules that a public resource depends on, an IAM role with no permissions attached. Two of the leading infrastructure-orchestration platforms are already shipping AI-generated provisioning as a headline feature, which means this exact gap is opening underneath their own new product, not a hypothetical one.
A network command that was fine, until the moment it wasn't. In 2021, a single command issued during routine maintenance disconnected a major platform's entire global backbone for roughly six hours. The detail worth sitting with, from the company's own account: an internal auditing tool was supposed to catch exactly this kind of misconfiguration, and a software bug caused it to fail silently. “Nobody had a safety layer” is a weaker argument for a dedicated, independently verifiable constraint engine than “the layer existed and its failure was invisible until the outage made it visible.”
A CPQ agent that quietly ships a quote missing a required part. Ask an AI sales agent to configure and submit a rack-server quote and it will apply every rule exactly as written: add a redundant power supply once rack units cross a threshold, require a cooling fan kit whenever that power supply is present. Both rules are individually correct, and both fire. The failure is in the order: legacy CPQ engines evaluate every rule assigned to a stage against one snapshot of the quote taken before any of that stage's actions run, so the cooling-fan rule checks whether the power supply is present a beat too early and never sees the one the first rule just added. The quote saves clean, no error, missing a required part. A human rep might eventually hit Calculate a second time out of habit and happen to catch it on the now-current snapshot; an agent that goes straight from “no errors returned” to “submit” has no reason to.
Why the Existing Guardrails Stop Short
The tools in each example are genuinely capable, not absent — the gap persists for a structural reason. Policy engines evaluate one input document at a time (“does this one thing satisfy this one rule,” not “is this consistent with everything else true about the system”); static scanners pattern-match a resource at a time against known-bad shapes; a prompt instruction is weighed by the model rather than enforced against it. All three stop at a boundary — the single resource, the single rule, the single turn of reasoning — by design. What's missing is a layer that holds the whole graph of relationships in view and propagates one decision's consequence to every other decision it touches, in whatever order the facts arrive. That's the problem constraint-based reasoning was built to solve.
Where a Constraint Engine Actually Fits
Predictika's Logic Validation Engine (LVE) models a domain as entities and the constraints — requires, excludes, compatible-with, value limits — that relate them, and evaluates every constraint against the current state jointly and order-independently, the same approach we've applied for years to complex product and pricing configuration. Pointed at AI-agent execution instead of a product catalog, that gives two integration patterns, shown below, that map directly onto the examples above.
Both patterns share the property that matters most to a business trusting an agent with real actions: the check is deterministic and explainable. It doesn't approximate an answer the way a second LLM asked to “grade” the first one would; it evaluates a formal model and can show exactly which relationship failed — the same guarantee we make in product configuration, correctness and completeness as first-class properties, applied here to the objects an agent now touches directly.
The same check also catches a related but different failure: an agent that hallucinates a value which conflicts with something else already known to be true — a device that doesn't exist, a policy that doesn't match, a window pulled from the wrapper's own resolution of the real system rather than taken on the agent's word. The engine doesn't distinguish between a joint-consistency error and a hallucinated one, because both surface the same way: a value that doesn't match what the model already knows. What it can't catch is a hallucinated value that's individually plausible and touches nothing else the model encodes — wrong, but with no relationship to check it against. That narrower problem is what our work on LLM accuracy validation addresses directly; this validation layer alone isn't a general hallucination fix.
Where This Leaves Us
None of this argues that existing safety tooling should be replaced. Policy-as-code, static scanners, compatibility checklists, and prompt-level instructions all solve real problems, and none of the six examples above suggests otherwise. The argument is narrower: as agents take on more of the actions themselves, the checks need a layer underneath them that reasons about relationships across the whole system jointly — not one more rule on a per-resource checklist, and not one more sentence in a prompt. That's a validation problem with the same shape as the configuration and pricing problems we've built this engine to solve, and we'd welcome a conversation about where it fits alongside what you've already built.
About Predictika
Predictika.ai builds a patented constraint-based configuration and pricing engine rooted in a research lineage that runs from Xerox PARC through Selectica, the enterprise CPQ pioneer whose customers included IBM, Cisco, Dell, GE, Hitachi, Disney, and AT&T. Predictika's declarative modeling language, LVML, carries forward a distinctive prototype object-oriented architecture in which sub-entities inherit both parameters and constraints from the structures that contain them. The company holds patents covering deterministic validation of LLM-driven systems (U.S. 11,544,475 and 11,914,970).
About the author
Dr. Sanjay Mittal is the founder and CEO of Predictika.ai. His work in constraint-based AI began at Xerox PARC and was commercialized through Selectica, where he helped build one of the first enterprise CPQ platforms. Predictika continues that lineage, applying constraint reasoning to configuration and pricing across data center infrastructure, cloud pricing, and other domains where interdependent decisions must be reasoned about jointly.
Suggested Further reading
" You May not Realize it, But Your Business has a Configuration Problem " – a CXO self-diagnosis piece on where configuration hides inside a business.
" Complex Product Configuration Requires a Constraint-Based Approach " — the technical case for constraint-based configuration, with architecture and object-model detail.
" The Business Case for Constraint-Based Configuration " — a condensed overview for CIO/COO/CRO audiences.
" Requirements for a Constraint Server Behind an LLM Front End " — the correctness, completeness, propagation, and consistency requirements for a constraint server sitting behind an LLM, in full technical depth.
Copyright © Predictika Inc. 2026