Forward deployed AI engineers.

What forward deployed engineering means

Forward deployed engineering is a delivery model in which the vendor’s engineers work inside the customer’s organisation, with the people who do the work, and are responsible for a system reaching production use. It is the opposite of throwing a specification over a wall.

Palantir popularised the model and still describes it in its job advertisements: “We pioneered this unique position, embedding talented engineers directly with our customers to tackle their most pressing challenges head-on” (Palantir posting, as listed on 19 October 2026). The AI labs have since adopted it. OpenAI’s forward deployed engineers, including a role based in Sydney, “lead complex end-to-end deployments of frontier models in production alongside our most strategic customers” (OpenAI posting). Anthropic’s forward deployed engineer “embeds directly with our most strategic customers” and delivers artefacts such as MCP servers, sub-agents and agent skills (Anthropic posting).

Two details in those descriptions matter for a New Zealand organisation. Lab teams serve their most strategic customers, which rarely includes a mid-sized NZ business. And a lab’s engineer builds on that lab’s models. Levy Street offers the same embedded model, lab agnostic, at New Zealand scale.

Why deployment is the bottleneck

For most business work, today’s models are capable enough. Projects stall on everything around the model: getting access to the right data, setting permissions, handling exceptions nobody wrote down, designing who approves what, and earning the trust of the people expected to use the result. None of that can be solved from a requirements document. It is solved by engineers who sit with operators, see the work and change the system the same week.

That is why we measure embedded work against an operating number you already track, such as revenue, cost to serve, cycle time or decision quality, rather than against features delivered.

Who it suits

• A chosen workflow and no AI engineers. Leadership has picked the work and backs it, but nobody in-house has shipped an LLM system to production.
• A stalled pilot. A demo impressed people, then progress stopped somewhere between the prototype and real use. See also AI system rescue.
• A capable team new to AI. Your developers are strong and want to learn LLM systems by building one properly alongside people who have.
• Work that crosses teams and systems. Requirements cannot be written up front because nobody holds the whole picture.

What the embedded team brings

Agentic workflow design

Deciding which steps are rules, which need a model, and where an agent is genuinely warranted.

Evaluation suites

Test sets built from your real cases, scored on every change, so quality is measured rather than asserted.

Tool and API integration

Connecting models to the systems of record your staff already use.

Data access patterns

Getting the right information to the model, with permissions that match who is asking.

Human approval loops

Putting people at the decision points that matter, with the evidence in front of them.

Security and permissions

Scoped service identities, secrets handling and defences against prompt injection.

Model selection

Choosing between OpenAI, Anthropic, Google and open-weight models by testing on your task.

Production observability

Traces, quality sampling, cost tracking and alerts from the first release.

Team enablement

Pairing, code review and runbooks so your people can operate and change the system.

Who owns what

How an embedded engagement runs

1. Discover, on site. Engineers spend time with the operators, collect real cases, map systems and access, agree the operating metric and write the exit criteria.
2. Prove: narrowest production system. Build the smallest version that can move the metric with real data, real users, evaluation and approvals in place. Operators see working software every week, not status reports.
3. Prove: measure in production. Run under supervision, measure against the baseline, and fix what the exceptions reveal.
4. Scale: harden and hand over. Integration hardening, monitoring, documentation and pairing until your named owners can run it. Then the embedded team tapers off, or moves on to the next workflow.

What drives the cost

Cost is driven by how many engineers are embedded and for how long, the share of time on site (travel outside Wellington adds cost), the number of systems involved, and how long access and security approvals take on your side. Slow access is the most common reason embedded work runs longer than planned. We do not publish rates; each phase is scoped and priced with its own exit criteria. For the cost of the resulting system, see what custom AI projects cost, and use the AI ROI calculator to size the prize.

Production delivery examples

• Bebop is an AI sales agent for small and medium businesses, owned and sold by Blackpearl Group (NZX/ASX: BPG). Levy Street engineers work with Blackpearl Group’s AI team on Bebop, inside another company’s product and team.
• The Property Management Agent for APL Property is an internal AI agent for a regional NZ property firm that handles email triage, records, orders and follow-up, with staff keeping the decisions.
• PainPal is an AI “digital workmate” for musculoskeletal pain and injury prevention, launched by BetterWorx (a subsidiary of CHASNZ) in December 2025. Levy Street worked with BetterWorx on PainPal.

When not to use forward deployed engineers

• No owner or no access. If nobody can give engineers system access or decide trade-offs, wait until someone can.
• General development capacity. If you need extra hands on an existing backlog, hire contractors; embedding is for outcomes, not hours.
• Advice only. If the question is whether to use AI at all, start with AI consulting.
• A permanent need. If you will need AI engineers indefinitely, hire them. Embedding can bootstrap the capability and help you hire; our comparison of an AI agency versus an internal hire sets out the choice.

New Zealand notes

• Skills are the constraint. In Datacom’s 2026 index, lack of internal capability was the top barrier to scaling AI (20%), followed by employee concern or fear of job displacement (18%). Embedding addresses both, if enablement is part of the scope.
• People and process. Where the system changes roles, Employment New Zealand says workplace changes need consultation and a fair process. Operators who helped design the system are also the ones who make it work.
• Data location. No major AI vendor processes model requests inside New Zealand as at October 2026, so every embedded build records where data is stored and processed under the 14 information privacy principles.

Written by the Levy Street team in Wellington. Last updated 19 October 2026.