Don't learn AI Agents without Learning these Fundamentals transcript

A lot has been going on with AI over the past few years. Prompt engineering, context, windows, tokens, embeddings, rag, vector DB, MCPS, agents, lang chain, langraph, claude, Gemini, and more. If you felt left out, this is the only video you'll need to watch to catch up. In this video, we assume you know absolutely nothing and try to explain all of these concept through a single project so that by the end of it, you go from zero to gaining an overall understanding of everything that's going on with AI.

We'll start with AI fundamentals, then move on to rag, vector DB, lang chain, langraph, MCP, prompt engineering, and finally put it all together with a complete system. Let's start with the basics. When you ask an AI model a question, it's typically answered by a subset of AI called large language models. Large language models have gotten popular right around when Chachib was released in late 2022 when we started to see language models get larger in size because of their obvious benefits in performance.

So let's dig a bit deeper to understand how large language models are able to process requests that we send. Popular LLMs like OpenASGPT, Enthropics Claude, and Google's Gemini are all transformer models that are trained on large sets of data. The size of training tokens can go up to tens of trillions of tokens that are used to train these models. And the training data includes data from thousands of different domains like healthcare, law, coding, science, and more.

But when we work in TechCorb, the 500 GB of data that we have aren't part of the training data that was used to train the model, which means that in order for us to use the LLMs to ask questions about the TechCorp's internal documents, we need the ability to pass in data to the LLM. One of the ways that we can pass the data into the model is by adding them to the conversation history functions like a short-term memory where during the duration of the conversation, all of this context is kept in memory.

And this memory is called the context window. Context windows are measured in tokens which is roughly 3/4 of a word for English text. The context window is typically limited in size and the upper limit varies depending on the model. Some models like XAI GO 4 have 256,000 tokens whereas Enthropics Cloud Opus 4 has 200,000 tokens and Google's Gemini 2.5 Pro has 1 million tokens. So as you can see the total upper bound for how much context can be stored for each model can vary.

While the context window plays an important role in storing them in memory, there are practical limitations in how LLM treats what's inside the context window. For example, if I asked you to memorize the pi digits 3.141592653589791 and asked you to recite it, some of you might have a hard time committing that many numbers all at once, which is similar to how LLM's context window works. So therein lies the current limitations in LLM.

How much context can it hold in a given time? This can vary depending on model to model. For example, a lot of nano, mini, and flash models can have very small context windows in the size of 2,000 to 4,000 tokens, which amounts to about 1,500 to 3,000 words. Conversely, bigger models like GPT4.1 and Gemini 2.5 Pro offer context windows up to 1 million tokens, which is equivalent to roughly 7,500 words or 50,000 lines of code.

So, as you can see, choosing the right model for the task can be very important. For example, if you downloaded a novel in a txt format and you wanted to change the script, choosing a model that offers a large context window would be best. Conversely, if you are working on a small document and require very low latency, meaning faster responses, using flash and nano variants would be best. Here's another angle to look at when it comes to memory in LLMs.

Let's say I ask you this question. Sally and Bob own an apple farm. Sally has 14 apples. Apples are often red. 12 is a nice number. Bob has no red apple, but he has two green apples. Green apples often taste bad. How many apples do they all have? This might require you to think about the problem a little bit to get to the final answer, which is 16. That's because the context here includes information that is completely irrelevant to the question, which is to count how many apples they have in total.

The fact that apples are red or green or how it tastes have nothing to do with the total number of apples that they have because they either have the apple or they don't. Now that we have a grasp on what context window provides, Techorp's 500 GB of documents, this creates an immediate problem. Even the largest context window, like Gemini 2.5 Pro's 1 million tokens, can hold only about 50 files of typical business documents all at once.

We need our AI model to understand all 500 gigabytes, but it can only see a tiny fraction at a given moment. This is where embedding comes in, and they're absolutely crucial to understand. Embeddings transform the way we think about information. Instead of storing text as words, we convert meaning into numbers. The sentence employee vacation policy and staff time off guidelines use completely different words, but they mean essentially the same thing.

Embeddings capture that semantic similarity. And here's how it works. An embedding model takes a text and converts it into a vector. Typically, 1536 numbers that represent the meaning. Similar concepts end up with similar number patterns like vacation and holiday will have vectors that are mathematically close to each other. For TechCorb, this means that we can find relevant documents based on what someone means, not just the exact word that they've used.

When an employee asks, "Can I wear jeans to work?" Our system will find the dress code policy, even if it never mentions the word jeans specifically. Now that we understand how LLMs and embeddings work, we will need a system that ties everything together. In our case, Tech Cororb needs a chatbot where customers can ask questions about the company policy, product information, and support issues. The chatbot needs to remember conversation history, access the company knowledge base, and handle complex multi-step interactions.

Your first instinct might be to use OpenAI's SDK to build a quick chat interface. But you quickly realize that there are massive missing pieces. Storing chat messages, maintaining conversation context, connecting to Tech Corp's internal knowledge base, and handling the possibility that the company might switch from OpenAI to Anthropic or Google in the future. And now what seemed like a simple project becomes a massive undertaking.

