I proposed a rules layer for the A2A protocol. Here's why.

The AI agent protocol stack is taking shape fast. Two standards are now widely adopted:

• MCP (Anthropic → Linux Foundation): Agent ↔ Tools. 97M+ monthly downloads.
• A2A (Google → Linux Foundation): Agent ↔ Agent. 150+ organizations in production.

Both are solid protocols. But they expose a question that every engineer deploying agents hits eventually:

Who decides what an agent shouldn't do?

---

The current answer: Prompts

You are a responsible agent. Do not execute dangerous commands.
Follow security policies. Respect data boundaries.

Any engineer who's actually deployed an agent knows how this ends. The prompt is a suggestion. The LLM is a probability engine. It doesn't understand "forbidden" — it understands "low probability."

That's fine for a chatbot. It's not fine for banking, healthcare, or production infrastructure.

What's needed is a mechanism that sits before the tool call and says "no" deterministically — not as an LLM judgment, but as a protocol-level enforcement.

---

What I proposed in the A2A community

Last week, I opened a discussion on the A2A repo (#2031) proposing an extension to the Agent Card: a way for agents to declare their behavioral rules at the protocol level.

The reactions confirmed what I suspected: this is a real gap.

A respected contributor from the community (chopmob-cloud / AlgoVoi) responded with a sharp distinction that materially improved the proposal: a trust score is reputation, but compliance requires evidence. A number like 850 says "this agent is generally trusted." A recomputable, content-addressed record — hash(rule_version + inputs + verdict) — says "this specific decision was permitted, and you can verify it yourself with no keys and no issuer contact."

That distinction is now baked into the spec. Reputation scores are advisory. Compliance is per-decision, recomputable, no-trust-required.

---

ERDL in 30 seconds

ERDL (Entity-Rule Definition Language) is a declarative rules standard. One YAML file. Placed in the agent's workspace. Evaluated by a deterministic engine before every tool call.

# agent.erdl.yaml

rules:
  - name: "no-dangerous-commands"
    priority: 100
    when:
      logic: AND
      conditions:
        - field: "tool.name"
          operator: eq
          value: "exec"
        - field: "tool.args.command"
          operator: match
          value: "(delete|format|drop table)"
    then: BLOCK
    message: "Dangerous command intercepted"

  - name: "required-human-approval"
    priority: 45
    when:
      logic: AND
      conditions:
        - field: "action.impact_tier"
          operator: gte
          value: "high"
        - field: "action.domain"
          operator: in
          value: ["employment", "credit", "healthcare"]
    then: REQUEST_HUMAN
    message: "High-impact decision requires human approval"

The agent cannot bypass this. It's not a prompt. It's a gate.

---

Where ERDL fits

A2A  (Google)   Agent ↔ Agent   Communication
ERDL (OpenOBA)  Rules & Governance   ← This
MCP  (Anthropic) Agent ↔ Tool   Tools

It doesn't replace either. It complements them.

• MCP says what tools the agent can use
• A2A says who the agent can talk to
• ERDL says what the agent should and shouldn't do

---

The evidence-first architecture

This is the part I'm most proud of, and it came directly from community feedback.

Every ERDL decision generates an evidence record:

rule_name: "no-dangerous-commands"
rule_version: 1.3.2
inputs: { tool: "exec", command: "drop table users" }
eval_tree:
  - tool.name == "exec" → true
  - command MATCH "(delete|format|drop table)" → true
  - AND → true
verdict: BLOCK
timestamp: 2026-07-05T09:23:11.452Z
receipt: sha256(canonicalize(above))

Any third party — a regulator, a partner, an auditor — can re-derive the receipt from the record alone. No keys, no issuer contact, no "trust me."

This is the difference between saying "our agent is safe" and proving it.

---

What we have so far

• Spec v1.0: English + Chinese, MIT license
• Reference implementation: npm install @openoba/erdl, 197 tests, 0 failures
• Agent Card extension proposal: under active discussion on A2A #2031
• Landing page: openoba.github.io/erdl-landing

---

What we need

This isn't a solo project. A protocol standard only works if people use it, critique it, and contribute to it.

If you've deployed AI agents and hit the "how do I stop it from doing X" problem — I'd love to hear about your experience. What guardrails did you build? What broke?

If you think a rules layer in the agent protocol stack makes sense — or doesn't — I'd welcome the debate.

GitHub: github.com/openoba/erdl
A2A Discussion: RFC #2031
Contact: [e-mail]

---

Posted by haoran-tang-ch · OpenOBA

Comments

[Alex Shev]

Rules layers for agent protocols feel necessary because capability discovery alone is not enough. Agents also need to know which actions require approval, which state must be preserved, and what evidence has to come back.

[Tang Haoran]

This maps exactly to the three-layer model we've been building. We call it Action Guard (approval gating), Cognitive Audit Log (state preservation + traceability), and ReAct reasoning chain (evidence loopback). The insight we'd add: a rules layer needs to be a first-class semantic contract — shared between human, LLM, system, and auditor — not something baked into prompts. Happy to compare notes.

[Alex Shev]

The semantic-contract point is the part I would emphasize most. If the rules layer is only prompt text, every participant interprets it slightly differently. If it is a shared contract, humans, agents, tools, and auditors can all reason over the same boundary.

[Tang Haoran]

That's exactly the design. ERDL is that shared contract — a YAML-based protocol that sits at L9 of the agent stack. Humans read the rules, LLMs generate them, the engine enforces them, and auditors trace every decision.

We just published the v1.0 spec on GitHub: github.com/OpenOBA/erdl-landing

The latest addition (§11 Rule Governance) addresses the "what happens when hundreds of rules interact" problem — conflict detection, shadow detection, and multi-agent rule partitioning at the protocol level, not left to application code.

[Alex Shev]

That layered framing makes sense. The part I would keep testing hard is whether the contract stays understandable to a human reviewer under pressure. If auditors cannot quickly see why an action was allowed or blocked, the rules layer will be hard to trust operationally.

[Tang Haoran]

That's exactly the test we run every day.

Our erdl_explain tool shows the full decision trail — every rule checked, which ones fired, which ones didn't, and why. One line per rule. No YAML. No code. No training required.

复制
✅ TS-001 No any types → DENY — intent contains "any", output_text contains "any"
⏭️ DEP-001 Confirm deps → skipped — intent doesn't match "npm install"
⏭️ WR-001 No cliché → skipped — intent doesn't match "write_blog"

Final: DENY — 1 of 20 rules matched
If an auditor cannot read this at 2 AM during an incident, we've failed. That's the bar.

These 29 rules have been running on our own Agent for weeks. We hit them every time we write code, commit, or deploy. The contract isn't theoretical — it's the only reason we haven't drifted off-spec three times this month.