
The 90 Day FDE Learning Plan for RAG and Agent Memory Builders
Most 90 day FDE learning plans for RAG and agent memory builders are either vague skill lists or thinly disguised course promotions. You won't find a week-by-week path here that's tailored to engineers who already build retrieval pipelines and memory systems. That's the gap this plan fills. It's built for practitioners who can stand up a vector database and wire a retriever, but haven't yet learned how to scope a customer deployment or run a technical discovery call. GigaRAG's agent memory infrastructure shows up throughout as a concrete reference point, not as a product pitch. The honest expectation: 90 days gets you interview-ready for FDE roles, not senior-level. You won't close every gap, and you won't learn enterprise sales in three months. What you'll get is a structured plan with weekly milestones, three portfolio projects with measurable outcomes, and a clear list of what this plan cannot do.
| At a glance | Details |
|---|---|
| Duration | 90 days, week-by-week milestones |
| Target Role | Forward Deployed Engineer (FDE) |
| Core Focus | RAG pipelines and agent memory systems |
| Prerequisite | Software engineering experience and basic RAG familiarity |
| Weekly Commitment | 10–15 hours per week |
| Outcome | Interview-ready portfolio and deployment skills |
In This Guide
- What Is a Forward Deployed Engineer (FDE)?
- 90-Day FDE Plan vs Generic FDE Courses
- What Skills Are Required for FDE?
- 90 Day FDE Learning Plan: A Step-by-Step Guide
- The 90 Day FDE Learning Plan: Weeks 1–4 (Foundations)
- The 90 Day FDE Learning Plan: Weeks 5–8 (Integration & Evaluation)
- The 90 Day FDE Learning Plan: Weeks 9–12 (Interview Readiness)
- Practical Projects for Your FDE Portfolio
- Common Mistakes in a 90 Day FDE Learning Plan
- What This 90 Day FDE Learning Plan Cannot Do
- Final Thoughts on Your 90 Day FDE Learning Plan
What Is a Forward Deployed Engineer (FDE)?
A Forward Deployed Engineer (FDE) is an engineer who works directly inside a customer's environment to scope, build, and ship a working integration, usually under a tight deadline. The role sits between product engineering and sales: you write real code, but you write it on someone else's stack, for someone else's problem.
The term came out of Palantir, where engineers were sent into government and enterprise deployments to make the product actually work in messy, real-world data environments. Other AI infrastructure companies picked it up because LLM products break in customer-specific ways: weird data formats, odd permission models, legacy systems nobody documented.
FDE vs. Solutions Engineer vs. GTM Engineer
A solutions engineer demos the product and answers technical questions during the sale. A GTM engineer builds reusable demos, integrations, and sales tooling. An FDE goes further: you own the deployment end to end, from discovery calls to production code. You are not selling. You are shipping.
Why RAG and agent memory builders are natural FDE candidates
If you already build retrieval pipelines and agent memory systems, you have the core skill FDE work demands: making unstructured data useful under constraints. RAG builders know chunking, embeddings, evaluation, and failure modes. Agent memory builders know state, context windows, and persistence. Those are exactly the problems that break when a product leaves the lab and hits a customer's data. The gap is not technical. It's customer-facing reps.
[!note] This plan assumes you already have software engineering experience and basic familiarity with RAG concepts. It does not cover general software engineering fundamentals or non-AI FDE skills.
90-Day FDE Plan vs Generic FDE Courses
| Factor | 90-Day FDE Plan | Generic FDE Courses |
|---|---|---|
| Structure | Week-by-week milestones with specific projects | Monthly themes or skill lists |
| Focus | RAG pipelines and agent memory systems | Broad FDE skills, often sales-oriented |
| Projects | Hands-on specs with measurable outcomes | Vague or theoretical exercises |
| Cost | Self-directed, minimal cost | Varies; some charge significant fees (verify at publish) |
| Outcome | Portfolio and interview readiness | Certificate or course completion |
What Skills Are Required for FDE?
FDE work splits into two halves: the technical half you probably already have, and the customer-facing half you probably don't. The technical side covers RAG pipeline construction, vector database selection, LLM orchestration, and agent memory design. The soft side covers discovery, communication, and expectation management. Most RAG builders fail the second half, not the first.
Technical skills: RAG, vector databases, LLM orchestration
You need to build a retrieval pipeline end to end: chunking, embedding, indexing, reranking, and generation. You need to pick a vector database and justify the choice against alternatives. You need to orchestrate LLM calls with retries, fallbacks, and cost controls. Agent memory adds another layer: short-term context windows, long-term persistence, and the retrieval logic that decides what the agent remembers. None of this is exotic if you already build RAG systems. The FDE twist is that you build it on a customer's stack, with their data, under their constraints.
Soft skills: discovery, communication, expectation management
Discovery means asking the right questions before writing code. What data does the customer have? What format is it in? What does "working" mean to them? Communication means explaining tradeoffs plainly: why a 95% retrieval hit rate might be good enough, why a vector database won't fix bad source data. Expectation management is the hard one. Customers want the demo to work perfectly on day one. It won't. You need to say what will break, when, and why, without losing their trust.
Skills you already have as a RAG builder — and gaps to close
You already have chunking strategies, embedding models, evaluation metrics, and failure mode intuition. Those transfer directly. The gaps are customer-facing reps: running discovery calls, writing scoping documents, presenting tradeoffs to non-technical stakeholders. You close those gaps by practicing, not by reading. The 90 day plan builds in that practice starting week seven.
[!tip] For RAG and agent memory builders, focus on demonstrating measurable improvements in retrieval accuracy and memory retention in your projects. Document before-and-after metrics to showcase impact during interviews.
90 Day FDE Learning Plan: A Step-by-Step Guide
- Weeks 1-2: Master RAG fundamentals by building a basic retrieval-augmented generation pipeline with a vector database.
- Weeks 3-4: Implement agent memory systems, including short-term and long-term memory, using frameworks like LangChain or LlamaIndex.
- Weeks 5-6: Develop a customer-facing RAG application with a focus on deployment, monitoring, and iteration.
- Weeks 7-8: Optimize RAG pipelines for latency and accuracy, and add memory persistence and retrieval strategies.
- Weeks 9-10: Build an end-to-end agent with memory that solves a real business problem, and document the architecture.
- Weeks 11-12: Prepare for FDE interviews by practicing system design, coding, and explaining your projects.
- Week 13: Review and refine your portfolio, and apply to FDE roles with your projects as evidence.

