The current wave of AI systems is not failing because models are weak.
They are failing because the systems they operate inside are undefined.
Despite massive improvements in reasoning, tool use, and planning, agents remain brittle, unpredictable, and difficult to scale. Teams respond by layering on guardrails, prompt hierarchies, evaluators, planners, and harnesses. AI labs publish postmortems. Engineers write internal RFCs. Everyone feels the same pain.
And yet, most discussions circle the same surface-level explanations:
These are symptoms.
The underlying issue is simpler-and more uncomfortable:
We are deploying intelligent components inside systems that lack an execution model.
Over the past year, leading AI organizations have begun acknowledging this reality indirectly.
Anthropic introduces MCP servers.
Others talk about agent harnesses, planners, executors, evaluators, and guardrails.
The language differs, but the implication is the same:
Large language models behave better when constrained by explicit structure.
This is not an AI-specific revelation.
It is a systems truth.
Every reliable computing system in history-from compilers to CI pipelines to cloud infrastructure-works because it operates within explicit contracts. When those contracts are missing, behavior becomes emergent, fragile, and ungovernable.
AI is not exempt from this law.
Much of the industry is still asking:
"How do we make agents smarter?"
This is the wrong question.
The correct question is:
"What kind of system can intelligent agents operate in without destabilizing it?"
Smarter agents inside a poorly defined system do not produce better outcomes.
They amplify failure modes.
You can see this clearly in self-modifying agent systems.
Without explicit boundaries, they:
Intelligence without structure is not autonomy.
It is entropy.
This failure pattern is not new.
We have seen it before-in content management systems.
Traditional CMS platforms optimize for human editors:
This works when humans are in the loop.
It fails catastrophically when machines are.
AI agents interacting with CMS-like systems inherit all the same problems:
The result is not intelligence.
It is chaos with confidence.
The success of modern infrastructure tooling already showed us the solution.
Terraform does not rely on dashboards.
Kubernetes does not require GUIs.
Git does not need a visual editor.
They work because:
UI is optional.
Contracts are mandatory.
This is why infrastructure engineers live in manifests and schemas, not interfaces.
AI systems are now reaching the same inflection point.
SMALL is the minimal execution model required for agent-legible systems.
Schema → Manifest → Artifact → Lineage → Lifecycle
Each primitive answers a non-negotiable question:
If a system cannot answer these questions explicitly, it is not safe for agents to operate inside.
This is not a framework.
It is not a product feature.
It is not a wrapper around models.
It is an execution substrate.
See the five primitives in detail, read the compliance specification for what it means to be SMALL-compliant, or learn how to use SMALL in your own systems.
Without SMALL, agentic systems exhibit predictable failure modes:
Agents act without declaring intent in a verifiable form.
Humans must infer meaning from logs, prompts, or behavior.
Outputs overwrite inputs. History disappears. Rollbacks become guesswork.
No one can answer "where did this come from?" with certainty.
Actions happen, but transitions are not recorded as first-class events.
Human-facing interfaces stand in for machine-legible contracts.
Each of these failures compounds the others.
Together, they make reliable agent systems impossible.
SMALL does not make agents smarter.
It makes systems legible.
With SMALL:
This creates a critical boundary:
Agents can propose intent, but systems control execution.
That boundary is the difference between autonomy and safety.
Compliance is binary. A system either is SMALL-compliant or is not.
SMALL is not optional complexity.
It is the complexity that already exists-made explicit.
Every AI team is rebuilding fragments of SMALL today:
The difference is that without a named model, these pieces remain ad hoc.
SMALL unifies them.
And because it is minimal, it scales:
The industry is approaching a tipping point.
As AI systems move from demos to production:
Systems without execution models will fail under scrutiny.
The winners will not be those with the flashiest agents.
They will be those with the clearest contracts.
The next generation of AI systems will be judged not by how impressive they look, but by how reliably they execute.
When that happens, the systems that survive will be SMALL-whether they use the name or not.
The difference is that naming it allows us to build it properly.
If you're building agent systems, here's where to start:
Audit your intent model. Are agents submitting structured manifests, or acting directly on state? If the latter, you have no execution boundary.
Check your provenance. Can you answer "where did this come from?" without reading logs? If not, your lineage is implicit.
Test determinism. Run the same input twice. Do you get the same output? If not, your system is not auditable.
Define your lifecycle. What states can an artifact be in? What transitions are allowed? If this is undefined, agents will invent their own.
Try the playground. Paste a manifest into the SMALL Playground and see what deterministic validation looks like. The protocol contract is available at /protocol/small/v1. For a complete guide to using SMALL in your projects, see How to Use SMALL.
Start small. Make one system legible. Then expand.
SMALL replaces implicit AI systems with deterministic, auditable execution contracts-and makes agents safe to deploy at scale.
This is not hype.
It is the missing layer.
And it is already being built.