Syntic
All posts

Published October 4, 2026 in Agents

AI Workflows Are Becoming the Glue Between Business Tools

By Syntic AI

Business automation has always stopped at the same place: the moment information arrives in a form no rule can read. A trigger can fire when a row is added to a spreadsheet. It cannot read a supplier's email that says the attached invoice replaces last month's, except for the freight line, which is disputed.

That gap is where most operational work still lives, and it is the part language models change. A model can turn an email, a PDF or a call transcript into a structured record that the rest of the workflow can act on. For the first time, the glue between business tools can interpret as well as move data.

That makes workflow design harder, not easier. A model step is useful precisely because it handles ambiguity, and risky for the same reason. Good AI workflows use the model narrowly, where interpretation is the job, and keep everything else deterministic, observable and reversible.

Two generations of glue

The first generation of integration was plumbing. Integration platforms and trigger-action tools connected systems through their APIs: when a deal closes in the CRM, create a project and send the invoice. Each step was a rule. It did the same thing every time, and when it broke, it usually broke loudly.

The second generation, robotic process automation, went around systems that had no usable API. In their 2018 editorial in Business & Information Systems Engineering, Wil van der Aalst, Martin Bichler and Armin Heinzl described RPA as tools that operate on the user interface "in the way a human would do", an "outside-in" approach in which "the information system remains unchanged."

The same editorial explains why both generations hit a ceiling. Work follows a long tail: roughly 80% of cases come from 20% of case types. Classic automation covers the frequent types, RPA stretches into the middle, and "the end of the long tail" still needs people, because those cases are too varied to script and too rare to justify the cost.

The authors also named the risk that matters most here. Bots mimicking people "can start making incorrect decisions because of contextual changes," and "this may remain unnoticed for some time."

What a model step actually adds

A model step does something neither generation could: it reads. It can classify an inbound email, pull fields out of a contract or summarise a call. Unstructured input becomes structured output, which the rest of the stack already knows how to use.

The format problem is now largely solved. When OpenAI introduced Structured Outputs in August 2024, it reported that its new model, constrained to a JSON schema, scored 100% on its evaluation of complex schema following, against less than 40% for an earlier model without the feature. A workflow can now rely on getting back a valid object with the expected fields.

Valid is not the same as correct. A schema guarantees that invoice_total is a number. It does not guarantee that it is the right number. Microsoft's transparency note for its document extraction service makes the distinction concrete: if two words out of thirty are misread, the word error rate is 6%, but if those words sit inside two of ten names, the name error rate is 20%. A single wrong character in the amount paid can get a whole invoice flagged as incorrect.

That is the core design fact of AI workflows. The model removes the parsing problem and replaces it with a verification problem.

Deterministic by default

The practical rule is simple to state: if a step has a right answer that can be computed from data, keep it in code.

Tax calculation, currency conversion, matching a purchase order number, checking a total against an approval limit and writing to the system of record are all deterministic. Putting a model in any of them adds cost, latency and variance, and removes nothing.

Variance is not hypothetical. In September 2025, researchers at Thinking Machines Lab sampled 1,000 completions of the same prompt at temperature zero from an open-weight model and got 80 distinct outputs. The cause was not randomness in the model but inference servers batching requests differently under varying load. They showed the effect can be engineered away, but a workflow builder should not assume it has been. Plan for a model step to answer differently on a rerun.

Errors also compound across steps. Five steps that are each right 95% of the time, failing independently, produce a correct end-to-end run about 77% of the time. Every model step in a chain should earn its place.

A test for each step

Three questions sort most steps:

  1. Is the input unstructured or ambiguous? If not, a rule will do.
  2. Can the output be checked by code? A total can be reconciled against line items; a vendor ID can be looked up. If the output can be checked, add the check right after the model.
  3. What does a wrong answer cost, and can it be undone? Drafting a reply is cheap to get wrong. Changing a supplier's bank details is not.

A well-designed workflow often looks like a deterministic pipeline with one or two model steps placed at its edges, where messy input enters, and a validation step immediately after each. Not every step needs the same model either. Classification and extraction can run on small, fast models; drafting a careful customer reply may justify a larger one. That argument is made at length in why one AI model is not enough.

Confidence is a routing decision

Once a model is reading documents, the question is what to do with its uncertain reads. Microsoft's guidance for document extraction is a good template. The service returns a confidence value between 0 and 1 for each field. Customers are told to run a pilot on their own documents, see the range of values, and then set a threshold: for example, results at or above 0.80 go straight through, and anything below goes to a person.

The details matter more than the number. Microsoft's own examples set thresholds differently for regulated product labels, where an extraction error can bring fines, and for a large supplier catalogue, where too many false flags would swamp the review team. The same logic applies inside a single document. A misread reference code and a misread payment amount carry different costs, so thresholds belong on fields, not on whole documents.

