The frameworks aren't the runtime

The questions after the demo

You build an agent. It demos flawlessly: it reasons, calls tools, produces a clean result. Then you try to put it in front of a regulated customer, and the questions start. Can you prove it will only ever take the actions that were approved? When it does something wrong, can you reconstruct exactly why? Who, on the compliance side, can read what this thing is actually allowed to do without reading your code?

The reflex at this point is to reach for a better framework (LangGraph, CrewAI, Microsoft Agent Framework) or a better model. Neither closes the gap, because the gap is neither composition nor reasoning quality. Three things block production, and all three are structural:

What the agent may do is bounded only by the agent's own code. An agent that demos perfectly can still propose an action nobody approved, under a prompt you didn't anticipate.
Governance gets bolted on. Audit trails get reconstructed after incidents. Human sign-off is wired into the agent by whoever writes it, so only engineers can read what the agent is permitted to do; compliance can't.
Building the missing infrastructure in-house is a project of its own: multi-tenancy, an event log, deterministic execution, HITL state machines.

All three sit in the infrastructure, below the application.

The frameworks aren't the runtime

Agent frameworks live in the application layer. They help you compose an agent that you then trust to decide and act. That is an agent-first posture: trust the agent, and control it better. The frameworks do ship control primitives, and all three put them in the agent's own code: an interrupt() call in a LangGraph node, human_input on a CrewAI task, approval_mode on a Microsoft Agent Framework tool.

Where Zarel fits in the stack: the interaction layer, the reasoning layer (the LLM), the control layer where the contract is enforced, and the execution and data layer.

A runtime takes the opposite posture, system-first. The agent is probabilistic, so by design it holds no execution authority. The model's job is to translate the user's words into a structured intent, and the runtime decides whether that intent ever becomes an action.

The stack has four layers, and the runtime is the third:

Interaction    →  chat, voice, UI
Reasoning      →  the LLM
Control        →  intent compilation, governance, state machines, audit  ← the runtime
Execution/Data →  databases, external APIs

The runtime is the Control layer itself: it runs agents, governs them and keeps the record of what they did.

The Contract

