Declarative AI Agents: Spec Once, Generate Everywhere with ACEL

Most agent frameworks still force you to write imperative code: wire tools, manage memory, hard-code oversight logic, and re-implement the same patterns for every new runtime. The result is brittle agents that are hard to review, version, audit, or port.

A cleaner path is emerging: treat the agent as a declarative contract.

ACEL (Agent Capability Expression Language) is a small, focused language for defining AI agents. It is built on the Rectified Pentachoron Framework (RPF) and models an agent as exactly five aspects plus a global autonomy modal:

Autonomy is not a sixth aspect. It is a modal that qualifies every aspect (supervised perception, supervised deliberation, etc.). Oversight rules sit alongside it as first-class triggers (uncertainty thresholds, irreversible actions, cost limits, etc.).

A minimal example looks like this:

agent research_assistant {
  autonomy: SUPERVISED

  telos {
    goal: ACHIEVE "comprehensive_report" AND MAINTAIN "factual_accuracy"
    priority: HIGH
  }

  world_model {
    grounding: REQUIRED
    percept web_search { type: RETRIEVE protocol: MCP freshness: 1h }
  }

  memory {
    type: HYBRID
    store short_term { capacity: 10000 ttl: 1h retrieval: RECENCY }
    store long_term  { capacity: 1000000 retrieval: RELEVANCE }
  }

  deliberation {
    mode: HYBRID
    plan   { strategy: HIERARCHICAL depth: 4 replan_on_failure: true }
    decide { strategy: MONTE_CARLO_TREE_SEARCH risk: 0.4 explore: 0.2 }
    reflect { trigger: ON_ERROR over: long_term }
  }

  actuation {
    effect document_store { type: MODIFY protocol: REST permissions: READ, WRITE }
  }

  oversight high_stakes {
    trigger: UNCERTAINTY_ABOVE 0.3
    action: ASK_APPROVAL
    escalate_to: lead
  }
}

The language enforces clean separations (percepts are read-only; effects are write; reflection must bind to a declared memory store) and produces a conformance report against the five-aspect basis. The .acel

file becomes the single source of truth — versionable, reviewable, and enforceable in CI.

Writing the contract is only half the story. acel-generator (OpenAPI-Generator-style tooling for ACEL) turns that contract into concrete artifacts.

Pipeline:

.acel  →  parse + validate + RPF conformance  →  IR  →  generators  →  artifacts

Current built-in generators include:

AGENT.md

) + Mermaid architecture diagram.well-known/agent-card.json

) for discovery and delegationmcp.json

) with percepts as read tools and effects as write tools (plus destructiveHint

annotations)Governance details that current interoperability protocols do not express (autonomy level, oversight, grounding, retention shape) are emitted under namespaced extensions so the gap stays visible rather than being papered over.

Design principles of the generator:

ACEL is deliberately not a runtime. It is the contract that binds the layers you already run (agent loop, control plane, gateway, tools/MCP, memory). Author-time validation shifts left; runtime enforcement compiles autonomy and oversight into gateway rules.

Both are MIT-licensed (with a narrow patent non-assertion on the language itself). The projects are early (alpha), but the conceptual clarity is already strong.

If you are tired of re-implementing the same agent skeleton for every framework, try writing the contract once and generating the rest. Declarative agents are not just cleaner code — they are a practical step toward agents that are governable, auditable, and portable by design.