AI systems & operational intelligence

AI Automation: What It Takes to Make One Work

What an AI automation has to do to work in production, the obligations it creates, and measured results from three delivered systems. From the build side.

Cogya · 12 min read

A paper supplier quote tabbed with the five stages of an AI automation: read, decide, act, escalate, prove.

Search "AI automation" and the first page is platform vendors — Oracle, Salesforce, UiPath, IBM, AWS, Microsoft, Make. Each one answers "what is AI automation?", lists the same dozen use cases, and ends at a signup form. They are competent pages. Not one of them can show you a system they built for a client and the numbers it moved, because that is not what a platform does.

This page is written from the other side. Cogya builds these systems for operators, one at a time, and what follows is what we have learned has to be true for one to survive contact with a real business. The measured results in the middle section are from delivered builds, and they are linked so you can read them in full.

What AI automation is, in build terms

An AI automation is a system that performs a repeated task that previously needed a person, where at least part of the input is unstructured — a document, an email, a photograph of a quote, a note someone typed.

That last clause is the whole distinction, and it matters more than the acronyms. Traditional automation — the rules engines, the workflow tools, the robotic process automation that has been sold for two decades — works when the input arrives in a known shape. Row 4 of a CSV. A field in a form. Give those tools a supplier quote as a PDF with the total in a different place each time and they stop.

So the useful question is not "should we use AI automation or RPA?". It is: what shape does the information arrive in? Structured input, and conventional automation is cheaper, more predictable and easier to maintain — use it. Unstructured input, and you need something that can read. Most real processes are a mix, and most working systems are a mix too.

Everything else about the category — agentic, intelligent process automation, hyperautomation — is a description of how much of the decision the system is trusted with. Useful vocabulary, but it does not change what you have to build.

The five things every working AI automation does

Across the builds that have gone into production and stayed there, the same five functions are present. Systems that skip one of them tend to fail in a way that is specific to the one they skipped.

1. Read. Turn the unstructured input into structured data. A purchase order PDF becomes fields. A supplier email becomes line items with prices. This is the part that has become genuinely cheap and genuinely good in the last two years, and it is the part people mean when they say AI automation.

The obligation it creates: your inputs have to be reachable. If the documents live in an inbox nobody can grant access to, or in three systems that disagree about what a customer is, the reading step produces fast, confident, wrong data. That problem is upstream and it is a different project — see when connected isn't integrated.

2. Decide. Apply a rule or a judgment to the structured data. Match this candidate to this role. Flag this price as out of range. Route this claim. The decision can be a hard rule, a model, or both, and the mix should be deliberate rather than accidental.

The obligation it creates: somebody has to be able to say what the right answer is. Not in general — case by case, quickly. If judging an output takes as long as producing it, you cannot validate the system, improve it, or prove it works. Which tasks pass that bar is covered in which tasks are worth automating.

3. Act. Write the result into the systems where work actually happens — the ERP, the CRM, the quoting tool, the shared drive. An automation that produces a correct answer and leaves it in a dashboard has automated nothing; someone still has to re-key it, and now they are also checking a dashboard.

The obligation it creates: write access, and a decision about what the system is allowed to do without asking. This is a governance question disguised as a technical one, and it is worth settling before the build rather than during.

4. Escalate. Hand off what it could not handle. Every automation produces a residue — the malformed document, the contract that breaks the pattern, the supplier who sends quotes as photographs of a fax. The system has to route those to a person, with enough context that the person can act in seconds rather than reconstructing the case.

The obligation it creates: a named owner for that queue. This is the single most common cause of an otherwise sound system quietly falling out of use. The queue is a job. Unowned, it becomes a backlog, and once people stop trusting that exceptions get handled they route around the whole system.

5. Prove. Produce evidence that it is still correct. A set of known-good cases the system is measured against, and a number somebody looks at. Not a launch report — a standing measurement.

The obligation it creates: a measure fixed before the build, not chosen afterwards. Time per item before and after, error rate before and after, exception queue size. A measure picked after launch is picked to flatter the launch.

Read, decide, act, escalate, prove. If a proposal in front of you covers the first two in detail and the last three in a sentence, you are looking at a demo rather than a system.

What it looks like when it works

Three delivered builds, with the figures the clients reported. They are chosen because they are different shapes of the same problem.

Document-heavy procurement. In a healthcare procurement and bid management build for a company operating across the US and Saudi Arabia, RFQ response time went from 24–48 hours to 1–2 hours, large bid preparation from 4–6 weeks to 2–3 weeks, and supplier price collection from 2–3 weeks to 5–7 days.