The runtime is configured by a single declarative artifact: the contract, written in YAML. One contract declares the data model, access control down to the field, the deterministic workflows, the governance rules (preconditions and how strictly each action's preconditions bind, which steps need a person), the business process, and the external integrations. The runtime reads the contract and configures itself. There is no framework to wrap and no boilerplate to write: the contract is the program, and the runtime is the interpreter.

Engineers, product and compliance can all read the contract, and it is the contract that compliance signs.

And the runtime enforces it strictly: no contract, no action. An action outside the declared surface has no tool the model can call. If the model names it anyway, it fails as an unknown action before any other check, and the REST actions route answers unknown_action.

Here are three of the actions in the support-triage reference contract, verbatim, each declaring the state it requires, what it writes, and the phase of the process it belongs to.

actions:
  - name: create_ticket
    entity: tickets
    type: create
    preconditions:
      - op: entity_exists
        entity: users
        scope: owner
    effects:
      writes:
        - entity: tickets
          field: status
    phases:
      - intake
  - name: classify_ticket
    entity: tickets
    type: update
    preconditions:
      - op: entity_state
        entity: tickets
        field: status
        values:
          - open
    effects:
      writes:
        - entity: tickets
          field: status
    phases:
      - triage
  - name: escalate_ticket
    entity: tickets
    type: update
    preconditions:
      - op: entity_state
        entity: tickets
        field: status
        values:
          - triaged
    effects:
      writes:
        - entity: tickets
          field: status
    phases:
      - resolution

The preconditions are assertions about state that a machine checks; the LLM is never asked to honor them. Where a person must sign off, the contract says so on the transition. Two of the transitions in the fintech credit contract:

- from: policy_validated
  to: hitl_required
  allowed_roles:
    - system
  rules:
    - condition: requested_amount > credit_accounts.current_limit * 1.25
      message: high_value_requires_review
- from: hitl_required
  to: approved
  allowed_roles:
    - risk_officer
  effect: confirm

What sends a request to review is a condition on the data. Approving it takes the risk_officer role, and effect: confirm, written on the edge by whoever wrote the contract, means the runtime does not take that edge until the approver confirms it. No model score enters either decision.

What the runtime actually enforces

These are properties of the runtime, which is the only place they can be enforced.

The governance pipeline: a request crosses runtime-api, which authenticates and validates it, and cognitive-engine, which asks the LLM for an intent and dispatches what it proposes; record-service authorizes and executes it against PostgreSQL, and every write verdict and every state-machine and flow event is hash-chained.

Topic gate. A regulated boundary the contract declares is refused before the answering model runs: a classifier labels the input, and the refusal comes in fixed words and fails closed (see The refusal is a control output). Other off-topic input is handled leniently by design: an unclear request goes through rather than risk blocking a legitimate one.
Governance pipeline. Every write to a record goes through the same checks in the same order (permission, phase, preconditions, value binding), whether it came from the agent or the REST API. The agent's proposals meet the topic gate first, and a write the contract marks for confirmation waits for a person.
Human-in-the-loop as a first-class persisted state. A flow step that needs a person returns suspended: true; the flow is persisted and resumes when that person confirms or decides, with the original intent intact. The confirmation is bound to the exact write it approves, and the contract declares where one is needed (persisting the pause is the easy half).
Recorded decisions. Every verdict on a proposed write, refusals included, is hash-chained before the write runs, with the version of the contract that decided it; every state transition and flow step is a hash-chained event too. A trace id ties them together: the verdicts, the preconditions that failed, and, on a state transition, the role the actor held.
Native multi-tenancy. One deployment serves many business units or customer tenants, isolated by row-level security in PostgreSQL, so the database enforces the isolation on every query.

The honest version of "deterministic"

"Deterministic" is the most overused word in this category right now, which is exactly why the precise claim matters: architects detect an exaggerated one instantly.

For a flow the contract declares, the execution graph is deterministic; the intent, the response, and any step the contract hands to a model are not.

The LLM is confined to the places the contract names. At the start of a turn it turns the user's words into a structured intent, which includes choosing the flow and filling its inputs. At the end it phrases the response. A flow may also declare a model step, as support triage does to classify the message, and when the step declares an output schema, its output must match it before anything reads it. Everything in between (which action is formed, whether it is allowed, what side effects run, what gets logged) is driven by the contract: with the same contract, the same intent and the same outputs from its model steps, the flow takes the same path. Outside a declared flow, when the model plans several steps on its own, the sequence is adaptive: each step is governed, and the order is the model's.

If the model held operational authority over execution, none of these guarantees would survive. Governance, multi-tenancy, an event log and HITL state machines can only be enforced as properties of the runtime; added on top of a probabilistic agent, they stay advisory. The best-built counter-offer promises the opposite: Microsoft's Agent Governance Toolkit, where, in the review by Venkat Peri, who works on agentic AI infrastructure for wealth management at Advisor360°, "You do not rewrite your agent code." The agent proposes is about where that promise stops: by the toolkit's own README, the policy engine and the agents it governs run in the same process.

Who this is for

Two shapes of team hit this wall.

The first deploys agents internally into regulated or high-stakes operations (financial services, insurance, legal), where the cost of an agent doing the wrong thing is measured in money or in compliance exposure.

The second is where the runtime model matters most: B2B SaaS teams shipping agents to their own regulated customers. If you sell software into banks and insurers, governance can't be a dependency you rent from one cloud's gateway. Your customers span environments, so the controls have to be infrastructure that travels with your product rather than a lock-in you and they share.

If your team is shipping agents into regulated operations and weighing governance, audit gaps, or a build-versus-buy decision, talk to us.

Nicolás Moreno builds Zarel: governed AI operations, where the AI proposes and the contract decides.