Automation Before AI: The Foundations Most Enterprise Teams Miss

A customer request arrives by email. Someone reads it, finds the account in one system, checks eligibility in another and asks a colleague for approval. Once the work is done, they copy the outcome into a spreadsheet.

An AI assistant could interpret the email or draft the reply. But the account still needs to be identified correctly, the eligibility rules applied and the approval sent to someone with authority. Someone also needs to record the outcome without creating conflicting records.

How those steps work determines whether AI saves time across the process. A faster draft helps less if the request then spends two days waiting in an inbox.

That is the reasoning behind automation before AI. Establish how work moves and what permits it to proceed before asking a model to take responsibility for part of it. A pilot needs enough structure around its chosen workflow to produce a result the team can trust. It can build that structure within a narrow scope, without waiting for an enterprise-wide transformation.

For leaders deciding where to invest, process ownership and integration deserve attention alongside model selection. They determine how much of a demonstration can become a service people use every day.

Find out how the work gets done

A process diagram may show a request moving neatly from submission to approval. Follow a few real cases and you may find shared inboxes, private spreadsheets and decisions made through chat.

Those informal steps can contain information the automation needs. A coordinator recognises that a particular customer requires another check. An administrator knows which duplicate account is current. A finance analyst waits for a purchase order to appear before forwarding an invoice. None of that may be written down.

Observe an ordinary request, a delayed one and a case that needed correction. Record where people found information, what they checked and why work stopped. Ask how they handle the same case when the person who usually resolves it is away.

Then question the steps themselves. An approval introduced for a retired system may persist because nobody has authority to remove it. A reconciliation task may exist because two applications disagree about who owns a record. Automating either step preserves the underlying problem.

The first process map should distinguish required controls from historical workarounds. It needs enough detail for someone outside the team to follow a case without relying on personal knowledge. That gives the business owner something concrete to review before implementation begins.

Keep rules separate from interpretation

Checking whether a required field exists is a rule. Calculating a contractual deadline is also a rule, once the relevant dates and terms are known. Understanding an ambiguous customer email may benefit from AI.

These tasks can sit in the same workflow while retaining different responsibilities:

The boundary can change as the team gathers evidence, but it should remain visible in the implementation.

Anthropic's guidance on building effective agents distinguishes predefined workflows from systems where models direct their own execution. It recommends starting with the simplest approach that meets the need and weighing the extra cost and latency of greater complexity.

For an enterprise application, a model might propose a request category while application code applies the routing policy. The model interprets the input; the workflow determines what that interpretation permits.

This also helps when something goes wrong. Engineers can investigate whether the system misunderstood the request, applied an incorrect rule or failed to carry out the intended action. Combining all three inside an opaque model interaction makes that investigation harder.

Put someone in charge of the completed outcome

Customer operations may receive a request, finance may validate it, and a technology team may maintain the integration. Each department can complete its assigned task while the request itself remains unresolved.

A business owner needs authority to resolve disagreements about the process. They should decide which rules apply, who handles stalled work and how exceptions affect priorities. Giving someone the title without that authority leaves the same gaps in place.

The service also needs a technical owner after the delivery team leaves. Interfaces need maintenance, failures need investigation and changes need a release process. Agree those responsibilities before production use.

Both owners need a shared measure of success. Successful API calls tell the technical team whether an integration is responding. They do not tell the business whether a customer's request has been completed. The service should report both, with enough detail to explain why the numbers differ.

This is part of process automation and AI adoption: agreeing what completion means and who acts when the workflow cannot reach it.

Decide which records to trust

People can work around data problems through experience. An automated process needs an explicit way to resolve them.

A customer may have different identifiers in billing and support. A supplier record may contain an outdated address. Two policy documents may disagree without saying which version applies. A model can generate an answer from that material, but the organisation still has to establish whether the evidence is authoritative.

For the workflow being built, identify:

• The system responsible for each important record.
• The identifier that connects records across systems.
• How current the information must be.
• Who resolves missing or conflicting values.
• Which historical version applies to a past decision.

Keep this work scoped. A supplier-onboarding project needs reliable supplier identification and the status of the required checks. It does not need to repair every data problem in the enterprise before it can start.

When extracting or transforming information, preserve its source. Reviewers should be able to find the original document, the relevant passage and the time of processing. Without that context, they may have to repeat the extraction work to verify a proposed value.

An extracted value also needs the checks appropriate to its use. A bank account number can have a valid format without belonging to the intended supplier. Treating extraction as a proposal keeps that distinction visible.

The practical purpose of data engineering here is to give each step information with enough context and ownership to support the next action.

Make system changes safe to repeat

An assistant that explains the next step still needs a dependable way to carry it out. For every system interaction, define the required input, the operation's effect and the evidence that confirms success.

A request to create a case, for example, needs a customer identifier, accepted fields and defined failure responses. It also needs a way to recognise a case that already exists.

Suppose the destination creates the case but its response is lost. A retry could create a duplicate. An idempotency key or another duplicate-detection mechanism can make repeated attempts safe. If the destination cannot support that behaviour, the integration needs a way to reconcile the uncertain result.

A timeout leaves the outcome unknown until the application has enough evidence to establish what happened. Treating every timeout as a failed action can lead the workflow to repeat work that succeeded.