The speed figures are the ones that get quoted. The ones that changed the business were about correctness: a 70% reduction in pricing errors, a 90% reduction in supplier pricing discrepancies, and an 80% reduction in non-compliance incidents, with reported annual bid capacity up 40% and RFQ conversion up 25%. Capacity rose because rework fell. A project that had chased only the visible slow step would have delivered a faster version of the same error rate.

Matching at volume. In an AI recruitment build for a France-based cybersecurity recruitment agency, candidate matching and filtering went from around five days to three hours, and preparing a standardised, anonymised client-ready profile from roughly 40 minutes to seconds. The agency reported around a 30% improvement in deal win rate.

Note what did the work there. The matching was not smarter than their recruiters — recruiters kept the final submission decision. It was fast enough to act on while the candidate was still on the market. That is the test any speed claim should have to pass: does something become possible that was not possible before, or does the week just feel better?

Encoding expert judgment. In the ROI Monitor build, fifteen years of a causal marketing-attribution methodology became a working system. Attribution analysis went from four days to seconds, with roughly 50% higher accuracy than the correlation-based approach it replaced and 30%+ savings on marketing budget across pilot use.

This shape is the most valuable and the most expensive. It is also the only one that produces something a competitor cannot simply buy, because the asset is the judgment rather than the software.

How these systems degrade

Launch is not the risk. These systems fail slowly, and the failure modes are specific enough to design against.

Input drift. A supplier changes their quote template. A form gains a field. The reading step keeps working at 94% instead of 99% and nobody notices, because nothing errors. This is why the prove step exists, and why a standing accuracy measure is not optional.

Silent decision decay. A rule that was right in March is wrong in September because a policy changed, a tax rate moved, or a product line was retired. The system keeps applying it confidently. Whoever owns the process needs a route to change the rule that does not require a developer.

Exception backlog. Volume grows, the exception rate stays constant, and the queue that was ten items a week becomes sixty. If nobody has capacity for it, the queue becomes the new bottleneck — the same constraint you automated, relocated.

Cost creep. Per-call model costs scale with volume, and the cheapest model that works today is rarely the one the system launched with. Worth knowing the unit cost per item and watching it, rather than discovering it in an annual review.

Those four are about the system. The other half of the question — which processes should never have been automated in the first place — is answered in where the returns are, which sets out the four conditions a candidate process has to meet and the four cases where automation reliably returns nothing.

A sequence that holds up

Start with one document-to-data process at the highest daily volume. Not the one that annoys people most — the annoying ones are usually annoying because they are rare and unpredictable, which is the worst possible profile for a first build. High volume gives you a measurable before-and-after quickly and teaches your team what a review queue actually feels like.

Measure it honestly for a month. That number funds everything after it and will be read sceptically by whoever holds the budget.

Then widen or deepen. Widen to a second process of the same shape, which is cheap because the pattern already exists. Or deepen into matching and filtering, where the payoff is larger and validation is harder.

Consider encoding judgment last. It is the highest-value pattern and the most likely to fail if attempted first, because it requires the organisation to articulate how it actually decides — which is much harder than buying software, and is usually the real project.

If you cannot yet tell which process is the constraint, that diagnosis comes before any of this: start with the bottleneck, not the tool.

How to buy it

Three things are worth settling before you speak to anyone: whether the process has one agreed version, how often it actually runs from real records, and who will own the exception queue. No supplier can resolve those for you, and an engagement that starts before they are settled produces a system that hard-codes an unresolved internal disagreement.

Beyond that, the first thing to buy should be small, fixed in price, and allowed to conclude "don't build this". What to buy first from an AI automation consultant sets out what that deliverable should contain; if you are comparing firms rather than deciding whether to hire, the questions that separate them are more useful.

Cogya builds these as custom AI development engagements, starting from the bottleneck rather than from a platform. For distributors, wholesalers and importers specifically — where the pattern is almost always supplier data, pricing and quotation — there is a narrower version of this.

Where to go deeper

The short version

AI automation works when a repeated, checkable decision comes off a named person's queue, and the system that does it can read its inputs, write its outputs, escalate what it cannot handle to someone who owns that queue, and prove it is still correct next quarter.

The technology is rarely the limiting factor now. The limiting factors are whether the process is settled, whether the inputs can be trusted, and whether anyone owns the exceptions — all three of which are decidable before you spend anything.

Frequently asked questions

Next step

Let's map your #1 bottleneck.

Bring us one operational problem that is taking too much time, creating too much manual work or limiting your business. We'll help structure the problem and determine whether a custom AI system could create meaningful value.

30-minute working session with a Cogya co-founder.