While you can write your own implementation to connect them, there's already a wellestablished abstraction layer called langchain. Langchain is an abstraction layer that helps you build AI agents with minimal code. It addresses all those pain points using pre-built components and standardized interfaces. But first, let's understand the crucial difference between an LLM and an agent. When you use large language models like GBT, Claude and Gemini directly, you're using them as static brain that can answer question based on their training data.

An agent on the other hand has autonomy, memory, and tools to perform whatever task it thinks that is necessary to complete your request. For TechCorp's customer support scenario, imagine a customer asks, "What's your company's policy on refunding my product that arrived damaged?" An agent will self-determine how it should answer that request based autonomously instead of traditional software that requires conditional statement that determines how a program should execute.

Langchain comes with extensive pre-built components that handle the heavy lifting for Techorp Chatbot. Langchain chat models provide direct access to LLM providers. Instead of writing custom API integration code, you can set up OpenAI with open bracket model equals GPT3 turbo. So if the requirements change to use enthropic instead, you simply change one line LLM equals chat enthropic open bracket model equals claw 3 sonnet.

This same pattern applies to every other capability techp needs. Memory management uses memory saver to automatically store and retrieve chat history, which means there's no need to build your own database schema or session management. Vector database integration works through standardized interfaces. Whether you choose Pine Cone or Chroma DB, Langchain provides consistent APIs and we'll go through what a vector database is in the next couple chapters.

For text embedding, it uses OpenAI embeddings or similar components to convert Tech Corp's document into vector representation. The embedding process becomes a single function call instead of managing API connections and data transformations manually. Finally, tool integration allows the agent to access external system. So if you need to query Tech Corp's customer database, you can simply create a tool that the agent can call when it determines customer specific information is needed.

Without lang chain, you would need to build all of this infrastructure yourself. API management for multiple LLM providers, vector databases, SDKs, embedding pipelines, semantic search logic, state management, memory system, and tool routing. The complexity grows exponentially. Lang chain's component library includes modules like chat anthropic API connections. Chromad vector database operations, OpenAI embeddings for texttoveector conversion, memory saver for chat history management, custom tool definitions for external system integrations.

The agent orchestrates these components based on the conversation context. So as we're talking about tech corp depending on what the question is asked the agent will now use the given tools like vector databases as well as the context it built from conversation memory and the system prompt written in API layer autonomously handle your request and you can extend the agents abilities beyond this example by using other pre-built tools that lang chain offers like custom database access web search local file system access and more.

Now that we covered the conceptual elements of lang chain, let's look at how it looks like on a practical level. We can look over at this lab specifically geared towards how to use lang chain. All right, let's start with the labs. In this lab, we're going to explore how to make your very first AI API calls. The mission here is to take you from absolute zero to being able to connect, call, and understand responses from OpenAI's APIs in just a few progressive steps.

We begin by verifying our environment. In this step, we're asked to activate the virtual environment. Check that Python is installed. Ensure the OpenAI library is available and confirm that our API keys are set. This is important because without this foundation, nothing else will work. Once the verification runs successfully, the lab will confirm that the environment is ready. Next, we take a moment to understand what OpenAI is.

Here we're introduced to the company behind chatbt and their family of AI models including GBT4, GBT4.1 Mini and GBT 3.5. The narration highlights that we'll be working with the Python OpenAI library which acts as a bridge between our code and OpenAI server. With that context set, we move into task one. In this task, we're asked to open up a Python script and complete the missing imports. Specifically, we need to import the OpenAI library and the OS library.

After completing these lines, we run the script to make sure that the libraries are properly installed and ready to use. If everything is correct, the program confirms that the import worked. From here, we transition into authentication and client setup. Here, the lab explains the importance of an API client, an API key, and the base URL. The API key works like a password that identifies us and grants access, while the base URL defines the server location where requests are sent.

This prepares us for task two. In task two, we open another Python script and are asked to initialize the client by plugging in the correct environment variables. This involves making sure we pass the OpenAI API key and OpenAI API base. Once those values are filled in, we run the script to verify the client has been properly initialized. If done correctly, the script confirms the connection to OpenAIS servers. Once the setup is complete, we move on to the heart of the lab, making an API call.

Before jumping into it, we learn what chat completions are. This is OpenAI's conversational API where we send messages and receive messages just like a chat. Lab explains the three roles in a conversation. System, user, and assistant, and how the request format looks like in Python. That takes us into task three. Here we open the script, uncomment the lines that define the model, role, and content, and then configure it.

So the AI introduces itself. Once we run the script, if all is correct, the AI should respond back with an introduction. This is the first live call to the model. Next, we're guided into understanding the structure of the response object. The lab breaks down the response path, showing how we drill down into the response, choices, message content to extract the actual text returned by the AI. Although the response object contains other fields like usage, statistics, and timestamps, most of the time what we really need is the content field.

That brings us to task four, where we're asked to update the script to extract the AI's response using the exact path. Running the script here confirms that we can successfully capture and display the text that the AI returns. Once we've mastered making calls and extracting responses, the lab shifts gears to tokens and costs. We learned that tokens are the pieces of text used by the model that every request consumes tokens.

