A forward deployed engineer's day in the life is mostly unblocking, debugging, listening and writing, with the actual coding fitted in between. To make that concrete, this article follows one fictional week, Monday to Friday, in the third week of a fictional engagement: putting a claims-assistant RAG system into production at an insurer's global capability centre (GCC) in Hyderabad. Each day ends with the skills it called for. After that we cover what the job is not, the hard parts, who enjoys it and how to prepare.
Read this first: this is an illustrative composite. "Kavya" is not a real person, the insurer is not a real customer and the vendor is not a real company. The week is assembled from patterns common in enterprise AI deployments. It does not describe how any particular company runs its FDE practice.
For a definition of the role, see our guide to what a Forward Deployed Engineer is. This article skips the definition and stays with the detail.
The setup: week 3 of a claims-assistant engagement
Kavya is an FDE at a fictional AI platform vendor. She is embedded at the Hyderabad GCC of a multinational insurer, where claims handlers process motor and property claims for the parent company's overseas business. Much of their day goes on looking things up: policy wordings, claims guidelines, endorsements, surveyor reports and the scanned documents customers attach to their claims.
The first milestone is deliberately narrow. A handler asks a question ("Is burst-pipe water damage covered under this wording, and what excess applies?"). The assistant answers with citations to the exact clause and retrieves only documents that handler is entitled to see. It never makes a claim decision; a human always does.
The stack is ordinary enterprise RAG: Python/FastAPI, PostgreSQL with pgvector, a managed LLM endpoint in the insurer's approved cloud region, ingestion jobs on the customer's Kubernetes cluster, OpenTelemetry tracing and a nightly evaluation suite. Weeks 1 and 2 produced a pilot for one small team of handlers. Week 3 is about making it trustworthy enough to widen.
Handler question
|
v
[SSO / entitlements] --> [Retriever: pgvector + filters]
|
v
[LLM: answer + citations]
|
v
[Trace + eval log] --> [Handler decides]Monday: stand-up, and an SSO integration stuck in security review
The 9:30 stand-up in the GCC project room brings together a product owner from claims operations, two of the customer's developers, an infrastructure engineer and a claims team lead who speaks for the users.
One card has not moved in six days. The pilot uses a temporary allow-list of named users. Widening it needs single sign-on through the insurer's identity provider, with group claims that map each handler to the lines of business they may see. The integration code is done, but the app registration is sitting in the information security team's review queue, and that team works in another time zone.
Kavya spends the morning shortening the wait. She asks the infrastructure engineer what security has rejected before. The answer is vague redirect URIs and over-broad scopes. So she rewrites the request: an exact list of redirect URIs, read-only group membership as the only scope, a data-flow diagram showing that group claims never leave the insurer's tenant, and a paragraph on how the retriever uses those claims to filter documents. She attaches the week-1 threat-model notes and asks the product owner to raise the item at the weekly change board.
In the afternoon she builds a fallback. If approval slips, a second team can join on the allow-list, with handlers mapped to lines of business by hand and reviewed by their team lead. Both options go on the shared status page.
Skills used: OAuth/OIDC scopes and group claims (see identity and access for AI agents), knowing how security reviews actually work, writing for a reviewer, and contingency planning.
Tuesday: debugging retrieval misses on scanned PDFs
Overnight a team lead posted a screenshot: the assistant had said "I couldn't find this in the available documents" about a surveyor's report, and she knew the answer was in it. By morning two more handlers had reported similar misses.
Kavya starts with the cheapest evidence, the traces. For each failed question the relevant document either ranked low or wasn't retrieved at all. Looking at the stored chunks shows why: many contain only a page header, a page number and a few stray characters. These documents are scans. Some PDFs have no text layer; others have poor scanner OCR, and the rotated pages came out as garbage. The ingestion pipeline was built around the clean, digitally generated policy wordings tested in week 1, and it accepted whatever text layer it found.
The fix takes the rest of the day:
- Detect, don't assume. Flag a page when its extracted text is too short, or mostly non-words, for its size.
- Route flagged pages to OCR with orientation detection, and keep table structure, because surveyor reports put the key figures in tables.
- Record provenance. Each chunk stores whether its text came from OCR and with what confidence, so answers built on shaky text can carry a warning.
- Re-ingest only what changed, using idempotent chunk IDs so the backfill doesn't create duplicates.
- Grow the eval set. The reported questions, plus similar ones written with the team lead, become permanent test cases.
By evening the reported questions retrieve the right pages. One handwritten surveyor note is still unreadable, and Kavya logs it as a known limitation rather than hiding it. The enterprise document intelligence project covers this class of problem in depth.
Skills used: trace-driven debugging, document parsing and OCR, idempotent data backfills, turning complaints into eval cases, and being honest about limitations.
Wednesday: a discovery call, then a design doc
The pilot has created demand: the subrogation team, which recovers claim costs from third parties, wants help too. Kavya runs the discovery call.
She doesn't open with a demo. She asks the team to walk through a recent case screen by screen: what triggers a recovery, which systems they open, where they wait, and how they judge a good outcome. The real pain turns out not to be finding information. It is assembling a recovery file from the claims system, email and scans, then drafting a demand letter for legal to review. Someone mentions in passing that some jurisdictions require specific wording. That kind of detail can make or break a design.
The afternoon goes on a short design doc:
- Problem and outcome: the problem in the team's own words, plus the measure they agreed to track (time to assemble a recovery file), with no number promised.
- Scope: evidence assembly and a template-based draft letter for one claim type. Legal approval is mandatory and nothing is sent automatically (see human-in-the-loop AI design).
- Architecture: reuse the existing retriever and entitlements, and add a read-only connector to the claims system.
- Risks and out of scope: data-access approvals, jurisdiction rules and template ownership are listed as risks. Deciding liability and contacting third parties are explicitly excluded.
She shares the doc and asks two specific questions instead of "any feedback?". For the method, see how to find and prioritise enterprise AI use cases.
Skills used: discovery interviewing, turning a workflow into requirements, reusing architecture, design writing, and saying clearly what is out of scope.
Thursday: an evaluation regression after a prompt change, and a rollback
On Wednesday evening a customer developer merged a prompt change. Handlers had complained that answers were long, so the system prompt now asked for "three sentences or fewer". It passed code review.
The nightly evaluation run did not. Faithfulness and citation correctness had dropped noticeably on the policy-wording subset. The failing cases showed why: to fit three sentences, the model was dropping the exclusions and conditions that follow "covered, subject toβ¦". In insurance those qualifiers are the answer. A confident "yes" missing the gradual-leakage exclusion is worse than no answer.
The team follows the routine it agreed in week 1:
- Roll back the prompt. It is versioned in Git and ships through the same pipeline as code, so this takes minutes.
- Re-run the evaluation to confirm the rollback.
- Check the traces from the hours the change was live. Two handlers had received incomplete coverage answers, and Kavya sends their team lead the exact questions so those claims can be rechecked.
- Write a short incident note covering the change, the impact, the fix and the new rule: prompt changes must pass the evaluation gate before merge, not only nightly.
The complaint about length was still valid, so Kavya and the developer fix it properly. The new format is a one-line summary followed by the conditions and exclusions as a short cited list. It reads faster and holds faithfulness. For the metrics, see RAG evaluation metrics.
Skills used: reading eval reports, failure analysis, release engineering for prompts (versioning, gates, rollback), incident communication, and enough domain sense to know that qualifiers matter.
If you want practice on the production half of AI engineering, not only the demo half, look at Cloudsoft's FDE PRO program. Its weekly Customer Engagement Lab and its "GlobalBank" capstone, a simulated customer engagement, are built around moments like this one.
Friday: the executive demo, an honest status update and product feedback
At 11:00 the product owner presents to the GCC's head of claims operations and a visiting director from the parent company. Kavya drives the screen and takes the technical questions. There is no scripted happy path. The director picks a real, anonymised claim and asks questions live, and both get cited answers. Kavya then shows one failure, Tuesday's handwritten note, where the assistant says it cannot read the page and points to the original. The director asks about exactly that, and the answer is easy because nothing was hidden.
The written status update has four headings: done, at risk, decisions needed and next. "At risk" lists the SSO approval with its fallback, and the Thursday regression with its impact and fix, reported before anyone hears about it second-hand. "Decisions needed" holds the subrogation design doc. Early bad news with a fix attached builds trust. Our playbook on taking AI from POC to production covers the stage gates this update feeds.
The last task is internal: a product-feedback note to the vendor's home engineering team.
- Ingestion should detect missing or bad text layers by default. This is the second engagement where it has been added by hand.
- Prompt versions should be first-class, with built-in evaluation gates.
- Answers should support OCR-confidence warnings natively.
Each point comes with customer-safe evidence and the workaround she used. Then she logs off, just as the parent company's working day begins.
Skills used: stakeholder communication, live-demo judgement, status reporting that leads with risk, and product thinking that turns field work into platform improvements.
What the FDE job is not
| It is not⦠| Because, in this week⦠|
|---|---|
| Pre-sales demoing | Kavya owned a production system, including its failures and its rollback. |
| Pure prompt engineering | The prompt edit was the smallest part of Thursday. Evaluation and release discipline were the real work. |
| Consulting slides | The design doc led to code, connectors and approvals. |
| Ticket-taking | She shaped the scope on Wednesday instead of building whatever was asked. |
| A solo hero role | Almost every win depended on the customer's developers, security team and team leads. |
The hard parts
- Context switching. Identity configuration, OCR internals, a process interview, an incident and an executive demo in five days. You have to protect focus time deliberately.
- Ambiguity. Nobody hands an FDE a complete spec. The subrogation team only found its real need by walking through a case, and the scanned-PDF problem stayed invisible until users hit it.
- Travel and time zones. Many FDE roles include time on customer sites, sometimes for weeks during critical phases. Customer teams, home engineering teams and approvers are often spread across regions, so early or late calls come with the job. How much varies widely by employer and engagement.
- Accountability without authority. Outcomes depend on approvals, data access and people you don't manage, and when something breaks, the person in the room gets the first call.
Who enjoys it
The engineers who thrive as FDEs enjoy the whole week, not just Tuesday. They like meeting the people who use what they build, they are curious about how insurance or banking actually work, they find a clear status update as satisfying as a clean pull request, and they stay steady when Thursday's report comes back red. If you want long uninterrupted stretches on one deep problem, core product or platform roles may suit you better, and that is a good choice too.
How to prepare
Work backwards from the week:
- Monday: add SSO with group-based access to your own project, and write the security-review request for a sceptical reader.
- Tuesday: build RAG over messy documents, scans included, and debug from traces rather than guesses.
- Wednesday: interview someone about their workflow and write a two-page design doc with an out-of-scope section.
- Thursday: add an evaluation gate to CI, then break a prompt on purpose and watch the gate catch it.
- Friday: record a demo that includes one honest failure, and write the status update that goes with it.
The full skill map is in FDE engineer skills employers look for. For routes from developer, DevOps, cloud or ML backgrounds, see how to become an AI Forward Deployed Engineer. Interviewers probe days like Tuesday and Thursday directly, as our FDE engineer interview questions show. When you're ready, browse verified Forward Deployed Engineer job listings.
Frequently asked questions
What does an FDE do daily?
A typical day mixes customer meetings, hands-on engineering and writing: a stand-up with the customer team, debugging a data or retrieval issue, unblocking an approval, reviewing evaluation results, and writing a design doc or status update.
Is this week based on a real person or customer?
No. Kavya, the insurer and the vendor are fictional. The week is an illustrative composite of common enterprise AI deployment patterns and does not describe any real company's FDE practice.
How much of an FDE's time is coding?
It depends on the employer and the phase of the engagement. Build-heavy weeks can be mostly code, while discovery and go-live weeks are mostly meetings, reviews and writing. Coding is a substantial part of the job, but rarely all of it.
Do forward deployed engineers have to travel?
Many FDE roles involve some time on customer sites, especially during discovery and go-live, and regulated customers often prefer engineers on premises. The amount varies widely, so ask about it in interviews.
What is the hardest part of the FDE job?
Most FDEs point to context switching and ambiguity: very different problems in one day, and progress without clear requirements. A close third is being accountable for outcomes that depend on people you don't manage.
Is an FDE the same as a pre-sales engineer?
No. Pre-sales roles mainly demonstrate a product before a sale. An FDE builds, deploys and owns a production solution inside the customer's environment, including its incidents, evaluation and handover.
Can a fresher become a forward deployed engineer?
It is harder but possible. A fresher needs evidence of end-to-end work, meaning deployed projects with access control, evaluation and monitoring, plus clear writing. Many people move into FDE roles after a few years in development, DevOps, cloud or ML engineering.
What should I practise to prepare for FDE work?
Practise the five days in this article: SSO with group-based access, debugging RAG over messy documents, a discovery conversation and design doc, an evaluation gate with rollback in CI, and a demo with an honest status update.
Want to rehearse weeks like this before you live one? FDE PRO, Cloudsoft's AI Forward Deployed Engineer course in Hyderabad, runs 12 weeks: 120+ hours of live engineering, a weekly Customer Engagement Lab and five enterprise projects, including an Enterprise Knowledge Assistant and a Secure Banking AI Assistant. You can attend in the classroom beside Ameerpet Metro or live online, with placement support until you're placed. For a free demo, call +91 96660 19191.
