Deterministic Workflow Plus LLM Calls vs MightyBot

How the pattern works

Code owns control flow. Each LLM call is a step with a defined input and output, and the next step is chosen by code, a rule or a state machine. Anthropic names five workflow shapes: prompt chaining, routing, parallelization, orchestrator-workers and evaluator-optimizer (Building effective agents). A lending workflow usually combines them: route by document type, chain classify then extract then validate, run independent extractions in parallel, then let a checker step score the result.

Teams build this on several stacks, and each is a reasonable base:

• LangGraph, a graph and state machine runtime for LLM applications. Readers evaluating that vendor can see MightyBot vs LangChain and LangGraph.
• Temporal, durable execution: "the ability of a Workflow Execution to maintain its state and progress even in the face of failures."
• AWS Step Functions with Bedrock tasks, including human approval through task-token callbacks. See also MightyBot vs Amazon Bedrock AgentCore.
• Azure Durable Functions, stateful orchestrations on serverless compute.
• LlamaIndex Workflows, event-driven steps in Python.
• Prefect, a Python workflow orchestrator.

The word "deterministic" applies to the orchestration. The routing rules are predefined, and a check applied to the same extracted values under the same policy version returns the same result. The model call inside a step is a separate question: re-extracting the same document can change the values, and with them the branch taken and the verdict. Full-document rerun agreement has to be evaluated across extraction and every other model step. More below and in what deterministic AI means.

What your team builds for a lending workflow

The stack gives you the graph. For a lending or finance workflow, the graph is a small part of the system. Your team builds:

• Document ingestion and classification across packages that arrive in different orders, formats and scan quality.
• Extraction schemas and validation for every document type the workflow reads.
• The policy layer. Rules as code branches, thresholds and validators, or a store of versioned configuration, decision tables or a policy service that the code reads.
• Policy authoring, versioning and rollback for that layer, so a credit policy change can be released and reversed, and so you can say which version governed a decision made six months ago.
• Evals and regression suites that run again at every model upgrade.
• Review queues for the cases the checks cannot settle, and the interface reviewers use.
• Decision evidence that ties each outcome to its source pages and the policy version in force.
• Capacity, retries, state recovery and on-call. The fault-tolerant agent pipelines post covers the retry and state machine side.

The hub lists the eight layers a build has to add with the engineering each takes.

Where it breaks down

The LLM step stays probabilistic inside a deterministic graph. Temperature 0 narrows sampling but does not make a hosted model deterministic. In one published test, 1,000 identical requests at temperature 0 produced 80 unique completions (Thinking Machines). A repeatable graph around a variable step gives you predefined routing rules and a variable extraction, and a different extraction can take a different branch. Putting the decision in code makes the check repeatable for identical inputs. It does not make the whole run repeatable, so rerun agreement has to be measured over the full document, extraction included. Moving the decision into code also brings the second point.

Policy change runs through engineering when the rule lives in code. In the usual implementation a threshold, a branch or a validator is application code, so a change to the credit policy becomes a ticket: edit, test, review, deploy, and rollback is a redeploy. The policy owner who understands the rule and the engineer who can change it are different people, and the queue between them sets the pace of policy change.

The workflow definition does not force that. It fixes the control flow (LangGraph describes workflows as having "predetermined code paths"), and it says nothing about where policy values live or who may edit them. A team can keep policy in versioned configuration, decision tables or a separate policy service that the workflow reads, and let policy owners edit it. That layer then needs its own authoring interface, versioning, review, rollback, tests and a record of which version governed each decision. The team builds and operates it, or buys and integrates it. The comparison on this page is between providing that layer yourself and MightyBot supplying it.

The build is larger than the graph. The ROI calculator treats this pattern as the strongest internal build and still sizes it, as a planning assumption, at 6 engineers for 15 months plus 3 maintenance engineers once live. Those are editable inputs. The full build vs buy cost comparison runs the three-year math.

How MightyBot does it

MightyBot runs the same hybrid: deterministic code paths for checks and LLM steps for reading and judgment, inside one compiled plan. The difference is that the policy layer comes with the platform.

Your policy owners write the rules as plain English in the policy engine. The Agent Compiler builds the schemas, the workflow and a versioned execution plan from that description. A policy change is an edit to the policy, versioned, with rollback, and reruns execute against the policy snapshot that was in force. The authoring, versioning, review and per-decision policy record that a team would otherwise build around its own configuration or rules store are part of the platform.

Policy Profiles handle the variants that would otherwise be code branches: one workflow, with rules that vary by jurisdiction, counterparty or product, and every decision records the profile it ran under.

Documents arrive through the Document Intelligence Pipeline, which classifies, splits, extracts, normalizes, reconciles and recomposes each package and attaches document intelligence evidence pointers down to the page and character.

Every decision leaves a why-trail: policy version, values checked, evidence pointers, evaluation results and the final determination, with compliance exports.

Proof, attributed to its deployment: 99% or higher accuracy was observed in one construction draw review deployment; validate other workflows on your own data. See production results.

How we are benchmarking this architecture

MightyBot is running a first-party benchmark that includes this pattern. The same regulated document workflows run on a deterministic workflow with LLM calls and on each of the other four build types. Results will be labeled vendor-run, synthetic and specific to the configurations tested. Nothing has been published yet; this page will link to the results when they are.