Prom tokens are what we send in. Completion tokens are what the AI sends back and total tokens are the sums of both. Importantly, output tokens are more expensive than input tokens. So being concise can save money. Finally, in task five, we're asked to extract the token usage values, prompt completion, and total tokens from the response. The script is already set up to calculate costs. So once we complete the extraction and run it, we can see exactly how much the API call costs.

The lab wraps up by congratulating us. At this point, we verified our environment, connected to OpenAI, made real API calls, extracted responses, and calculated costs. The key takeaway is remembering how to navigate the response object with response.content. Some of the finer points and details like exploring usage fields or playing with different models are left for you to explore yourself. But by now, you should have a solid foundation for working with AI APIs and be ready for what comes next in the upcoming labs.

All right, let's start with the labs. In this lab, we're going to explore Lang Chain and understand how it makes working with multiple AI provider simpler and faster. The key idea here is that instead of being locked into one provider's SDK and rewriting code whenever you switch, Langchain offers one interface that works everywhere. With it, you can move from OpenAI to Google's Gemini or XAI's Gro by changing just a single word.

We begin the environment verification. In this step, we're asked to run a script that checks whether Langchain and its dependencies are installed, validates our API keys and our base URL, and confirms that we have access to different model providers. Once this check passes, we're ready to start experimenting. The first test compares the traditional OpenAI SDK approach with Lang. We have to write 10 or more lines of boilerplate code just to make an API call.

If we want to switch to another provider, we'd have to rewrite all of it. With Langchain, the same logic is cut down to just three lines. And switching providers is as simple as changing the model name. In this task, we're asked to complete both versions in a script and then run them side by side. This is where we really see the 70% reduction in code. The second task demonstrates multimodel support. Here we're asked to configure three providers.

Open GPT4, Google's Gemini, and XAS Gro, all with the same class and structure. Once configured, we can run the exact same prompt through all of them and compare their responses. This is especially powerful when you need to do AB test or balance cost because you can evaluate multiple models instantly without changing your code structure. In the third task, we're introduced to prompt templates. Instead of writing separate hard-coded prompts for every variations, we create one reusable template with placeholders.

Then we can fill in the variables dynamically just like fstrings in Python. This eliminates the nightmare of maintaining hundreds of slightly different prompt files. After completing the template, we test it with multiple inputs to see how the same structure generates varied responses. The fourth task takes a step further by introducing output parsers. Often AI responses are just free text, but what our code really needs are structured objects.

Here we're asked to add parsers that can transform responses into lists or JSON objects. In this way, instead of dealing with unstructured sentences, we can access clean Python lists or dictionaries that our application can use directly. Finally, we reach task five, which is all about chain composition. Langchain allows us to connect components together with pipe operator. Just like Unix pipes, instead of writing multiple variables for each step, creating a prompt, sending it to the model, getting a response, and parsing the result, we simply chain everything together.

With one line, we can link prompts, models, and parsers, and then invoke the chain to get the structure output. It's a much cleaner and more scalable way to build AI pipelines. By the end of this lab, we've learned how a lane chain reduces boiler plate, enables multimodel flexibility, creates reusable templates, parses structured outputs, and ties everything together with elegant chaining. Some of the finer details like experimenting with more complex parser setups or chaining additional steps are left for you to explore on your own.

Now, we come to the technique, but it's not a technique in the sense of building lane chain application like we just did. No, we're talking about a technique that involves how you send your prompt to the agent that we just built. In other words, prompt engineering. When you send a prompt as an input to TechCorps AI document assistant that we just built, the quality of your prompt directly impacts the quality of responses you receive.

While AI agents can certainly handle wide range of prompts, understanding prompt techniques help you communicate more effectively with TechCorp system. For example, if you prompt the agent with this question, "What is the policy?" It can pull a lot of details that are irrelevant. Sending a more specific prompt like, "What's the company's remote work policy for international employees?" will lead to a more accurate result from the agent.

And the same thing applies to role definition when you're describing the role of the agent. For example, you might descriptively write out a detailed prompt like, "You are a tech customer support expert." When you are asked about the company's policy, you are to always respond with bullet points for easier readability. As you can see, being able to control the agents behavior can directly benefit from a well-written prompt.

This type of technique is referred to as prompt engineering. And there are different prompt techniques like zeroot, oneshot, fshot, and chain of thought prompting have its own use case for the task. For example, zerootshot prompting means that we are asking AI to perform a task without providing any examples. So if you send a prompt, write a data privacy policy for our European customers, you're essentially relying entirely on the AI's existing knowledge base to write the data policy document.

Since within the prompt, we're not giving any examples of what they are. Oneshot and few shot prompting is similar to zerootshot but in this case we're providing examples of how the agent should respond directly within the prompt. For example, you might say here's how we format our policy documents. Now write a data privacy policy following the same structure because you provided a template. The AI follows your specific formatting and style preferences more consistently.

And conversely, fusart learning is the act of learning from the LLM side where even though the LLM might not have seen the exact training data for how to process your unique request, it's able to demonstrate the ability to fulfill your request from similar examples provided. And finally, chain of thought prompting is a style of prompting where you provide the model with a trail of steps to think through how to solve specific problems.

