Reconstructing what happened
An execution stops and you have to work out which steps have already completed.
AI workflows · Delivery and managed platform
We design workflows with AI.
We run the platform behind them.
mklang describes the AI’s work in a document: what to produce, which conditions to meet and when to revise, ask for a decision or stop.
mklang platform connects that work to business systems and manages workflow execution, credentials and external actions.
We start with your process, whether new or already automated. We build the workflow and put it into operation on the managed platform.
01 / Process
What still needs your intervention?
Chasing a decision
A person needs to decide, but the request and reply happen outside the workflow.
Checking before retrying
The external system may have performed the action even though no reply reached you.
These paths are part of the process we design.
02 / Operator console
Your team can see where to step in.
Operators use the console to inspect executions, answer waiting decisions and check recorded events. Operational decisions stay with the people who know the process.
Read the film transcript (20 seconds)
- 0–4s: The platform loads the request and facts. A mklang machine prepares a reply; a later workflow step performs the external action.
- 4–10s: An exact excerpt from support_reply.mkl shows acceptance, at most two repairs, or escalation. Prose gates are model judgements; the host enforces transitions.
- 10–16s: Real Run detail crops show the question, available context and reply controls. The example asks what the reply should say, with any missing facts or instruction.
- 16–20s: Applying a reply lets the machine use the instruction. The workflow may continue; this does not establish run completion or message delivery. The real console shows In progress.
The complete machine is available below. This is an illustrated sequence with read-only fixture snapshots, not a continuous execution recording.
A mklang machine inside the workflow
-
Platform · Inputs
Fetch the inputs.
A connector reads the request and available information from business systems.
-
mklang · support_reply.mkl
Draft and assess the reply.
The
draftstate generates a reply. Gates decide whether to return it, revise it up to twice or ask a person.With
escalate, the host suspends execution. After the human reply,apply_human_decisionprepares the result. -
Platform · External action
Act on the result.
A later workflow step can send the reply through a connector, subject to platform authorisation and controls. The machine does not send messages.
The machine below is complete and checked with the platform’s interpreter. Fetching and sending illustrate integration; they are not included in the file. No customer data.
The diagram describes two states in one machine: a single mklang workflow step can contain multiple states, judgements and revisions.
Read the complete mklang document
# Platform example: prepares text; never sends a message (ADRs 0001 and 0040).
# Prose gates are model judgements, not guarantees of factual correctness.
# The mkp: hooks below are supplied by mklang platform, not standalone mklang.
mklang: "0.4"
machine: support_reply
entry: draft
budget: 6
default_tier: balanced
result: reply
context:
request: ""
facts: ""
hooks:
- name: "mkp:eq:output:"
description: True when the generated text is the empty string.
- name: mkp:has:output
description: Checks presence only, not correctness or quality.
states:
draft:
structure: A short support reply, using only the supplied facts.
execution: Do not invent facts or claim to have performed any external action.
prompt: |
Request: {{request}}
Available facts: {{facts}}
Draft a reply. If facts are missing, say what needs clarification.
output: reply
gates:
- when: the draft is empty
hook: "mkp:eq:output:"
fail: true
- when: the reply answers the request and is supported by the supplied facts
then: ok
to: END
- when: the draft can be corrected using only the supplied facts
repair: 2
to: draft
- when: otherwise
escalate: true
ask: "What should the reply say? Supply the missing facts or an instruction."
to: apply_human_decision
apply_human_decision:
structure: A support reply following the human instruction.
execution: Do not claim to have sent a message or performed any external action.
prompt: |
Request: {{request}}
Available facts: {{facts}}
Previous draft: {{reply}}
Human instruction: {{human.reply}}
Prepare the reply using these instructions.
output: reply
gates:
- when: a reply was produced
hook: mkp:has:output
then: ok
to: END
- when: otherwise
fail: true
Natural-language gates are model judgements. The tests script the
model’s answers to check paths; they do not measure its accuracy.
The mkp:has:output hook checks only that a value is
present and non-empty, not that it is correct. An empty-string
check stops an empty draft before model judgement.
Standalone mklang can use host-supplied tool: states.
Platform machines forbid them: I/O belongs to explicit workflow
steps. The mkp: hooks in this example are supplied by
the platform; the file is not an example of standalone execution
without that host.
03 / Offer
An initial project. An ongoing platform.
01 / Initial project
The project.
We examine the current workflow, define its expected behaviour, build the connections and verify the process before launch.
02 / Recurring fee
The platform.
The process runs on the hosted mklang platform runtime, with an operator console, managed credentials and recorded events.
03 / Operational responsibility
Your team.
Owns the business rules and makes the human decisions defined in the workflow.
The project and recurring platform fee are quoted for the agreed scope. Later changes and support terms are agreed as part of the engagement.
Model usage is billed to the customer by the model provider.
We scope implementation of an agreed process, whether new or already automated. The offer does not include general support for existing automations or automatic imports.
04 / Failure and recovery
An uncertain outcome needs a check.
If an action’s outcome cannot be established safely, the run stops. Recovery through another call depends on the external system’s deduplication guarantees. Checking the outcome with the vendor requires connector support.
Controls, data handling and limitations →A defined process does not guarantee that every AI judgement is correct. Model-judged conditions need testing on your cases; exact rules require deterministic checks.
Crash tests: a summary of three cases
An editorial summary of the cases checked by the suite, not literal output from the pytest command. These tests check platform recovery; they do not measure AI judgement accuracy.
The suite kills the process after the vendor records the action and before its reply arrives. It separately checks when to stop, when another call is safe and when to verify the outcome with the vendor.
When the connector declares vendor deduplication, the call can be repeated with the same key: two requests, one action.
When the connector supports checking the outcome, recovery can confirm the action with the vendor and continue without repeating the write.
$ uv run --directory tests/e2e pytest -k 'crash or deduplicates' crash vendor records action; reply never arrives no guarantee ambiguous claim → run stops, no second call deduplication same key → two calls, one action reconciliation vendor confirms action → no second write PASSED no duplicate effect in each tested recovery path
A crash test, run on every code change. The test is in the private platform repository.
05 / First conversation
Show us where you have to step in.
Describe the process, the systems involved and the steps that need judgement or human intervention. We will assess whether it fits the platform and what building or rebuilding it would involve.
Managed onboarding is open, one workflow at a time.
- Current or proposed process
- Systems involved
- Recurring intervention
- Approximate volume