AI is increasingly being put in the middle of automated workflows.
Send it an email and classify the intent. Give it a document and extract some information. Send it a support request and decide which department should receive it.
This is useful because it allows automations to make decisions about data which doesn't fit neatly into traditional rules.
It also introduces a problem.
AI can give you the wrong answer.
More importantly for an automation, it can give you an answer your system doesn't understand.
That means an AI node shouldn't just sit in the middle of a workflow with everything before it assuming the input is correct and everything after it assuming the output is correct.
It needs boundaries.
An example
Take a support ticket automation with this basic flow:
Form → API → Queue → OpenAI → HubSpot
Someone submits a support request through a form.
The request is validated, stored in a queue and eventually sent to OpenAI. OpenAI reads the message and decides which department should receive it.
The available departments might be:
- Technical
- Billing
- Sales
A request saying:
"I've been charged twice this month."
should come back as:
Billing
The workflow can then map Billing to the corresponding HubSpot pipeline and create the ticket.
Simple.
But what happens if OpenAI returns:
Customer Service
That's not necessarily a bad answer.
It's just useless to the automation.
There is no Customer Service route.
This is the difference between something being reasonable to a human and valid to a system.
Validate What Goes Into AI
Before worrying about the answer, the workflow needs to know that the model is receiving the right data in the first place.
This starts much earlier than the OpenAI node.
The backend API checks the original submission in stages.
- First: is it valid JSON?
- Then: is the JSON actually an object?
- Then: are the required fields present?
- Then: do those fields contain acceptable values?
An array can be perfectly valid JSON. That doesn't mean the API should accept one if it's expecting a support request.
Only after those checks should the request enter the rest of the system.
This matters because otherwise bad data is allowed to travel further into the workflow, where it becomes harder to work out what actually went wrong.
If OpenAI receives undefined instead of a support message, the problem isn't really OpenAI.
The problem happened several steps earlier.
Validate What Comes Back
The other side is just as important.
Once OpenAI classifies the request, the response is checked against the list of categories the system supports.
If the available values are:
Technical, Billing, Sales
then the result needs to be one of those values.
Not something similar.
Not something arguably better.
One of those values.
This gives the non-deterministic part of the workflow a deterministic boundary.
The model can make the decision, but it doesn't get to invent the rules the rest of the system operates under.
Why Not Just Use Code?
If the output needs to be so tightly controlled, why use AI at all?
Because the input isn't tightly controlled.
People don't submit support requests like this:
department = billing
They write:
"Hi, I upgraded yesterday but it looks like I've been charged for both plans. Can someone have a look?"
Traditional code is excellent when the rules are known.
You could search for words like charged, invoice or payment, but that quickly becomes messy. A technical ticket could mention a payment. A sales enquiry could ask about billing. People can describe the same problem in hundreds of different ways.
AI is useful here because it can interpret the meaning of unstructured text.
The mistake would be assuming that because it's good at interpretation, it should also control the structure of the system around it.
The two jobs are different.
AI interprets the messy part.
Code and workflow logic enforce the rules.
What Happens When Validation Fails?
Rejecting an invalid classification solves one problem, but creates another.
The ticket still needs to go somewhere.
It also shouldn't disappear because the AI returned something unexpected.
This is where the rest of the workflow matters.
The request exists in a persistent queue before classification begins. If processing fails, it isn't deleted.
The failure can be recorded, an attempt added to the queue entry, and the workflow can try again on a later run.
After repeated failures, automatic processing stops and the issue can be sent for human investigation.
This is important because validation shouldn't mean:
Something unexpected happened → throw the data away.
It should mean:
Something unexpected happened → don't let it corrupt the next stage.
The original request is still there.
AI Shouldn't Be the Foundation
There is a temptation when adding AI to an automation to make everything revolve around it.
It is the clever part, after all.
But the OpenAI node in this workflow is really just one component.
- The API still controls what enters the system.
- The queue still holds the state.
- The workflow still controls retries.
- HubSpot still stores the final ticket.
- Validation still decides whether the output is safe to use.
If OpenAI disappears tomorrow, the classification component needs replacing.
The entire system shouldn't need rebuilding.
That separation also makes changing models much easier. OpenAI could be replaced with another provider, a locally hosted model, or even traditional classification logic without redesigning everything around it.
AI Is Good at Messy Data. Systems Aren't.
This is where AI becomes particularly useful in automation.
Software likes structure.
Humans don't provide it.
People write emails, documents, support requests and descriptions however they want. AI can sit between that messy human input and the structured systems that need to do something with it.
But there needs to be a line between interpretation and control.
Let AI work out what something means.
Then check its answer before allowing the rest of the system to act on it.
An AI model can be intelligent without being authoritative.