For example, instead of prompting the AI agent with fix our data retention policy, you might instead use chain of thought prompting to say here's how you fix data retention policy. Review current GDPR requirements for data retention periods. Then analyze our existing policy for specific gaps. Then research industry best practices for similar companies. And finally, draft specific recommendations within implementation steps.

Now fix our customer policy. As you can see, providing how LLM should go through in breaking down a specific request for how data retention policy should be fixed gives an exact blueprint for how the LLM should then go and fix the customer policy, which in this case, we're not explicitly telling the agent how to fix the policy for that, but it gives the reasoning steps for the model to fix accordingly. So, in this lab, we're going to master prompt engineering using lane chain.

The main problem being addressed here is that AI can sometimes give vague or inconsistent responses or not follow instructions properly. The solution is to use structured prompting techniques, zero shot, one shot, viewshot, and chain of thought. Each of which controls the AI's behavior in a different way. We begin by verifying the environment. The provided script checks that lang chain and its OpenAI integrations are installed, confirms that the API key and base URL are set and ensures that prompt template utilities are available.

Once this verification passes, we're ready to move into tasks. The first task introduces zero prompting. In this exercise, we're asked to compare what happens when we provide a vague instruction versus when we write a very specific prompt. For example, simply asking the AI to write a policy results in a long generic essay. But when we specify write a 200word GDPR compliant privacy policy for European customer with 30-day retention period, the response is focused, useful, and aligned to the constraints.

This demonstrates why being specific is crucial in zero shot prompts. The second task moves us to oneot prompting. Here we provide one example for the AI to follow almost like showing a single template. For example, if we gave the AI one refund policy example with five structured sections, we can then ask it to produce a remote work policy and it will replicate the same style in structure. This shows how one example can set the tone and ensure consistency across many outputs.

Next, in task three, we expand on this with few shop prompting. Instead of one example, we provide multiple examples so the AI can learn not only the format but also the tone, patterns, and style. For example, giving three examples of emphatic support replies teaches the model how to handle customer support issues consistently. Once the examples are in place, the AI can generate new responses that follow the same tone and structure, making it especially powerful for use cases like customer service.

In task 4, we're introduced to chain of thought prompting. This technique encourages the AI to show its reasoning step by step. Instead of vague oneline answer, the AI breaks a problem into steps and works through it systematically. This results in clear or more reliable and more accurate outputs, particularly for complex reasoning tasks. Finally, task 5 brings all of these techniques together in a head-to-head comparison.

We run the same problem through zero shot, one shot, few shot and chain of thought prompts to see the difference. Each approach has its strength. Zero shot is quick. One shot ensures formatting. Few shot enforces tone and consistency and chain of thought excels at detailed reasoning. The outcome shows that choosing the right technique can dramatically improve results depending on the task. By end of this lab, we not only learned what each prompt method is, but we've also seen them in action.

The key takeaway is that the right technique can make your prompts 10 times more effective. Some of these exercises are left for you to explore and refine. But now you have the foundation to decide whether you need speed, structure, style, or reasoning in your AI responses. That wraps up this narration. And with it, you're now ready to move on to the next lab onto vector databases and semantic search. Let's do a quick recap of what we just built.

We learned about what LLM is and how LLMs use what's inside the context window. After learning about LLMs, we wanted to solve Tech Corp's business requirements of searching for 500 GB worth of data. In order to do that, we determined that embedding is a good way to search a massive set of documents. After that, we went over Langchain and what functions they serve, which is that they allow us to easily build Gentic application like Tech Corps chatbot.

So now that we have the lang chain application, we need to be able to search through these large sets of documents. Let's say inside the 500 GB of documents, your company has a document called employee handbook that covers policies like time off, dress code, and equipment use. Employees might ask terms like vacation policy, but miss time off guidelines. While these are common questions that people would typically ask, building a database around this requirement can be tricky.

In a conventional approach where data is stored in a structured database like SQL, you typically need to do some amount of similarity search like select all from documents content like vacation or vacation policy with a wild card before and after to look for details about questions on holiday. To expand your result set, you might increase the scope by adding VA or VAC space P. However, the drawback to this approach is that it puts the onus on the person searching for the data to get the search term formatted correctly.

But what if there was a different way to store the data? What if instead of storing them by the value, we store the meaning of those words? This way, when you search the database by sending the question itself of can I request time off on a holiday based on the meaning of those words contained in the question, the database returns only relevant data back. This is a spirit of what vector databases tries to address storing data by the embedding.

So essentially instead of searching by value, we can now search by meaning. Popular implementation of vector databases include pine cone and chroma. These platforms are designed to handle embeddings at scale and provide efficient retrieval based on semantic similarity. And these are also great use cases for prototyping something quick. While conceptually this seems straightforward, there's a bit of an overhead in setting this up.

And you might be asking, well, can we just throw the employee handbook into the database like we just did for SQL database? Not quite. And here's why. With SQL database, the burden is put on the user searching to structure the database. But with vector databases, the burden is put on you who is setting up the database since you are trying to make it easier for someone searching for the data. And you can imagine why a method like this is becoming extremely popular when paired with large language models in AI since you don't have to train separately on how LLM should search your database.

