The problem
Many valuable processes are not a single question and answer. They are sequences: read an incoming request, look something up in one system, decide what to do, act in another system, and record the outcome. People do this work, and it consumes a large share of their time on tasks that are mostly mechanical but require judgement at a few points.
A single language-model prompt cannot do this reliably. The work needs tools, state that persists across steps, and the ability to recover when a step fails. At the same time, the opposite extreme — an agent left to act freely across live systems — is not something a serious organisation can put in front of real data and real actions. The failure modes are unbounded: wrong actions taken confidently, loops that burn cost, and no record of why anything happened.
The practical need is a middle path: automation that handles the mechanical steps end to end, pauses for a human at the decisions that carry consequence, and leaves an auditable trail of everything it did.
What I design and build
I build multi-step workflows as explicit, orchestrated graphs using LangGraph, where each step is a defined node with defined inputs, outputs, and permitted tools. This is deliberately not an open-ended agent told to “figure it out.” The set of tools it can call, the systems it can touch, and the actions it can take are all bounded and declared up front.
Tool use is how the workflow interacts with the world — calling internal and external APIs, querying databases, retrieving documents. For integration I use standard approaches; where a tooling protocol such as MCP fits the organisation’s stack, it is one industry-standard way to expose tools to a workflow in a consistent manner. State is managed explicitly so the workflow can pause, resume, and be inspected mid-run rather than being an opaque single call.
Consequential actions sit behind human approval gates. The workflow assembles the proposed action and its rationale, then waits for a person to approve, edit, or reject before anything irreversible happens. Every step — inputs, tool calls, decisions, approvals — is written to an audit log. To be clear about scope: this is bounded task automation, not autonomous general intelligence, and I design it as such.
Where it fits
This fits repeatable, multi-step processes that cross systems and have clear rules with a few judgement points: triage and routing of incoming requests, data gathering and enrichment across services, drafting actions for human sign-off, and orchestrating a sequence of API calls that a person currently stitches together by hand.
It is not the right tool where a deterministic script or an existing integration already does the job — adding a model there only adds cost and unpredictability. It is a poor fit for one-off tasks that will not recur, and for processes so ambiguous or high-stakes that no reliable rule set exists, where the honest answer is that a human should own the decision. Where regulation or safety demands a guaranteed outcome every time, I keep the deterministic parts deterministic and use the model only where genuine language understanding is needed.
How it works
A trigger starts the workflow. The orchestrator moves through the graph one node at a time, calling only the tools that node is permitted to use. Reversible, low-risk steps proceed automatically. When a step would take a consequential or irreversible action, the workflow stops at an approval gate and surfaces the proposed action for a human to approve or reject. Approved actions execute; every step is written to the audit log. Failed tool calls are retried with backoff, and if a step cannot complete the workflow fails into a defined safe state rather than proceeding on bad data.
Security and privacy
Each node is granted only the tools and credentials it needs, so the blast radius of any step is limited by design. Credentials are held in a secrets manager and injected at runtime, never embedded in prompts or code. For sensitive environments the workflow can run on-premises with open-weight models and restricted network egress. The audit log records who or what triggered each run, every tool call and its arguments, every approval and who granted it, and the final outcome — a record designed to answer, after the fact, exactly what happened and why.
Evaluation and reliability
Agent behaviour is evaluated, not trusted. I build test scenarios covering normal paths and known edge cases, and check that the workflow calls the right tools, respects its permissions, stops at approval gates, and reaches correct outcomes. Where a step’s output is judged qualitatively, I use LLM-as-judge scoring alongside human review on sampled runs.
Reliability is engineered in: retries with backoff on transient failures, idempotency so a retried step does not double-act, timeouts and loop limits so a run cannot spin indefinitely, and cost controls that cap token and API spend per run. When something falls outside what the workflow can handle safely, it escalates to a human rather than guessing. Regression tests run against the scenario suite so changes to prompts or tools do not silently break established behaviour.
Deployment
Workflows are containerised and run in the organisation’s cloud or on-premises. They trigger from events, schedules, queues, or API calls, and integrate with existing systems of record rather than replacing them. State and audit logs persist to a datastore you control. Human approval gates surface through whatever interface fits the team — an internal tool, a ticketing system, or a messaging channel — so approvers work where they already are.
How an engagement starts
I start by mapping one real workflow with you and identifying where judgement genuinely matters. From that I build a scoped prototype of a single process — with its tool permissions, approval gates, and audit logging in place — so you can see the automation running end to end on a contained slice before committing to a broader rollout. The first engagement is small, observable, and easy to stop.
Related work
For a worked example of a multi-step orchestrated workflow with tool use and defined control points, see the agentic workflow case study.
FAQ
Will it take actions on its own that we cannot undo?
Not unless you choose to let it. Consequential and irreversible actions sit behind human approval gates by default: the workflow proposes the action and waits for a person to approve before anything executes. Which actions require approval is a decision we make together during scoping.
How is this different from just giving an AI access to our systems?
The workflow is a bounded graph, not an open-ended agent. Each step can use only declared tools and credentials, actions are gated, and everything is logged. That containment is the point — it is what makes the automation safe to run against real systems.
What stops it from looping and running up a large bill?
Loop limits, per-run timeouts, and hard caps on token and API spend. Runs that exceed their budget stop and escalate rather than continuing.
What happens when a step fails?
Transient failures are retried with backoff and steps are made idempotent so a retry does not act twice. If a step still cannot complete, the workflow fails into a defined safe state and escalates to a human rather than proceeding on bad data.