The 90 Day FDE Learning Plan: Weeks 1–4 (Foundations)
The first four weeks are about locking down your RAG fundamentals and starting agent memory work. You're not learning new concepts here. You're proving you can explain and rebuild what you already know under pressure. That's the FDE difference.
Week 1: RAG pipeline audit and baseline project
Start by auditing a RAG pipeline you've already built. If you don't have one, build a minimal one: chunk a document set, embed it, index it in a vector database, retrieve top-k, generate an answer. Use whatever stack you know. The point isn't novelty. It's having a baseline you can measure against for the next eleven weeks.
Write down every decision you made. Why that chunk size? Why that embedding model? Why cosine similarity instead of dot product? If you can't answer a question, that's a gap. Fix it before week two.
Deliverable: a working RAG pipeline plus a one-page decision log. Not a blog post. A private document you can reference in interviews.
Week 2: Vector database deep dive and chunking strategies
Pick two vector databases you haven't used. One managed, one self-hosted. Load the same dataset into both and compare retrieval quality, latency, and cost. You'll hit differences fast: index types, filtering support, metadata handling. Those differences matter when a customer asks why you chose Pinecone over Qdrant.
Chunking is where most RAG pipelines quietly fail. Test three strategies on the same source: fixed-size, sentence-based, and semantic. Measure retrieval hit rate for each. The honest answer is that no single strategy wins everywhere. It depends on document structure, query patterns, and embedding model. Your job is to know which tradeoff you're making.
Week 3: Agent memory architecture fundamentals
Agent memory splits into three layers: working memory (the context window), episodic memory (what happened in past sessions), and semantic memory (facts the agent has learned). Most tutorials blur these together. Don't.
Read the memory sections of at least two agent frameworks. LangChain and LlamaIndex both have memory abstractions. Compare how they handle persistence, retrieval, and eviction. Then write a one-page summary of what each layer does, what it stores, and when it fails. The failure modes are the part interviews test.
Week 4: Build a mini agent memory system
Build a small agent that remembers facts about a user across sessions. Keep it simple: a chat interface, a vector store for long-term memory, and a retrieval step that pulls relevant memories before generating a response. No fancy orchestration. No multi-agent setups.
The deliverable is a working system plus a written explanation of what breaks when memory grows. What happens at 10,000 stored memories? At 100,000? You won't solve those problems this week. You'll just know they exist, which is more than most candidates can say.
The 90 Day FDE Learning Plan: Weeks 5–8 (Integration & Evaluation)
Weeks 1–4 built the foundation. Weeks 5–8 shift from "can you build it" to "can you prove it works and ship it to someone." This is where most RAG builders stall. Evaluation feels academic. Deployment feels like ops. Customer work feels uncomfortable. Push through all three.
Week 5: RAG evaluation frameworks and metrics
Pick one evaluation framework. RAGAS is the most common starting point. LlamaIndex has built-in evaluators too. Don't build your own harness yet.
Measure four things on your week one pipeline: faithfulness, answer relevance, context relevance, and retrieval hit rate. Run the eval on at least 50 questions. You'll discover your pipeline scores worse than you assumed. That's the point.
Write down what each metric actually catches and what it misses. Faithfulness checks if the answer matches retrieved context. It doesn't check if you retrieved the right context in the first place. Interviews test that distinction.
Week 6: Deploy a RAG pipeline to production
Take your week one pipeline and put it behind an API. Add logging, rate limiting, and a basic retry loop. Use Docker. Deploy to any cloud provider.
The deliverable isn't the deployment. It's the runbook. Write down how you'd update the embedding model without downtime, how you'd roll back a bad index, and what you'd monitor. FDEs get asked these questions constantly.
Week 7: Customer discovery and technical scoping practice
Find a real person with a real document retrieval problem. Could be a colleague, a friend's small business, anyone. Run a 30-minute discovery call. Ask what they're doing today, what breaks, what they'd pay to fix.
Then write a one-page scope: problem statement, proposed solution, what's in scope, what's out, and a rough timeline. No code this week. The scoping document is the deliverable.
Week 8: Build a proof-of-concept for a hypothetical client
Take the scope from week seven and build a working prototype. Timebox it to 20 hours. The POC should solve one narrow problem well, not five problems badly.
Record a five-minute demo walking through the problem, the solution, and what you'd build next with more time. That recording becomes portfolio material. It also forces you to explain technical work to a non-technical audience, which is half the FDE job.
The 90 Day FDE Learning Plan: Weeks 9–12 (Interview Readiness)
Weeks 5–8 proved you can evaluate and ship. Weeks 9–12 turn that into a story you can tell in an interview room. The shift is from building to communicating.
Week 9: Portfolio project — end-to-end RAG with agent memory
Build one complete system. Not a tutorial clone. A RAG pipeline with persistent agent memory that solves a problem you can describe in one sentence.
The spec: a support assistant that remembers user preferences across sessions, retrieves from a knowledge base, and cites sources. Wire memory to the retrieval layer, not bolted on after. Deploy it. Write a README that explains the architecture, the tradeoffs you made, and what you'd change with more time.
Interviewers don't read code. They read the README and ask you to defend decisions. Make sure you can.
Week 10: Mock FDE interview loop practice
FDE loops differ from SWE loops. Expect a technical screen, a system design round, and a customer scenario round. Practice all three.
For the technical screen, rehearse explaining your week nine project in five minutes. For system design, practice whiteboarding a multi-tenant RAG deployment: tenancy isolation, index partitioning, cost controls. For the customer scenario, record yourself handling a vague requirement like "we need better search." Then watch the recording. You'll hear hedging. Fix it.
Do three mock interviews minimum. One with a peer, one recorded solo, one with someone non-technical.
Week 11: Soft skills drills and stakeholder communication
FDE interviews test whether you can talk to a customer without losing them or lying to them. Practice translating.
Take three technical decisions from your portfolio. Write a one-paragraph explanation for an engineer. Then rewrite it for a VP who doesn't care about chunking strategies but cares about cost and time to value. Then say it out loud.
Also practice saying "I don't know" followed by how you'd find out. That answer matters more than any technical detail.
Week 12: Final review and application strategy
Audit your portfolio against the job descriptions you're targeting. If a posting asks for evaluation experience and your portfolio doesn't show it, add it or pick a different posting.
Apply to ten roles. Not fifty. Tailor each application to the specific problem the company solves. Reference your RAG and agent memory work in the first paragraph.
Then stop preparing and start interviewing. The plan ends here. The reps begin.
Practical Projects for Your FDE Portfolio
A portfolio that shows RAG and agent memory work beats a list of skills every time. The projects below are specs, not tutorials. Each one forces a decision you'll have to defend in an interview.
Project 1: Customer support RAG with persistent agent memory
Build a support assistant for a real product's documentation. Pick something with messy docs: a SaaS tool, an API reference, a hardware manual. The mess is the point.
The system retrieves from the docs, answers the question, and stores what it learned about the user across sessions. If a customer says "I'm on the enterprise plan" in session one, session two should not ask again. Memory lives in a separate store, keyed by user ID, and the retrieval layer checks it before answering.
Measurable outcome: answer accuracy above 80% on a 50-question eval set you write yourself. Latency under two seconds. Memory persistence verified across five separate sessions.
The catch: writing the eval set takes longer than building the pipeline. That's the part interviewers care about.
Project 2: Multi-tenant RAG pipeline with evaluation dashboard
Take project one and make it multi-tenant. Three tenants, each with their own index, their own chunking strategy, and their own retrieval settings. One tenant uses semantic search. Another uses hybrid. The third uses keyword-only as a baseline.
Build a dashboard that shows retrieval quality per tenant: precision, recall, latency, cost per query. Not a fancy dashboard. A table with numbers.
Measurable outcome: you can explain why tenant A's precision dropped when you changed chunk size, and you have the dashboard to prove it. That explanation is the FDE skill.
Project 3: Technical discovery document for a hypothetical client
Write a five-page discovery document for a company that does not exist. Pick a real industry problem: a logistics company that wants RAG over shipment records, a legal firm that wants agent memory for case research.
The document covers: current state, proposed architecture, data requirements, evaluation plan, timeline, risks, and what you'd need from the client to start. No code. Just decisions and tradeoffs.
Measurable outcome: a non-technical reader can understand the proposal. A technical reader can find the holes. You can defend both in conversation.
This project is the one most engineers skip. It's also the one that most closely matches what an FDE does in week one on the job.
Common Mistakes in a 90 Day FDE Learning Plan
Most failed FDE transitions don't come from a lack of effort. They come from effort pointed the wrong way. Three mistakes show up again and again, and each one is avoidable if you catch it early.
Mistake 1: Building without evaluation
You build a RAG pipeline. It returns answers. You call it done.
That's not done. Without an eval set, you have no idea whether the pipeline is good or just looks good in a demo. You can't measure precision, recall, or latency. You can't defend your chunking choices in an interview because you never tested alternatives.
The fix: write the eval set before you build. Fifty questions, real answers, edge cases included. Then every change you make gets measured against that set. If the number doesn't move, the change didn't matter.
Mistake 2: Ignoring customer-facing practice
Engineers default to building. FDEs default to talking. The job is both, but the talking is what gets you hired.
If you spend 90 days on pipelines and zero days on discovery calls, you'll fail the interview loop. FDE interviews include role-play: a mock customer with a vague problem, and you have to scope it. Practice that. Write discovery questions. Record yourself answering stakeholder objections. It feels awkward. It's also the skill that separates FDEs from backend engineers.
Mistake 3: Trying to learn everything at once
Vector databases, chunking strategies, agent memory, prompt engineering, evaluation frameworks, deployment, sales, communication. The list is endless, and the instinct is to touch all of it every week.
That produces shallow knowledge across the board. You know a little about everything and can defend nothing.
The plan in this article sequences things for a reason. Weeks 1-4 are foundations. Weeks 5-8 are integration and evaluation. Weeks 9-12 are interview readiness. Stick to the week you're in. Depth on one thing beats breadth on ten.
What This 90 Day FDE Learning Plan Cannot Do
The plan is honest about its ceiling. It gets you interview-ready for FDE roles in RAG and agent memory. It does not make you a senior FDE, and it does not replace years of customer-facing deployment work.
You will not become a senior FDE in 90 days
Senior FDEs have shipped multiple production deployments. They've handled angry customers, broken pipelines at 2 a.m., and scoped deals that fell apart in procurement. That judgment comes from reps, not from a plan.
What you can build in 90 days is a defensible foundation: working RAG pipelines with evaluation, one agent memory system, and enough discovery practice to survive an interview loop. That's the target. Nothing more.
This plan does not cover enterprise sales or procurement
FDEs sit close to revenue, but this plan focuses on the technical and discovery side. You won't learn contract negotiation, security reviews, or multi-stakeholder procurement cycles here. Those skills matter in the role, but they're learned on the job, not from a 12-week self-study plan.
No plan guarantees a job offer
The market decides. This plan improves your odds by giving you specific projects and interview practice. It cannot control headcount, hiring freezes, or a bad interviewer. Anyone who promises otherwise is selling something.
Final Thoughts on Your 90 Day FDE Learning Plan
The plan works because it's specific. You're not watching tutorials or collecting certificates. You're building a RAG pipeline with evaluation, shipping an agent memory system, and running mock discovery calls. Those artifacts are what interviewers actually ask about.
Start week one today. Not Monday. Audit your current RAG pipeline and write down what breaks. That audit becomes your baseline, and every week after builds on it.
If you want a reference implementation for the agent memory pieces, GigaRAG's memory infrastructure is a practical example to study alongside your own builds. It's not required. But seeing how a production system handles persistence and retrieval will save you time in weeks 3 and 4.
The 90 day FDE learning plan is a framework, not a cage. Swap projects if you need to. Skip a week if work gets heavy. But don't skip the evaluation and discovery practice. Those are the two things most engineers never do, and they're the two things FDE interviews test hardest.
Start the audit. You'll know within a week whether this path fits.
Frequently Asked Questions
How much does FDE Academy charge?
FDE Academy pricing varies and may change; check their official website for current fees. This 90-day plan is self-directed and does not require paid courses.
What skills are required for FDE?
FDE roles typically require strong software engineering, system design, and customer-facing skills. For AI-focused FDEs, expertise in RAG pipelines, agent memory systems, and deployment is essential.
How do you become an FDE?
Becoming an FDE involves building a portfolio of deployed projects, often in AI infrastructure like RAG and agent memory. This 90-day plan provides a structured path to gain those skills and prepare for interviews.
Can I complete this 90-day plan while working full-time?
Yes, the plan is designed for 10–15 hours per week, which is manageable alongside a full-time job. Consistency is key; adjust the pace if needed.
What projects should I build for an FDE portfolio?
Focus on end-to-end RAG applications and agent memory systems that solve real problems. Include measurable outcomes like improved retrieval accuracy or reduced latency.
Is 90 days enough to become an FDE?
90 days can make you interview-ready if you already have software engineering experience. However, becoming a fully independent FDE takes longer; this plan gives you a strong foundation.
About GigaRAG
GigaRAG is for agent memory and RAG pipeline builders. get this right. Whether you are working through 90 day FDE learning plan or something adjacent, we publish what we have actually tested, including where it falls short.


