Senior AI engineers for fintech and insurance.
The model is the easy part. We do everything after it, in your repo, until it runs in production.
Named engineers, not anonymised profiles. Their pull requests go through your review.
Over 150 senior AI engineers. Delivering for clients since 2008. ISO 27001 and CMMI Dev 3 certified.
Something runs. Against your real data, in your environment, invoked end to end by one of your people, with a logged trace. Not a demo on our laptop.
- Days 1–3 Access, environment, and the bar it has to clear agreed in writing before anyone touches a model.
- Days 4–6 First path through your data, end to end, however rough.
- Days 7–9 It runs, measured against that bar rather than described.
Day 30 is your exit, not our deadline. Stop, continue or scale. Monthly terms, no annual lock-in, and the code, runbook and evals are yours either way.
Day 9 assumes read access to one named source by day 2. If that slips, day 9 slips, and we tell you on day 2 rather than on day 9.
The difference is where the work joins your loop.
Same people, same bar, same monthly terms. What changes is how much of your review process the work has to pass through.
Forward deployed engineer
- take this whenYou have engineers, not AI engineers
- writing codeDay one
- termsMonthly
AI pod
- take this whenThere is no team to absorb it
- running byUnder a week
- termsMonthly, gate at day 30
Start with one and add a pod later or the reverse. The people don't change, only where they join does
Everyone else stops somewhere.
A forward deployed engineer is a senior engineer who works inside your company instead of building from a distance. Here is how far each option travels.
Forward deployed engineers focus on enabling many capabilities for a single customer.
Palantir Engineering Blog
Six pods. Each one owns a different kind of problem.
They do not overlap. If your problem sits between two of them, you will hear that on the first call.
Your people cannot find what the company already knows.
- A retrieval system your staff query in plain language, against your live documents
- Connectors into the systems those documents actually live in
- Permission rules tested against your access model, so a person sees only their own
- An eval set of real questions with correct answers, so accuracy is measured
- A monthly accuracy report with the failures listed and what changed
A person is doing the same sequence forty times a day.
- Working automation for one named process, running in your systems
- The tools it may call, and the written limits on what it may do alone
- Auth, retries and an audit trail your risk team can actually read
- A measured error rate, and the threshold at which it stops and asks a person
- The list of steps we deliberately left human, and why
Numbers get produced every month. Nobody plans around them.
- A model backtested against the method you use today, both results shown side by side
- The serving layer, so the forecast reaches where the decision gets made
- Drift monitoring, because the real failure is quiet degradation by month three
- Accuracy tied to a decision somebody takes, not to a leaderboard number
- A written account of what the model cannot see, so nobody over-trusts it
A person is checking by eye, and the line moves faster than the person.
- A trained model on the hardware you already have, at the speed your line runs
- Labelling done against real conditions: bad light, dirt, the angles nobody planned for
- The threshold set with your quality team, and the agreed handling for a miss
- False positive and negative rates measured on your floor, not on a clean dataset
- The retraining path, so it keeps working when the product changes
The AI cannot reach the data, or nobody trusts the data it reaches.
- Connectors and pipelines that put the data somewhere a model can reach it
- Permission and lineage mapping, so you know who may see what and where it came from
- Data quality tests on a schedule, with failures raised rather than absorbed
- A written account of what is missing, what is wrong and what it would cost to fix
- A stated point at which the other pods can safely start, or an honest answer that they cannot
It works in the demo. It falls over the moment real people use it.
- An honest audit of what exists: what to keep, what to rewrite, what to throw away
- The rebuild of whatever cannot survive real load, real permissions or real edge cases
- Evals, logging and monitoring, which prototypes almost never have
- Cost control, because a prototype that ignores token spend becomes a budget argument
- A deployment your team can roll back without calling us
A new name.
Not a new company.
Avogtal is the AI practice of a software company that has been building and running systems for clients since 2008, with more than 800 people and over 150 of them working in AI. The engineers, the security posture and the delivery record are already in place. You are not the experiment that proves whether a young firm can ship.
The certifications matter more than they sound. Your security review is the thing most likely to delay a start date, and a supplier who has already been through ISO 27001 and CMMI assessment answers most of that questionnaire from a document rather than from a promise.
You keep the decisions.
We do the build.
Most of the argument about AI delivery is really an argument about who is accountable for what. Here it is written down, so nobody discovers the answer during an incident.
Behind your access controls, in your repo, through your review process. Not on our infrastructure and not on sample data.
A marked test the system has to pass, written before anyone touches a model, so the result can be argued with.
Data access, guardrails, deployment and the monitoring that catches a system going wrong three months in.
Not until the handover document is finished. Until the thing is working where your business actually uses it.
Nothing lands that your engineers have not read. That is how the knowledge stays inside your company rather than inside ours.
We will not tell you what a good answer is in your business. We write down what you tell us and then build to it.
All of it yours, in your repository, under your licence. There is nothing to hand back because it was never held.
Continue, widen or stop. Monthly terms exist so that stopping is a real option rather than a negotiation.
The test we hold ourselves to: if we disappeared on day 31, the system keeps running and your team can change it. Any arrangement that fails that test is a dependency you are paying to build.
You'll know if this is working
before you're committed.
Every stage ends in something you can open, run or read. If there's nothing to inspect, the stage didn't happen, and that's your signal to stop, not ours to explain. The exit is written into the engagement, not negotiated at the end of it.
We find out whether you need us
Thirty minutes on what's actually stuck. You leave with the outcome written down, the first thing we'd hand you named and an honest answer on whether one engineer covers it or it needs a pod.
You get: the problem written down and a straight answerYou meet the actual people
Named engineers on a call, not anonymised profiles to screen. If the fit is wrong you say so now and we change it, which costs nothing at this point and a great deal later.
You get: the people, by name, before you commitWe agree what "working" means, in writing
Access, environment and the specific bar the system has to clear, all signed off before anyone touches a model. Skipping this is the single most common reason a pilot can't be evaluated later.
You get: success criteria you approvedSomething runs in your environment
Not a slide, not a notebook on sample data. A thing your team can open and use, measured against the bar you set in week one.
You get: a working artifact and its resultsYou decide, with evidence
Continue, scale or stop. Terms are monthly precisely so stopping is a real option. If we haven't earned the next month you shouldn't be paying for it.
You get: the evidence and a genuine exitWho we turn away
is the whole product.
Any firm can assemble people. What you're actually buying is the filter: who gets in and what we refuse to do once they have.
The terms, before
you ask for them.
Most of these usually surface late, in a redline, after both sides have spent a month getting attached to the deal. They are cheaper to read now. Nothing here changes in the contract, because the contract is where we wrote it down first.
Ask before you talk to anyone.
Type a question. Answers come from this page, not from a model, so nothing here will be invented to close you.
What does it cost?
A pod is one monthly price for the pod; an individual engineer is a monthly price against an agreed scope. We don't bill hourly, because hourly billing rewards a vendor for taking longer. The number depends on the workload and the mix of specialists, and it comes out of the first call. We'd rather quote something real than publish a rate card that fits nobody.
How fast can someone actually start?
An individual engineer usually starts within days of the brief being agreed; a pod is assembled and working inside a week. In practice the limit is your side: repo access, data permissions and security review are what set the real start date, so it's worth beginning those before you've decided.
Do I need one engineer or a whole pod?
If you already have an engineering team and the gap is specifically AI capability, take one embedded engineer, because they'll be more useful inside your team than beside it. If there's no team with capacity to absorb the work, take a pod, because otherwise the coordination lands on a manager you can't spare. If you're unsure, that's what the first call is for.
What happens if it isn't working?
You stop at the day-30 gate and stop paying. Terms are monthly for exactly this reason. We'd rather end an engagement early than carry one that isn't producing. A client who stayed too long is worse for us than one who left on good terms.
Do you understand our industry or just the technology?
This is the objection CIOs raise most, and it's the right one. A lot of firms know models well and know nothing about the rules you operate under. We match on domain as well as stack, and if nobody in the network has worked under your constraints (clinical, financial, safety-critical), we'll tell you on the first call rather than learn on your budget.
Will this disrupt the systems we already run?
No, and that's a design constraint rather than a hope. Engineers work inside your existing environment, behind your access controls, shipping through your review process. Nothing gets replaced to make our work easier. The AI has to fit the workflow your business already runs; the workflow does not get rebuilt to suit the AI.
Are we going to end up dependent on you?
You shouldn't be, and we build to prevent it. Your engineers review every pull request, so the code is understood inside your team as it lands. You keep it. We write the runbook and the evals with your people, not for them. The honest test: if we disappeared at day 31, the system keeps running and your team can change it.
How do you know your engineers are any good?
Five stages, and the one that matters most is the fourth: we call their last client and ask whether the work reached production. Anyone can pass a technical interview. Far fewer can hold a scoping conversation with a sceptical stakeholder and still ship. Screening only for coding skill or only for client-facing skill is how this role fails. We screen for both, and most applicants don't clear it.
Will our data or code leave our environment?
No. Engineers work inside your systems under your controls: your repo, your access model, your review process, your logging. There's nothing to export, because the work happens where the data already is.
Which models and tools do you work with?
Whichever is right, and we hold no reseller relationship with any of them. Engineers work across the major providers and the surrounding stack: retrieval, orchestration, evaluation, serving and the data plumbing underneath. If your existing stack is fine, we'll tell you that rather than propose a migration.
Which of the four pods do we need?
Pick by the shape of the problem, not by the technology. If people cannot find what the company already knows, that is the document retrieval pod. If a person repeats the same sequence dozens of times a day, that is process automation. If numbers get produced and nobody plans around them, that is forecasting. If a person is checking by eye faster than they can keep up, that is visual inspection. If the data itself is the blocker, that is the data readiness pod. If something already works in a demo and falls over with real users, that is the prototype to production pod. If your problem sits between two of them, you will hear that on the first call instead of being sold the nearest fit.
Who is actually behind Avogtal?
Avogtal is the AI practice of a software company that has been building and running systems for clients since 2008 and employs more than 800 people, over 150 of them working in AI. That matters mostly for the boring reasons: ISO 27001, ISO 20000, ISO 9001 and CMMI Dev 3 are already in place, so your security review is answered from documents rather than from promises.
What lands in our hands every month?
It depends on the pod, and each one lists it on this page rather than leaving it to the statement of work. Broadly: a working system in your environment, the evals that prove it clears the bar you set, the connectors and permissions underneath it and a written account of where it currently fails. If a month produces nothing you can open, run or read, that is your signal to stop at the gate.
Tell us what's stuck.
Thirty minutes, no deck. You describe what isn't shipping; we tell you whether it needs one engineer, a pod or neither. You leave the call with the outcome written down, the first thing we'd hand you named and the date you'd get it. If it's neither, you'll hear that on the call rather than after a proposal.