Legacy applications need the same care, even when their interfaces are limited. Where screen automation is the only practical option, identify which interface changes could break it and give failures a monitored recovery route.

Targeted legacy modernisation can provide a stable interface around the operations the workflow needs. A small integration layer may be enough; the scope should follow the process requirements and the limitations of the existing application.

Give exceptions somewhere to go

Missing attachments and conflicting records belong in the design from the start. So do unsupported requests and unavailable services.

When processing stops, the exception record should explain why, show the evidence collected and identify the decision needed next. It must also say whether the workflow has already changed anything in an external system. Otherwise, the person resolving the case may repeat an action without knowing it.

Recovery depends on the failure. A temporary connection problem may justify a bounded retry. A missing approval needs an authorised person. Conflicting customer identities need investigation. Sending all of them through the same retry loop creates delay and can increase risk.

AWS describes explicit retry and catch mechanisms in its guidance on handling workflow errors in Step Functions. Whatever orchestration technology the team chooses, each failure class needs a defined recovery path.

Assign an owner and a service target to the exception queue. During the pilot, review why cases leave the automated path and how long they wait. The evidence may point to a missing rule, an unreliable integration or an unclear policy. It also helps identify where AI could usefully handle variation in the input.

Define authority at the point of action

An assistant may need to read a customer record without being allowed to update it. It may prepare a refund recommendation while an employee approves the payment. Those are separate permissions, and the integration should enforce them.

Use identities with access appropriate to the task. Check proposed actions against business rules before execution. A prompt asking the model to behave carefully cannot enforce those controls.

Where approval is required, bind it to the action's material details. Approval to refund £50 against a particular transaction should apply to that amount and transaction. If either changes, the workflow needs to establish whether a new approval is required.

Keep a record of who requested the action, what supported it and who approved it. Include the destination system's confirmation so the record covers what happened as well as what was intended.

Reviewers need an interface that makes the relevant evidence and differences easy to inspect. If they have to reconstruct every case from logs, review becomes another expensive manual task. If they routinely approve without checking, investigate workload, presentation and incentives before assuming the control provides meaningful oversight.

Measure the work that remains

Faster data entry can come with more correction. Quicker draft responses can leave customers returning because their underlying request is unresolved. Measuring one step misses both effects.

Track the complete workflow, including:

• Time from receipt to verified completion.
• Staff effort per completed case.
• The percentage completed without correction.
• Exception volume and time awaiting resolution.
• Cost per accepted outcome.
• Errors discovered after completion.

Define an accepted outcome before comparing approaches. A supplier record might require correct information, completed checks and a confirmed update in the destination system. Use the same definition for the manual baseline, ordinary automation and the AI-assisted version.

Consider a hypothetical team handling 1,000 requests a month. A tool saves four minutes on each request, giving 4,000 minutes of gross savings. If 200 requests then need ten extra minutes of correction, half the saving disappears before support and operating costs are counted.

That calculation gives the team a place to investigate. It also gives leaders a more useful business case than a component's processing speed alone. Keep review and recovery effort in the numbers as the service grows.

Introduce AI for a specific unresolved task

Once account validation, entitlement rules and work-order creation operate reliably, a service-request process may still need someone to interpret descriptions written in many different ways. That is a bounded task for AI to evaluate.

Build a test set from representative descriptions. Include ambiguous requests and examples outside the supported scope. Check whether the model selects the correct category and whether it recognises when the available information is insufficient.

Choose acceptance thresholds from observed performance on labelled examples and the consequences of an error. The model's stated confidence alone is insufficient evidence.

Begin with proposals visible to staff. Where appropriate, run the model alongside the existing process so the team can compare outputs without giving it control over production actions. That comparison should include the time people spend checking and correcting its work.

Expand responsibility selectively. Low-consequence categories with consistent evaluation results may become suitable for automatic routing. Other cases can continue to receive review.

Re-evaluate when the model, prompt or policy changes, and when the incoming requests change. The workflow's state tracking and exception records should help the team detect where previously acceptable behaviour has deteriorated.

Build within one useful workflow

A foundations programme can grow until the original operational problem disappears beneath it. Keep the work attached to one process with sufficient volume, a business owner and a measurable result. The team needs representative cases and a safe way to recover from mistakes.

First, observe the process and measure its current performance. Identify unnecessary steps, authoritative records and the main causes of delay.

Implement the predictable parts next: validation, routing, state tracking and system updates. Include exception handling and operational visibility in that first version. These are requirements for running the workflow, even while its scope remains small.

Then evaluate AI for the part that still requires interpretation, using the same completion criteria as the baseline. Pilot the whole process at limited volume and review corrections with the people doing the work. Before increasing usage, confirm who supports it and how they recover interrupted cases.

Each stage should leave something useful. Better intake validation can reduce follow-up. A reliable integration can remove duplicate entry. A visible exception queue can expose requests that previously sat unnoticed in inboxes. Those improvements also make the AI evaluation easier to interpret because fewer unrelated failures obscure the result.

For the next candidate workflow, follow one real case from arrival to completion. Establish which records it uses, what permits each system change and who handles an uncertain outcome. Resolve those questions within that process, then test whether AI improves the remaining task. The decision to expand should rest on completed cases, including the effort spent reviewing and recovering them.