Generative models do not always expose a calibrated confidence score, so workflows build proxies: agreement between two extraction passes, consistency checks against other fields, lookups against known records. The principle is the same. Uncertainty should change the path a case takes, not just be written to a log.

Approvals that mean something

Most AI workflows end in a human approval for anything consequential. The step is necessary. It is also easy to design badly.

In 1983, Lisanne Bainbridge's "Ironies of Automation" observed that automating the routine work leaves people with the hardest part: monitoring for rare failures they no longer practise handling. Parasuraman and Manzey's 2010 review in Human Factors found that automation complacency appears in experts as well as novices, emerges when people are handling several tasks at once, and is not overcome by simple practice. The EU AI Act's human-oversight article asks that people overseeing high-risk systems be able to stay aware of "automation bias" and to "disregard, override or reverse" the output.

An approval queue that shows a summary and a green button invites exactly that bias. Better designs show the evidence beside the proposed action: the source email or document, the extracted fields with low-confidence values highlighted, and the exact change that will be written. The reviewer approves the action, not the model's description of it.

Timeouts deserve the same care. Zapier's Human in the Loop step, for example, lets a builder choose what happens when nobody responds: end the run, or skip the review and continue. Both are legitimate for different steps, but they are not the same control. An approval that proceeds by default when ignored is a notification, and the workflow should be labelled that way.

The cost and latency of a run

Rule-based steps cost almost nothing to execute. Model steps are not, and their costs scale with volume in ways that are easy to miss in a pilot.

The cost of a run is roughly the number of model calls, times the tokens each consumes, plus retries, plus the minutes of human review it triggers. Review is often the largest line: a workflow that sends 30% of cases to a person has automated far less than its dashboard suggests.

Latency splits workflows into two kinds. A step inside a live phone call or a checkout needs an answer within a second or two. A step that processes the overnight inbox can wait. For the second kind, major providers including OpenAI and Anthropic discount asynchronous batch jobs by 50%, with results returned within 24 hours. Deciding which steps must be synchronous is one of the cheapest optimisations available. As the cost of intelligence keeps falling, the price per call matters less than how many calls, retries and reviews each run triggers.

When the glue fails

Deterministic integrations fail with an error code. Model steps fail by returning something plausible. That is van der Aalst's warning about RPA in a sharper form, and it changes how failure handling must work.

Trace every run. Each run should record its input, every model call with the prompt version and model used, the output, any validation results, who approved it, and what was written where. OpenTelemetry now has semantic conventions for generative AI, including standard attributes for model calls and token usage, so these traces can sit in the same observability tools as the rest of the stack.

Make writes idempotent. Retries are normal in workflows, and a retried step must not create a second payment or a duplicate ticket. Stripe's API shows the pattern: the client sends an idempotency key, and a repeat request with the same key returns the original result instead of performing the operation again.

Give failures somewhere to go. Cases that fail validation, time out, or fall below threshold should land in a named queue with an owner, not disappear into a retry loop.

Treat inputs as untrusted. The feature that makes AI workflows useful, reading arbitrary email and documents, is also an attack surface. In 2025, researchers disclosed EchoLeak (CVE-2025-32711), a vulnerability in Microsoft 365 Copilot in which a single crafted email could trigger data exfiltration without the user clicking anything. Microsoft fixed it before disclosure. The lesson for workflow builders is structural. A step that reads external content should hold only the permissions that step needs, and should not be able to take sensitive actions on the strength of instructions found in that content. The wider architecture of agent permissions is covered in AI agents are becoming the execution layer for business.

Data quality sets the ceiling

A 2015 Google paper on hidden technical debt in machine learning observed that a mature system "might end up being (at most) 5% machine learning code and (at least) 95% glue code," and warned that this glue is costly to maintain. AI workflows reverse the arrangement: the model has become part of the glue. Their reliability is bounded by the data flowing through them.

In a 2021 CHI study of 53 AI practitioners, Nithya Sambasivan and colleagues at Google found that 92% had experienced "data cascades", where data problems compound downstream, often invisibly and with a delay. Workflows that write into systems of record are especially exposed. An extraction error does not stay in a log. It becomes a CRM field, a ledger entry or a customer record that the next workflow reads as fact.

Three habits help. Validate model output against reference data before writing it. Record which fields were machine-extracted, and with what confidence. And sample approved runs for audit, because the errors that pass review are the ones nobody is looking for.

The glue is becoming a product

Incumbents are converging on this design. UiPath, which built its business on RPA, launched an agentic automation platform in April 2025 around an orchestration layer, Maestro, that coordinates software robots, AI agents and people in one process. Trigger-action tools have added model steps and human review. The categories are merging into workflows that mix rules, models and people, with explicit handoffs between them.

The deeper change is in who owns integration. When the glue only moved data, it belonged to IT. Once it interprets messages and decides what reaches a person, it encodes business judgment, and the people who own the process need to own the design. Getting the model to read the email is now the easy part. Deciding what happens when it reads it wrong is the actual work.

Sources