Forward-Deployed Engineering
Keep a named engineer with your team after a project ends, so evaluation and operations stay current as models and harnesses change. This is how we deliver Forward Deployed Agents inside a working organisation.
Named days each month, embedded with your team. We keep the evaluation sets current, review upstream releases, and stay close enough to catch questions before they turn into incidents. This is the usual arrangement once a system is live and the work has no clean end date.
- What keeps moving: model releases, harness updates, your codebase
- Your evaluation set: true only while someone tends it
- Maintained: decisions stay defensible
- Left alone: stops telling the truth
Start small
Begin on a rolling month, one-month minimum.
Continuity
The same engineer stays with your team.
Reviewed
Outcomes agreed up front, reviewed in writing each term.
Where it applies
A system already delivered, where models and harnesses keep changing and the evaluation behind it needs to stay current.
How it works
A named engineer stays with your team, on a rolling month, with capacity adjustable at any review.
What you keep
Everything, as before. The engagement maintains what you already own rather than adding a dependency.
Fit
When teams call
An engagement has finished and the result needs to hold while everything underneath it keeps moving.
After a project
The gains need to survive the next model release
Fast-moving stacks
Tracking releases nobody on the team chose
Lean platform groups
Agent infrastructure carried alongside everything else
Scaling rollouts
Extending agent work from one team to many
Process
How we work
Agree the capacity
Pick a day count that matches the work in front of you. Start rolling monthly, move to a longer term once it has proved itself.
Embed
We join the channels your team already uses, pick up context from prior work, and take ownership of the evaluation sets.
Run the cycle
Each month: maintenance on the measurement, agreed work from your backlog, and a check on what upstream releases changed.
Review and adjust
Capacity, outcomes and cost reviewed each term. Adjusting, extending or ending it is straightforward at every review.
Deliverables
What you receive
Reserved capacity
An agreed number of engineering days held for your team each month
Maintained evaluation
Your task sets updated as codebase, models and harnesses move
Embedded access
In your channels and your planning, reachable before decisions get made
Regular review
A written account of what changed, what it cost, whether the measures hold
Scope
Engagement Options
Start on a rolling month. Longer terms carry a lower rate, and capacity moves at any review.
Monthly
Rolling, one month minimum
Rolling month, cancel anytime
Try the arrangement without committing a quarter.
- Evaluation set maintenance
- Upstream release review
- Channel access for questions
- Written review each term
- Priority on new work
Typical starting point
Quarterly
Three months, reduced rate
Three months, reviewed at the end
Long enough to build context and carry backlog work, at a lower rate.
- Everything in Monthly
- Backlog work each month
- Harness and memory changes
- Involvement in planning
- Onboarding for new teams
Long Term
Six or twelve months
Named engineer, best rate
Agent work across several teams, with the same engineer throughout.
- Everything in Quarterly
- Multiple teams supported
- Rollout and enablement
- Governance and policy input
- Named escalation path
Open source
Underlying systems
The work rests on systems we maintain openly, inside your existing setup.
Questions
Questions
Discuss retained capacity
Describe the system and how much cover it needs. We will suggest a tier that fits.
London and San Francisco. Remote or on site.
