Most AI projects work in the demo and fail in the month after.
What does AI and automation work actually involve?
AI and automation work means finding the operations where judgement is repeated often enough to be worth encoding, building that judgement into the ERP or the workflow that already runs it, and then instrumenting it so failures surface. At Entrivis it is engineering work with a governance layer, not a model demonstration.
The pattern we see is consistent. A business buys or builds an AI feature, it performs well in a controlled test, and it goes into production without a fallback path, without logging, and without anyone owning the question of what “wrong” looks like. Six weeks later the team has quietly stopped using it, because nobody could tell the good outputs from the bad ones fast enough to trust either.
We start from the operation, not the model. Which decision is being made, how many times a day, by whom, and what it costs when it’s made badly. Sometimes the answer is an LLM. Often it’s a rule, a queue, and a well-placed exception report, and we will tell you that instead of selling you the more expensive thing.
Three ways this capability shows up.
AI Custom Solutions
Models and LLM workflows built for a specific operation, wired into the system of record rather than bolted alongside it. Assessment scoring, document extraction, practitioner-facing decision support, structured-output pipelines that write back into ERP.
Explore AI custom solutions →AI Workflow Automation
The unglamorous half. Queues, triggers, human-in-the-loop review gates, retry and escalation logic. Automation that a finance controller is willing to sign off on because they can see every step it took.
Explore AI workflow automation →AI Governance & Observability
Logging, evaluation, drift monitoring, fallback architecture, and a documented answer to “what happens when the model is unavailable.” This is the section most proposals leave out. It is the section that decides whether the work survives.
Explore AI governance and observability →AI-first practitioner workflows
Built for VitaOne, a health and wellness operator that came to us after a previous partner. The practitioner workflow is AI-assisted end to end, with structured handoffs back into Odoo.
Read the work →Blood-test data mapping
A module that normalises laboratory output into the structures the practitioner workflow consumes. Mapping and validation. The clinical reading stays with the clinician.
What nobody quotes for.
AI proposals price the model and the interface. The first quote is cheap, the second partner is expensive, and the business concludes AI doesn’t work for them.
| In the quote | Not in the quote |
|---|---|
| The model | The evaluation harness |
| The interface | The fallback path |
| The integration | The audit log |
| The demo | Drift monitoring |
| - | The exception queue and who reads it |
| - | Six weeks of production tuning |
| - | Handover of prompts and eval sets |
| // week 1–6 | // week 7 onward, or never |
About a third of our clients hired someone else first. That number isn’t specific to AI work, but AI produces the cleanest version of the failure: something impressive was demonstrated, nothing was instrumented, and the system quietly stopped being trusted. We price column B up front. Removing it later is not a saving.
How an AI engagement runs.
An AI engagement runs as a structured sequence, not a model drop. It opens with a paid discovery (we map the decisions worth encoding before a line is written) and it doesn’t end at go-live, where the governance, tuning, and ownership that keep the work trusted actually sit.
-
01
Use-case discovery
Two to three weeks. We map decisions, not features. Volume, cost of error, and who is accountable today. Most candidate use cases die here, correctly.
-
02
Architecture and fallback design
What the model does, what it must never do, what happens when it is unavailable, and where a human sits in the loop. Written down before anything is built.
-
03
Build and integrate
The workflow is built into the system of record. Structured outputs, write-back paths, and exception queues that route to real people.
-
04
Evaluation and instrumentation
Test sets, logging, and the dashboards that tell you the model has drifted before your customer does.
-
05
Production tuning, then sustained ownership
The first six weeks after go-live are where the work is earned. Thirty-five percent of our delivery effort across the firm sits post-go-live. This is why.
Common questions about AI and automation
Do we need to be on Odoo for this?
No. Most of this work reaches us through Odoo engagements, and Odoo is where the write-back paths are cleanest, but the workflow and governance work is platform-independent.
Will you tell us if AI isn’t the right answer?
Yes, and often. A rule engine with a good exception report solves a surprising share of what gets scoped as AI work, at a fraction of the cost and with none of the evaluation burden. We would rather be the firm that said so.
Who owns the models and the prompts?
You do. Prompts, evaluation sets, and configuration live in your repository and are handed over as part of delivery.
How do you handle data leaving our systems?
Model routing, retention, and residency are decided in architecture, not after. Where data cannot leave the environment, we design for that constraint before selecting the approach. Our data and hosting posture is documented on the Trust page.
Start with the operation, not the model.
Tell us the decision you’re making too many times a day. We’ll tell you whether it’s worth encoding.