Advanced

The FDAE Career Playbook

The skills you must have before your first engagement, the soft skills that determine whether you get repeat engagements, how the role sits within different employer models, and the 30-day plan to get there.

✍️ AI School Editorial Team · Lilly Tech Systems 📅 Published Jul 2, 2026 · Reviewed Jul 2, 2026

The Non-Negotiable Technical Skills

The FDAE role has a genuine technical floor. Below it, you will stall on your first customer engagement when the integration does not work and you cannot debug it, or when the prompt design needs to change and you do not know how to evaluate why it failed. The skills below are not theoretical knowledge - they are operational requirements. Before your first engagement, you need to be able to do all of them, under time pressure, without help.

Skill area	What “operational” means
LLM API integration	Can call Anthropic and OpenAI APIs directly in Python; handle auth, rate limits, timeouts, and structured output parsing without consulting docs for basic patterns
Prompt engineering	Can write and iterate a prompt that produces consistent structured output on 80%+ of examples; knows when the problem is the prompt vs. the model vs. the data
Vector search	Can set up and query Pinecone, Supabase pgvector, or equivalent from scratch; understands chunking, embedding model selection, and retrieval accuracy tradeoffs
Basic web UI	Can deploy a working Streamlit or Flask app from scratch; knows how to expose it on a URL a customer can access without requiring them to install anything
Data handling	Can read, clean, and process CSV, JSON, and plain text in Python without relying on perfect data; can write a normalizer for inconsistent formats
Agent orchestration	Can build a multi-step LLM pipeline where one call’s output feeds the next; knows when to use tool-calling vs. prompt chaining vs. a framework
Evaluation	Can write a quick eval loop over 20-50 examples that reports accuracy on a defined metric; can use this to measure the effect of a prompt change
Deployment basics	Can deploy to a cloud run environment or a customer VM; can set environment variables, manage dependencies, and write a basic health check

Skills You Build On the Job

The technical floor gets you into the role. The skills below are what you build across engagements and what determine your ceiling as an FDAE:

✓

Domain pattern recognition. After three or four engagements in different industries, you will start to recognize that the “customer feedback summarization” problem in healthcare and the “incident ticket triage” problem in logistics are the same structural problem dressed differently. This pattern library is a major productivity multiplier on subsequent engagements.

✓

Constraint anticipation. With experience, you begin to anticipate the security constraint, the IT approval bottleneck, and the stakeholder concern before they arise. You build around them in the design phase rather than discovering them at the demo.

✓

Scope control. Junior FDAEs often say yes to scope additions because they are trying to please. Experienced FDAEs know how to say “yes, and here is where that fits in the roadmap” without letting the current engagement collapse under its own weight.

✓

Handoff quality. Writing documentation that actually gets used, not just written. Running a self-sufficiency test that the team remembers and can repeat. These are skills that only improve with practice.

Soft Skills That Determine Repeat Business

Technical skills get you hired. Soft skills determine whether the customer signs the next engagement. The five that matter most in the FDAE context:

Skill	What it looks like in practice
Calibrated confidence	You tell customers what you are certain of, what you are uncertain of, and the difference. You do not project confidence to manage anxiety - you give them accurate information to make decisions.
Curiosity about the domain	You ask questions about the customer’s business that go beyond what you need to build the system. People can tell whether you are genuinely interested. Genuine interest builds trust faster than any presentation.
Proactive communication	You send the update before they ask. A weekly summary email, a quick message when something goes wrong before they notice, a heads-up when the scope is about to drift. Customers who have to ask for status updates feel out of control.
Teaching patience	You can explain the same thing three different ways without frustration. The person who needs to maintain the system after you leave may not have your context. They deserve explanations that meet them where they are.
Boundary setting	You can say “that is outside the scope of this engagement” without making the customer feel dismissed. You can hold a deadline without being inflexible. These are relationship skills that compound over an engagement.

The FDAE Engagement Model

The FDAE role exists in several organizational structures, each with different tradeoffs for the engineer:

