Workflow automation with clear review points.

Automate the repeatable part of the workflow

Examples include extracting fields from documents, classifying incoming requests and drafting a follow-up. Deterministic rules should handle known steps; AI can help with unstructured inputs when its results can be checked.

Choosing which step to automate comes before choosing any tooling. Automation is useful where the input arrives in a consistent form, the correct output can be described precisely enough to check, and the cost of an incorrect result is bounded.

Deterministic rules and model judgement

Most workflows need both, and the boundary should be explicit. Conditions that can be enumerated belong in ordinary code: thresholds, routing tables, business rules and permission checks, which are inexpensive and can be unit tested.

Model steps suit unstructured input and rules that cannot be written in advance: an attachment of unpredictable layout, a free-text request to classify, a reply to draft for review. The model's output is parsed into a typed value, and deterministic code decides what happens next.

What the implementation can include

Connect the agreed tools, validate extracted data, record processing state and define retries or review queues. Specify which actions may run automatically and which require a person to approve the result.

Validating model output before it causes an action

A model step returns a value. Validation determines whether it may be used to trigger an action. The first layer is structural: the output is parsed against a schema, and anything that does not parse is rejected rather than coerced into shape.

The second layer is semantic. An extracted supplier is matched against the existing vendor list, line items are checked to sum to the stated total, an identifier is confirmed to exist before a record is updated. Items that fail either layer are routed to a review queue with the original input attached.

Integration with CRM, email and messaging

Each system has its own authentication model, rate limits and field semantics, and the available API determines what can be automated. During the sprint we review the access that can be granted and how changes arrive.

Email and messaging add further constraints: replying inside a thread depends on retaining message identifiers, and some platforms require approved templates.

Approval gates and audit trails

Actions are classified while the workflow is scoped. Reversible, low-cost actions such as an internal note or a prepared draft can run without review. Actions that reach a customer, move money or are difficult to undo are queued for approval, with the input, the proposed action and the validation result shown together.

Each run leaves an audit record: what triggered it, which model and prompt version produced the output, what validation returned, who approved it and what was written. An incorrect result is investigated from that record, which is also the evidence for any later decision to relax an approval gate.

Repeated runs, retries and failure handling

An automated workflow will process the same item more than once, because webhooks are redelivered, scheduled runs overlap and failed jobs are retried. Each step therefore needs a stable key from the business object, such as an invoice number, and a record of what it has already processed, so a repeated run does not duplicate a record or send a second message.

Retries are separated by error type. A timeout or a rate limit response is retried with backoff, honouring any retry interval the provider returns. An expired access token is refreshed once and the step retried. A rejected payload is not retried, because the same request cannot succeed. Per-step state lets a retry resume from the step that failed.

Revoked permissions, provider outages and renamed fields cannot be fixed by retrying, so each needs a defined response: stop the affected step, hold the item and alert a named owner. Monitoring covers throughput and queue age as well as error counts, so that a step which stops processing without returning an error is also detected.

Exceptions that fall outside the rule

Cases the rule does not cover accumulate in any workflow: a document in an unexpected format, a request that combines two categories, a customer record that does not exist yet. These are routed to a defined exception path with the reason recorded, rather than resolved by a rule that does not fit.

Who reviews that queue, and how often, is agreed in the proposal with the rest of the support arrangement. Recurring exceptions show whether a case should become a rule, move inside a model step or stay with a person. Changes of that kind are agreed scope changes.

Manual override and rollback

A step can also run first in shadow mode. Its output is recorded and compared against a person's decision, and the step takes no action until the comparison supports it.

Undoing an action already sent to another system usually requires a compensating action rather than a transaction rollback, so the previous value of any field the workflow writes is retained and the audit record lists every item a run touched.

Measure a bounded workflow first

Document the current process and agree how to judge the result. Acceptance may cover supported inputs, data quality, duplicate handling and failure recovery. Expansion to another workflow requires an agreed scope change.

The baseline recorded during the sprint covers how many items arrive in a period, how long each takes today, and the current error rate. Real historical items with their correct outcomes then serve as a regression set, rerun whenever a prompt, model version or rule changes.

What an automation project costs

Every engagement starts with a fixed-price discovery sprint at USD 2,500 over two weeks, which produces the architecture, initial screen designs, acceptance criteria, a running-cost model and a fixed price for the build. The sprint fee is deducted from the build.

Running cost has a variable part and a fixed part. The variable part scales with the number of items processed: model inference, metered API or message charges for the systems being read and written, and the overhead of retries. The fixed part does not scale with volume: hosting for the orchestration, and any seat or tier fees for the tools involved. The sprint produces that model with your expected volume, so the per-item cost is estimated before the build is committed. What an AI feature costs to run →

Part of the AI Feature Implementation Sprint → · Explore our work →