Deployment
Forward deployed engineering at Mirage
Engineers who build and run AI systems inside your operation, on your own documents and systems, until they work in production.
Mirage Metrics is a forward deployed engineering company: its engineers build and run AI agents inside client operations in logistics, construction, mining and manufacturing, instead of selling self-serve software.
They work on site before any system goes into production, and stay involved once it runs.
This page covers how Mirage's engineers work inside your operation and what to expect, step by step and in time. The model itself (definition, origins, how it compares with consulting, integration and staff augmentation, data access, security, cost and how to choose a provider) is in the complete guide. Read the complete guide to forward deployed engineering
How does an engineer actually get into my operation?
The Mirage deployment method
Five steps, in this order, for every deployment in every sector: Observe, Map, Build, Run, Expand.
Observe
Engineers spend time with the operational team before writing anything, to see how the work is actually done.
What it settles
- How the team really works
- Where friction appears
- Which decisions need a person
What you get
A system map: who does what, in which tool, with which exceptions
Map
Workflows, exceptions, data sources, manual checks and escalation points are mapped with the team.
What it settles
- The workflow to start with
- Its exceptions
- Its systems and data sources
What you get
The technical architecture: systems read and written, rules, approval points
Build
The system is built around the constraints observed on site, not around an idealized process diagram.
What it settles
- Connectors into the systems in place
- The client's own rules
- What goes to a person
What you get
A working agent, on your own data and in your own systems
Run
It runs in production with human supervision and feedback loops from day one.
What it settles
- Exceptions reviewed by the team
- Rules adjusted on live data
- Who signs off
What you get
The operator interface: review queue, approvals, action history
Expand
Once a workflow is trusted, the same team moves to the next one.
What it settles
- The next workflow
- The same engineers
- The same platform
What you get
A production report: volumes, exceptions, corrections, and the next workflow
Why deploy engineers instead of shipping software?
Most operational problems only become visible once you spend time on site.
A workflow that looks simple on paper can depend on dozens of informal checks, manual validations or habits built up over time.
Some processes vary between sites. Some decisions depend on context that exists nowhere in documentation, and only become visible once a system is already running in production.
This is why Mirage deploys engineers directly inside operational environments, instead of shipping a product for your team to configure.
Before deployment, engineers observe how teams work, where friction appears, which decisions need supervision and where automation can realistically create value.
The objective is not to force operations to adapt to software.
The objective is to build systems that adapt to operational reality.
Where does a system need a human?
AI systems are capable, but operational environments still require engineering judgment and human supervision.
Some tasks can be heavily automated. Others require context, validation or accountability that stays with a person.
An agent can process information correctly thousands of times in a row, then encounter a case that needs human review. That's normal in a production environment, not a failure of the system.
Automation
AI handles repetitive coordination work, large document volumes and structured operational tasks.
Supervision
Human operators validate, escalate and review decisions when a case calls for it.
Accountability
Operational teams stay in control of critical workflows, not the model.
The objective is not to remove humans from operations.
The objective is to reduce repetitive work without losing supervision or accountability.
What forward deployed engineers have put into production
Five published deployments, each built on the client's own documents and systems. The figures are the ones each case study states.
John Cockerill
Industrial engineering group, Morocco operations
A piping takeoff module that reads isometric drawings and produces separate MTO and BOM outputs, every quantity reviewable against its drawing by the group's engineers. Boilermaking (API 650) and structural steel modules are built on the same engine and rolling out next.
80 to 90% less time spent on piping takeoff
OCBM
Construction company, Casablanca
Engineers worked on OCBM's real projects and drawings. Quantity takeoff came first, then bid pricing and a check of consistency across drawing revisions and tender documents.
3 agents in production, every quantity traceable to its source drawing
Biodéal
Organic dairy distributor
A pipeline that reads customer orders received by email in every format, applies Biodéal's own business rules and creates the order in SAP Business One. A line it cannot confirm is flagged to the team, never dropped.
A median of 48 seconds from order email to order ready in SAP Business One; about 7% of orders flagged for a person
OFRET Groupe
Freight forwarding group
Two quoting agent environments, one for full truckload and one for groupage, built on site with each team's documents and connected to the group's TMS.
More than 90% of standard freight quote requests answered automatically
Transwin
Logistics operator, Morocco
One freight document workflow first, then fuel, mining equipment, a control room and a private assistant, each built by engineers on site from Transwin's own documents, trucks, tanks and TMS.
5 systems live; 70% less manual data entry on freight documents; 12% lower fleet diesel consumption
How we measure a deployment
Every deployment is followed on the same five measures, from the first meeting on. They are defined here; the figures for each deployment are in its case study.
| Measure | What it counts | What is published |
|---|---|---|
| Time from first meeting to proof of concept | Days between the first meeting and a working proof of concept on the client's own documents. | The commitment: one week after the first meeting. |
| Time to the first workflow in production | Time until the first workflow runs in production on the client's systems, with real volumes. | Usually 4 to 6 weeks. Workflows spanning several systems can take longer and are scoped at the first meeting. |
| Share of items handled without a person | Documents, orders or requests that go from intake to the client's system with no human step, out of all those received. | Per deployment, for example more than 90% of standard quote requests at OFRET Groupe, about 7% of orders flagged for a person at Biodéal. |
| Exceptions per week | Items routed to a person each week, with the reason: missing data, a rule not yet written, a case outside the agreed scope. | Used with the client's team to decide which rule to add next. Not published. |
| Hours returned to the team | Time the team no longer spends on the work the system now does, against how long that work took before. | Stated per deployment as time saved, for example 80 to 90% less time on piping takeoff at John Cockerill, 70% less manual data entry at Transwin. |
Why does this still work after the demo ends?
Many systems look impressive in a controlled demonstration.
Production environments are different: operational constraints keep changing, teams adapt workflows, exceptions appear, and systems have to evolve alongside them.
Mirage focuses on systems that keep functioning once they're exposed to real operational conditions, not just the conditions of a demo.
That takes engineering, iteration and continued adaptation after deployment, which is why the engineers who build a system stay engaged once it's running.
FAQ
Mirage engineers work inside your operation before, during and after a system goes into production, instead of shipping a self-serve product for your own team to configure.
No. Mirage's systems are built for automation, supervision and accountability to work together, with operational teams staying in control of critical decisions.
The same engineering team moves to the next workflow, following the same five steps: Observe, Map, Build, Run, Expand.
Operational constraints differ by site and change over time. Mirage engineers stay engaged after deployment to adapt the system as conditions change, rather than treating the initial rollout as finished.
A proof of concept on your own documents one week after the first meeting, then the first workflow in production in 4 to 6 weeks. Workflows spanning several systems can take longer; they are scoped at the first meeting.
With a first meeting. A week later Mirage shows a proof of concept on your own documents. If you continue, engineers run a fixed-price pilot on site that you can stop after, followed by an annual subscription priced by volume.
In Paris, Barcelona and Casablanca. They travel to client sites for each deployment. Mirage works for more than 30 clients in France, Spain, Morocco, Egypt, Saudi Arabia and the United States.
The ones already in place: ERP, TMS, WMS, maintenance, telematics and document systems, more than 200 so far. The agents write their results back into those systems instead of adding another tool.
More on forward deployed engineering
- See the Forward Deployed Engineer role
- See the complete guide to forward deployed engineering
- See build, buy or forward deploy compared
- See the platform the engineers deploy
- See every case study
- See who we are
Engineers based in Barcelona, Paris and Casablanca.
Get a custom automation plan
Tell us where your operations lose time. We send back a written plan: which workflows are worth automating, what a deployment looks like on your systems, and the shortest path to production. No commitment.
Prefer to talk it through? Book a call