Controlling AI In Production

A Decision Control Layer for AI in Production

As AI systems move into production, the core challenge is no longer model performance. It is control.

For senior engineering teams, this can show up as an inability to clearly explain system behaviour to clients, difficulty changing requirements without touching code and growing risk as decision logic becomes scattered across prompts, agents and orchestration flows.

In real production systems, all relavent stake holders need to understand why a decision was made, what outcome was produced and how it can be changed.

Many teams attempt to regain control by adding layers of complexity. Prompts become longer and more fragile. Guard clauses spread across services. Human review is added as a safety net.

In practice, this creates behaviour that is difficult to explain and makes systems harder to sell, harder to audit and harder to operate at scale. 

Human oversight cannot be added as a final step. It only works when decision boundaries are explicit and behaviour can be inspected, explained and changed intentionally. 

We suggest a different approach.

The model remains probabilistic. The decisions do not.

By externalising decision authority into a dedicated DSL, behaviour becomes visible, reviewable and changeable without modifying agents or workflows. This allows teams to retain control as systems evolve, while giving clients clearer, more deterministic insight into how decisions are made and how they can be adjusted.

This document explains how a decision focused Domain Specific Language can be layered on top of AI driven workflows and agent runtimes to externalise decision authority. 

This document presents one concrete example. The exact shape will vary by application, but the principle remains the same.

The Decision DSL defines decision rules, thresholds, policies and priorities. These are compiled into runtime logic used during execution. Rules may optionally be authored using an English like DSL and compiled into the execution representation. It remains responsible for workflow orchestration, state handling and agent execution. Executors act as the integration point between execution and decision authority. At explicit decision points, executors invoke the compiled rule logic and apply the resulting decision. The DSL does not define workflows, agents, or prompts. It governs how decisions influence execution.

Where the DSL Sits

The Decision DSL sits above execution but below orchestration intent.

It does not replace:

  • workflow engines
  • agent runtimes
  • orchestration frameworks


It complements them by owning decision authority.

High level responsibilities are split as follows.

Execution framework:

  • workflow orchestration
  • agent invocation
  • state handling
  • retries and failure handling


Decision DSL:

  • decision rules
  • thresholds
  • policies
  • priorities
  • conflict resolution
  • decision outcomes


How Decisions Are Executed

Decisions are evaluated only when explicitly invoked.

Invocation happens at defined decision points such as:

  • after an agent produces output
  • before routing to a downstream step
  • before executing a tool or external action
  • before committing data
  • before escalation or closure


At runtime:

  • an executor gathers relevant facts
  • the executor invokes the decision engine
  • the decision engine evaluates applicable rules
  • a structured decision is returned
  • the executor applies that decision


The executor is the integration point between execution and decision authority.

Dynamic Workflows

Dynamic workflows introduce branching and behavioural change over time.

In these workflows:

  • the workflow structure remains stable
  • agents remain unchanged
  • prompts remain unchanged


Only decisions change.

Rules influence behaviour by returning structured outcomes such as:

  • allow progression
  • block downstream actions
  • escalate to manual review
  • select stricter execution paths


This allows behaviour to evolve immediately without redeploying workflows or modifying agents.

This diagram shows a workflow with dynamic decision outcomes. The workflow structure and execution order remain unchanged. Executors invoke the decision engine at explicit decision points. The Decision DSL evaluates rules and returns structured outcomes that configure execution behaviour, such as allowing progression, escalating to manual review, or blocking downstream actions. Behaviour changes at runtime without modifying the workflow, agents or prompts.

Example Dynamic Workflow

A workflow evaluates candidate suitability for a role.

Fixed workflow steps:

  • ingest candidate profile
  • run assessment agent
  • decide next action
  • route outcome 


Example rule set:

  • IF role is marked high risk AND assessment confidence is below 0.85
    THEN escalate to senior reviewer
    ELSE continue workflow
  • IF protected attribute indicators are detected
    THEN mask attributes before assessment
    ELSE proceed with original profile


Runtime flow:

  • the agent produces an assessment
  • the executor extracts confidence score and detected terms
  • the decision engine evaluates the rules
  • a decision is returned such as allow escalate or block
  • the executor routes or halts execution accordingly

The workflow does not change. Only the outcome changes.

Static and Batch Workflows

The same decision model applies to static or batch workflows.

In static workflows:

  • the execution order is fixed
  • steps are predefined
  • execution is deterministic


The DSL does not generate or modify workflows.

It governs decisions inside workflow steps.

Example decisions include:

  • inclusion or exclusion criteria
  • validation conditions
  • scoring thresholds


Rules are evaluated inside executors during execution. Changing rules affects the next run without changing code.

Rule Authoring and Ownership

How rules are authored is separate from how they are executed.

At runtime decisions are represented in executable form for efficiency and integration.

Low level formats such as JSON or code are not suitable for:

  • review by non engineers
  • discussion with stakeholders
  • clear ownership of decision logic

For this reason an English like authoring DSL can sit above the execution representation.

In this model:

  • domain experts define rules in readable language
  • rules are reviewed without referencing code
  • the DSL compiles into executable decision logic
  • execution behaviour remains unchanged


This provides:

  • transparency
  • auditability
  • explicit ownership
  • faster change cycles


The authoring DSL feeds execution logic. It does not replace it.

Contact US