Instead, the LLM can freely search based on meaning and have the confidence that your database will return relevant data it needs. So let's explore some of the key concepts behind what goes into setting up a basic vector database. Let's start with embedding. Embedding is really the key concept that makes the medium go from value to meaning. In SQL, we store the values contained in the employee handbook as a straightup value.

But in a vector database, you need to do some extra work up front to convert the value into semantic meanings. And these meanings are stored in what's called embeddings. For example, the words holiday and vacation should semantically share a similar space since the meaning of those words are close to each other. So before the sentence employee shall not request time off on holidays in the document is added to the database.

The system runs through an embedding model and the embedding model converts that sentence into a long vector of numbers and when you search the database you are actually comparing this exact vector. That way when someone later asks can I take vacation during a holiday even though the phrasing is a little bit different the database can still service the request. And this is the fundamental shift. Instead of searching by exact wording, we're now searching by meaning.

Another important concept is dimensionality. And you might be asking, why do I have to worry about dimensionality? Can't I just throw the words into embedding and store it into the database? There's one more aspect in embedding that you need to think about, and that's dimensionality. Typically, a word doesn't just have one meaning to learn from. For example, the word vacation can have different semantics depending on the context that is used in. and capturing all those intricacies like tone, formality, and other features can give richness to those words.

Typically, dimensions we use today are 1536 dimensions, which is a good mix of not having too much burden in size, but also giving enough context to allow for depth in each search. Once the embedding is stored with proper dimension, there are two other major angles that we need to consider when we're working with vector databases. And this is the retrieval side. Meaning now that we store the meaning of those words, we have to take on the burden of the retrieval side of embeddings.

Since we are not doing searches like we did in SQL with a wear query, we need to make a decision on what would technically be counted as a much and by how much. This is done by looking at scoring and chunk overlap. And if you're at this point wondering, this seems like a lot of tweaking just to use vector database. And that's the serious trade-off you ought to consider when using a vector database, which is that while a properly set up vector database makes searching so much more flexible, getting the vector database properly configured often adds complexity up front.

So with that in mind, scoring is a threshold you set to how similar the results need to be to be considered a proper match. For example, the word Florida might have some similarity to the word vacation since it's often where people go for vacation. But asking the question, can I take my company laptop to Florida is very different than does my company allow vacation to Florida? Since one is asking about a policy in IT jurisdiction and the other is about vacation policy.

So setting up a score threshold based on the question can help you limit those low similarities to count as a match. Okay, there's one final angle which is chunk overlap. So in SQL, we're used to storing things rowby row, but in vector databases, things look a little bit different. When we're storing values in vector databases, they're often chunked going into the database. So when we chunk down an entire employee handbook into chunks, it's possible that the meaning gets chunked with it.

That's why we allow chunk overlap so that the context spills over to leave enough margin for the search to work properly. In this app, we're going to build a semantic search engine step by step. The story begins with TechDoc Inc. where users search through documentation 10,000 times a day. But more than half of those searches fail. Why? Because traditional keyword search can't connect reset password with password recovery process.

Our mission is to fix that by building a search system that understands meaning, not just words. We begin with the environment setup. In this step, we're asked to install the libraries that make vector search possible. Sentence transformers for embeddings. lang chain for orchestration, chromadb for vector database and few utility libraries like numpy. Once installed, we verify the setup using a provided script. If everything checks out, we're ready to move forward.

Next, we take a moment to understand embeddings. These are the backbone of semantic search. Instead of treating texts as words, embedding converts text into numerical vectors. Similar meanings end up close to each other in this mathematical space. That means forgot my password in account recovery looks very different in words but almost identical in vector 4. This is a magic that allows our search engine to succeed where keyword search fails.

That takes us into task number one where we put embedding into action. We open the script, initialize the mini LM model, encode both queries and documents and then calculate similarity using cosign similarity. Running the script demonstrates how a search for forgot password successfully matches password recovery, showing semantic understanding in real time. Once we understand embeddings, we move to document chunking.

Large documents can't be embedded all at once. So, we need to split them into smaller chunks, but if we cut too bluntly, we lose context. That's why overlapping chunks are important. They preserve meanings across boundaries. For example, setting a chunk size of 500 characters with 100 characters overlap can improve retrieval accuracy by almost 40%. Lang chain helps us do this intelligently. In task number two, we put this into practice by editing a script to import lane chain's recursive characters text splitter and set the chunking parameters.

Running the script confirms that our documents are now split into overlapping pieces ready for storage. The next concept we explore is vector stores. Embeddings alones are just numbers. We need a system to store and search through them efficiently. That's where Chromma comes in. It's a production ready vector database that can handle millions of embeddings, perform similarity search in milliseconds, and support metadata filtering.

In task number three, we're asked to create a vector store using Chroma DB. We import the necessary classes, configure the embedding model, and then run the script. Once confirmed, we have a working vector store that can accept documents and retrieve them semantically. Finally, we bring everything together with semantic search. Here we implement the full pipeline, convert the user query into an embedding, search the Chromma store, retrieve the most relevant document chunks, and return them to the user.