Structure	Typical engagement length	Advantages	Tradeoffs
AI vendor professional services team	2-8 weeks per customer	Variety of customer domains; strong technical support network; defined playbooks	Less autonomy; engagement goals set by sales; travel common
AI consultancy / boutique firm	4-12 weeks per customer	More autonomy; often deeper technical engagement; direct customer relationship	More business development responsibility; income variability if independent
Enterprise AI team (internal FDAE)	Ongoing with internal customers	Deeper domain knowledge; stable income; no travel; long-term impact visible	Less variety; internal politics; slower feedback loops than external customer work
Independent contractor	Project-based, 2-16 weeks	Full autonomy; higher day rates; direct customer equity in outcomes	Business development overhead; no team support; income variability

Landing the First FDAE Role

The FDAE role is usually not listed under that name. Search for combinations of: “forward deployed engineer AI,” “AI solutions engineer,” “AI implementation engineer,” “enterprise AI specialist,” or “AI customer success engineer.” The job exists in many companies; the title is inconsistent.

What hiring managers for these roles look for that differs from standard AI engineering roles:

✅

The portfolio that gets interviews: A GitHub repository with a complete end-to-end LLM application (not a toy demo - a working tool that solves a real problem) counts for more than certifications. Even better: a case study describing a problem you solved, how you scoped it, what you built, what you measured, and what you would do differently. Describe it at the level you would use with a stakeholder, not a developer. That level-switching ability is exactly what hiring managers are evaluating.

The 30-Day Readiness Plan

If you have the technical foundation described above, this plan brings you to first-engagement-ready within 30 days. The goal is not to learn everything - it is to build the specific muscles the FDAE role exercises that a typical AI engineering background does not.

Days 1-5

Build a working end-to-end prototype in under 8 hours. Pick a domain problem you find interesting. Write a one-sentence specification. Build a Streamlit app that calls an LLM and produces structured output. Time yourself. Repeat with a different domain. This trains the prototype loop speed that customers will depend on.

Days 6-10

Practice the discovery session. Find a friend or colleague who uses software in their work. Run a 30-minute discovery session on a workflow they find tedious. Produce a one-page spec at the end. Get their feedback on whether the spec accurately captures what they said. Do this twice.

Days 11-16

Build the integration layer. Take an existing prototype and add: environment variable management for secrets, retry logic on all external calls, output validation, and a basic log of every LLM call. Document how to deploy it to a cloud environment without touching the code itself. This is the gap most AI engineers have.

Days 17-22

Run an evaluation loop. Take a working prompt and 30 examples with known correct outputs. Write a script that runs the prompt on all 30 and reports accuracy. Change one thing in the prompt. Measure the change. Document what you changed and why it improved or degraded results. This trains the empirical iteration muscle.

Days 23-27

Write the handoff package. For one of your prototypes, write a complete handoff package: system overview, architecture diagram, runbook, prompt documentation, known limitations, and a hypothetical next-step roadmap. Show it to someone who was not involved in building it and ask them to follow the runbook without your help.

Days 28-30

Do a full mock engagement. Combine all of the above: discovery session, spec, 48-hour prototype (target 8 hours), demo to a non-technical audience, self-sufficiency test, and handoff package. This is the engagement rehearsal that makes the first real engagement feel familiar rather than overwhelming.

FDAE Readiness Checklist

Use this checklist to self-assess before applying for FDAE roles or accepting your first engagement. Every “not yet” is a specific item in your development plan.

Capability	Ready	In progress	Not yet
Can call Anthropic and OpenAI APIs from scratch without docs	☐	☐	☐
Can write a prompt that produces consistent JSON output	☐	☐	☐
Can build and deploy a Streamlit app in under 2 hours	☐	☐	☐
Can set up a vector search index from scratch	☐	☐	☐
Can run a 30-minute discovery session and produce a spec	☐	☐	☐
Can write an eval loop over 20+ examples	☐	☐	☐
Can build a prototype with retry logic, logging, and output validation	☐	☐	☐
Can present a working demo to a non-technical audience	☐	☐	☐
Can write a handoff package someone else can follow	☐	☐	☐
Can explain AI limitations specifically and constructively	☐	☐	☐

📚

Technical depth for the role: This course covers the people, process, and career layer of FDAE work. For the technical depth you will need on customer sites, see Production Readiness Runbook for LLM Systems for deployment and monitoring patterns, Prompt Patterns That Survive Production for prompt design, and AI Agent Frameworks in Practice for multi-agent orchestration choices.