Forward deployed
An engineer inside your operation for a month, before anything is built.
A forward deployed engineer is placed inside your operation — on your floor, or entirely inside your working hours — typically for a month, sometimes longer. The first stretch is spent watching how the work actually happens, not how anyone believes it happens. What is built afterwards runs in your own infrastructure, and is handed to your team one person at a time.
- Minimum placement
- 1 monthMinimum placementExtended in monthly blocks, with thirty days’ written notice on either side.
- Spent building nothing
- Week 1Spent building nothingThe first week is observation only. It ends in a written map of the work that you sign.
- Days a week inside your hours
- 4 / 5Days a week inside your hoursThe fifth day is held for build and review, so the work does not only happen in the gaps.
- Handover, per named owner
- 1:1Handover, per named ownerEach person who has to operate or change the system gets their own recorded session.
The model
Proximity is the deliverable.
A forward deployed engineer is capacity placed inside your operation rather than scope thrown over a wall. The engagement runs from your office where that is practical, and otherwise entirely inside your working hours — the same standups, the same queues, the same escalations, the same bad afternoons. A month is the usual length, because a month is roughly how long it takes for people to stop performing their process and simply do it.
Most automation fails on the parts nobody writes down. The spreadsheet on one person’s desktop that the official system quietly depends on. The three exceptions a week that are settled by walking over to someone’s desk. The field everyone agrees is mandatory and everyone leaves blank. None of that survives a remote scoping call, because the people describing the process describe the version they are supposed to follow. Sitting beside the work for a month is how it gets found rather than guessed.
Proximity also changes what gets shipped. A change can be put in front of the person who does that job the same afternoon, watched in use, and corrected before it hardens into a habit nobody wants. Nothing waits two weeks for a review call. Everything is built to the same engineering standard as any other work here — your cloud, your repositories, your keys, version control, failure paths, evaluation suites wherever a model is involved, and observability from the first week.
Suited when
- The process is real, daily and messy, and nobody can describe it accurately without doing it in front of you.
- You commissioned a scoped project before and it delivered what was described rather than what was needed.
- The work spans several systems, several teams, and a set of exceptions nobody has ever counted.
- Your operation has constraints — regulatory, contractual or physical — that only make sense from inside it.
- You want your own people running and changing the system afterwards, not dependent on whoever built it.
Not a fit when
- You already know exactly what to build and only need it built — a fixed-scope sprint is the better instrument.
- The engagement would have access to managers describing the work, but not to the people doing it.
- Nothing may be deployed into your own infrastructure and everything must live on a vendor’s tenancy.
- You want a demonstration for a board meeting rather than a system that has to survive a bad Monday.
Being told a fixed-scope sprint would serve you better is a legitimate and common outcome of the first call.
A standard month
Four weeks, and each one has a gate it has to clear.
The sequence is deliberate. Nothing is built in week one, because everything built in week one is built against the process as described rather than the process as run.
- 1
Week 1
Sit with the work, build nothing.
The first week is spent alongside the people who do the job — shadowing, screen time, reading the queue, timing what actually takes the time. No tooling is chosen and no architecture is drawn. The output is a written map of the operation as it runs today, including the parts that are not supposed to exist.
Exit gate · You sign the written map of how the work actually runs today.
- 2
Week 2
The first thing that survives contact.
One candidate is taken from the map — usually the smallest piece carrying the highest daily cost — and built in your infrastructure, in version control, with its failure paths from the start. It goes in front of the person who does that job before the week ends, and is corrected in front of them.
Exit gate · One component in real use, with retries and a dead-letter path.
- 3
Week 3
Widen it, then break it on purpose.
With one thing running, the surrounding steps are automated and connected, and the whole path is deliberately failed — bad data, dead integrations, timeouts, and the exceptions counted in week one. Anything touching a language model gets its evaluation suite and a documented pass threshold before it is trusted.
Exit gate · Failure injection survived and the evaluation threshold met.
- 4
Week 4
Handover, one person at a time.
The runbook is written and observability is wired into a channel your team already reads. The handover is then done individually — a separate session with each person who will operate, change or depend on the system, pitched at what that particular person has to know. Nobody is asked to keep pace with anyone else.
Exit gate · Every named owner has had their own recorded handover session.
Three shapes
One component, a whole function, or a system designed from nothing.
What a placement is pointed at is agreed before it starts and frozen at the end of week one, once there is a map to point at.
One component, automated properly
The narrowest form: a single step inside a larger process is taken out of human hands and built to production standard, without disturbing what sits either side of it. It is the right shape when the bottleneck is already known and the rest of the operation is sound.
For instance: a claims team’s document intake — classified, extracted and validated on arrival, with anything ambiguous routed to a named reviewer.
A whole product or function
Everything one function does end to end, or one product’s operational spine, rebuilt with the AI layer where it earns its place and plain software everywhere else. This is the common shape, and it is why an embed is measured in months rather than days.
For instance: an entire order-to-invoice function — intake, exception handling, approvals, reconciliation, and the reporting that hangs off it.
End-to-end design and delivery
Where there is no existing process to observe, the system is designed before it is built: data flow, model choice, evaluation strategy, human review points, running cost, and the behaviour on the worst day. Design and delivery stay with the same engineer, so nothing is lost between them.
For instance: a new AI-assisted underwriting path, designed from the risk policy upward, then built, evaluated, and put into supervised production.
Inside a build
What actually happens between the deposit and the handover
Every build follows the same path, and each stage has a gate that has to be met before the next one starts. It is unglamorous and it is the reason the ten days stays honest.
Access-Complete
Credentials, a named owner on your side, a test environment, real sample data and a signed definition of done. The delivery clock starts here, not at signature.
Process map frozen
Edge cases enumerated and acceptance criteria agreed in writing. You sign the map before a line of it gets built.
Modular build
Small components rather than one monolithic flow, configuration externalised, everything committed to your repository as it is written.
Failure injection
Bad data, dead integrations, timeouts and rate limits, run deliberately against the happy path until the retries and dead-letter paths hold.
Evaluation run
Forty golden pairs against a documented pass threshold on anything touching a language model. Below threshold is not shipped.
One-to-one handover
A separate recorded session for each named owner, pitched at what that person has to do with it, plus the runbook and the 14-day bug window.
What is written down
A placement is still a fixed-scope engagement.
An embed is open-ended about what it will discover, and completely closed about the terms it discovers it under. Both of those are on the statement of work before anyone arrives.
What you get
- A written map of the operation as it actually runs, produced before anything is built and signed off by you.
- Working software in your own cloud, your own repositories and your own keys, with delegated access you can revoke.
- Failure paths built rather than assumed: retries, timeouts, dead-letter handling, alerting into a channel you read.
- An evaluation suite with golden pairs and a documented pass threshold for anything touching a language model.
- A runbook written for the person who inherits the system, and a recorded walkthrough of how to change it.
- A one-to-one handover for every named owner, each session built around what that individual does with the system.
- A written record of what was found and deliberately not automated, and why it is not worth doing yet.
- Term
- 1 month minimum, extended in monthly blocks
- Payment
- Monthly, invoiced in advance · 30 days’ written notice on either side
- Scope caps
- 1 engineer placed with 1 client, minimum 1 month, extended in monthly blocks
- 4 days a week inside your working hours; 1 day held for build and review
- Scope frozen at the end of week 1, then re-agreed at each monthly renewal
- On-site within Bengaluru; elsewhere remote by default or quoted with travel
Placements take a block of a capped calendar, so they book ahead.
Handover
The system is handed over the same way everything else here is delivered.
One person at a time. A shared briefing at the end of a month-long embed is how a system ends up owned by nobody in particular.
Name the owners
Week 3
Every person who will operate, change, approve or depend on the system is written down, along with what each of them actually has to be able to do with it.
A session each
Week 4
Separate recorded sessions, pitched at that individual. The person who runs it daily and the person who signs off on its output need entirely different half-hours.
They drive it once
In their own session
Each owner performs their part of the work themselves, on the real system, while the engineer watches — the same principle that governs every enablement session here.
Runbook and the bad day
At close
The runbook, the alerting channel, the failure paths and what to do when a model provider deprecates something underneath you. Written for whoever inherits it, not for you.
The hard questions
What buyers press on before committing a month.
You are one person. How can an engineer be embedded with us for a month?
Because the delivery calendar is capped rather than optimistic. An embed takes a block of that calendar exclusively, which is why only a small number can run in a year and why they are booked well ahead. For its duration you have the engineer’s working attention rather than a share of it divided across four accounts. Everything is still built the way the rest of this practice builds — in your infrastructure, in version control, with a runbook and an evaluation suite — so if the arrangement ends for any reason, your own engineer can pick it up by reading the repository instead of by calling me.
Why not scope the work remotely and skip the month inside our operation?
You can, and for a known, bounded process that is the better instrument — a fixed-scope sprint exists precisely for it. An embed is for the case where the scope itself is the unknown. Remote scoping gets you the process as described: the version in the standard operating procedure, the version told to a manager, the version people sincerely believe they follow. The distance between that and what happens at eleven on a Thursday is where these projects die, and it is not a distance you close over video for an hour a week. A month of proximity is how you avoid building the wrong thing precisely and on time.
What happens if we do not like what is being built?
You see it before it is finished, which is the entire point of the format. Work goes in front of the person who does that job in the same week it is built, and the direction is corrected there rather than in a review three weeks later. Each week closes on a written checkpoint with a stated exit gate, and the map produced in week one is signed by you before any building begins, so the target is agreed rather than assumed. If a component turns out to be the wrong thing to automate, it is dropped and the reason is written down — a month spent finishing the wrong build serves nobody.
Does the engineer have to be physically in our office?
On-site is the stronger version and is offered where it is practical: within Bengaluru without qualification, elsewhere quoted with travel. Where it is not practical, the embed runs fully inside your working hours instead — your standups, your queues, your escalation channels, and screen time with the people doing the work rather than scheduled calls with the people who supervise it. What matters is access rather than geography: being present when the exception happens, instead of reading a summary of it afterwards. Working-hours placement is practical across the United States, the United Kingdom, Europe, the UAE, Singapore and Australia, and is quoted on that basis.
What it costs
Every engagement is quoted individually — and quickly.
There is no price list here because there is no honest one. What a workflow, an agent or a rollout costs depends on how many systems it touches, how clean the data is, how much of the process is written down, and — for adoption work — how many people are actually in it. A number quoted before knowing those is either padded to cover the unknown or discovered to be wrong halfway through.
What you get instead is a fixed price, in writing, before you commit to anything — and fast enough that it is never the reason a project stalls.
From first contact to a number
- 01
A reply within 24 hours
From the person who would actually do the work, not an automated sequence.
- 02
A 20-minute fit call
Qualification only. Which process or which people, how many hours a week, and who signs off. No advice given and no pitch.
- 03
A written proposal within 24 hours of that call
A fixed price, with the scope caps, timeline, deliverables and payment schedule already in it.
- 04
The price then does not move
Two revision rounds are included on builds. Anything outside the written caps is quoted and agreed before it happens, never billed as a surprise.
FAQ
Questions about embedded placements
Sits inside your operation for a month or more and builds the AI layer for the work as it actually happens, rather than as the process document describes it. The early weeks are spent watching: which spreadsheet is really the system of record, which approval is a formality, where the same value gets re-keyed into three systems. What follows is a build — one component’s automation, a whole product’s automation, or end-to-end AI solution design and delivery — in your infrastructure, in your version control, with the same evaluation suites, failure paths, observability and runbooks as any other engagement. The difference is proximity, not standard: decisions that would take a week of email get made at the desk where the work is done.
Either. On-site placement is available in Bengaluru and elsewhere by arrangement, quoted with travel and subject to your own access, security and background-check requirements. Remote placement means working your hours rather than overlapping them — present in the same channels, the same queues and the same daily rhythm for the working day, for a defined term agreed in advance. A forward deployed engineer is placed with you against a written brief and a named client-side owner, and the term is fixed before it starts. In both forms the constraints are unchanged: credentials stay in your secret manager, code lands in your repositories, and the delegated access is revocable in one click.
The intakes are an unusually accurate automation diagnostic, and they feed straight into it. Sitting with people individually and watching them work surfaces the same task done a dozen different ways, the export nobody automated, and the three steps every one of them repeats by hand every morning — which is precisely the input a Workflow Automation Sprint or an AI Agent Build needs. Where something turns out to be worth building rather than teaching, it is written up as a ranked candidate with an hours-saved estimate and the assumptions stated, so you can challenge it. The two are quoted separately and neither is a condition of the other. Teaching a person to do a task faster is the wrong answer when the task should never have reached them.
Is the problem the people, or the process itself?
Describe the operation and what nobody outside it understands about how it runs. If a fixed-scope sprint would get you there faster and cheaper, I will tell you that on the call.
Prefer email? hello@soloz.ai