For example, a query like work from home policy will now correctly surface remote work guidelines. In task 4, we configure the query, set the number of top results to return, and establish a threshold for similarity scores. Running the script validates our search engine end to end. The lab closes with a recap. We started with a broken keyword search system where 60% of the search failed. Along the way, we learned about embeddings, smart document chunking, vector stores, and semantic search.

By the end, we built a productionready search engine with 95% success rate. Some of the deeper experiments like adjusting chunk sizes, testing different embedding models and or adding metadata filters are left for you to explore on your own. So is it possible that instead of searching through the entire 500 GB of documents, AI assistant can fit them into their context window and generate output. This is called rag or retrieval augmented generation.

Let's say your company used the AI assistant to ask this question. What's our remote work policy for international employees? In order to understand how rag works, we need to break them into three simple steps. Retrieval, augmented, and generation. Starting with retrieval, just like how we convert the document into vector embeddings to store them inside the database, we do the exact same step for the question that reads, "What's our remote work policy for international employees?" Once the word embedding for this question is generated, the embedding for that question is compared against embeddings of the documents.

This type of search is called semantic search where instead of searching by the static keywords to find relevant contents, the meaning and the context of the query is used to match against the existing data set. Moving on to augmentation in rag refers to the process where the retrieved data is injected into the prompt at runtime. And you might think why is this all that special? Typically, AI assistants rely on what they learned during pre-training, which is static knowledge that can become outdated.

Instead, our goal here is to have the AI assistant rely on up-to-date information stored in the vector database. In the case of RAG, the semantic search result pends to the prompt that essentially serves as an augmented knowledge. So, for your company, the AI assistant is given details from company's documents that are real, up-to-date, and private data set. And all this can occur without needing to fine-tune or modify the large language model with custom data.

The final step of rag is generation. This is a step where AI assistant generates the response given the semantic relevant data retrieved from the vector database. So the initial prompt that says what's our remote work policy for international employees? The AI assistant will now demonstrate its understanding of your company's knowledge base by using the documents that relate to remote work and policy. And since the initial prompt specifies a criteria of international employees, the generation step will use its own reasoning to wrestle with the data provided to best answer the question.

Now, RAG is a very powerful system that can instantly improve the depth of knowledge beyond its training data. But just like any other system, learning how to calibrate is an acquired skill that needs to be learned to get the best results. Setting up a rag system will look different from one system to another because it heavily depends on the data set that you're trying to store. For example, legal documents will require different chunking strategies than a customer support transcript document.

This is because legal documents often have long structured paragraph that need to be preserved and intact. While conversational transcript can be just fine with sentence level chunking with high overlap to preserve context. In this lab, we're taking our semantic search system to the next level by adding AI power generation. Up until now, we've been able to find relevant documents with high accuracy. For example, matching remote work policy when someone searches work from home.

But the CEO wants more. Instead of retrieving a document, the system should actually answer the user's questions directly. something like yes, you can work three days from home, not just showing a PDF. We begin the environment setup. In this step, we're asked to activate the Python environment and install the key libraries. These include Chroma DB for vector storage, sentence transformers for embeddings within lane chain with integrations for OpenAI and hugging face.

Once installed, we verify everything using the provided script to ensure the rack framework is ready. Next, we move into task number one, setting up the vector store. Here we initialize a chromabb client. Create our get collection named tech corp brag and configure the embedding model all mini6v2. This is where we get our system of memory. A place where all of our company documents will be stored as vectors so that we can search them semantically.

In task number two, the focus shifts to document processing and chunking. Unlike our earlier lab where we split text into fixed-size character chunks, here we upgrade to paragraph-based chunking with smart overlaps. The goal is to preserve meaning so that each chunk contains complete thoughts. This is crucial for RAG because when AI generates answers, the quality depends on having coherent chunks of context. From there, we go to task number three, LLM integration.

This is where we connect OpenA model GPD4.1 Mini. The API key and base are already preconfigured for us. We just need to set the generation parameters like temperature, max tokens, and top P values. Once integrated, we can test simple text generation before layering on retrieval and augmented steps. Task number four introduces prompt engineering for rag. We're asked to build a structured prompt template that always ensures context is included.

The system prompt makes it clear that answers must come only from the retrieved documents. If the information isn't in context, the AI must respond with, "I don't have that information in the provided documents." This keeps our answers factual and prevents hallucinations. Finally, we reach task number five, the complete rag pipeline. Here we wire everything together. The flow is embed the user query, search Chromad, retrieve the top three chunks, build a contextaware prompt, and generate an answer using LLM.

The final touch is a source attribution. Every answer points back to the document it was derived from. This transforms the system into a full production ready Q&A engine. At the end, we celebrate rag mastery. What started as simple document search has evolved into a powerful system that retrieves, augments, and generates answers. This is the same architecture that powers tools like catchupt, claude, and gemini. Some parts like experimenting with different trunk strategy, refining prompts are left for you to explore yourself.

