Forward Deployed Engineer

What you will do

Own agent performance, wherever the agent is in its lifecycle. Hold a current picture of every agent you touch: what outcome it exists to move, what it is moving this week, and what changed. When a number drifts, find out why before the client asks. Where the instrumentation to see the drift does not exist, building it is your work, not the reason it was invisible.

Diagnose at the right layer before you change anything. Almost every issue arrives as a symptom. Place it first: context assembly, disposition or configuration error, or broken integration. These have different fixes and different owners, and a patch at the wrong layer holds for a fortnight and returns in a new shape. Read the transcripts, logs and configuration, and state a root cause you can defend.

Treat configuration as production. A change to a prompt, a disposition taxonomy or a threshold changes what a customer experiences with no deployment at all. It gets a review, a version and a rollback path exactly as code does. Where a configuration change cannot yet be governed that way, closing that gap is your work. This is the single strongest belief we screen for.

Sustain the trust loop with the client. Test, flag, patch, retest — visibly, on a cadence the client can see, during UAT and long after. In our verticals confidence is rebuilt by watching us find and fix our own faults, not by an absence of faults. Changes touching live campaign behaviour go out staged and reversible.

Ship the fix, and the instrumentation that would have caught it. Every fix carries a second question: how would we have known sooner? A meaningful share of your output should be monitoring, alerting and evaluation coverage that turns the next instance of that fault into an alert rather than a client email.

Build features with the SDEs, not requests for them. When a fix generalises, you take it to SDE 1 and SDE 2 as a designed capability — the problem, the evidence across accounts, and a proposal for how it should work — and you pair on building it. You hold the field context they do not; they hold the codebase depth you may not. Where a change touches core platform, the CTO is consulted before it is built, not after.

Be the technical face on live accounts. You will speak directly to a client's operations and IT counterparts: what broke, why, what you changed, when it is verified. The CSM owns the relationship; you own the technical truth inside it. Being plain about a fault we caused buys more trust than a clean-sounding account of a bad week.

Who you will work with

Stakeholder Your relationship with them

Chief Product Officer

Your manager. Owns the application layer this role sits in. Reviews agent outcome metrics, reusability and escalation precision.

Chief Technology Officer

Owns core platform engineering. Consulted when a change reaches into the platform, and the escalation point for genuine architecture gaps.

SDE 1 and SDE 2

Your build partners. You bring the field context and the problem definition; you ship the generalised capability together.

Associate Product Managers

Owns the change train and intake. Your changes ship under that discipline; your recurring-failure patterns tell the APM where defects cluster.

Customer Success / Account Managers

Own the customer relationship. They bring the escalation; you give the technical truth and a date you can defend.

Client operations and IT counterparts

Your direct contacts on live accounts — CRM and telephony integrations, data issues, UAT and verification of fixes.

What we are looking for

Must-haves

At least 1 year building or running software in production. We are hiring on judgement and ownership, not tenure — but you must have shipped something real that other people depended on.

Strong Python and comfort with SQL, and the ability to read an unfamiliar codebase and follow a request end to end through it.

Hands-on work with LLM applications: prompting, context assembly, retrieval, tool or function calling, and evaluation. If you have built an eval harness for a component whose output is a distribution rather than one correct answer, lead with that.

Real debugging discipline — you can hold a hypothesis, test it, and discard it. We assess this on a live, messy artifact, not a whiteboard algorithm.

API and integration work: REST, webhooks, queues, retries, auth, and the failure modes of somebody else's system that you cannot change.

You treat configuration as production. If you have shipped systems governed by config, flags, rules or prompts, and have opinions on how those get reviewed, versioned and rolled back, say so early.

Willingness to face a customer during a failure and be plain about it, and excellent written communication — root-cause notes and change summaries are artifacts people act on. You will be assessed on writing, not asked about it.

Comfort with ambiguity and half-built process. You will operate without a runbook and then write the runbook.

Nice-to-haves

Voice or conversational AI: telephony, dialers, STT and TTS, latency and barge-in behaviour, call-quality debugging.

Regulated environments — BFSI, insurance, healthcare — and the data-handling, DPDP and audit gates that come with them.

Observability tooling (Grafana, Looker, Metabase or equivalents), CRM and contact-centre integrations, and Indian-language deployments where transcription quality varies by language, accent and channel.

Disqualifiers

Treating a configuration change as exempt from release discipline because it is not a deploy.

Patching symptoms — adjusting a prompt until a complaint stops, without a stated root cause.

Escalating as a reflex, or the opposite: absorbing a genuine platform gap into patch work for months, and optimising for the queue while the agent's outcome metrics drift.

Declaring something fixed because it worked in one test, on a component whose output is a distribution.

What this role is not

Core platform architecture and technical direction — layering, security model, technology choices (CTO).

Release cadence, intake gating and cross-service contract governance (TPM).

Product roadmap ownership and prioritisation (Product, with your input from the field).

Owning the customer relationship, WBRs and QBRs (CSM).

Commercial scoping, pricing and renewal (AM).

What success looks like

By day 30

You can state, for every agent you own, its intended outcome, current numbers and top two failure modes — without asking anyone.

You have taken over the live-issue queue end to end, and platform engineering has stopped being pulled into it by default.

At least one recurring issue is traced to a root cause and fixed there, rather than at the symptom.

By day 60

Agent outcome metrics are holding at or above the baseline you measured in week one, and that baseline is written down.

At least one customer-visible regression was caught by us before the client raised it, and you can point at what caught it.

At least one field fix has been generalised with the SDEs into a capability other clients can use.

Every agent you touched has its configuration under version control and a reversible path to production.

A written handover exists that would let a second FDE pick this up: known faults, baselines, patterns worth productising.