You obviously know there is a huge demand for forward-deployed engineers right now, and a lot of people are truly confused about what sort of projects they should be working on, which makes them a better fit for this role. So, if your portfolio has PDF chatbot, or travel planner, or a generic multi-agent research assistant, you have proved that you can follow AI tutorials, but you have not quite proved that you can actually do forward-deployed engineering. That distinction matters because an FDE is really hired to build clever demos in isolation. The job of an FDE is to walk into a messy customer environment, understand their workflows, connect with their systems that were never really designed to work together, and make that AI reliable enough for the stakes involved, and actually get that solution to production. So, in this video, I'm going to give you five portfolio projects that actually demonstrate these abilities, and along the way you're also going to learn a lot from it. Now, for every project, I'll explain the customer problem, what you should build, what makes the project technically credible, and specific forward-deployed engineering signal it sends to a hiring manager. I also want to be very clear about one thing. You do not need to build all the five of them. Just two projects done well, documented properly, and I would highly recommend just build it in public, which means that you can share it on GitHub, LinkedIn, X, or whatever your platform of choice is. That'll actually do far more than just five half-finished repositories. Now, if you're new to my channel, hi there. I'm Ashwatha Srinivas, and I've worked in the machine learning and AI space for over a decade. I spent my time at companies like Google, Microsoft, and IBM. I recently quit my full-time job to actually work on my own AI startup. While I'm doing that, I also love teaching people, and that's what I'm doing here. Now, before we get into the projects, let me define the role properly. So, the current FDE job descriptions for companies like OpenAI or Google actually describe it as an embedded builder who owns discovery, technical scoping, system design, implementation, debugging, and production rollouts alongside the customer, which simply means this: your portfolio has to prove four things. First, that you can discover the real problem instead of accepting the first feature request that the customer might give you. Second, you can build across the stack including the models, the APIs, the data, the permissions, and deployment. The third thing is that you understand production AI needs including evaluations, observability, security, and human approval boundaries. And the fourth thing is that you can connect technical systems to a measurable business outcome. Now, use that as the filter for every single project. Don't begin with I want to use LangGraph or I want to use this new model. Begin with a customer, a broken workflow, a constraint, and a success metric. The technology is just a tool to fix it. Now, let's start with the first project. The first one that I want you to do is a permission-aware enterprise knowledge system. Sounds complicated, but it's pretty simple. I'm deliberately not calling it a PDF chatbot. Now, imagine a B2B software company where account managers actually need answers from project documentations and support tickets or call transcripts, internal policies, or even Slack exports. A person should be able to go to this AI agent and ask something like, "What did we promise to the customer and has the product team committed to a delivery date?" And the system in this case needs to return a grounded answer with citations while making sure that the person only sees information that they're authorized to access. And maybe also give them warning that certain information is confidential and should not be shared with the customer. So, how do you really build this? Here's the workflow. You ingest the data from at least three different source types. You parse it and chunk it. Attach the metadata such as source, account, department, timestamp, as well as access level. Now, at query time, you're actually authenticating the user. You filter the retrieval based on their permissions. Then, you run hybrid search, rerank the result, generate a cited answer, and then log the trace. Technically, the important part is permission-aware retrieval. Now, if you're not familiar with RAG in general, which is retrieval-augmented generation, I had recorded a previous video on RAG explain. So, go check that out and then Then can come back to this video. Now, in this permission-aware retrieval system that you're building, the model should never receive a chunk the user is not allowed to use. So, filtering the answer after generation is too late because the sensitive context has already entered the model call. Once you build this, then you need to build an evaluation set. So, create at least 50 questions across easy lookups or cross-document synthesis or conflicting sources or stale information and questions that the system should refuse to answer. This is basically called a golden data set which you're going to be using to evaluate the system. So, what you do is measure retrieval quality separately from the answer quality. Both of these metrics are different. If retrieval failed, changing the prompt is not going to fix that system. So, you need to basically evaluate the retrieval side of it and generation side of it separately and then fix whatever is breaking. Also, if you want to go deeper into AI eval, I've recorded another video on that as well. I'll add all of those in the description below. Now, the FD signal here is that you understand the enterprise data is fragmented and permissions are actually part of the architecture. And a good-looking answer is not the same as a trustworthy system. Now, how do you really make this use case your own? You need to choose a domain that you understand. Let's say for legal work, you can track clause versions and document authority. For healthcare, you can actually include access controls and redaction. For developer tools, you can actually combine documentation, GitHub issues, support tickets, and other release notes. What I would recommend is add one realistic constraint such as a source that updates every hour or a document that becomes inaccessible when a user role actually changes. That's going to give you a very, very good understanding on how to build these systems at enterprise level. Now, let's get to project number two. Project two is an intake to resolution workflow for things like support, IT, security, review, HR, or vendor onboarding. Now, understand this. Every company has a front door where messy requests arrive. Somebody's actually going and reading the request, figuring out what it means, they're checking the customer or the employee context, and deciding how urgent it is, and routing it to the next person. Now, that workflow is actually perfect for demonstrating agentic AI systems because the output is a decision and an action, rather than just a chat response. So, my recommendation is that build the system as an explicit workflow. A request arrives through a form, email, or a ticketing API. The system extracts the structured fields, looks up a relevant context, classifies the request, checks the policy, and chooses one of the four paths, either asking for a missing information, drafting a response, routed to the correct team, or escalated to a human. In this case, use structured outputs for fields such as category, urgency, confidence, policy basis, owner, and next action. This will actually teach you how to use structured outputs as part of model output. Then, keep deterministic policy checks outside the model. So, if a security ticket contains a known severity one signal, that escalation should not depend on whether the model happens to reason correctly that day or not. This is also when you should show state and human in the loop properly. A person needs to be able to pause the workflow, edit the proposed action, approve it, and then resume from the same state. LangGraph is actually a reasonable choice in this case if you genuinely need branches, checkpoints, and resumability. Now, if the flow is fixed and simple, ordinary application code is completely fine. You know, choosing a smaller abstraction or a cleaner way to build this is a senior engineering signal. Complex is not always better. Now, for evaluating the system, you need to replay a historical or a synthetic ticket set. Measure what the routing accuracy looks like, where the false escalations happen, are there going to be any missed escalations, is there any total call success, and the percentage of cases that requires human intervention. Then, inspect the failures by each of these categories. The FD signal in this project is that you can turn ambiguity into a reliable operational workflow. You're also showing that you understand where AI judgment is useful and where policy code or a person needs to remain in control. In most of the enterprise use cases, human in the loop is critical. So, by doing this project, you're actually upskilling yourself in order to design these workflows. Now, let's get to project number three. Project three could be a document intelligence and approval system. So, you can start with something like an invoice approval, contract review, insurance claim, or a clinical prior authorization. Pick one document workflow with real consequences. So, let us use the invoice approval in this case. The system receives an invoice, extracts the field into a layout-aware way, validates the vendor and the line items, matches the invoice against a purchase order, applies the company's approval policy, and then sends exception to a reviewer. Now, every decision should be explainable and auditable. The key design principle is to separate probabilistic work from deterministic control. A model can extract a vendor name from an ugly scan or info which line item maps to a purchase order. The code should be able to verify the totals, check tolerances, detect duplicates, and enforce approval thresholds. But, a human should always be in the loop to approve low-confidence or high-value exceptions. And do not stop at extraction. The business value is in the match and the decision. So, build a two-way match between the invoice and the purchase order. If you want to go deeper, you can actually add a three-way match with a goods receipt. Then, create a failure case such as duplicate invoice or having a changed bank account or a missing purchase order or mismatched quantity or any unreadable field. Now, in this case, your evaluation should actually operate at different Things like field extraction accuracy, match accuracy, exception recall, false approvals, latency, as well as estimated review time saved. A system that extracts 98% of the fields can still be dangerous if the missing 2% contains the bank account or total amount. The FTE signal in this one is that you can build inside a high-stakes workflow, integrate AI with systems of record, design accountability, and quantify value in terms the customer actually cares about. Now, let's get to project number four. Project four is going to be about customer data onboarding and integration pipeline. I think this is one of the most relevant FDA projects because a surprising amount of deployment work is data mapping, API integration, validation, and handling exceptions that nobody mentioned during the sales process. Now, imagine you work for a risk platform and a new enterprise customer needs to send data from its CRM, billing system, and support platform into your product. Their schema do not match with yours. The fields could be missing, the customer IDs are inconsistent, and dates arrive in three different formats. And even the documentation could be incomplete. So, what you need to do is build a small onboarding portal where a customer can go and upload a sample file or connect a mock API. The system profiles the data, proposes a mapping into your own canonical schema, explains uncertain mapping, and asks for confirmation. Now, after approval, deterministic validation check types, required fields, referential integrity, duplicates, and business rules, valid records move forward. Invalid records enter an exception queue with a clear reason and suggested fix. The model that you're going to be using here can help you interpret the column names and generate transformational suggestions. It should not silently rewrite the customer data. So, keep that proposed mapping reviewable and versioned. If the source schema changes later, you need to detect the drift and show exactly which mapping broke. What I would recommend is expose the pipeline through an API, add item potency so retrieves do not create duplicates, and create deployment with logs and alerts. Then just document how you would move from a sample environment to a customer's private cloud or VPC. Now, for the evaluations part, create several intentionally messy source schemas and measure mapping accuracy, validation coverage, correction rate, and time to complete onboarding. Include one mid-project change request, such as customer adding a new required field. Then show how your architecture absorbs the change without a complete rewrite. The FDA signal that you get from this particular project is very strong. It is that you can work with incomplete requirements, integrate real systems, protect data quality, and adapt when the customer changes the problem. Now, the fifth and the last project. In this project, you're going to be building a operations command center with an action loop. So, pick one function such as support operations, infrastructure reliability, sales pipeline, fraud, or marketplace supply. The system should answer three questions every morning. What changed? Why does it matter? And what should somebody do next? Let's look at a support operations example. Let's say you ingest a ticket volume, you ingest the backlog, response time, escalations, SLA misses, and customer sentiment. You're going to be using SQL and Python to compute the metrics. Then you use statistical methods such as moving average, thresholds, or change point detection to identify any sort of anomalies. Now, only after the system has computed the facts, should the model explain what changed and identify likely contribution segments and propose an action. This separation really matters. The model should narrate the truth, not calculate the truth. Do not hand it 10,000 rows and ask it to tell you weekly SLA rate. Compute the numbers in code, pass the results with provenance, and require every claim in the narration to point back to a metric. Then close the loop. Let the user drill into the accounts, regions, and queues that move that number. Give them the option to draft a Jira ticket, create an investigation, or send an internal update. Keep the final action behind a human approval. Now, in this particular system, you need to evaluate whether the system found the correct anomalies, attributed them to the correct segment, cited the correct metric, and avoided claims that the data did not support. You should actually add observability for model calls, tool errors, latency, as well as cost. If you can replay a month of data and show how the system would have behaved, even better. Now, the FD signal that you're actually giving away here is that you know when to use models, when to use conventional software, and how to move from inside to an operational outcome. Now, let's talk about how to make any of these projects actually look like an FDE work instead of yet another GitHub demo. So, this is what you need to do. Start with a one-page discovery brief. Hypothetically name the customer, the users, the current workflows, the pain point, the systems involved, and the constraints as well as the success metric. You can totally create a fictional customer, but make the environment believable. Another thing that you can actually go and do is read about a customer case study. You can find plenty of them online. Hypothetical is okay, but be very detailed. If you're going to write something like a support team wants an AI agent, that's too vague. Rather have a problem statement something like this. A 20% support team manually triggers 800 tickets a week across three product lines, and priority mistakes are causing SLA breaches. This gives you something that you can actually design against. Next, show the architecture and the tradeoffs. Explain why you use retrieval, a workflow graph, a rules engine, or a queue. Explain what you deliberately did not automate. Explain how identity, permissions, retries, and failure mode actually move through the entire system. Then, build one complete vertical slice. I would rather see one workflow go from input to production-like output than six beautiful screen with mocked-up back-end logic. You can totally use a boring stack if you need one. Say Python, FastAPI, Postgres, a queue, and one model provider, and the smallest orchestration layer that fits your problem. Then, deploy it somewhere. Add logs to it, write a runbook, make another person be able to use it without you sitting next to them. Your evaluation section should also include real test cases and failure analysis. Show what happened when the source was stale or the model returned an invalid structure or a tool called timed out or a user lacked permission or even a request was outside the policy. Then, show what the system did about it. Finally, package that entire communication stuff. Your readme should be answering six questions. Who is the customer? What was broken? What did you build? How does it work? How did you evaluate it? And what would you change before production? And you know what can make it even better? Record a 3-minute demo that begins with the business problem, show the workflow, include one failure case, and actually don't spend the first minute reading your architecture diagram. Walk them through the build. And please, oh please, build in public. Share the discovery brief, share your architecture decision, share any evaluation failure that forced you to change the system. That trail of thinking is often more valuable than the finished launch post. Because it really shows how you work. And trust me on this when I say build in public, it is not about getting 500 likes on your post. It is about five right people who see your post and identify your skill set. And please, please, please trust me, there are ample amount of hiring managers and recruiters out there just going through LinkedIn trying to find the best candidate for the role that they're hiring for. FDE roles is not easy to hire for. So, if you truly want to be an FDE, building in public can actually get you there. Now, one more thing about AI coding tools that I wanted to mention. I would say use Codex or any other coding agent to accelerate your implementation, review your architecture, generate these kind of tests, and help you debug. Don't ask it to make every product and technical decision while you watch. In an interview, you actually need to explain why the workflow has these boundaries, why the evaluation measures those failures, and what you would do when the customer requirement changes. If you cannot explain those decisions, the repository is not going to come and save you. Now, if you're deciding where to begin, build project one and project two first. Together, they actually cover retrieval, permissions, tool use, state, human approvals, and evaluations. Then choose one domain project that matches the company that you want to join. See, if you're targeting financial services or healthcare, choose a document approval system. If you want to show strong integration and deployment skills, choose customer data onboarding. If you enjoy analytics and operations, choose the command center one. What I would say is two deep projects with a clear customer story are more than enough for you. The main thing that I want you to take away is that FDE portfolio is not a collection of AI features. It is an evidence that you can take an ambiguous customer problem through discovery, design, implementation, evaluation, and roll out. Pick one workflow that you understand, write the discovery brief before you write the code. Build the smallest complete solution. Measure when it fails, then explain the business value in plain language. If this is a kind of engineering that you want to learn more deeply, my co-founder Arvind and I are actually building Gen Academy. Our mission is to empower the next generation of AI builders. And our focus is actually to train you on AI engineering. We are going to be hosting a deep dive masterclass on AI for forward deployed engineers on 13th September. If you want to become an FDE and upskill yourself for the role, do check out the workshop details in the description below. And from this video, if you're actually going to be building any of these projects, please do tag me on LinkedIn. I would genuinely love to see the workflow that you chose and the decisions that you made. And I would love to actually amplify your posts. And maybe it actually reaches the right hiring manager. >> >> Also, if you want more practical, technically grounded videos on building with AI, do subscribe to my channel. Awesome. I'll see you in the next one.