But by now you've built a complete RAG system that answers questions with context, accuracy, and confidence. Now that we covered the conceptual elements of RAG, let's look at how it looks on a practical level. To better understand this, we can look over at this lab specifically geared towards how to use Rag. Now we covered the basic concepts of simple chat application that allows us to chat with documents using vector databases and rag.

Most business cases in the real world may be slightly more complicated. For example, in tech corp's case, the business requirement might extend to more complex requirements like being able to connect the agent to human resource management system to pull employee documents to cross reference and make personalized responses. However, lang chain has limitations. When business requirements become more complex like multi-step workflows, conditional branching or iterative processes, you need something more sophisticated for better orchestration.

That's where langraph becomes essential. Langraph extends lane chain to handle more complex multi-step workflows that go beyond simple question and answer interactions. For example, if a customer asks, I need to understand our data privacy policy for EU customers. Since we assume that inside the 500 GB of database, it contains details about EU specific regulations, we need to create a system that can analyze Tech Corp's data privacy policies for EU customers, ensuring compliance with GDPR, local regulations, and company standards.

While in a traditional software development, you need to write code that can sequentially and conditionally call different sections of the code to process this request. With lang graph, this becomes a graph where each node handles a specific responsibility. For example, node one, search and gather privacy policy documents. Node two, extract and clean document content. Node three, evaluate GDPR compliance using LLM analysis.

Node four, cross reference the local EU regulations. And node five, identify compliance gaps and generate recommendation. A node is an individual unit of computation. So think of a function that you can call. Once you have all the nodes created in langraph, you will then need to connect them and this connection is called an edge. Edges in langraph define execution flow. For example, after node one gathers documents, the edge routes to node two for content extraction.

And after node 3 evaluates compliance, a conditional edge either routes to node four for additional analysis or jumps to node five for report generation. And one final concept to keep in mind beyond nodes and edges is shared state between each node. This is possible by using state graph that essentially stores information throughout the entire workflow. For example, class compliance state type dictionary topic string documents list of string current documents optional string compliance score optional integer gaps list of string recommendation list of string can be used for nodes we identified before.

As the workflow progresses, each node updates relevant state variables. Node one populates documents with found policy files. Node two processes individual documents and updates current document. Node 3 calculates compliance score. Node 4 identifies gaps. Node 5 generates recommendation. The state graph orchestrates execution based on configured flow. If node 3 determines compliance score is below 75% the conditional edge routes back to node one to gather additional documents.

If the score exceeds 75% execution proceeds to node 5 for final report generation. As you can see this creates powerful capabilities loops for iterative analysis conditional branching on intermediate results persistent state that maintains context across the entire workflow. So for Tech Corps compliance assistant, Langraph is an essential tool for workflow automation. All right, let's start with the labs. In this lab, we're diving into Langraph, a framework designed for building stateful multi-step AI workflows.

Unlike simple chains, Langraph gives us specific control over how data moves, letting us create branching logic, loops, and decision points. By the end of this journey, we'll have built a complete research assistant that can use multiple tools intelligently. We begin with environment setup. In this setup, we activate the Python virtual environment and install the required libraries. Langraph itself, Langchain, and OpenAI integration.

Once everything is installed, we run a verification script to make sure our setup is ready. With the environment ready, we start small. Task number one introduces us to essential import. We bring in state graph end and type dict to define the data that flows through the workflow. Then we add a simple state field for messages. This is the foundation. State graph holds the workflow and marks completion and the state holds shared data.

In task number two, we create our first nodes. Nodes are just Python functions that take state as inputs and return partial updates. In this case, we define a greeting node and an enhancement node. Once connected, one node outputs a basic greeting and the next node improves it with a bit of a flare. This demonstrates how state accumulates step by step. Pass number three is about edges. The connections between nodes. Here we use add nodes and add edges to wire greeting nodes to the enhancement node.

With that, we built our first mini workflow. Data flows from one function to another. The state updates along the way. In task number four, we take it further with a multi-step flow. We add new nodes like a draft step and a review step. Connect them and see how the data moves through multiple stages. Each step preserves states, adds detail and passes it on. This mimics real world pipelines where content is outlined, drafted and polished.

Pass number five introduces conditional routing. Instead of a fixed flow, the system now decides dynamically. For example, if the query is short, it routes one way. If detailed, it routes another. The router inspects the state and returns the next node name, making workflows flexible and adaptive. Then comes task number six, tool integration. Here we add a calculator tool. The router checks if the query is math related.

If so, it routes to the calculator node which computes the answer. This is our first glimpse at how Langraph lets us integrate specialized tools directly into workflows. Finally, task number seven puts everything together into research agent. We combine the calculator with a web search tool like duck.go. Depending on the query, the system decides whether to perform a calculation, run a web search, or handle a text normally.

This is a dynamic tool orchestration, the foundation of modern AI agents. By the end of this lab, we've gone from simple imports to a fully functional research assistant. We've seen how to build nodes, connect them, design multi-step flows, and add routing logic and integrate tools. Some of the deeper experiments like chaining more advanced tools or refining the router logic are left for you to explore on your own. Now that we covered lang chain and langraph and understood how techp business requirements can be met by leveraging pre-built tools that it offers, there's one final piece that's been popular since Anthropics released back in November 2022 called MCP or model context protocol.

