Position: Forward Deployed Engineer

Location: Bangalore

️ Working Days: Monday to Friday

Experience Required: 6 months to 1 years

Forward Deployed Engineer |

Solving agent problems across the lifecycle — build, deployment, tuning and steady state — measured on what the agent achieves. About The Role We are hiring a Forward Deployed Engineer to solve agent problems wherever they occur in the lifecycle.

During build, that means getting a configuration to actually do what the use case requires. Through deployment and tuning, it means finding why an agent underperforms and fixing it at the right layer. In steady state, it means holding an agent's numbers where they were promised and catching drift before a client does.

The common thread is not a phase; it is that an agent is not performing and you are the person who makes it perform.

Your scorecard is the agent's outcome metrics. Connectivity, engagement and the outcome rate the use case exists to move — per agent, per use case. Tickets closed, response times and patch counts are hygiene we will look at, never the measure. A month with forty tickets closed and a drifting outcome rate is a bad month; a month with four and every agent holding its numbers is a good one.

This role sits in the application layer, not core platform. That has a consequence worth stating plainly: you are partly an SDE. A fix that only ever helps one client is the weakest version of your work. Because you hold more context than anyone on why agents fail in the field, you are expected to recognise when a recurring fix should become a platform capability every client can use, and then to build it — pairing with SDE 1 and SDE 2 to ship it properly.

It is hands-on and customer-facing at once. You will read production code, logs, transcripts and configuration; reproduce faults; write and ship changes; and speak directly to a client's operations or IT counterpart about what went wrong and what you changed. An FDE who cannot form an independent technical opinion becomes a ticket router, and a ticket router cannot move an outcome metric.

What you are walking into

Several enterprise accounts are live on real customer timelines while the platform is under active build. Most of what changes customer-visible behaviour here is not code — it is configuration: a prompt, a disposition taxonomy, a threshold, a routing rule — shipping through a thinner review path than code. And our worst defects are not escaped, they are undetected: a configuration fault once put a placeholder outcome on two thirds of one campaign's calls for about a month, and the client found it, not us.

None of that should discourage you; all of it is why the role exists.

What you are measured on

One primary metric, four supporting ones. The supporting metrics explain a movement in the primary; they never substitute for it.

Metric Definition, and how it can be gamed

Agent Outcome Metrics (primary) Connectivity, engagement and outcome rate per agent and use case, against the committed baseline. This is the scorecard. Counter-metric: baselines are set once and not renegotiated downward after a bad month.

Detection latency Median time from a customer-visible regression starting to someone at our client's knowing. A fault we find in an hour is an incident; the same fault found by a client in five weeks is an account risk.

Root-cause accuracy Share of issues where the first fix held. Re-opens mean a symptom was patched at the wrong layer. Counter-metric: time to first response, so accuracy is not bought with indefinite investigation.

Escalation precision Share of items sent to core platform that were genuinely platform gaps, and share you resolved that never needed to go there. Both directions fail: over-escalation taxes platform engineering, under-escalation buries a real signal in patches.





Reusability Share of your fixes that became a configurable capability available to every client rather than a one-account patch. A high patch count with zero productised output is a warning sign, not throughput.

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 recent 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.

📌 Forward Deployed Engineer (Bengaluru)
🏢 Rempact
📍 Bengaluru