The 4 Portfolio Projects Every AI Forward Deployed Engineer candidate should build in 2026
The 4 portfolio projects every AI FDE candidate should build in 2026
You’ve done the courses. You shipped a RAG app to GitHub. You pushed a notebook or two. And somewhere in the back of your mind there’s a quiet worry you haven’t quite said out loud: is any of this actually going to convince someone to hire you as an AI Forward Deployed Engineer?
I’ll say the hard thing gently, because I’ve watched genuinely strong engineers fall into this exact trap. Most FDE portfolios are interchangeable. One generic RAG demo, lifted from a course, unevaluated, near-identical to the thousand others. It isn’t a lack of effort. It’s effort pointed in the wrong direction.
So let me give you the reframe I use with the engineers I coach into these roles.
Across every client, every industry, every messy customer problem, enterprise FDE work collapses into **four build patterns**. Whatever the customer actually needs, the solution is almost always one of these four, for now. Which means your portfolio shouldn’t be a pile of tutorials. It should be four projects - one per pattern. Each in a real repo. Each with a small front-end so a reviewer can watch it run instead of reading your code to imagine it. And each with honest evaluation, not a screenshot of it working once.
If the FDE role itself still feels fuzzy, start with my full breakdown of what a Forward Deployed AI Engineer actually does, then come back here and build. These are the four.
1. Agents (and Multi-agent systems)
This is the highest-demand, least-solved pattern of 2026, which is exactly why it’s where an FDE earns their seat. Agents in production are still not reliably accurate. There’s no settled recipe yet, the way there is for more deterministic systems. That gap is the job. I went deep on this whole job family in my guide to the AI Automation Engineer in 2026 - worth reading alongside this.
Where it shows up. Agentic work is the part of the FDE job that clients can’t buy off the shelf, so it spans every domain:
- Finance / operations - an invoice-processing or accounts-payable agent that reads a PDF, extracts vendor, line items and totals, reconciles them against a purchase order, and flags or routes exceptions.
- Insurance / healthcare - a claims-triage agent that classifies an incoming claim, pulls the relevant policy clauses, and drafts an adjudication recommendation a human signs off on.
- Legal - a contract-review agent that walks a redline, surfaces non-standard clauses, and proposes fallback language.
- Customer operations - a support agent that resolves a ticket end to end: reads the account, calls the right internal tools, takes the action, and writes the reply.
- Sales / RevOps - a research agent that enriches a lead from public sources and drafts a tailored outreach brief.
The project to build. Pick one domain you actually understand and build an agent that does real work in it - not a chatbot, an agent that takes an action. Use the invoice example if you have no domain: extract structured fields, reason over them, decide, and act, with the hard parts handled rather than hidden. The interview is won in the hard parts: What happens when extraction is wrong? How do you bound the error? Where do you hand control back to deterministic code instead of trusting the model? Show that you know the difference between deterministic and probabilistic control flow and where each belongs.
Build from these:
- Anthropic’s Building Effective AI Agents - the single best conceptual grounding; read it before you write a line, and cite it in your README to show you design deliberately.
- LangGraph - the industry-standard framework for stateful, graph-based multi-agent systems.
- Hugging Face smolagents - a minimal, code-first agent library; great if you want to show you understand agent internals, not just framework wiring.
- OpenAI Agents SDK - production framework with handoffs, guardrails and tracing (this is the maintained successor to the old Swarm experiment - use this one).
How to evaluate it. Accuracy on a labelled sample. The failure modes you found and how you handled each. Latency under load. Cost per run. “It worked in the demo” is not evaluation - a measured failure rate and a recovery strategy is.
2. RAG
Almost every enterprise is building retrieval-augmented generation right now, so yes, you need a credible RAG project. But the bar has moved. A RAG app that returns plausible text is table stakes. A RAG app you have *measured* is what signals seniority. This is really an applied slice of context engineering - the discipline of getting the right information into the model’s window at the right time, which is fast becoming the core FDE skill.
Where it shows up. RAG is the default enterprise ask because every company is sitting on documents it wants to query:
- Financial services - retrieval over 10-Ks, earnings transcripts and analyst notes for research and compliance.
- Healthcare / life sciences - grounded Q&A over clinical guidelines, drug labels or trial protocols, where a hallucinated answer is a safety event.
- Legal - search and synthesis across case law, contracts and regulatory filings with citations back to the source.
- Internal enablement - the “chat with our policies / runbooks / wiki” use case nearly every client eventually wants.
- Customer support - answer generation grounded in product docs and past tickets.
The project to build. Build retrieval over a real enterprise document type from a domain you know - policy, compliance, filings, claims. Go past naive chunking: show you considered chunking strategy, hybrid (keyword + vector) retrieval, metadata filtering, and re-ranking. Add citations so every answer points back to its source passage. Then put a thin front-end on it so a reviewer can interrogate it.
Build from these:
- Ragas - the standard RAG evaluation toolkit; gives you faithfulness, answer relevancy and context precision out of the box.
- LlamaIndex - the leading data framework for RAG over your own data, with strong docs at [developers.llamaindex.ai](https://developers.llamaindex.ai/python/framework/).
- LangChain’s RAG tutorial - end-to-end walkthrough covering both chain-based and agentic RAG.
How to evaluate it. This is the differentiator, so make it loud. Run RAGAS and report faithfulness, answer relevancy and context precision on a small labelled question set you built yourself. Show a before/after when you added re-ranking or hybrid search. Walking an interviewer through those numbers puts you in a completely different category from the candidate demoing a chat window and hoping nobody asks how they know it’s good.
3. Fine-tuning
You don’t need to fine-tune everything, and knowing *when not to* is half the skill. But you want one project that shows you can - and that you understand the decision. When does fine-tuning actually beat prompting or RAG? How would you pick a base model across capability, latency and price? How would you measure whether the fine-tune helped at all? If the post-training landscape is hazy, my complete guide to post-training LLMs - SFT, RLHF, DPO and GRPO maps the whole terrain.
Where it shows up. Fine-tuning earns its keep when prompting and RAG hit a ceiling:
- Format and structure - reliably emitting a client’s exact JSON schema, report format or tagging taxonomy that prompting only gets right 80% of the time.
- Domain tone and language - a model that writes in a bank’s compliance-approved voice, or handles legal/medical terminology a base model fumbles.
- Classification at scale - a small fine-tuned model that does a narrow extraction or routing task far cheaper and faster than calling a frontier model on every request.
- Latency and cost pressure - distilling a workflow into a small open model when per-call price or on-prem/privacy constraints rule out the big APIs.
The project to build. Take a narrow, real task and fine-tune a small open model on it - then prove it beat the cheaper alternatives. A parameter-efficient (LoRA / QLoRA) fine-tune on a free Colab GPU is enough; the value is in the judgment, not the GPU budget. Document the decision explicitly: here’s why I fine-tuned rather than prompted or RAG’d, here’s the base model I chose and why, here’s the eval that shows it worked.
Build from these:
- Hugging Face PEFT - the canonical library for LoRA / QLoRA adapter-based fine-tuning.
- Hugging Face TRL - SFT, DPO and GRPO post-training; the go-to for supervised and preference tuning.
- Unsloth - 2x-faster, low-memory fine-tuning, with ready-to-run free Colab/Kaggle notebooks you can fork today.
- Axolotl - YAML-config fine-tuning for reproducible, config-driven runs.
How to evaluate it. Held-out task accuracy versus three baselines: the base model prompted, a RAG approach, and your fine-tune. Report the deltas on quality, latency and cost. The headline an interviewer wants to hear is a sentence like “I’d use RAG for this, not fine-tuning, and here’s the number that proves it” - judgment backed by measurement.
4. MCP servers
The newest pattern, and rising fast. Anthropic open-sourced the Model Context Protocol, and within a year it became a default way to expose tools and context to agents. Building a working MCP server - even a focused one that wires a single real data source or tool into an agent - signals that you’re current with where the stack is going, not where it sat eighteen months ago. For the enterprise framing of why this matters to FDEs specifically, see my piece on Claude Certified Architect.
Where it shows up. MCP is becoming the connective tissue of enterprise AI - the standard way an agent reaches a client’s systems:
- Internal tools - an MCP server exposing a company’s ticketing system, CRM or database to an assistant, safely and with scoped permissions.
- Data access - wrapping a warehouse, a document store or a search index so any MCP-aware client can query it.
- Vertical workflows - a domain server (say, a filings or claims lookup) that multiple agents reuse instead of each re-implementing the integration.
- The FDE’s actual day job - clients increasingly want their bespoke systems wired into off-the-shelf AI clients; an MCP server is exactly that bridge.
The project to build. Build and document a real MCP server that exposes one genuinely useful tool or data source - your RAG index from project 2 is a perfect candidate, which also shows you can compose your own work. Handle the parts that matter in production: auth and scoped permissions, input validation, error handling, and clear tool descriptions so a model uses it correctly. Then connect it to a real MCP client and show it working end to end.
Build from these:
- MCP reference servers - official implementations to study and fork; the canonical place to learn real server code.
- MCP documentation and spec - architecture, build-a-server and build-a-client guides.
- Anthropic’s MCP launch post - the authoritative “what and why” to cite in your README.
How to evaluate it. Show the server doing real work from a real client, with the failure cases handled (bad input, auth failure, tool misuse) rather than ignored. Most candidates haven’t touched this yet. That, for you, is the opening.
The four rules that matter more than the projects
The patterns are the skeleton. These rules are what actually move you from “hobby portfolio” to “I’d put this person in front of a client.”
Build in public. Every project lives in a repo with a clear README. Where it helps, add a lightweight front-end. The people reviewing your profile should be able to *see* the thing work.
Evaluation is not optional. This is the single biggest differentiator I see. The credible portfolios ship with how you evaluated each project and what the numbers were. The forgettable ones ship with vibes.
Pick domain-relevant problems. If you have finance, healthcare, legal, or any regulated-industry background, build all four projects *in that domain*. Business context is half the FDE job, and a domain-specific portfolio proves you can do the part that’s hardest to teach.
Work backwards from the project. This is the meta-point, and I’ll admit I learned it backwards myself. Early on I collected courses like badges, quietly certain that enough of them would add up to readiness. They didn’t. The projects taught me; the courses just reassured me. So pick the project first, then learn exactly what that build demands. A course is worth taking when it unblocks something you’re building, and close to worthless when it’s one more certificate of completion.
Here’s the pattern I notice most often: the candidates I place fastest are almost never the ones with the most projects. They’re the ones who can walk me through the evaluation on *one*.
Four patterns. Four projects. Each measured, each in your domain, each visible. That’s a portfolio that quietly says “I can walk into your client and ship” - which is the only thing an FDE interview is really trying to find out. When you’re ready to see how that portfolio gets tested, read my career guide to AI Forward Deployed Engineer interviews in 2026.
If you’re staring at a half-finished RAG demo right now, you’re not behind. You’re one good decision away from a portfolio that actually works. Pick the pattern. Build the thing. Measure it.
Cheers,
Sundeep
Sundeep Teki, PhD
Website | Coaching | LinkedIn | X
P.S. If you want the full map - the FDE interview loop, the use cases behind these four patterns, and a skills checklist to see where you stand against them - that’s exactly what my FDE Career Guide is built for.
And if you’d rather pressure-test your specific plan with me, a Career strategy Session is where we turn these four projects into a portfolio aimed at the roles you actually want.