Techorps AI document assistant is working well for internal knowledge base, but employees might now need to access external systems like customer database, support systems, inventory management software, and other thirdparty APIs. And writing custom integrations to all these API connections will take a huge amount of time. MCP functions like an API, but with crucial differences that make it perfect for AI agents. Traditional APIs expose endpoints that require you to understand implementation details leading to rigid integrations tied to specific systems.

MCP doesn't just expose tools. It provides self-describing interfaces that AI agents can understand and use autonomously. The key advantage here is that unlike traditional APIs, MCP puts the burden on the AI agent rather than the developer. So when you start an MCP server, an instance starts and establish a connection with your AI agent. For example, the Techorps document assistant might easily have these MCP servers to enable powerful integration.

Let's say customer database MCP. When someone asks, "What's the status of the order 1 2 3 4?" The AI uses an MCP to query TechCorb's order management system, retrieves the current status, and provides a complete response. The same logic applies for support tickets, inventory databases and notification system mentioned earlier where we can simply plug into existing integrations of MCP servers to allow the agent to now extend its capabilities.

For example, we can create a very simple MCP server code that looks something like this. Here we have fast MCP customer DB that starts the MCP server with the name customer DB at MCB tool that exposes a function to MCP clients. the AI can call like an API function parameters and return types that tells the MCP client what inputs are required and what type of output to expect. Finally, customers variable that is a fake database in this case stored in memory, but in your company's case, you can connect this to a SQL database or MongoDB or any other custom database you might hold customer information on.

Now, looking at this code might confuse you on what MCP really is, since it's typically being talked about as a simple plugand play, and you're right to think that way. The difference here is that this MCP server code that's written only needs to be written once, and it doesn't necessarily have to be you. In other words, a community of MCP developers might have written custom MCP servers for other popular tools like GitHub, GitLabs, or SQL databases, and you can simply use them directly on your agent without having to write the code yourself.

That's where the power of MCP really comes from. In this lab, we're going deeper into MCP, model context protocol, and learning how to extend Langraph with external tools. Think of MCP as a universal port like USB that allows AI system to connect to any tool, database or API in a standardized way. With it, our langraph agents can go beyond built-in logic and integrate external services seamlessly. We begin with the environment step.

In this step, we activate our virtual environment and install the key packages. Lang graph for the workflow framework, Langchain for the core abstractions, and Langchain OpenAI for the model integration. The setup also prepares for fast MCP, the framework we'll use to build MCP servers. Once installed, we verify by learning the provided script, ensuring everything is ready for MCP development. Next, we get a conceptual overview of the MCP architecture.

Here the lab explains that the MCP protocol acts as a bridge between an AI assistant built with Langraph and external tools. The flow works like this. The MCP server exposes tools and schemas. Langraph integrates with them and queries are routed intelligently. The naming convention MCP server tool ensures clarity when multiple tools are involved. A helpful analogy is comparing MCP to USB devices. A protocol is a port.

The server is a device. The tools are its functions. And Langraph is a computer that uses them. That brings us to task number one, MCP basics. Here we're asked to create our very first MCP server. The task involves initializing a server called calculator, defining a function as a tool with at MCP.tool decorator and running it with the SCDIO transport. This shows how simple it is to expose a structured function as an external tool. that langraph can later consume.

In task number two, we integrate MCP with langraph. The challenge here is to connect the calculator server to an agent. This involves configuring the client fetching tools from the server create react agent that can decide when to call the calculator selected when needed. Next, task number three scales things up with multiple MCP servers. Instead of just a calculator, we add another server, in this case, a weather service.

Now, Langraph orchestrates between both. The system retrieves available tools, creates an agent with access to both servers, and intelligently routes queries. If a user asks a math question, the calculator responds. If they ask about the weather, the weather tool responds. This is where we see the true power of MCP. Multiple servers are working together under a unified AI agent. The lab wraps up by celebrating MCP mastery.

By now, we've created MCP servers, integrated them with ElangRaph, and orchestrated multiple tools. The key takeaways are that MCP is universal. It can connect any tool to any AI. Routing is what gives it power. The design is extendable, so we can add servers anytime. Some deeper explorations like exposing databases, APIs or file systems through MCP are left for you to explore on your own. That concludes this narration.

Next, we'll continue the journey by experimenting with resource exposure, human in the loop approval flows, and eventually deploying production ready MCP packages. Now that we have put all these pieces together like context windows, vector databases, lang chain, langraph, MCP, and prompt engineering, Techorp is now able to do complex document search that went from manual searching that could have taken up to 30 minutes to now less than 30 seconds using our AI agent.

And we also have a higher accuracy using contextaware semantic search like using rag. And finally, the chat application UI allows users to have more satisfaction in working with a tool that can help keep track of conversation history and better intuition overall. And the availability for this is 24/7 as long as the application is running. And this is just the beginning. Imagine layering on predictive analytics, proactive compliance agents, and workflow automation that doesn't just answer questions, but actively solves problems before employees can even ask.

The shift from static documents to living intelligent system marks a turning point not just for Tech Corp, but for how every other business can unlock a full value of its knowledge using agents.