chore: sync content to repo (#10329)

Co-authored-by: nilbuild <4921183+nilbuild@users.noreply.github.com>
This commit is contained in:
github-actions[bot]
2026-09-14 15:24:22 +02:00
committed by GitHub
co-authored by nilbuild
parent 79e9a0e7ca
commit e7fe436a08
38 changed files with 43 additions and 62 deletions
@@ -1,6 +1,6 @@
# Anthropic Tool Use
Anthropic Tool Use lets you connect a Claude model to real software functions so the agent can do useful tasks on its own. You give Claude a list of tools, each with a name, a short description, and a strict JSON schema that shows the allowed input fields. During a chat you send user text plus this tool list. Claude decides if a tool should run, picks one, and returns a JSON block that matches the schema. Your code reads the JSON, calls the matching function, and sends the result back to Claude for the next step. This loop repeats until no more tool calls are needed. Clear schemas, small field sets, and helpful examples make the calls accurate. By keeping the model in charge of choosing tools while your code controls real actions, you gain both flexibility and safety.
Anthropic tool use is Claude's implementation of native function calling, where the model can choose to call a defined tool with structured arguments as part of its response. The calling application executes the tool and returns the result, which Claude can use to continue reasoning or produce a final answer. It supports patterns like parallel tool calls and forcing a specific tool to be used when needed.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# AutoGen
AutoGen is an open-source Python framework that helps you build AI agents without starting from scratch. It lets you define each agent with a role, goals, and tools, then handles the chat flow between them and a large language model such as GPT-4. You can chain several agents so they plan, code, review, and run tasks together. The library includes ready-made modules for memory, task planning, tool calling, and function execution, so you only write the parts that are unique to your app. AutoGen connects to OpenAI, Azure, or local models through a simple settings file. Logs, cost tracking, and step-by-step debugging come built in, which makes testing easy. Because the agents are plain Python objects, you can mix them with other libraries or your own code. AutoGen is still young, so expect fast changes and keep an eye on usage costs, but it is a strong choice when you want to turn a prompt into a working multi-agent system in hours instead of weeks.
AutoGen is a framework from Microsoft for building applications with multiple agents that communicate with each other to solve tasks. It defines agents with specific roles and lets them exchange messages, delegate subtasks, and collaborate toward a shared goal. It is commonly used for research and applications that benefit from multiple specialized agents working together.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Bias & Toxicity Guardrails
Bias and toxicity guardrails keep an AI agent from giving unfair or harmful results. Bias shows up when training data favors certain groups or views. Toxicity is language that is hateful, violent, or rude. To stop this, start with clean and balanced data. Remove slurs, stereotypes, and spam. Add examples from many voices so the model learns fair patterns. During training, test the model often and adjust weights or rules that lean one way. After training, put filters in place that block toxic words or flag unfair answers before users see them. Keep logs, run audits, and ask users for feedback to catch new issues early. Write down every step so builders and users know the limits and risks. These actions protect people, follow laws, and help users trust the AI.
Bias and toxicity guardrails are checks put in place to detect and block outputs that are discriminatory, offensive, or otherwise harmful before they reach a user. These can be implemented through classifier models, keyword filters, or the underlying model's own safety training. They are important for agents that generate open ended content or interact directly with end users.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Closed Weight Models
Closed-weight models are AI systems whose trained parameters—the numbers that hold what the model has learned—are not shared with the public. You can send prompts to these models through an online service or a software kit, but you cannot download the weights, inspect them, or fine-tune them on your own computer. The company that owns the model keeps control and sets the rules for use, often through paid APIs or tight licences. This approach helps the owner protect trade secrets, reduce misuse, and keep a steady income stream. The downside is less freedom for users, higher costs over time, and limited ability to audit or adapt the model. Well-known examples include GPT-4, Claude, and Gemini.
Closed weight models are language models accessed only through an API, with the underlying weights kept private by the provider, examples include GPT-4 and Claude. Developers send requests and receive outputs without ever handling the model itself. This approach removes the need to manage infrastructure but ties usage to the provider's pricing, rate limits, and terms of service.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Code Execution / REPL
Code Execution or REPL (Read-Eval-Print Loop) lets an AI agent run small pieces of code on demand, see the result right away, and use that result to decide what to do next. The agent “reads” the code, “evaluates” it in a safe sandbox, “prints” the output, and then loops back for more input. With this tool the agent can test ideas, perform math, transform text, call APIs, or inspect data without waiting for a full build or deployment. Python, JavaScript, or even shell commands are common choices because they start fast and have many libraries. Quick feedback helps the agent catch errors early and refine its plan step by step. Sandboxing keeps the host system safe by blocking dangerous actions such as deleting files or making forbidden network calls. Overall, a Code Execution / REPL tool gives the agent a fast, flexible workbench for problem-solving.
A code execution or REPL tool lets an agent run code and see the actual result, rather than only generating code as text. This is useful for tasks like calculations, data processing, or verifying that generated code works before presenting it. Giving an agent this tool turns it from something that writes code into something that can test and correct its own output.
Visit the following resources to learn more:
@@ -1,8 +1,6 @@
# Context Windows
A context window is the chunk of text a large language model can read at one time. It is measured in tokens, which are pieces of words. If a model has a 4,000-token window, it can only “look at” up to about 3,000 words before it must forget or shorten earlier parts. New tokens push old ones out, like a sliding window moving over text. The window size sets hard limits on how long a prompt, chat history, or document can be. A small window forces you to keep inputs short or split them, while a large window lets the model follow longer stories and hold more facts. Choosing the right window size balances cost, speed, and how much detail the model can keep in mind at once.
New techniques, like retrieval-augmented generation (RAG) and long-context transformers (e.g., Claude 3, Gemini 1.5), aim to extend usable context without hitting model limits directly.
The context window is the maximum number of tokens a model can process in a single request, including both the input and the generated output. Anything beyond this limit gets truncated or causes an error, so long conversations or documents need to be managed carefully. A larger context window lets an agent keep more history, tool outputs, or retrieved documents in view at once.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Forgetting / Aging Strategies
Forgetting or aging strategies help an AI agent keep only the useful parts of its memory and drop the rest over time. The agent may tag each memory with a time stamp and lower its importance as it gets older, or it may remove items that have not been used for a while, much like a “least-recently-used” list. Some systems give each memory a relevance score; when space runs low, they erase the lowest-scoring items first. Others keep a fixed-length sliding window of the most recent events or create short summaries and store those instead of raw details. These methods stop the memory store from growing without limits, cut storage costs, and let the agent focus on current goals. Choosing the right mix of aging rules is a trade-off: forget too fast and the agent loses context, forget too slow and it wastes resources or reacts to outdated facts.
Forgetting or aging strategies decide what stored information an agent should discard or deprioritize over time, since keeping everything indefinitely is neither practical nor useful. Common approaches include removing information after a set time, lowering its priority if it is not accessed, or replacing outdated details with newer ones. These strategies keep an agent's memory relevant and prevent it from being cluttered with stale or contradictory information.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Frequency Penalty
Frequency penalty is a setting that tells a language model, “Stop repeating yourself.” As the model writes, it keeps track of how many times it has already used each word. A positive frequency-penalty value lowers the chance of picking a word again if it has been seen many times in the current reply. This helps cut down on loops like “very very very” or long blocks that echo the same phrase. A value of 0 turns the rule off, while higher numbers make the model avoid repeats more strongly. If the penalty is too high, the text may miss common words that are still needed, so you often start low (for example 0.2) and adjust. Frequency penalty works together with other controls such as temperature and top-p to shape output that is clear, varied, and not boring.
Frequency penalty reduces the likelihood of the model repeating tokens it has already used, with the penalty growing the more often a token appears. This discourages repetitive phrases and loops in longer generations. It is commonly tuned when a model produces text that gets stuck repeating the same words or ideas.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Gemini Function Calling
Gemini function calling lets you hook the Gemini language model to real code in a safe and simple way. You first list the functions you want it to use, each with a name, a short note about what it does, and a JSON schema for the needed arguments. When the user speaks, Gemini checks this list and, if a match makes sense, answers with a tiny JSON block that holds the chosen function name and the filled-in arguments. Your program then runs that function, sends the result back, and the chat moves on. Because the reply is strict JSON and not free text, you do not have to guess at what the model means, and you avoid many errors. This flow lets you build agents that pull data, call APIs, or carry out long action chains while keeping control of business logic on your side.
Gemini function calling is Google's implementation of native tool calling, letting a Gemini model select from provided function definitions and return a structured call with arguments. The application runs the corresponding function and returns the output to continue the interaction. It follows the same general pattern as other providers' function calling, with its own specific request and response format.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Haystack
Haystack is an open-source Python framework that helps you build search and question-answering agents fast. You connect your data sources, pick a language model, and set up pipelines that find the best answer to a users query. Haystack handles tasks such as indexing documents, retrieving passages, running the model, and ranking results. It works with many back-ends like Elasticsearch, OpenSearch, FAISS, and Pinecone, so you can scale from a laptop to a cluster. You can add features like summarization, translation, and document chat by dropping extra nodes into the pipeline. The framework also offers REST APIs, a web UI, and clear tutorials, making it easy to test and deploy your agent in production.
Haystack is an open source framework for building search and question answering pipelines, including retrieval augmented generation and agent based applications. It provides modular components for document retrieval, ranking, and generation that can be combined into custom pipelines. It is often used in production search and NLP applications that need a flexible, composable architecture.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Integration Testing for Flows
Integration testing for flows checks that an AI agent works well from the first user input to the final action, across every step in between. It joins all parts of the system—natural-language understanding, planning, memory, tools, and output—and runs them together in real scenarios. Test cases follow common and edge-case paths a user might take. The goal is to catch errors that only appear when parts interact, such as wrong data passed between modules or timing issues. Good practice includes building automated test suites, using real or mock services, and logging each step for easy debugging. When integration tests pass, you gain confidence that the whole flow feels smooth and reliable for users.
Integration testing for flows checks that an agent behaves correctly across a full multi step task, not just that individual tools work on their own. It verifies that the agent chooses the right tools in the right order and handles the combined behavior of reasoning, acting, and observing correctly. This catches issues that only show up when components interact, which unit tests on individual pieces would miss.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# LangFuse
LangFuse is a free, open-source tool that lets you watch and debug AI agents while they run. You add a small code snippet to your agent, and LangFuse starts collecting every prompt, model response, and user input. It shows this data as neat timelines, so you can see each step the agent takes, how long the calls cost, and where errors happen. You can tag runs, search through them, and compare different prompt versions to find what works best. The dashboard also tracks token usage and latency, helping you cut cost and improve speed. Because LangFuse stores data in your own database, you keep full control of sensitive text. It works well with popular frameworks like LangChain and can send alerts to Slack or email when something breaks.
Langfuse is an open source observability and analytics platform for LLM applications, providing tracing, evaluation, and prompt management features. It captures detailed traces of agent runs, including nested tool calls, and lets teams analyze performance and quality over time. It can be self hosted, which appeals to teams with strict data privacy requirements.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# LangSmith
LangSmith is a tool that helps you see how well your AI agents work. It lets you record every step the agent takes, from the first input to the final answer. You can replay these steps to find places where the agent goes wrong. LangSmith also lets you create test sets with real user prompts and compare new model versions against them. It shows clear numbers on speed, cost, and accuracy so you can spot trade-offs. Because LangSmith links to LangChain, you can add it with only a few extra lines of code. The web dashboard then gives charts, error logs, and side-by-side result views. This makes it easy to track progress, fix bugs, and prove that your agent is getting better over time.
LangSmith is a platform for debugging, testing, and monitoring LLM applications, including agents, by tracing each step of a run and logging inputs, outputs, and intermediate reasoning. It also supports building evaluation datasets and running automated tests against them to measure quality over time, alongside dashboards for tracking cost and latency in production. Built by the LangChain team, it is commonly paired with LangChain and LangGraph applications but can be used independently.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# LlamaIndex
LlamaIndex is an open-source Python toolkit that helps you give a language model access to your own data. You load files such as PDFs, web pages, or database rows. The toolkit breaks the text into chunks, turns them into vectors, and stores them in a chosen vector store like FAISS or Pinecone. When a user asks a question, LlamaIndex finds the best chunks, adds them to the prompt, and sends the prompt to the model. This flow is called retrieval-augmented generation and it lets an agent give answers grounded in your content. The library offers simple classes for loading, indexing, querying, and composing tools, so you write less boilerplate code. It also works with other frameworks, including LangChain, and supports models from OpenAI or Hugging Face. With a few lines of code you can build a chatbot, Q&A system, or other agent that knows your documents.
LlamaIndex is a framework focused on connecting language models to external data, providing tools for ingesting, indexing, and querying documents for retrieval augmented generation. It handles tasks like chunking documents, generating embeddings, and building indexes that support efficient retrieval. It is commonly used as the data layer underneath a RAG based agent.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# LLM Native "Function Calling"
LLM native function calling” lets a large language model decide when to run a piece of code and which inputs to pass to it. You first tell the model what functions are available. For each one you give a short name, a short description, and a list of arguments with their types. During a chat, the model can answer in JSON that matches this schema instead of plain text. Your wrapper program reads the JSON, calls the real function, and then feeds the result back to the model so it can keep going. This loop helps an agent search the web, look up data, send an email, or do any other task you expose. Because the output is structured, you get fewer mistakes than when the model tries to write raw code or natural-language commands.
LLM native function calling is a capability built directly into a model's API that lets it output a structured call to a predefined function, including the function name and arguments, instead of freeform text. The application executes the actual function and returns the result to the model to continue the conversation. This standardizes how models request actions, removing the need to parse tool calls out of plain text output.
Visit the following resources to learn more:
@@ -1,10 +1,10 @@
# MCP Servers
An MCP Server is the main machine or cloud service that runs the Model Context Protocol. It keeps the shared “memory” that different AI agents need so they stay on the same page. When an agent sends a request, the server checks who is asking, pulls the right context from its store, and sends it back fast. It also saves new facts and task results so the next agent can use them. An MCP Server must handle many users at once, protect private data with strict access rules, and log every change for easy roll-back. Good servers break work into small tasks, spread them across many computers, and add backups so they never lose data. In short, the MCP Server is the hub that makes sure all agents share fresh, safe, and correct context.
An MCP server exposes a set of tools, data, or capabilities to any compatible client using the Model Context Protocol. It might, for example, provide access to a file system, a database, or a third party API. Because servers follow a shared protocol, they can be reused across different AI applications without custom integration work.
Visit the following resources to learn more:
- [@opensource@punkeye/awesome-mcp-servers](https://github.com/punkpeye/awesome-mcp-servers)
- [@article@Introducing the Azure MCP Server ](https://devblogs.microsoft.com/azure-sdk/introducing-the-azure-mcp-server/)
- [@article@Introducing the Azure MCP Server](https://devblogs.microsoft.com/azure-sdk/introducing-the-azure-mcp-server/)
- [@article@The Ultimate Guide to MCP](https://guangzhengli.com/blog/en/model-context-protocol)
- [@article@AWS MCP Servers for Code Assistants](https://aws.amazon.com/blogs/machine-learning/introducing-aws-mcp-servers-for-code-assistants-part-1/)
@@ -1,11 +1,11 @@
# Model Context Protocol (MCP)
Model Context Protocol (MCP) is an open, standardized protocol that lets AI applications connect to external data sources and tools in a uniform way. Instead of writing a custom integration every time a model needs to read a file, query a database, or call an API, developers expose that capability through an MCP server, and any MCP-compatible client (the AI application) can discover and use it the same way. MCP follows a client-server architecture: the host application runs a client that talks to one or more servers over a defined protocol, exchanging structured requests for tools, resources, or prompts. This decouples AI applications from the specific systems they connect to, similar to how the Language Server Protocol decoupled code editors from language-specific tooling.
Model Context Protocol (MCP) is an open standard that defines how AI applications connect to external tools, data sources, and services in a consistent way. Instead of building a custom integration for every tool an agent needs, MCP provides a common interface that any compliant client and server can use to communicate. This makes it easier to plug new capabilities into an agent without writing bespoke connection code each time.
Visit the following resources to learn more:
- [@course@MCP: Build Rich-Context AI Apps with Anthropic](https://www.deeplearning.ai/short-courses/mcp-build-rich-context-ai-apps-with-anthropic/)
- [@official@Model Context Protocol](https://modelcontextprotocol.io/introduction)
- [@opensource@Model Context Protocol](https://github.com/modelcontextprotocol/modelcontextprotocol)
- [@article@Introducing the Azure MCP Server ](https://devblogs.microsoft.com/azure-sdk/introducing-the-azure-mcp-server/)
- [@article@Introducing the Azure MCP Server](https://devblogs.microsoft.com/azure-sdk/introducing-the-azure-mcp-server/)
- [@article@The Ultimate Guide to MCP](https://guangzhengli.com/blog/en/model-context-protocol)
@@ -1,6 +1,6 @@
# Open Weight Models
Open-weight models are neural networks whose trained parameters, also called weights, are shared with everyone. Anyone can download the files, run the model, fine-tune it, or build tools on top of it. The licence that comes with the model spells out what you are allowed to do. Some licences are very permissive and even let you use the model for commercial work. Others allow only research or personal projects. Because the weights are public, the community can inspect how the model works, check for bias, and suggest fixes. Open weights also lower costs, since teams do not have to train a large model from scratch. Well-known examples include BLOOM, Falcon, and Llama 2.
Open weight models are language models whose trained parameters are published for anyone to download, run, and fine-tune, examples include Llama and Mistral. Because the weights are available, developers can self host these models, modify them, and avoid relying on a third party API. This gives more control over cost, data privacy, and customization, at the expense of needing your own infrastructure.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# OpenAI Assistant API
The OpenAI Assistants API lets you add clear, task-specific actions to a chat with a large language model. You first describe each action you want the model to use, giving it a name, a short purpose, and a list of inputs in JSON form. During the chat, the model may decide that one of these actions will help. It then returns the name of the action and a JSON object with the input values it thinks are right. Your code receives this call, runs real work such as a database query or a web request, and sends the result back to the model. The model reads the result and continues the chat, now armed with fresh facts. This loop lets you keep control of what real work happens while still letting the model plan and talk in natural language.
The OpenAI Assistants API is a higher level interface for building agents that manages conversation threads, tool calls, and file based context on OpenAI's servers, rather than requiring the developer to track state manually. It handles things like persisting conversation history and running tools like code execution or file search. This reduces the amount of infrastructure a developer needs to build to get a working agent.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# OpenAI Functions Calling
OpenAI Function Calling lets you give a language model a list of tools and have it decide which one to use and with what data. You describe each tool with a short name, what it does, and the shape of its inputs in a small JSON-like schema. You then pass the user message and this tool list to the model. Instead of normal text, the model can reply with a JSON block that names the tool and fills in the needed arguments. Your program reads this block, runs the real function, and can send the result back for the next step. This pattern makes agent actions clear, easy to parse, and hard to abuse, because the model cannot run code on its own and all calls go through your checks. It also cuts down on prompt hacks and wrong formats, so agents work faster and more safely.
OpenAI's function calling lets a model choose from a set of functions defined in the API request and return a structured call with the function name and arguments as JSON. The calling application executes the function and sends the result back for the model to use in its next response. It is one of the earliest and most widely adopted implementations of native tool calling.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# openllmetry
openllmetry is a small Python library that makes it easy to watch what your AI agent is doing and how well it is working. It wraps calls to large-language-model APIs, vector stores, and other tools, then sends logs, traces, and simple metrics to any backend that speaks the OpenTelemetry standard, such as Jaeger, Zipkin, or Grafana. You add one or two lines of code at start-up, and the library captures prompt text, model name, latency, token counts, and costs each time the agent asks the model for an answer. The data helps you spot slow steps, high spend, or bad answers, and it lets you play back full traces to debug agent chains. Because it follows OpenTelemetry, you can mix these AI traces with normal service traces and see the whole flow in one place.
OpenLLMetry is an open source observability standard that extends OpenTelemetry, a widely used tracing framework, to cover LLM specific data like prompts, completions, and token usage. It lets teams instrument their LLM applications using familiar observability tooling rather than a separate, proprietary system. This makes it easier to integrate LLM monitoring into existing infrastructure that already uses OpenTelemetry.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Planner Executor
A **planner-executor agent** is a type of AI agent that splits its work into two clear parts: planning and execution. The **planner** thinks ahead, taking a goal and breaking it down into a sequence of steps, ordering them in a logical and efficient manner. The **executor**, on the other hand, takes each planned step and carries it out, monitoring the results and reporting back to the planner. If something fails or the world changes, the planner may update the plan, and the executor follows the new steps. This modular approach allows the agent to handle complex tasks by dividing them into manageable parts, making it easier to debug, reuse plans, and maintain clear and consistent behavior.
A planner executor architecture splits an agent into two roles: a planner that breaks a goal down into a sequence of steps, and an executor that carries out each step and reports back the result. This separation lets the planner focus on high level strategy while the executor handles the details of each individual action. It can make an agent's behavior easier to reason about and debug compared to a single combined loop.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Pricing of Common Models
When you use a large language model, you usually pay by the amount of text it reads and writes, counted in “tokens.” A token is about four characters or three-quarters of a word. Providers list a price per 1,000 tokens. For example, GPT-3.5 Turbo may cost around $0.002 per 1,000 tokens, while GPT-4 is much higher, such as $0.03 to $0.06 for prompts and $0.06 to $0.12 for replies. Smaller open-source models like Llama-2 can be free to use if you run them on your own computer, but you still pay for the hardware or cloud time. Vision or audio models often have extra fees because they use more compute. When planning costs, estimate the tokens in each call, multiply by the price, and add any hosting or storage charges.
Different LLM providers charge different rates per million input and output tokens, and prices vary widely between model sizes and capability tiers. Comparing pricing across common models like GPT, Claude, and Gemini helps in picking a model that fits both the task's quality requirements and the project's budget. Costs can shift quickly as providers release new models, so pricing should be checked against current rate cards rather than assumed.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# RAG Agent
A RAG (Retrieval-Augmented Generation) agent mixes search with language generation so it can answer questions using fresh and reliable facts. When a user sends a query, the agent first turns that query into an embedding—basically a number list that captures its meaning. It then looks up similar embeddings in a vector database that holds passages from web pages, PDFs, or other text. The best-matching passages come back as context. The agent puts the original question and those passages into a large language model. The model writes the final reply, grounding every sentence in the retrieved text. This setup keeps the model smaller, reduces wrong guesses, and lets the system update its knowledge just by adding new documents to the database. Common tools for building a RAG agent include an embedding model, a vector store like FAISS or Pinecone, and an LLM connected through a framework such as LangChain or LlamaIndex.
A RAG agent combines retrieval augmented generation with the ability to take actions, retrieving relevant documents as part of its reasoning process rather than just as a one time context lookup before generating text. This lets it decide when retrieval is needed and query external knowledge sources multiple times during a task. It is commonly used for question answering over private or specialized document collections.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# RAG and Vector Databases
RAG, short for Retrieval-Augmented Generation, lets an AI agent pull facts from stored data each time it answers. The data sits in a vector database. In that database, every text chunk is turned into a number list called a vector. Similar ideas create vectors that lie close together, so the agent can find related chunks fast. When the user asks a question, the agent turns the question into its own vector, finds the nearest chunks, and reads them. It then writes a reply that mixes the new prompt with those chunks. Because the data store can hold a lot of past chats, documents, or notes, this process gives the agent a working memory without stuffing everything into the prompt. It lowers token cost, keeps answers on topic, and allows the memory to grow over time.
Using RAG with a vector database means storing pieces of information as embeddings and retrieving the most relevant ones by similarity search when the agent needs context. This combination lets an agent access a large body of knowledge without keeping it all in the prompt, since only the relevant retrieved pieces get added to context. It is a common way to give agents access to long term or external memory.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Ragas
Ragas is an open-source tool used to check how well a Retrieval-Augmented Generation (RAG) agent works. You give it the user question, the passages the agent pulled from a knowledge base, and the final answer. Ragas then scores the answer for things like correctness, relevance, and whether the cited passages really support the words in the answer. It uses large language models under the hood, so you do not need to write your own scoring rules. Results appear in a clear report that shows strong and weak spots in the pipeline. With this feedback you can change prompts, retriever settings, or model choices and quickly see if quality goes up. This makes testing RAG systems faster, repeatable, and less guess-based.
Ragas is an evaluation framework focused specifically on retrieval augmented generation pipelines, measuring things like the relevance of retrieved documents and the faithfulness of generated answers to that retrieved content. It provides a standard set of metrics tailored to RAG systems rather than general purpose LLM evaluation. This makes it useful for diagnosing whether errors come from the retrieval step or the generation step.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# ReAct (Reason + Act)
ReAct is an agent pattern that makes a model alternate between two simple steps: Reason and Act. First, the agent writes a short thought that sums up what it knows and what it should try next. Then it performs an action such as calling an API, running code, or searching a document. The result of that action is fed back, giving the agent fresh facts to think about. This loop repeats until the task is done. By showing its thoughts in plain text, the agent can be inspected, debugged, and even corrected on the fly. The clear split between thinking and doing also cuts wasted moves and guides the model toward steady progress. ReAct works well with large language models because they can both generate the chain of thoughts and choose the next tool in the very same response.
ReAct is an agent architecture that interleaves reasoning steps with actions, having the model think through what to do, take an action, observe the result, and reason again before the next action. This tight loop between thought and action lets the agent adjust its plan based on real feedback rather than committing to a full plan upfront. It is one of the most widely used patterns for building tool using agents.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Reasoning vs Standard Models
Reasoning models break a task into clear steps and follow a line of logic, while standard models give an answer in one quick move. A reasoning model might write down short notes, check each note, and then combine them to reach the final reply. This helps it solve math problems, plan actions, and spot errors that simple pattern matching would miss. A standard model depends on patterns it learned during training and often guesses the most likely next word. That works well for everyday chat, summaries, or common facts, but it can fail on tricky puzzles or tasks with many linked parts. Reasoning takes more time and computer power, yet it brings higher accuracy and makes the agent easier to debug because you can see its thought steps. Many new AI agents mix both styles: they use quick pattern recall for simple parts and switch to step-by-step reasoning when a goal needs deeper thought.
Standard models generate a response directly from a prompt, while reasoning models are trained or prompted to work through intermediate steps before producing a final answer. This extra reasoning process tends to improve performance on complex tasks like math or multi-step planning, but it usually costs more tokens and takes longer to respond. Choosing between the two depends on whether the task needs deep step by step reasoning or a fast, direct answer.
Visit the following resources to learn more:
@@ -1,8 +1,8 @@
# REST API Knowledge
A **REST API** (Representational State Transfer) is an architectural style for designing networked applications. In AI agents, REST APIs enable communication between the agent and external systems, allowing for data exchange and integration. The agent can use REST APIs to retrieve data from external sources, send data to external systems, and interact with other AI agents or services. This provides a flexible and scalable way to integrate with various systems, enabling the agent to access a wide range of data and services. REST APIs in AI agents support a variety of functions, including data retrieval, data sending, and system interaction. They play a crucial role in facilitating communication between AI agents and external systems, making them a fundamental component of AI agent architecture.
REST APIs serve as a standardized way for different software systems to communicate with each other over the internet using HTTP requests. They allow an application to send data or request specific actions from a web server by using common methods like GET, POST, PUT, and DELETE. Understanding these protocols is essential for enabling an agent to interact with external tools, fetch real-time information, and perform tasks across various web-based services.
Visit the following resources to learn more:
- [@article@What is RESTful API? - RESTful API Explained - AWS](https://aws.amazon.com/what-is/restful-api/)
- [@article@What Is a REST API? Examples, Uses & Challenges ](https://blog.postman.com/rest-api-examples/)
- [@article@What Is a REST API? Examples, Uses & Challenges](https://blog.postman.com/rest-api-examples/)
@@ -1,21 +1,6 @@
# Short Term Memory
# Short-Term Memory
Short term memory are the facts which are passed as a part of the prompt to the LLM e.g. there might be a prompt like below:
Users Profile:
- name: {name}
- age: {age}
- expertise: {expertise}
User is currently learning about {current_topic}. User has some goals in mind which are:
- {goal_1}
- {goal_2}
- {goal_3}
Help the user achieve the goals.
Notice how we injected the user's profile, current topic and goals in the prompt. These are all short term memories.
Short-term memory refers to the immediate, transient information that an AI agent holds during a specific task or conversation. It is typically implemented by including recent interaction history, active goals, and relevant context directly within the model's prompt window. This data allows the agent to maintain coherence and follow the flow of a single session, though this information is usually cleared once the context limit is reached or the session ends.
Visit the following resources to learn more:
@@ -1,8 +1,6 @@
# Streamed vs Unstreamed Responses
Streamed and unstreamed responses describe how an AI agent sends its answer to the user. With a streamed response, the agent starts sending words as soon as it generates them. The user sees the text grow on the screen in real time. This feels fast and lets the user stop or change the request early. It is useful for long answers and chat-like apps.
An unstreamed response waits until the whole answer is ready, then sends it all at once. This makes the code on the client side simpler and is easier to cache or log, but the user must wait longer, especially for big outputs. Choosing between the two depends on the need for speed, the length of the answer, and how complex you want the client and server to be.
An unstreamed response waits until the model finishes generating the entire output before returning anything to the caller. A streamed response sends tokens back as they are generated, so the caller can start displaying or processing output immediately. Streaming improves perceived responsiveness in user facing applications, while unstreamed responses are simpler to handle when the full output is needed before continuing.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Structured Logging & Tracing
Structured logging and tracing are ways to record what an AI agent does so you can find and fix problems fast. Instead of dumping plain text, the agent writes logs in a fixed key-value format, such as time, user\_id, step, and message. Because every entry follows the same shape, search tools can filter, sort, and count events with ease. Tracing links those log lines into a chain that follows one request or task across many functions, threads, or microservices. By adding a unique trace ID to each step, you can see how long each part took and where errors happened. Together, structured logs and traces offer clear, machine-readable data that helps developers spot slow code paths, unusual behavior, and hidden bugs without endless manual scans.
Structured logging and tracing record an agent's execution in a consistent, machine readable format, capturing details like which tool was called, what arguments were used, and how long each step took. Unlike plain text logs, structured data can be filtered, searched, and analyzed programmatically. Tracing connects these individual log entries into a full picture of a single run, which is essential for debugging complex, multi step agent behavior.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Summarization / Compression
Summarization or compression lets an AI agent keep the gist of past chats without saving every line. After a talk, the agent runs a small model or rule set that pulls out key facts, goals, and feelings and writes them in a short note. This note goes into long-term memory, while the full chat can be dropped or stored elsewhere. Because the note is short, the agent spends fewer tokens when it loads memory into the next prompt, so costs stay low and speed stays high. Good summaries leave out side jokes and filler but keep names, dates, open tasks, and user preferences. The agent can update the note after each session, overwriting old points that are no longer true. This process lets the agent remember what matters even after hundreds of turns.
Summarization or compression reduces the size of stored or in context information by condensing it into a shorter form that keeps the key details. This is used when conversation history or retrieved data grows too large to fit within a context window. Compressing older information lets an agent retain the gist of past interactions without spending excessive tokens on the full detail.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Tokenization
Tokenization is the step where raw text is broken into small pieces called tokens, and each token is given a unique number. A token can be a whole word, part of a word, a punctuation mark, or even a space. The list of all possible tokens is the models vocabulary. Once text is turned into these numbered tokens, the model can look up an embedding for each number and start its math. By working with tokens instead of full sentences, the model keeps the input size steady and can handle new or rare words by slicing them into familiar sub-pieces. After the model finishes its work, the numbered tokens are turned back into text through the same vocabulary map, letting the user read the result.
Tokenization is the process of breaking text into smaller units called tokens, which can be whole words, parts of words, or individual characters depending on the tokenizer. A language model does not read raw text, it reads a sequence of token IDs mapped from these units. The choice of tokenizer affects how many tokens a piece of text uses, which in turn affects cost and context limits.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Tool Definition
A tool is any skill or function that an AI agent can call to get a job done. It can be as simple as a calculator for math or as complex as an API that fetches live weather data. Each tool has a name, a short description of what it does, and a clear list of the inputs it needs and the outputs it returns. The agents planner reads this definition to decide when to use the tool. Good tool definitions are precise and leave no room for doubt, so the agent will not guess or misuse them. They also set limits, like how many times a tool can be called or how much data can be pulled, which helps control cost and errors. Think of a tool definition as a recipe card the agent follows every time it needs that skill.
A tool definition describes a function an agent can call, including its name, purpose, and the parameters it accepts, usually specified in a structured format like JSON schema. The language model reads this definition to decide when the tool is relevant and how to fill in its arguments. Clear, well documented tool definitions directly affect how reliably an agent chooses and uses the right tool.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Transformer Models and LLMs
Transformer models are a type of neural network that read input data—like words in a sentence—all at once instead of one piece at a time. They use “attention” to find which parts of the input matter most for each other part. This lets them learn patterns in language very well. When a transformer has been trained on a very large set of text, we call it a Large Language Model (LLM). An LLM can answer questions, write text, translate languages, and code because it has seen many examples during training. AI agents use these models as their “brains.” They feed tasks or prompts to the LLM, get back text or plans, and then act on those results. This structure helps agents understand goals, break them into steps, and adjust based on feedback, making them useful for chatbots, research helpers, and automation tools.
Transformers are a neural network architecture that process sequences of tokens using a mechanism called attention, which lets the model weigh the relevance of different parts of the input to each other. Large language models (LLMs) are transformers trained on massive amounts of text to predict the next token in a sequence. This next token prediction, repeated many times, is what lets an LLM generate coherent text, answer questions, and follow instructions.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Understand the Basics of RAG
RAG, short for Retrieval-Augmented Generation, is a way to make language models give better answers by letting them look things up before they reply. First, the system turns the users question into a search query and scans a knowledge source, such as a set of documents or a database. It then pulls back the most relevant passages, called “retrievals.” Next, the language model reads those passages and uses them, plus its own trained knowledge, to write the final answer. This mix of search and generation helps the model stay up to date, reduce guesswork, and cite real facts. Because it adds outside information on demand, RAG often needs less fine-tuning and can handle topics the base model never saw during training.
Retrieval Augmented Generation (RAG) is a technique where relevant documents or data are fetched from an external source and added to a model's prompt before it generates a response. This lets the model answer questions using information it was not originally trained on, such as private documents or recent data. RAG typically combines a retrieval step, often using vector search, with a generation step handled by the LLM.
Visit the following resources to learn more:
@@ -1,6 +1,6 @@
# Use relevant technical terms
When a task involves a special field such as law, medicine, or computer science, include the correct domain words in your prompt so the AI knows exactly what you mean. Ask for “O(n log n) sorting algorithms” instead of just “fast sorts,” or “HTTP status code 404” instead of “page not found error.” The right term narrows the topic, removes guesswork, and points the model toward the knowledge base you need. It also keeps the answer at the right level, because the model sees you understand the field and will reply with matching depth. Check spelling and letter case; “SQL” and “sql” are seen the same, but “Sequel” is not. Do not overload the prompt with buzzwords—add only the words that truly matter. The goal is clear language plus the exact technical labels the subject uses.
Using relevant technical terms means including precise vocabulary from the domain of the task instead of describing things in vague, general language. A model trained on technical text responds better to prompts phrased the way experts in that field would phrase them. This reduces ambiguity and helps the model retrieve and apply the right knowledge for the task.
Visit the following resources to learn more: