There is a recurring mistake in enterprise AI projects:
People spend too much time asking which AI model to use and not enough time asking what the AI needs to connect to.
GPT vs Claude. RAG vs fine-tuning. Agents vs workflows.
Those are interesting engineering questions.
But after building automation for law firms, manufacturers, insurance agencies, accounting firms, and home-service companies, we've found that the hardest problems usually happen somewhere else.
The AI is often the easy part.
The messy inbox, legacy software, inconsistent documents, human approval steps, and missing APIs are the real engineering challenge.
And that changes how you should approach AI automation.
The "AI Project" Is Usually Not an AI Project
Consider a seemingly simple request:
"Can we automate our certificate of insurance process?"
At first glance, this sounds like a document-AI problem.
Read an email.
Understand the request.
Find the certificate.
Send it back.
But a production system needs to answer much more:
Where does the request arrive?
How do we identify the customer?
What information is missing?
Which policy should be used?
How do we validate the certificate?
What happens when the document is ambiguous?
Where does the result get written back?
Who approves exceptions?
What happens if the underlying system is unavailable?
The LLM is only one component.
The actual system is closer to:
Email
↓
Document / Request Parser
↓
Customer Identification
↓
Business Rules
↓
AI Classification
↓
Validation
↓
Human Approval (if needed)
↓
System-of-Record Writeback
↓
Customer Response
That distinction is incredibly important.
The Integration Layer Is Where the Value Lives
One of our insurance automation projects illustrates this well.
Top-quartile property and casualty agencies can clear certificates of insurance dramatically faster than middle-quartile agencies. In one project, we built a custom intake workflow that produced roughly a 6x improvement for a $42M broker.
The interesting part wasn't simply "AI reads PDFs."
The system needed three important pieces:
A parser in front of the email inbox.
Structured intake for the incoming request.
Write-back into AMS360 so the process could continue without requiring a producer to manually touch every request.
That's a very different engineering problem from dropping a PDF into ChatGPT and asking it a question.
The model provides intelligence.
The integration provides utility.
Don't Replace the System of Record
This is another lesson that became obvious very quickly.
Companies already have systems they depend on.
Accounting firms have tax platforms.
Insurance agencies have management systems.
Manufacturers have quoting and ERP systems.
Home-service companies have field-service platforms.
The instinct when building AI software is often:
"Let's build a new AI system."
Usually, that's the wrong starting point.
The better question is:
"How can we make the existing system dramatically more useful?"
For example, an accounting firm may already use CCH Axcess.
Replacing it isn't realistic.
But you can build an intelligent layer around it.
In one PBC workflow, a custom intake layer replaced an email-heavy process with a structured portal that could pre-validate uploads. The partner-to-PBC ratio improved from 1:4 to 1:11. The technical work included document classification based on historical requests and deadline write-back to the firm's tax workflow.
The AI wasn't replacing the accounting platform.
It was filling the gaps around it.
The Most Valuable Automation Is Often Boring
This is probably the least exciting thing about enterprise AI.
The best automation isn't always a flashy autonomous agent.
Sometimes it's:
"Stop making a partner manually chase documents."
Or:
"Stop making a producer re-enter the same information."
Or:
"Stop making a salesperson wait six hours for a quote."
Those problems don't make impressive demo videos.
But they have measurable economic value.
At a custom metals manufacturer, an automation project reduced quote turnaround from approximately 6 hours to 11 minutes, while win rate increased 22% based on speed alone, without changing pricing.
That's the kind of AI result businesses actually care about.
Not how many tokens the system processes.
Not whether the agent can have a clever conversation.
How much time did we remove from the workflow?
The Workflow Should Come Before the Model
Here's the approach we've found more useful.
Step 1: Find the repetitive decision
Don't start with:
"Where can we use AI?"
Start with:
"Where are humans repeatedly looking at information and making the same type of decision?"
That's your candidate.
Step 2: Map the existing workflow
Write down every step.
Customer sends request
↓
Employee opens email
↓
Employee identifies customer
↓
Employee opens another application
↓
Employee searches for information
↓
Employee checks document
↓
Employee makes decision
↓
Employee updates system
↓
Employee sends response
Now ask:
Which steps actually require a human?
You may discover that only one or two do.
Step 3: Identify the system boundaries
This is where many AI prototypes fall apart.
The prototype might work perfectly inside a notebook.
Production requires:
API
↓
Authentication
↓
Database
↓
Existing SaaS
↓
Webhooks
↓
Queues
↓
Retries
↓
Logging
↓
Human escalation
The model is just another service inside that architecture.
Step 4: Give the AI a narrow responsibility
Don't ask an LLM to run the entire business process.
Give it one job.
For example:
{
"document_type": "certificate_of_insurance",
"customer": "Acme Manufacturing",
"request_type": "additional_insured",
"confidence": 0.96,
"requires_human_review": false
}
Then let deterministic application code handle the consequences.
This separation is powerful:
AI decides.
Software enforces.
AI Should Not Be Your Business Logic
This is one of the biggest architectural lessons.
If a business rule can be expressed deterministically, don't ask an LLM to figure it out.
Bad:
LLM:
"Does this customer qualify?"
Better:
LLM:
"Extract the customer's revenue."
Code:
if revenue > threshold:
continue_workflow()
else:
escalate()
The model handles ambiguity.
The application handles rules.
That makes systems easier to test, debug, and trust.
Build for the Exception, Not the Demo
A demo usually looks like this:
Input → AI → Perfect Output
Production looks like this:
Input
↓
AI
↓
Missing information
↓
Retry
↓
Unexpected document
↓
API timeout
↓
Duplicate request
↓
Human review
↓
Corrected information
↓
Final output
The second diagram is where most of the engineering effort belongs.
A production AI system needs to answer questions like:
What happens when confidence is low?
What happens when the model returns invalid JSON?
What happens when an API call fails?
What happens when the same request arrives twice?
Can a human override the model?
Can we reconstruct why a decision was made?
Can we safely retry the workflow?
These aren't AI questions.
They're software engineering questions.
The Real AI Stack Is Bigger Than the Model
A useful mental model is:
┌──────────────────┐
│ AI / LLM │
│ Classification │
│ Extraction │
│ Reasoning │
└────────┬─────────┘
│
┌───────────▼───────────┐
│ Orchestration │
│ Workflows / Queues │
│ Retries / State │
└───────────┬───────────┘
│
┌──────────────────▼──────────────────┐
│ Integration Layer │
│ APIs • Webhooks • Databases • SaaS │
└──────────────────┬──────────────────┘
│
┌───────────▼───────────┐
│ Human Workflow │
│ Approval / Exceptions │
└───────────────────────┘
If one layer is missing, the system usually isn't ready for production.
So, Which Model Should You Use?
Of course, model selection still matters.
Latency matters.
Cost matters.
Context windows matter.
Structured output matters.
Tool calling matters.
Accuracy matters.
But these are often optimization problems, not the fundamental problem.
If your workflow has no reliable data source, no integration, no error handling, and no clear business rule, switching from one frontier model to another isn't going to save the project.
A mediocre model inside a well-designed workflow can create more business value than the world's best model connected to nothing.
The Bigger Lesson
AI automation isn't really about putting intelligence into a business.
Businesses already have intelligence.
It's sitting inside employees' heads, emails, spreadsheets, PDFs, CRM records, accounting systems, and years of accumulated processes.
The opportunity is to connect that intelligence to the systems where work actually happens.
That's why the most interesting AI engineering isn't necessarily building the next autonomous agent.
Sometimes it's building the tiny layer that connects:
an email → a document → an AI decision → an API → a database → a human.
And when that tiny layer removes six hours of waiting, eliminates repetitive data entry, or lets a partner stop chasing documents, suddenly the "boring" automation becomes the most valuable software in the company.
The model isn't the product.
The workflow is the product.
Top comments (0)