AI agents are no longer experiments. They’re writing code, moving money, and operating infrastructure. But as they gain autonomy, one question keeps coming up: how do you safely control what they can do?
Most teams start with system prompts and YAML configs. Some move to generic policy engines like OPA/Rego or Cedar. But neither approach was designed for agents. YAML lacks native concepts like budgets, phases, and delegation. Rego is powerful but generic and it treats “deny” as a runtime afterthought.
Thanks for reading Amjad! Subscribe for free to receive new posts and support my work.
That’s why we built FPL (Faramesh Policy Language), a domain‑specific language purpose‑built for AI agent governance. It’s not a repurposed config format. It’s a new primitive for the agentic stack.
Let’s compare how the three approaches handle real‑world agent policies.
The Problem: YAML Is a Convention, Not a Contract
A typical agent policy in YAML with expression evaluation looks like this (abbreviated):
Even in this simplified version, agent‑specific concepts like budgets, phases, and delegation are just conventions—they’re not enforced by the language. There’s no guarantee that a later rule won’t accidentally override the deny. And as policies grow, YAML becomes unmaintainable.
Rego (OPA) Is Powerful but Not Agent‑Native
Rego is a general‑purpose policy language designed for infrastructure authorization. It’s expressive, but writing a simple agent policy requires understanding a new logic language:
Now add budgets, phases, delegation, and a mandatory deny that can’t be overridden. You’ll end up with hundreds of lines, complex rule ordering, and no compile‑time safety. Rego also has no built‑in agent primitives you have to encode them manually.
FPL: Built for Agents, from the Ground Up
FPL is a declarative language that makes agent governance concise, readable, and safe. Here’s the same policy in FPL:
25 lines. Every primitive—budget, phase, defer, deny!—is a first‑class construct, not a convention.
deny! – Compile‑Time Mandatory Deny
This is a game‑changer. In FPL, deny! is a compile‑time constraint. It cannot be overridden by any other rule, regardless of position or priority. In Rego and YAML‑based systems, “deny” is just a runtime decision—you can accidentally permit something later. FPL eliminates that class of error.
Natural Language Compilation + Backtesting You can write policies in plain English:
`#bash
faramesh policy compile “deny all shell commands, defer refunds over $500 to finance”
`
The CLI generates FPL, validates it, and backtests it against real decision records before activation. You see exactly what the policy would have done to past agent actions. No guessing.
Side‑by‑Side Comparison
GitOps‑Native and Extensible
FPL files are plain text (.fpl), version‑controlled, and validated in CI. The language has a formal EBNF grammar, a conformance test suite, and editor tooling on the way (VS Code, JetBrains, Neovim). It compiles to the same internal representation as YAML, so you can mix and match.
You can also write policies as:
- Code annotations – @faramesh.tool(defer_above=500)
- YAML (interchange format)
- Natural language (compiled to FPL)
Why This Matters Now
As agents move into production, policy becomes a core primitive—as fundamental as the agent’s model or tools. YAML was never meant for this. Rego was built for static infrastructure, not dynamic, multi‑step agent workflows.
FPL is the first language designed specifically for AI agents. It reduces complexity, eliminates entire classes of configuration errors, and gives safety teams a way to enforce policy without rewriting the agent.
If you’re building agents, stop hoping that prompts or YAML will hold. Try FPL.
Ready to get started?
GitHub: https://github.com/faramesh/fpl-lang – language spec, examples, conformance
Docs: https://faramesh.dev/docs/fpl – complete language reference
Governance engine: https://github.com/faramesh/faramesh-core
