Forward deployed engineering
Engineers on your floor, not on a weekly call
Forward deployment is how we get agentic systems out of the pilot and into production. A small team works from your office, inside your systems, with the people who own the work.
What a forward deployed engineer does
Three jobs, held by the same people
Builds
Writes the agent, the integrations into your systems, and the evaluation suite. Works in your repositories and your cloud accounts from the first commit.
Embeds
Sits with the operators who own the workflow. Learns the exceptions, the workarounds and the unwritten rules that decide whether an agent is trusted.
Transfers
Pairs with your engineers throughout, writes the runbooks, and leaves when your team is on call for the system and does not need to phone us.
Engagement model
The shape of an engagement
- Team
- Two to four engineers, one of them the engagement lead
- Onsite cadence
- At least three days a week during discovery and build
- Duration
- Twelve weeks to production, then optional monthly support
- Scope
- One workflow with one measurable outcome, agreed in writing
- Where
- Your office, your environment, your cloud accounts
- Pricing
- Fixed fee for the deployment, set by the week-zero scoping note
Twelve weeks
From scoping note to on-call handover
Brass marks the phases where the team is at your office.
Week 0
Remote
Scoping
We pick one workflow with a number that has to move, list the systems it touches, and agree what done looks like. Two calls, one written scoping note.
Weeks 1–2
Onsite
Discovery, embedded
Two to four engineers arrive at your office. They sit with the team that owns the workflow, shadow the work, map the exceptions, and get access sorted.
Weeks 3–8
Onsite
Build, in your environment
A working agent is running on your systems by week four. From then on it is reviewed weekly by the people who will use it. Evals are built from your real cases.
Weeks 9–12
Onsite
Production and handover
The agent runs on live volume with human review on every risky action. Your engineers pair with ours. Runbooks, evals, dashboards and on-call move to your team.
Ongoing
Remote
Support, then the next workflow
Your team owns the system. We stay reachable, review model changes with you, and come back when you are ready to point the same approach at the next workflow.
What you provide
- An executive sponsor and a workflow owner who can make decisions
- Desk space and building access for the team
- System access and a security review path within the first two weeks
- One or two of your engineers to pair with ours
- Real cases, including the messy ones, to build evals from
What we deliver
- A production agent running on live volume in your environment
- An evaluation suite built from your cases, run on every change
- Permissions, audit logs and a human review queue
- Runbooks, dashboards and an on-call handover to your team
- A written before-and-after on the outcome we scoped
Why onsite
What changes when the engineers are in the building
The rules are in the building
The way your ops lead handles the odd case at 4:45 on a Friday is not in any document. Our engineers are there when it happens, so the agent learns the real process, not the written one.
Decisions in hours, not sprints
When the agent needs a permission, a missing field or a judgement call, the person who can give it sits across the desk. Blockers that take a fortnight over email clear before lunch.
Ownership moves by pairing
Your engineers build alongside ours from week one. By handover, nothing on the whiteboard is ours alone, and your team is running it without a call to us.
Questions
What buyers usually ask
What does forward deployed actually mean?
Our engineers work from your office, inside your environment, alongside the team that owns the workflow. They are not a remote delivery team with a weekly status call. They are at the desk when the exception happens.
How many engineers, and how often are they onsite?
Two to four engineers per engagement. During discovery and build they are onsite at least three days a week. During handover it tapers as your team takes over. We adjust to your working pattern and travel policy.
Who owns the code, the prompts and the evals?
You do. Everything is built in your repositories and your cloud accounts. At handover there is nothing to migrate because nothing ever lived anywhere else.
Can this run inside our VPC or on-premises?
Yes. We deploy into your AWS, Azure or GCP accounts, and can work with private model endpoints such as Bedrock, Azure OpenAI or a self-hosted model. Data does not leave your boundary.
Which models do you use?
Whichever fit the task and your procurement. We usually start with a frontier model for reasoning-heavy steps and smaller, cheaper models for classification and extraction. The platform routes between them and lets you swap later.
What if our data is not ready?
It never is. Part of the point of being onsite is finding out where the real data lives and what state it is in. We scope the first workflow so it can succeed with the data you have today, and leave a list of what to fix for the next one.
How is an engagement priced?
A fixed fee for the twelve-week deployment, scoped around one workflow and one measurable outcome, with an optional monthly retainer for support afterwards. The scoping note in week zero sets the number before you commit.
Next step
Pick one workflow. We will be at your office in two weeks.
A thirty-minute call to find the right first workflow, followed by a written scoping note. No deck, no pilot.