# AI Jargons - Plain-Language Glossary > Practical definitions, real-world use cases, and simple explanations for the AI terms that matter most to builders and operators. **URL:** https://aigarage.in/jargons **Total terms:** 21 --- ### Large Language Model **Category:** LLM **Tags:** beginner, generation, transformer, language-model A neural network trained on large language datasets to estimate token probabilities and generate or transform sequences from the context it receives. **In plain terms:** It predicts a useful next piece of language, adds that piece to the context, and repeats the process until it has produced a response. **Use cases:** - Conversational assistants - Summarization and structured extraction - Drafting and code generation **Why it matters:** An LLM can perform many language tasks through one general interface, but its output is generated from learned patterns and current context. Product reliability still depends on evidence, evaluation, validation, and the workflow around the model. **Why now:** LLMs increasingly sit inside products that also retrieve documents, call tools, process long context, and enforce structured outputs. Builders therefore need to distinguish the language model from the larger application that supplies evidence and controls actions. **AI Garage example:** An AI Garage build-workbook assistant could use an LLM to turn approved session evidence into a clear instructional section. Retrieval chooses the relevant evidence, application code checks the required structure, and the LLM performs the language transformation. **Mental model:** An LLM is a context-conditioned token predictor used repeatedly. It converts the available context into probabilities for the next token, selects a token, appends it, and runs again. Training shapes those probabilities; the surrounding product supplies current evidence, tools, limits, and validation. **Builder scenario: Draft a support answer without confusing fluency with truth** - **Context:** A support assistant receives a customer question and an approved policy passage, then asks an LLM to produce a concise answer. - **Failure:** The application treats the model's fluent response as a database lookup and displays a plausible exception that the supplied policy does not support. - **Intervention:** Give the model only the relevant policy evidence, require a structured answer with supporting excerpts, and validate consequential claims before displaying them. - **Outcome:** Supported answers include the policy evidence used, while unsupported requests produce an explicit uncertainty or review path instead of an invented rule. **Common misconceptions:** - **Claim:** Calling an LLM a next-token predictor means it behaves like simple phone autocomplete. **Correction:** Next-token prediction describes the generation mechanism. A large neural network can use extensive context and learned representations to perform many transformations, but that capability still does not guarantee factual or logically correct output. **Visual model (sequence):** A response is built through repeated token prediction. Fluency comes from learned language patterns, while factual support must come from the evidence and checks around the model. **Visual description:** An LLM receives tokenized context, estimates probabilities for the next token, appends a selected token, and repeats that cycle until it produces a response. **Related concepts:** [Token](https://aigarage.in/jargons/token), [Context Window](https://aigarage.in/jargons/context-window), [Neural Network](https://aigarage.in/jargons/neural-network), [Hallucination (AI)](https://aigarage.in/jargons/ai-hallucination) **Video explainer:** [Large Language Model: predict, append, repeat](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/llm/v2/llm.mp4) (50 seconds) See how tokenized context becomes next-token probabilities, how repeated prediction builds a response, and why the surrounding application must verify consequential claims. **Published:** 2026-10-11T21:02:02+05:30 **Captions:** [English](https://aigarage.in/jargons/llm/captions.vtt) **Narration:** generated **Transcript:** A customer asks a support assistant if they can get a refund. A large language model writes the reply. It does not look the answer up. It predicts the next small piece of text, called a token. It reads the question and the refund policy, then scores which tokens could come next. One token is picked and added to the text. Then it predicts again. Repeat that many times, and a full reply appears. That is like phone autocomplete, but far more capable, because it uses much more context. Still, a fluent reply is not a verified one. So the application around the model supplies current evidence, checks key claims, and controls any action. The model writes the language. Your application decides what it is allowed to become. **Last researched:** 2026-10-11 **Sources:** - [Google for Developers - Introduction to Large Language Models](https://developers.google.com/machine-learning/crash-course/llm) - [Google for Developers - What's a large language model?](https://developers.google.com/machine-learning/crash-course/llm/transformers) **URL:** https://aigarage.in/jargons/llm --- ### Decision Model **Category:** Machine Learning **Tags:** agents, classification, decision-making, routing A model designed to make structured judgments or choose between possible actions, returning scores or probabilities instead of primarily generating open-ended text. **In plain terms:** A language model is often asked what to say next. A decision model is asked which option to choose, whether something is true, or how strongly something scores. **Use cases:** - Routing requests to the right workflow - Checking whether an action meets a policy - Scoring or ranking possible decisions **Why it matters:** Agents often need many small, repeatable judgments. A specialized decision model can make those steps more explicit and structured instead of asking a general-purpose LLM to generate an answer every time. **Why now:** Decision models are becoming easier to use inside normal AI stacks. Since version 0.35, Ollama has exposed Jev-style decision models through a dedicated endpoint, with local models for bounded choices, true-or-false judgments, and rubric scores. **AI Garage example:** In an assistant like Shushi, a decision model could sit before the main language model and judge things such as: Is this message asking for a calendar action? Does the assistant have enough information to act? Should it reply, ask a follow-up question, or do nothing? The language model can then handle the parts that actually need language generation. **Mental model:** A decision model is a gate in front of an action. It evaluates a bounded question and returns a structured judgment, so the rest of the system can follow a clear route. **Builder scenario: Route a Shushi request before generation** - **Context:** Shushi receives a message that may require a calendar action, a follow-up question, a normal reply, or no action. - **Failure:** Sending every message directly to the main language model mixes routing decisions with language generation and makes the action boundary harder to inspect. - **Intervention:** A decision model first scores the message against the allowed routes and returns the selected route as structured data. - **Outcome:** Shushi can invoke the language model only when language is needed and handle the remaining routes with explicit workflow logic. **Common misconceptions:** - **Claim:** A decision model is just another name for a language model. **Correction:** A language model is commonly used to generate open-ended text. A decision model is used for bounded judgments such as choosing, ranking, scoring, or checking. **Visual model (system):** The decision model makes the route explicit before any language is generated or action is taken. **Visual description:** An incoming Shushi message passes through a decision model and is routed to a calendar action, follow-up question, generated reply, or no action. **Related concepts:** [Large Language Model](https://aigarage.in/jargons/llm) **Video explainer:** [Decision Model: a structured judgment before action](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/decision-model/v2/decision-model.mp4) (48 seconds) See how a scheduling assistant scores four allowed options, returns a result that is only data, passes it through explicit workflow checks, changes the calendar, and only then asks a language model to write the confirmation. **Published:** 2026-10-11T21:02:07+05:30 **Captions:** [English](https://aigarage.in/jargons/decision-model/captions.vtt) **Narration:** generated **Transcript:** A learner asks a scheduling assistant to move Friday's workshop to four. It could reply right away, but replying is not the same as deciding. First, a decision model steps in. It scores a fixed set of options and picks one. Here, the four options are changing the calendar, asking a question, writing a reply, or doing nothing. The scores settle, and the calendar option wins. That result is just data. It does not change anything yet. Ordinary workflow code checks the event, the person's permission, and the policy. Only then does the calendar change. Now a language model can write the confirmation. A decision model makes one narrow judgment. Your workflow decides what that judgment is allowed to do. **Last researched:** 2026-10-11 **Sources:** - [Ollama now supports Jev-style decision models](https://ollama.com/blog/ollama-now-supports-jev-style-decision-models) - [Ollama - Tev1 decision model and API reference](https://ollama.com/library/tev1) - [Together AI - Tev1 training and evaluation repository](https://github.com/togethercomputer/tev1) **URL:** https://aigarage.in/jargons/decision-model --- ### Prompt Engineering **Category:** Prompting **Tags:** beginner, instructions, evaluation, quality The iterative practice of designing instructions, context, examples, and output constraints so a model performs a defined task more reliably. **In plain terms:** It is writing a clear handoff for the AI, then testing the results and improving the handoff when it fails. **Use cases:** - Consistent support-ticket summaries - Structured extraction and classification - Task-specific AI workflows **Why it matters:** A production prompt defines the job, supplies relevant evidence, and makes the expected result inspectable. Testing it on representative inputs reveals where instructions or context still fail. **Why now:** Model families and even snapshots can respond differently to the same prompt. Current platform guidance therefore pairs prompt iteration with pinned model versions and repeatable evaluations instead of treating one successful response as proof of reliability. **AI Garage example:** For an AI Garage build-workbook workflow, the prompt could identify the source session, define the required section structure, distinguish evidence from interpretation, and include a small evaluation set that checks whether every step has an action, reason, and observable result. **Mental model:** Treat a prompt as a versioned task specification, not a magic phrase. It combines the goal, relevant context, constraints, examples, and output shape. Representative evaluations show whether that specification works and where the next revision should focus. **Builder scenario: Make support summaries testable** - **Context:** A support workflow asks a language model to turn incoming tickets into a short summary with an issue type, urgency, and recommended next action. - **Failure:** A vague request such as 'summarize this ticket' produces changing formats, occasionally omits urgency, and invents a next action when the ticket lacks enough evidence. - **Intervention:** Define the required fields and evidence boundary, provide representative examples, request a structured output, and run the prompt against a fixed evaluation set after each change. - **Outcome:** The workflow can validate every response for the required fields, compare prompt versions on the same cases, and route unsupported recommendations for review instead of silently accepting them. **Common misconceptions:** - **Claim:** Prompt engineering is finding one clever phrase that makes the model reliable. **Correction:** Reliable prompting is an iterative design and evaluation process. Clear instructions help, but model choice, context, tools, validation, and representative tests still matter. **Visual model (sequence):** The prompt improves through a measured loop. A polished first response is not a substitute for repeatable evaluation. **Visual description:** Prompt engineering moves from defining success to composing instructions and context, testing representative cases, and revising from observed failures. **Related concepts:** [Context Window](https://aigarage.in/jargons/context-window), [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [Fine-tuning](https://aigarage.in/jargons/fine-tuning) **Video explainer:** [Prompt Engineering: a testable handoff, not a magic phrase](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/prompt-engineering/v2/prompt-engineering.mp4) (43 seconds) See how a vague support-summary request becomes a versioned task specification with explicit evidence, output constraints, representative tests, and revisions based on observed failures. **Published:** 2026-10-12T11:59:37+05:30 **Captions:** [English](https://aigarage.in/jargons/prompt-engineering/captions.vtt) **Narration:** generated **Transcript:** A support team asks a model to summarize a ticket. One answer is a paragraph. Another leaves out urgency. A third invents a next step nobody requested. Prompt engineering starts by replacing that vague request with a clear task. Say which fields are needed, and what evidence the model may use. Show one example, and the shape the answer should take. Say what to do when the evidence is missing. Then run the prompt on the same set of real tickets. Look at where it fails, change the prompt, and test again. Magic phrases fail. One good answer proves little. Prompt engineering is a measured loop, not a lucky guess. **Last researched:** 2026-10-11 **Sources:** - [OpenAI API - Prompt engineering](https://developers.openai.com/api/docs/guides/prompt-engineering) - [OpenAI API - Model optimization](https://developers.openai.com/api/docs/guides/model-optimization) **URL:** https://aigarage.in/jargons/prompt-engineering --- ### Token **Category:** Beginner **Tags:** beginner, tokenization, pricing, context-window A unit produced when a model's tokenizer converts input or output into model-readable pieces. A token can be a word, part of a word, punctuation, whitespace, or another encoded unit. **In plain terms:** Before a model reads or writes text, a tokenizer cuts it into numbered pieces. Those pieces are tokens, and they do not line up one-for-one with words. **Use cases:** - Estimating API usage - Managing context-window capacity - Reserving space for complete outputs **Why it matters:** Models measure context capacity and many APIs measure usage in tokens. Counting the actual request helps builders avoid truncation, size work correctly, and estimate cost without relying on word-count guesses. **Why now:** AI requests increasingly include message roles, tool definitions, images, files, and prior conversation state. Current token-counting APIs account for request structure that a simple text or character estimate can miss. **AI Garage example:** Before turning a long coding session into a build workbook, an AI Garage workflow could count the complete model input, reserve output space, and retrieve only the source passages needed for the current section. **Mental model:** A tokenizer is the model's packing rule. It converts content into token IDs before inference and converts generated IDs back into content. The rule depends on the selected model or encoding, so the same visible text can occupy a different number of tokens elsewhere. **Builder scenario: Fit a build session into one model request** - **Context:** A builder sends a long coding-session transcript, instructions, tool definitions, and source excerpts to a model that must produce a complete workbook section. - **Failure:** The workflow estimates size from word count alone, misses tokens added by request structure, and leaves too little capacity for the generated section. - **Intervention:** Count the complete request with the selected model's tokenizer or token-counting endpoint, remove irrelevant material, and reserve a defined portion of the context window for output. - **Outcome:** The request stays within the selected model's limit and the model has enough remaining capacity to return the complete workbook section. **Common misconceptions:** - **Claim:** One token is one word. **Correction:** A token can be a whole word, a word fragment, punctuation, whitespace, or another encoded unit. Segmentation varies by model, encoding, language, and content. **Visual model (sequence):** Tokens are model-readable units, not a universal synonym for words. The selected model and full request shape determine the count. **Visual description:** A visible request is converted by a model-specific tokenizer into token IDs that consume a shared context budget, so the complete request should be counted with the selected model's method. **Related concepts:** [Context Window](https://aigarage.in/jargons/context-window), [Large Language Model](https://aigarage.in/jargons/llm), [API](https://aigarage.in/jargons/api) **Video explainer:** [Token: the model's unit of context](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/token/v2/token.mp4) (47 seconds) See how a complete AI request becomes model-specific tokens, why tokens do not map one-to-one with words, and how builders protect enough context capacity for the answer. **Published:** 2026-10-12T11:59:37+05:30 **Captions:** [English](https://aigarage.in/jargons/token/captions.vtt) **Narration:** generated **Transcript:** A model reads tokens, not words. A tokenizer first cuts your sentence into numbered pieces called tokens. A common word may be one token. A long word may be several. Punctuation, spaces and other languages change where the cuts fall. Different models cut text differently, too. Your request holds more than the text you typed. Roles, tools, files and images all add tokens. A long file can use up the budget fast. Every token counts against one shared budget, with the answer included. So token counts and word counts differ. For a big request, count everything with the model's own method. Cut anything unneeded, and leave room for the answer. **Last researched:** 2026-10-11 **Sources:** - [OpenAI API - Key concepts: tokens](https://developers.openai.com/api/docs/concepts) - [OpenAI API - Counting tokens](https://developers.openai.com/api/docs/guides/token-counting) - [OpenAI - tiktoken](https://github.com/openai/tiktoken) **URL:** https://aigarage.in/jargons/token --- ### Embeddings **Category:** Machine Learning **Tags:** vector, retrieval, search Numeric vector representations of text, images, or other data that preserve useful patterns so related items can be compared by similarity or distance. **In plain terms:** A way to turn text into numbers so AI can compare meaning, not just exact words. **Use cases:** - Semantic search - Recommendation systems - RAG document retrieval **Why it matters:** Embeddings let applications retrieve related material even when the query and source use different words. Their usefulness still depends on the embedding model, source quality, chunking, and retrieval design. **Why now:** As builders connect AI systems to private documents and product data, embeddings remain a common foundation for semantic retrieval, recommendations, and RAG. **AI Garage example:** An AI Garage workshop assistant could embed approved workshop notes and a learner's question, retrieve the nearest source passages, and pass the original text of those passages to the answering model. **Mental model:** An embedding places each item at a point in a model-made map. Items the model considers related tend to land closer together, so a system can retrieve nearby candidates before working with their original content. **Builder scenario: Find the right workshop passage without exact keywords** - **Context:** A learner asks a workshop assistant, 'What does the builder cohort cost?' The approved notes describe the same topic as the 'program fee.' - **Failure:** An exact keyword search can miss the relevant passage because the question and source use different words. - **Intervention:** Embed the learner's question and the approved note chunks with the same embedding model. Retrieve the nearest chunks, then give their original text to the answering model. - **Outcome:** The program-fee passage appears among the retrieved candidates even though the question used the word 'cost,' and the final answer can be grounded in the source text. **Common misconceptions:** - **Claim:** Each embedding dimension is a human-readable feature such as price, topic, or sentiment. **Correction:** The dimensions are learned numerical features whose individual meanings are usually not interpretable. The useful signal comes from relationships between complete vectors. **Visual model (system):** Embedding distance helps rank likely matches. The system still passes the original retrieved text to the next step. **Visual description:** A learner question about cohort cost sits closest to a passage about the program fee, while a schedule passage and an unrelated passage sit progressively farther away in the embedding map. **Related concepts:** [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [Token](https://aigarage.in/jargons/token) **Video explainer:** [Embeddings: find related meaning beyond exact words](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/embeddings/v2/embeddings.mp4) (47 seconds) See how a learner's question and approved source passages become vectors, settle into an illustrative similarity map, and lead the system back to the original supporting text. **Published:** 2026-10-12T11:59:38+05:30 **Captions:** [English](https://aigarage.in/jargons/embeddings/captions.vtt) **Narration:** generated **Transcript:** A learner asks an assistant what the builder cohort costs. The notes say program fee, so a keyword search for cost can miss them. An embedding model turns the question and each passage into a list of numbers. Those lists place meaning on a map, where similar ideas sit close together. The program fee passage lands nearest to the question. The schedule and an unrelated passage stay farther away. That distance ranks the likely matches. Then the system fetches the original passage and gives it to the answering model. The numbers do not hold the fee, and they prove nothing. They are only a similarity signal. Embeddings help find where to look. The source still has to support the answer. **Last researched:** 2026-10-11 **Sources:** - [OpenAI API - Vector embeddings](https://developers.openai.com/api/docs/guides/embeddings) - [Google Cloud - Get text embeddings](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/embeddings/get-text-embeddings) **URL:** https://aigarage.in/jargons/embeddings --- ### Fine-tuning **Category:** Machine Learning **Tags:** customization, model-training, evaluation, parameters Additional training that uses representative examples or feedback to update a pretrained model's parameters for a more specific task or behavior. **In plain terms:** It changes an existing model by training it on examples of how you want a particular task performed. **Use cases:** - Consistent structured outputs - Task-specific classification - Specialized response behavior **Why it matters:** Fine-tuning can make a repeated behavior more consistent or reduce the instructions needed at inference time. It also creates a new model version that must be evaluated, deployed, and maintained like any other trained artifact. **Why now:** Current model platforms offer supervised and preference-based tuning for specialized behavior. Their guidance still starts with a prompt baseline, representative evaluation data, and high-quality training examples before adding the cost and operational work of tuning. **AI Garage example:** After collecting and reviewing many session-to-workbook examples, AI Garage could fine-tune a model to produce a consistent workbook structure. The current session evidence would still be supplied at inference time rather than treated as reliable factual memory inside the tuned model. **Mental model:** Prompting changes what a model sees for one request. Retrieval adds temporary evidence. Fine-tuning changes learned parameters through a separate training run, producing a model version whose behavior must be tested before it replaces the previous version. **Builder scenario: Improve a repeated extraction task without baking in current facts** - **Context:** A support workflow repeatedly converts varied customer messages into the same reviewed JSON schema, but a prompt with several examples is long and still produces recurring format errors. - **Failure:** The team fine-tunes on a small, inconsistent dataset and assumes the new model will also remember every future policy change, so format regressions remain and answers become stale. - **Intervention:** Create representative training and holdout sets from reviewed examples, fine-tune for the extraction behavior, evaluate the new model against the prompt baseline, and continue supplying current policy evidence separately. - **Outcome:** The evaluated tuned model returns the required schema more consistently with shorter instructions, while policy updates remain available immediately through the runtime evidence path. **Common misconceptions:** - **Claim:** Fine-tuning is the best way to upload documents so a model always knows their latest facts. **Correction:** Fine-tuning changes model behavior through training. Current or frequently changing facts are usually better supplied at request time through prompts or retrieval, where the source can be updated and inspected. **Visual model (system):** Fine-tuning changes a model version through training. Prompting and retrieval remain separate runtime paths for instructions and current evidence. **Visual description:** A base model and reviewed examples enter a separate parameter-update process that produces a tuned model version, which is tested on a holdout evaluation before deployment. **Related concepts:** [Prompt Engineering](https://aigarage.in/jargons/prompt-engineering), [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [Inference](https://aigarage.in/jargons/inference), [Large Language Model](https://aigarage.in/jargons/llm) **Video explainer:** [Fine-tuning: change behavior through training](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/fine-tuning/v2/fine-tuning.mp4) (52 seconds) See how reviewed examples update model parameters, how holdout evaluation protects deployment, and why current facts still belong in the runtime evidence path. **Published:** 2026-10-11T21:02:07+05:30 **Captions:** [English](https://aigarage.in/jargons/fine-tuning/captions.vtt) **Narration:** generated **Transcript:** A support prompt fills in the right fields most of the time. Sometimes it misses. Fine-tuning is extra training that teaches an existing model your exact task. First, the team gathers reviewed examples of correct results. They keep some back, called a holdout, to test with later. Training then adjusts the model's internal settings, called parameters, and produces a new version. That version is not trusted yet. It runs on the held-back examples, next to the old prompt. If it does worse, the team blocks it. If it does better, the fields come out more consistently, with shorter instructions. But current policies still arrive with each request, through the prompt or a search step. Fine-tuning changes how a model behaves. It is not where changing facts should live. **Last researched:** 2026-10-11 **Sources:** - [Google Cloud - Introduction to tuning](https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/tune-models) - [Google for Developers - Fine-tuning, distillation, and prompt engineering](https://developers.google.com/machine-learning/crash-course/llm/tuning) - [OpenAI API - Optimizing LLM accuracy](https://developers.openai.com/api/docs/guides/optimizing-llm-accuracy) **URL:** https://aigarage.in/jargons/fine-tuning --- ### Hallucination (AI) **Category:** LLM **Tags:** risk, safety, beginner When a generative AI system produces plausible but false, unsupported, or internally inconsistent content. **In plain terms:** The AI sounds sure, but it made things up. **Use cases:** - Risk reviews in legal/finance - Fact-checking pipelines - Human approval workflows **Why it matters:** Fluent wording can make an unsupported claim look trustworthy. In consequential workflows, that can turn a generation error into a customer, compliance, or operational failure. **Why now:** Newer models reduce some hallucinations, but current primary research and risk guidance still treat confident false output as an unresolved problem that requires evaluation, grounding, abstention, and human review where stakes are high. **AI Garage example:** In an AI Garage example, Shushi, a WhatsApp AI assistant, could retrieve an approved policy passage, require the answer to point to that passage, and escalate when the source does not support a requested refund exception. **Mental model:** A language model is built to continue with plausible language. If the available evidence stops before the answer is complete, fluent generation can continue past the evidence boundary unless the surrounding system checks support or allows the model to abstain. **Builder scenario: Stop an unsupported refund exception** - **Context:** A customer asks a support assistant whether a workshop booking can receive a special refund. The approved policy explains standard refunds but contains no special exception for this case. - **Failure:** The model completes a helpful-sounding answer by inventing an exception that is not present in the approved policy. - **Intervention:** Retrieve the relevant policy, require every consequential claim to match a supporting passage, and instruct the workflow to abstain or escalate when the evidence is missing. - **Outcome:** The customer receives either a source-supported policy answer or a clear handoff for human review, rather than a fabricated exception. **Common misconceptions:** - **Claim:** Adding RAG or citations eliminates hallucinations. **Correction:** Retrieval and citations can reduce unsupported output, but retrieval can miss the right evidence and generated citations can themselves be wrong. The workflow must verify that the cited source actually supports the claim. **Visual model (sequence):** Fluency can continue after evidence ends. A reliable workflow makes that boundary visible and checks claims before they reach the user. **Visual description:** A customer question reaches an approved policy that does not contain the requested exception. Instead of continuing into an unsupported claim, the guarded workflow verifies support and abstains or escalates. **Related concepts:** [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [Large Language Model](https://aigarage.in/jargons/llm), [Decision Model](https://aigarage.in/jargons/decision-model) **Video explainer:** [Hallucination: fluency can continue after evidence ends](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/ai-hallucination/v2/ai-hallucination.mp4) (46 seconds) See how a support assistant crosses beyond an approved policy, then checks the unsupported claim, abstains, and routes the case for human review. **Published:** 2026-10-11T23:40:14+05:30 **Captions:** [English](https://aigarage.in/jargons/ai-hallucination/captions.vtt) **Narration:** generated **Transcript:** A customer asks an assistant for a special refund exception. The approved policy covers only standard refunds. A language model keeps writing plausible text, even when the evidence runs out. So it may invent a rule that sounds helpful and confident. That is a hallucination, fluent text that goes beyond what the evidence supports. Giving the model the policy helps, but it proves nothing. Even a citation can be wrong. A guarded workflow checks each important claim against the real passage. Here, nothing in the policy supports the exception. So the assistant says it is unable to confirm, and sends the case to a person. A polished sentence is no substitute for evidence. **Last researched:** 2026-10-11 **Sources:** - [OpenAI - Why language models hallucinate](https://openai.com/index/why-language-models-hallucinate/) - [NIST - Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1) **URL:** https://aigarage.in/jargons/ai-hallucination --- ### Neural Network **Category:** Machine Learning **Tags:** beginner, deep-learning, parameters, training A model made of connected layers that apply learned weights, biases, and nonlinear transformations to map input values to an output. **In plain terms:** It passes numbers through layers of adjustable calculations, then training changes those adjustments when the prediction is wrong. **Use cases:** - Image and speech recognition - Forecasting and classification - Language and generative models **Why it matters:** Neural networks can learn complex nonlinear patterns without a developer manually specifying every rule. Their outputs still depend on the architecture, training data, objective, parameter updates, and evaluation process. **Why now:** Large language models, multimodal models, and many recognition systems are built from deep neural networks. Understanding layers and learned parameters makes the distinction between training, inference, and model behavior easier to reason about. **AI Garage example:** An AI Garage workshop-routing model could convert form fields into numeric inputs, pass them through learned layers, and output route scores. Reviewed examples and a training objective would adjust the weights; production requests would use the fixed trained values for inference. **Mental model:** A neural network is a chain of parameterized mathematical transformations. Each layer combines incoming values with learned weights and biases, applies an activation function, and passes new values forward. Training uses prediction error to adjust the parameters; inference reuses the learned values on new input. **Builder scenario: Learn a nonlinear routing boundary from examples** - **Context:** A workshop team wants to route each request from several numeric and categorical signals, where no single field or simple threshold identifies the correct route. - **Failure:** A hand-written linear score misses combinations such as low urgency with a high-risk topic, and adding more brittle rules makes the system harder to maintain. - **Intervention:** Train a small neural network on reviewed examples, use hidden layers with nonlinear activations, measure prediction loss, and adjust the weights through backpropagation. - **Outcome:** On a held-out evaluation set, the trained network separates route combinations that the linear rule missed, while production inference uses the fixed evaluated parameters. **Common misconceptions:** - **Claim:** A neural network is a literal digital copy of a biological brain. **Correction:** Terms such as neuron and layer are useful analogies. The implemented system is a set of mathematical operations and learned parameters, not a simulation of how a whole brain works. **Visual model (system):** The layer diagram is a mathematical mental model. Training adjusts parameters from measured error; inference uses those learned values on new input. **Visual description:** Input values pass through a weighted layer and nonlinear activation to produce a prediction. During training, measured error feeds back to adjust the learned parameters. **Related concepts:** [Large Language Model](https://aigarage.in/jargons/llm), [Inference](https://aigarage.in/jargons/inference), [Fine-tuning](https://aigarage.in/jargons/fine-tuning), [Embeddings](https://aigarage.in/jargons/embeddings) **Video explainer:** [Neural Network: layered calculations learned from error](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/neural-network/v2/neural-network.mp4) (54 seconds) See input values cross weighted layers and nonlinear activations, then follow measured error backward as training adjusts parameters for later inference. **Published:** 2026-10-12T00:45:15+05:30 **Captions:** [English](https://aigarage.in/jargons/neural-network/captions.vtt) **Narration:** generated **Transcript:** A team wants to route requests, but one rule cannot pick the right route. A simple score misses combinations, like low urgency and a risky topic. A neural network learns those patterns from examples. Each connection multiplies a value by a number, called a weight. A node adds its inputs, then applies a bend, so the result is not a straight line. Layers of nodes pass results forward, until the network scores each route. At first the weights are random guesses. In training, the prediction is compared with the right answer. The error flows backward, and the weights are nudged to shrink it. After many examples, the weights capture the patterns. When deployed, the weights stay fixed. It is math tuned on data, like a brain only in name. **Last researched:** 2026-10-11 **Sources:** - [Google for Developers - Neural networks](https://developers.google.com/machine-learning/crash-course/neural-networks) - [Google for Developers - Nodes and hidden layers](https://developers.google.com/machine-learning/crash-course/neural-networks/nodes-hidden-layers) - [Google for Developers - Activation functions](https://developers.google.com/machine-learning/crash-course/neural-networks/activation-functions) - [Google for Developers - Training using backpropagation](https://developers.google.com/machine-learning/crash-course/neural-networks/backpropagation) **URL:** https://aigarage.in/jargons/neural-network --- ### API **Category:** Beginner **Tags:** integration, request-response, backend, developer An Application Programming Interface is a documented contract that lets one software system request data or operations from another and interpret the response or error. **In plain terms:** It is a service counter for software. Your app submits a request in the expected format, and the service returns a result or explains why it could not. **Use cases:** - Integrating AI models into products - Exchanging structured data between services - Orchestrating backend workflows **Why it matters:** An API creates a stable boundary between systems. Builders can validate inputs, authenticate callers, interpret status and error data, and change either side without exposing the service's internal implementation. **Why now:** Most production AI features reach models, tools, and data services through APIs. Reliable integrations must handle authentication, schemas, rate limits, transient failures, and request identifiers in addition to the successful response. **AI Garage example:** An AI Garage workshop assistant could send an authenticated request containing a learner's question to a model API, validate the returned structure, and show the answer only after checking for a successful response. Rate-limit or validation errors would follow separate workflow paths. **Mental model:** An API is a guarded boundary with a contract. A client sends an authenticated, structured request to an endpoint. The service validates and processes it, then returns a structured response or error. The client remains responsible for deciding what that result means and what happens next. **Builder scenario: Handle a model request beyond the happy path** - **Context:** A workshop assistant sends a learner's question to a model API and expects a structured answer that the product can display. - **Failure:** The integration assumes every call succeeds, ignores status and error data, and treats a timeout or rate-limit response as if it contained a valid answer. - **Intervention:** Authenticate the request, validate its input, check the HTTP status and response schema, log the request identifier, and retry only eligible transient failures with bounded backoff. - **Outcome:** Successful responses reach the learner in the expected shape, invalid requests fail visibly, and temporary service failures enter a limited recovery path instead of becoming fake answers or endless retries. **Common misconceptions:** - **Claim:** An API is an autonomous agent that decides what to do next. **Correction:** An API exposes operations through a contract. The calling application or workflow chooses when to call it, validates the result, handles errors, and decides the next action. **Visual model (sequence):** The API defines the exchange. It does not replace the workflow logic that validates results and handles failure paths. **Visual description:** A client sends a structured API request across a validated boundary. The service returns a response or error, and the client application decides how to handle that outcome. **Related concepts:** [Idempotency](https://aigarage.in/jargons/idempotency), [Inference](https://aigarage.in/jargons/inference), [Token](https://aigarage.in/jargons/token) **Video explainer:** [API: a contract between software systems](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/api/v2/api.mp4) (48 seconds) Follow a model API request across an authenticated boundary, through validation and processing, and back to client logic that must interpret success, errors, and retryable failures. **Published:** 2026-10-11T23:40:14+05:30 **Captions:** [English](https://aigarage.in/jargons/api/captions.vtt) **Narration:** generated **Transcript:** An app asks an AI model a question through an API. An API is a documented way for one program to ask another for something. The request carries an address, a login, and the question in the right format. Before any model runs, the service checks it. Is the caller allowed? Is the format right? Is it within limits? If all is well, the reply holds a success status and the answer. If not, the reply says what went wrong, such as invalid input or a timeout. The app reads that outcome, then shows the answer, rejects bad input, or retries a temporary failure. An API does not decide the workflow. It is a contract that includes a clear way to report failure. **Last researched:** 2026-10-11 **Sources:** - [RFC 9110 - HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html) - [OpenAI API - API overview](https://developers.openai.com/api/reference/overview) - [OpenAI API - Error codes](https://developers.openai.com/api/docs/guides/error-codes) **URL:** https://aigarage.in/jargons/api --- ### Idempotency **Category:** Beginner **Tags:** automation, api, webhooks, reliability The property that repeating the same operation has the same intended effect as doing it once, preventing retries from creating duplicate side effects. **In plain terms:** The same form submission can arrive more than once, but your system still creates only one record. **Use cases:** - Processing retried webhooks - Safely repeating API requests - Preventing duplicate records in automated workflows **Why it matters:** Reliable automations retry work when networks or downstream services fail. Idempotency lets those retries recover without duplicating records or repeating the intended action. **AI Garage example:** In an AI Garage-style Tally to n8n to Supabase workflow, the Tally submission ID can act as the idempotency key. A unique database constraint and upsert turn repeated webhook deliveries into one stored submission. **Mental model:** Idempotency gives an operation a durable identity. When the same operation arrives again, the system recognizes that identity and returns or preserves the first intended result instead of repeating the side effect. **Builder scenario: Deduplicate a retried form submission** - **Context:** A form tool sends each submission to a workflow that saves it in a database. The form tool retries the delivery when the workflow does not confirm in time. - **Failure:** If every delivery adds a new row, one submission can create duplicate lead or booking records when the delivery is retried. - **Intervention:** Pass the form tool's submission ID through the workflow and store it in a column that must be unique. Save with that ID so the first delivery creates the row and later deliveries update the same record. - **Outcome:** Repeated deliveries of the same submission resolve to one database row, while a genuinely new submission still creates a new row. **Common misconceptions:** - **Claim:** Idempotency means an operation runs only once. **Correction:** The operation may be attempted several times. Idempotency means those attempts have the same intended effect as one attempt. **Visual model (comparison):** Retries are safe when every delivery carries the same durable identity and the database enforces it. **Visual description:** Without idempotency, three deliveries of submission sub_4f21 create three database rows. With idempotency, the same deliveries resolve to one row through a unique operation key. **Related concepts:** [API](https://aigarage.in/jargons/api) **Video explainer:** [Idempotency: one submission, one result](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/idempotency/v4/idempotency.mp4) (50 seconds) See how a retried form submission can create duplicate database rows, and how a stable submission ID plus a one-row-per-ID rule keeps one intended result. **Published:** 2026-10-12T16:18:47+05:30 **Captions:** [English](https://aigarage.in/jargons/idempotency/captions.vtt) **Narration:** generated **Transcript:** One person submits a form. Three records appear. The form tool sends the submission to a workflow, but the workflow is slow to confirm. So the form tool tries again, and again. The same submission now arrives three times. If the workflow adds a new row each time, one person becomes three records. Idempotency fixes this by giving every submission a stable identity, like a submission ID. The workflow saves with that ID, and a database rule allows only one row per ID. The first delivery creates the row. The retries find the same ID and update the existing row. Retries still happen. Idempotency makes them harmless. Many attempts, same effect as one. **Last researched:** 2026-10-09 **Sources:** - [RFC 9110 - HTTP Semantics: Idempotent Methods](https://www.rfc-editor.org/rfc/rfc9110.html#section-9.2.2) - [Tally - Webhooks](https://tally.so/help/webhooks) - [Supabase - JavaScript: Upsert](https://supabase.com/docs/reference/javascript/upsert) **URL:** https://aigarage.in/jargons/idempotency --- ### RAG (Retrieval-Augmented Generation) **Category:** LLM **Tags:** retrieval, knowledge-base, grounding A pattern that retrieves relevant source material and gives it to a language model as context before it generates an answer. **In plain terms:** The AI gets an open-book step. It looks up useful notes, puts the best ones beside the question, and then writes the answer. **Use cases:** - Internal knowledge assistants - Policy and documentation Q&A - Customer support answers grounded in approved material **Why it matters:** RAG can make answers more grounded and inspectable because the knowledge source can be updated independently and the retrieved passages can be shown. Reliability still depends on source quality, retrieval quality, and generation. **AI Garage example:** Example: an AI Garage workshop assistant could retrieve from approved facilitator guides and setup notes before answering a participant, then cite the document it used. **Mental model:** Think of RAG as an open-book step at answer time. A retriever searches an external knowledge source for material related to the question. The selected passages become temporary context for the language model, which uses them while generating the response. The documents are not baked into the model, and weak retrieval can still lead to a weak answer. **Builder scenario: Answer from the latest workshop handbook** - **Context:** Imagine an AI Garage workshop assistant that answers participant questions from approved facilitator guides, workbook templates, and setup notes. - **Failure:** A language model answering from its built-in knowledge may give a generic response, miss a recent workshop change, or confidently fill a gap that the handbook does not cover. - **Intervention:** Index the approved workshop documents. For each question, retrieve the most relevant passages and place them, with their source titles, into the model's context before asking it to answer. - **Outcome:** The participant receives an answer tied to the current workshop material and can inspect the cited source. When retrieval finds no relevant passage, the assistant can say that the handbook does not provide an answer. **Common misconceptions:** - **Claim:** RAG teaches the model the retrieved documents. **Correction:** RAG normally supplies retrieved material as temporary context during a request. It does not update the model's trained parameters in the way fine-tuning does. - **Claim:** Adding RAG makes every answer correct. **Correction:** RAG can ground an answer only in what it successfully retrieves. Poor sources, missing passages, weak ranking, or unsupported generation can still produce a bad answer. **Visual model (system):** RAG changes what the model can consult during a request. The retriever finds evidence first; the model then generates an answer from that temporary context. **Visual description:** A question and an external knowledge source feed a retriever. The retriever selects relevant evidence, which is placed in the language model's context to produce a grounded answer with a source. **Related concepts:** [Embeddings](https://aigarage.in/jargons/embeddings), [Context Window](https://aigarage.in/jargons/context-window), [Large Language Model](https://aigarage.in/jargons/llm), [Hallucination (AI)](https://aigarage.in/jargons/ai-hallucination) **Video explainer:** [RAG: find evidence, then answer](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/rag/v2/rag.mp4) (48 seconds) See how retrieval finds and ranks approved workshop material, places selected evidence into temporary context, and helps a language model produce a sourced answer. **Published:** 2026-10-11T23:40:13+05:30 **Captions:** [English](https://aigarage.in/jargons/rag/captions.vtt) **Narration:** generated **Transcript:** A learner asks a workshop assistant what changed in the setup. A language model only knows what it learned in training. It may guess. RAG adds a lookup first. The question becomes a search. A retriever, the part that searches, scans approved guides and setup notes. It ranks the passages and picks the best ones. Those passages go into the model's context, the text it reads for this request. Now it can answer from them and point back to the source. The documents do not train the model. The answer is grounded and checkable, but it is not a truth machine. If the source is wrong, or the search misses the right passage, the answer can still fail. RAG changes what the model can read before it speaks. **Last researched:** 2026-10-10 **Sources:** - [Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks](https://papers.neurips.cc/paper/2020/file/6b493230205f780e1bc26945df7481e5-Paper.pdf) - [Google Cloud - Vertex AI APIs for building search and RAG experiences](https://docs.cloud.google.com/generative-ai-app-builder/docs/builder-apis) - [Google Cloud - Check grounding with RAG](https://docs.cloud.google.com/generative-ai-app-builder/docs/check-grounding) **URL:** https://aigarage.in/jargons/rag --- ### Multimodal AI **Category:** LLM **Tags:** vision, audio, video, generation An AI model or system that can process or generate more than one modality, such as text, images, audio, or video, within one task or workflow. **In plain terms:** It can work with more than one kind of information at once, such as reading a question while inspecting an image or listening to audio. **Use cases:** - Document and screenshot analysis - Audio or video summarization - Voice and visual assistants **Why it matters:** Many real tasks arrive as mixed evidence rather than clean text. Combining the relevant modalities can preserve relationships between a written request, a visual region, a sound, or a moment in a video that separate pipelines might lose. **Why now:** Current developer APIs can accept combinations of text, images, audio, and video for analysis or generation. Support still varies by model, direction, resolution, duration, latency, and cost, so modality capabilities must be checked rather than assumed. **AI Garage example:** An AI Garage workshop assistant could receive a participant's written question, an automation screenshot, and a short spoken explanation. A multimodal workflow could return a structured diagnosis that links each claim to visible evidence or a transcript timestamp. **Mental model:** Each modality is encoded into model-readable representations, with modality-specific processing and limits. A multimodal model or coordinated system relates those representations within one task, then produces only the output types it explicitly supports. **Builder scenario: Diagnose an automation issue from mixed evidence** - **Context:** A learner submits a text question, a screenshot of a failed automation, and a voice note describing what happened immediately before the error. - **Failure:** A text-only workflow sees only the typed question, misses the error shown in the screenshot, and loses the timing detail contained in the voice note. - **Intervention:** Use a model or coordinated pipeline that supports the three input modalities, preserve source references, and request a structured diagnosis with screenshot regions and transcript timestamps. - **Outcome:** The response identifies the visible error and the preceding spoken action, while each diagnostic claim points back to the modality that supports it. **Common misconceptions:** - **Claim:** A multimodal model automatically accepts and produces every kind of media. **Correction:** Multimodal is not a universal capability label. Each model documents which modalities it accepts, which it can generate, and the limits and quality tradeoffs for each direction. **Visual model (system):** Multimodal value comes from relating supported input types within one task. It does not imply that every model accepts or generates every modality. **Visual description:** A text question, screenshot, and voice note enter supported multimodal analysis, which relates their evidence and returns a diagnosis linked to visual regions and transcript timestamps. **Related concepts:** [Large Language Model](https://aigarage.in/jargons/llm), [Token](https://aigarage.in/jargons/token), [Context Window](https://aigarage.in/jargons/context-window), [Embeddings](https://aigarage.in/jargons/embeddings) **Video explainer:** [Multimodal AI: relate supported forms of evidence](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/multimodal-ai/v2/multimodal-ai.mp4) (49 seconds) See a written question, screenshot, and voice note converge into one evidence-linked diagnosis while the system keeps its supported capability boundary explicit. **Published:** 2026-10-12T00:45:16+05:30 **Captions:** [English](https://aigarage.in/jargons/multimodal-ai/captions.vtt) **Narration:** generated **Transcript:** A learner sends a question, a screenshot of an error, and a voice note. Each is a different kind of input, called a modality. A text-only tool sees just the question. It misses the error on screen and the detail in the voice note. A multimodal system turns each input into something the model can read. Then it relates them in one task. The answer points to the exact part of the screenshot, and the moment in the voice note. That gives a diagnosis you can check against each source. But no model takes every kind of input or makes every kind of output. Limits differ in size, quality and cost. Multimodal means more than one kind of input can take part. The documented limits decide what is possible. **Last researched:** 2026-10-11 **Sources:** - [Google AI for Developers - Image understanding](https://ai.google.dev/gemini-api/docs/image-understanding) - [Google AI for Developers - Audio understanding](https://ai.google.dev/gemini-api/docs/audio) - [Google AI for Developers - Video understanding](https://ai.google.dev/gemini-api/docs/video-understanding) **URL:** https://aigarage.in/jargons/multimodal-ai --- ### Context Window **Category:** Prompting **Tags:** tokens, prompting, beginner The model-specific token budget available for the information a model can use during one request, including the input and generated output and, for some models, reasoning tokens. **In plain terms:** How much the AI can keep in mind at one time. **Use cases:** - Long document summarization - Conversation memory - Complex planning prompts **Why it matters:** Instructions, conversation history, tool results, retrieved evidence, and the model's output share finite space. Exceeding that space can fail or truncate a request, while filling it with irrelevant material can make useful context harder to use. **Why now:** Long-context models can process much larger working sets, but agent loops, tool output, and multimodal inputs can consume that capacity quickly. Context management is therefore part of application design, not only prompt writing. **AI Garage example:** In an AI Garage example, Forgy, a workbook-building agent, could preserve the build brief and current constraints, retrieve only the source-session passages needed for the next workbook section, and compact older working notes instead of repeatedly sending the entire raw session. **Mental model:** A context window is a fixed workbench for one model call. Instructions, conversation history, retrieved evidence, tool results, and the answer all compete for room, so builders must choose what deserves to stay on the bench. **Builder scenario: Keep a coding-session workbook inside a useful context** - **Context:** An AI assistant using MCP tools is turning a long landing-page coding session into a reproducible build workbook. The session contains the original brief, decisions, failed attempts, screenshots, and repeated tool output. - **Failure:** Sending the entire raw session for every workbook section consumes the shared token budget, leaves less room for the answer, and makes the current constraints harder to find among stale details. - **Intervention:** Keep the build brief and active constraints pinned, retrieve only the coding-session passages needed for the current section, reserve output space, and compact older working notes into a checked summary. - **Outcome:** Each workbook section is generated from the relevant evidence and current constraints while the request remains within the selected model's token budget. **Common misconceptions:** - **Claim:** The context window is the model's permanent memory. **Correction:** It is the working information available to one request. Long-term memory requires an external store plus a method for selecting what returns to context. - **Claim:** A larger context window means every included detail will be used equally well. **Correction:** Capacity is not guaranteed recall or reasoning quality. Relevant, well-structured context can work better than filling the window with everything available. **Visual model (sequence):** Context engineering is the repeated choice of what stays, what is retrieved, what is compacted, and how much room remains for the answer. **Visual description:** A fixed context budget is divided between pinned instructions, relevant retrieved evidence, compacted prior work, and reserved output space for the next workbook section. **Related concepts:** [Token](https://aigarage.in/jargons/token), [Prompt Engineering](https://aigarage.in/jargons/prompt-engineering), [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [Agent Memory](https://aigarage.in/jargons/agent-memory) **Video explainer:** [Context Window: choose what belongs in this call](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/context-window/v2/context-window.mp4) (48 seconds) See how an AI assistant curates a long coding session into one useful model call by pinning requirements, retrieving current evidence, compacting older work, and reserving room for the answer. **Published:** 2026-10-12T11:59:39+05:30 **Captions:** [English](https://aigarage.in/jargons/context-window/captions.vtt) **Narration:** generated **Transcript:** A coding assistant is turning a long session into a workbook. The session holds the brief, decisions, failed tries, screenshots and tool output. A context window is the limit on what the model can read in one call. Instructions, history, evidence, tool results and the answer all share it. If everything is sent, old noise crowds out what matters now. So the assistant pins the brief and the active rules. It fetches only the passages this step needs. It squeezes old work into a short checked summary, and saves space for the output. A bigger window holds more, but it is not memory. Ask what the model needs for this step, not how much fits. **Last researched:** 2026-10-11 **Sources:** - [OpenAI API - Conversation state and context windows](https://developers.openai.com/api/docs/guides/conversation-state) - [OpenAI API - Key concepts](https://developers.openai.com/api/docs/concepts) - [Anthropic - Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) **URL:** https://aigarage.in/jargons/context-window --- ### Inference **Category:** Machine Learning **Tags:** prediction, latency, serving, production The process of applying a trained model to new input to produce a prediction, score, classification, or generated output. **In plain terms:** Training is when the model learns its settings. Inference is when you give that trained model a new input and use those settings to get an output. **Use cases:** - Real-time assistant responses - Batch classification jobs - Recommendation and routing scores **Why it matters:** Inference is the part users experience repeatedly. Its latency, throughput, model size, input length, and serving hardware shape product responsiveness and operating cost. **Why now:** AI products increasingly choose among real-time, streaming, batch, local, and hosted inference. That serving choice affects latency, capacity, privacy, and cost without being the same decision as how the model was trained. **AI Garage example:** A workshop intake workflow could run inference on each new response to predict the best support route. The prediction can guide the workflow immediately, while reviewed corrections are collected separately for a future training or fine-tuning run. **Mental model:** Training sets the model's parameters. Inference holds that trained model version steady, passes a new input through it, and reads the resulting output. Saving an input or correction can support later training, but the inference call does not by itself teach the deployed model. **Builder scenario: Route workshop requests without silent retraining** - **Context:** A deployed classifier receives each new workshop-support request and predicts one of four routes for the operations team. - **Failure:** The team assumes that correcting a bad route in the product automatically teaches the deployed model, so the same failure continues while nobody prepares new training data or a replacement model version. - **Intervention:** Use the current model version for inference, log its input and reviewed outcome, and send approved corrections to a separate evaluation and retraining process. - **Outcome:** Each request receives an immediate route from the known model version, while model behavior changes only through a deliberate, evaluated training step and deployment of a new version. **Common misconceptions:** - **Claim:** Every inference request teaches the model and updates its parameters. **Correction:** Ordinary inference applies the trained parameters to an input. Updating parameters requires a separate training, fine-tuning, or explicitly adaptive process. **Visual model (system):** Inference uses the current model. Learning from reviewed outcomes requires a separate, deliberate update path. **Visual description:** A new input passes through a fixed deployed model version to produce a prediction. Reviewed corrections move to a separate training step rather than changing the model during that inference call. **Related concepts:** [Neural Network](https://aigarage.in/jargons/neural-network), [Fine-tuning](https://aigarage.in/jargons/fine-tuning), [API](https://aigarage.in/jargons/api), [Decision Model](https://aigarage.in/jargons/decision-model) **Video explainer:** [Inference: using a trained model without retraining it](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/inference/v2/inference.mp4) (45 seconds) See a deployed classifier route a new request, then follow reviewed corrections into a separate evaluation and training path instead of silently changing the model during inference. **Published:** 2026-10-12T00:45:14+05:30 **Captions:** [English](https://aigarage.in/jargons/inference/captions.vtt) **Narration:** generated **Transcript:** A support team's assistant gets a new request and has to pick a route. A trained model makes that pick, and the act of using it is called inference. The request goes into the model, and a route comes out, with a score. The model has fixed settings, learned earlier during training. Inference only uses them. It does not change them. Now an operator corrects a wrong route. Saving that correction is useful, but the model does not learn from it. The team can gather many corrections, check them, and train a new version. They test it, and only then switch to it. Until then, every request uses the same known version. Training changes the model. Inference uses it. **Last researched:** 2026-10-11 **Sources:** - [Google for Developers - Supervised learning: inference](https://developers.google.com/machine-learning/intro-to-ml/supervised) - [Google Cloud - Get online inferences from a custom trained model](https://docs.cloud.google.com/vertex-ai/docs/predictions/get-online-predictions) - [Google for Developers - Fine-tuning, distillation, and prompt engineering](https://developers.google.com/machine-learning/crash-course/llm/tuning) **URL:** https://aigarage.in/jargons/inference --- ### Agent Skill **Category:** Prompting **Tags:** agents, skills, instructions, context A folder of instructions, and optionally scripts and reference files, that an AI agent loads only when a task calls for it, with a SKILL.md file at its core that says what the skill does and how to do it. **In plain terms:** It is a playbook the agent keeps on a shelf. It reads the title on the spine every time, and takes the whole playbook down only when the job needs it. **Use cases:** - Repeatable document and report tasks - A team's house style and checklists - Publishing workflows with fixed steps and exact checks **Why it matters:** A prompt lives in one conversation. A skill packages the same guidance once, so the agent applies it every time, loads it only when needed, and can run bundled scripts for steps that must be exact. Whether a skill actually works is a separate question that testing answers. **Why now:** Agent products now let people add their own skills, and Anthropic has published the Agent Skills format as an open standard. Availability and details vary by product, so check the current documentation before relying on a specific behavior. **AI Garage example:** The AI Garage Jargons workflow is itself organized as a skill in this repository. A SKILL.md sets the steps, reference files hold the knowledge contract and script standards, and scripts run checks such as the script audit. This describes how the repository is organized, not a claim about production usage. **Mental model:** A skill is reusable know-how that loads on demand. The agent always sees a short name and description, reads the full instructions only when the task matches, and opens extra files or runs bundled scripts only when needed. That keeps the context window light while the skill itself can hold a lot. **Builder scenario: Stop re-explaining the same task to an agent** - **Context:** A team asks an agent to publish a glossary entry every week, and each time pastes the same twelve instructions. - **Failure:** The agent follows the instructions differently each time. Some steps are skipped, and nobody can tell which version of the instructions was used. - **Intervention:** Package the steps as a skill: a short description that says when to use it, the full procedure in SKILL.md, reference files for the standards, and a script for the checks that must be exact. - **Outcome:** The agent loads the procedure only for glossary work and runs the same checks each time, and the team improves one file instead of twelve pasted prompts. **Common misconceptions:** - **Claim:** A skill is just a longer prompt. **Correction:** A prompt lives in one conversation. A skill is a folder the agent discovers and loads on demand, and it can include reference files and scripts. Only its name and description are always in context. - **Claim:** A skill makes the agent good at the task. **Correction:** A skill gives the agent instructions. Whether they work is a separate question, answered by testing the agent on real tasks, which is what evals do. **Visual model (comparison):** The skill and the eval form a loop: teach with a skill, let the agent work, evaluate the results, then improve the skill from the failures that keep recurring. This is AI Garage's framing of the relationship. **Visual description:** Two columns compare a skill and an eval. A skill teaches the agent how to approach a task and contains instructions, references, and scripts. An eval checks whether the agent can do the task and contains tasks, graders, and scores. Each improves the other. **Related concepts:** [Prompt Engineering](https://aigarage.in/jargons/prompt-engineering), [Context Window](https://aigarage.in/jargons/context-window), [API](https://aigarage.in/jargons/api), [Evals](https://aigarage.in/jargons/evals), [AI Agent](https://aigarage.in/jargons/ai-agent) **Video explainer:** [Agent Skill: know-how loaded on demand](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/agent-skill/v1/agent-skill.mp4) (45 seconds) See how a skill packages a team's repeated instructions into one folder that an agent loads only when a task matches, with scripts for exact checks. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/agent-skill/captions.vtt) **Narration:** generated **Transcript:** A team asks an agent to publish a glossary entry every week. Each time, they paste the same twelve instructions. The agent follows them a little differently every time. A skill packages those steps once, as a folder the agent can find. The agent always sees a short name and description. It opens the full instructions only when the task matches. Extra reference files and scripts load only when a step needs them, like an exact check. So the context stays light, and the checks run the same every time. The team now improves one file instead of twelve pasted prompts. A skill is know-how the agent loads when it needs it. **Last researched:** 2026-10-12 **Sources:** - [Anthropic Engineering - Equipping agents for the real world with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) - [Claude Docs - Agent Skills overview](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview) - [Anthropic - Agent Skills repository](https://github.com/anthropics/skills) **URL:** https://aigarage.in/jargons/agent-skill --- ### Evals **Category:** Machine Learning **Tags:** evaluation, agents, testing, quality Tests for an AI system: you give it an input, then apply grading logic to its output to measure how well it did the job. **In plain terms:** It is the exam. You give the agent real tasks, mark the results, and see where it fails, so you know what to fix. **Use cases:** - Checking a prompt or agent change before shipping - Catching regressions after an update - Comparing two versions of an agent **Why it matters:** An agent can look good in a demo and still fail in daily use. Evals turn that into numbers you can track, and they stop one improvement from quietly breaking an earlier case. **Why now:** Agents run many steps, call tools, and change state, so reading one answer is no longer enough to judge them. Teams building agents are moving from ad hoc checks to repeatable evals. Practices differ between teams, so check current guidance before adopting a specific method. **AI Garage example:** The AI Garage Jargons workflow already uses eval-like checks. A script audit scores each narration script against fixed targets such as length, reading ease, and closing length, and a video review scores each render against a rubric with a pass bar. This describes checks used in this repository, not a claim about production usage. **Mental model:** An eval is a set of tasks with clear success checks. Each task is run more than once because outputs vary, the grading looks at what the agent produced, and the results are kept so you can see whether a change helped. Graders can be code, another model, or a person. **Builder scenario: Know whether the agent is getting better** - **Context:** A team's agent drafts support replies. They change its instructions and it seems better. - **Failure:** They checked three examples by eye. A week later a case they never tried regresses, and nobody notices until a customer does. - **Intervention:** Collect about twenty to fifty real past failures as tasks, write a clear pass check for each, using code where possible and a rubric or a person where not. Run each task several times and rerun the whole set after every change. - **Outcome:** Each change shows which tasks improved and which regressed, and the team keeps the changes that raise the score without breaking earlier cases. **Common misconceptions:** - **Claim:** Evals are just tests. **Correction:** Tests check that software works. Evals check how well an AI system does the job, usually across several runs because the output can differ each time. In AI Garage's framing, tests check the software and evals check whether the agent is getting better. - **Claim:** One passing run means it works. **Correction:** Outputs vary, so teams measure across several trials. They report either the chance of at least one success or the chance that every trial succeeds, depending on whether one success is enough. **Visual model (comparison):** The eval is the exam that shows what the skill still gets wrong. Fix the recurring failures in the skill, then run the eval again. This is AI Garage's framing of the relationship. **Visual description:** Two columns compare a skill and an eval. A skill teaches the agent how to approach a task and contains instructions, references, and scripts. An eval checks whether the agent can do the task and contains tasks, graders, and scores. Each improves the other. **Related concepts:** [Prompt Engineering](https://aigarage.in/jargons/prompt-engineering), [Hallucination (AI)](https://aigarage.in/jargons/ai-hallucination), [Fine-tuning](https://aigarage.in/jargons/fine-tuning), [Agent Skill](https://aigarage.in/jargons/agent-skill), [AI Agent](https://aigarage.in/jargons/ai-agent) **Video explainer:** [Evals: is the agent really getting better?](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/evals/v1/evals.mp4) (45 seconds) See how a set of real tasks, graded by code, rubrics or people and rerun after every change, shows what improved and what quietly got worse. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/evals/captions.vtt) **Narration:** generated **Transcript:** A team changes how their support agent writes replies. Three examples look better, so they ship it. A week later, a case they never tried breaks, and nobody notices. An eval would have caught it. It is a set of real tasks taken from past failures, each with a clear way to mark the result. Code does the marking where it can. A rubric or a person does the rest. Outputs vary, so each task runs several times, not just once. After every change, the whole set runs again. Now the team sees which tasks improved, and which quietly got worse. Evals tell you if the agent is really getting better. **Last researched:** 2026-10-12 **Sources:** - [Anthropic Engineering - Demystifying evals for AI agents](https://anthropic.com/engineering/demystifying-evals-for-ai-agents) - [Anthropic Engineering - Equipping agents for the real world with Agent Skills](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) **URL:** https://aigarage.in/jargons/evals --- ### AI Agent **Category:** LLM **Tags:** agents, workflows, tools, autonomy A system where a language model decides its own next steps, using tools in a loop and checking the results, until the task is done or a limit is reached. **In plain terms:** A workflow is a recipe with fixed steps. An agent is a cook who looks in the fridge, tries something, tastes it, and decides what to do next. **Use cases:** - Open-ended research and investigation - Multi-step coding tasks - Support cases whose steps cannot be listed in advance **Why it matters:** Choosing an agent when a workflow would do adds cost, delay, and risk. Choosing a workflow when the steps cannot be known makes the system brittle. Knowing the difference is the first design decision. **Why now:** Models plan and use tools better, so agents are practical for more tasks, and providers now publish guidance on loops, tools, and stopping limits. Practices change quickly, so check current guidance before relying on a specific pattern. **AI Garage example:** The AI Garage Jargons work in this repository is run by a coding agent. It reads the skill, runs the script audit, renders a video, checks the result, and decides what to fix next, and it stops at approval gates that a person controls. The fixed gates around it are the workflow, and the work between them is the agent. This describes how the repository is worked on, not a claim about production usage. **Mental model:** The deciding is the difference. In a workflow, your code fixes the path and the model fills in steps. In an agent, the model chooses the next step from what the last step returned, and repeats until it stops. That freedom suits open-ended problems where the steps cannot be predicted. It costs more time and money and can compound errors, so it needs limits. **Builder scenario: Pick the right amount of freedom** - **Context:** A support team wants a system that handles refund questions. Most cases follow the same three steps, but a few need open-ended investigation. - **Failure:** The team builds a fully autonomous agent for every case. Simple cases get slower and cost more, and in the hard cases it loops, repeats tool calls, and never stops. - **Intervention:** Put the predictable path in a workflow: classify, look up the order, apply the policy. Hand only the open-ended cases to an agent with a small set of tools, a maximum number of steps, and a checkpoint where a person can step in. - **Outcome:** Routine cases run in a fixed number of steps, hard cases get flexible handling within a cap, and every run has a clear stopping point. **Common misconceptions:** - **Claim:** An agent is just a chatbot with tools. **Correction:** What makes it an agent is that the model chooses the next step in a loop and checks the result. A fixed sequence of model calls is a workflow, even when it uses tools. - **Claim:** More autonomy is always better. **Correction:** Autonomy trades speed and cost for flexibility, and mistakes can compound. The guidance is to start with the simplest approach and add complexity only when it clearly helps. **Visual model (comparison):** Use a workflow when you can write the steps down. Use an agent when you cannot, and give it limits. **Visual description:** Two columns compare a workflow and an agent. In a workflow, your code fixes the path and the model fills in steps, which is predictable and cheaper. In an agent, the model chooses the next step in a loop, which is flexible but slower and costlier and needs limits. **Related concepts:** [Tool Calling](https://aigarage.in/jargons/tool-calling), [Decision Model](https://aigarage.in/jargons/decision-model), [API](https://aigarage.in/jargons/api), [Context Window](https://aigarage.in/jargons/context-window), [Prompt Engineering](https://aigarage.in/jargons/prompt-engineering), [Agent Skill](https://aigarage.in/jargons/agent-skill), [Evals](https://aigarage.in/jargons/evals), [Agent Memory](https://aigarage.in/jargons/agent-memory), [Human in the Loop](https://aigarage.in/jargons/human-in-the-loop), [MCP (Model Context Protocol)](https://aigarage.in/jargons/mcp) **Video explainer:** [AI Agent: workflow or agent](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/ai-agent/v1/ai-agent.mp4) (52 seconds) See a support team split refund cases into a fixed workflow and an agent loop, and why an agent needs a small set of tools, a step cap, and a person to check in. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/ai-agent/captions.vtt) **Narration:** generated **Transcript:** A support team wants help with refund questions. Most cases follow the same three steps, so code runs them in order. That is a workflow. The path is set, and the model fills in steps. A few cases are different, and nobody can list their steps in advance. For those, an agent works better. The model picks the next step. It calls a tool, reads the result, and decides what to do next. That loop repeats until the job is done, or a limit is reached. The freedom costs time and money, and mistakes can pile up. So give it a small set of tools, a step cap, and a person to check in. Use a workflow when you can write the steps down. Use an agent when you cannot. **Last researched:** 2026-10-12 **Sources:** - [Anthropic Engineering - Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) - [Claude Docs - How tool use works](https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works) **URL:** https://aigarage.in/jargons/ai-agent --- ### Tool Calling **Category:** LLM **Tags:** tools, function-calling, api, agents A way for a language model to ask your application to run a defined action, by returning a structured request that names the tool and its arguments. Your application runs it and sends the result back. Also called function calling. **In plain terms:** The model cannot press buttons. It fills in a form that says run this, with these values, hands it to your code, and waits for the answer. **Use cases:** - Looking up fresh or private data - Taking actions such as sending an email or updating a record - Returning output in a guaranteed shape **Why it matters:** Tool calling is the bridge between a language model and your systems. It is also where side effects happen, so validation, permissions, and retries are decided in your code, not by the model. **Why now:** Tool calling is available across major model providers and sits under agents and shared tool protocols. Details differ by provider and change often, so check the current documentation before relying on a specific behavior. **AI Garage example:** The AI Garage website exposes read-only tools to AI clients for Jargons, events, fellowships, offerings, and case studies. Tools such as search_jargons, get_jargon, and get_case_study each have a name, a description, and an input schema, and a public manifest lists them at /api/agent/tools. A client's model can request a call and the site returns public catalogue data or page text. None of these tools takes personal data or changes anything. **Mental model:** Tool calling is a contract. You describe each tool with a name, a description, and an input schema. The model decides when a tool fits and returns a call. Your code, never the model, performs the action and returns a result, and the model continues from it. The model acts less like a text generator and more like a caller of typed functions. **Builder scenario: Let the model request an action without letting it act** - **Context:** An assistant should issue refunds when a customer's request meets the policy. - **Failure:** The model replies that the refund is on its way when nothing has happened, or a retried tool call issues the refund twice. - **Intervention:** Define a refund tool with a schema and let the model request it. The application checks permission and policy, runs the refund with an idempotency key, and returns the real result to the model. - **Outcome:** The reply states only what the system confirmed, and a retried call resolves to a single refund. **Common misconceptions:** - **Claim:** The model runs the tool. **Correction:** The model only emits a structured request. Your application, or the provider's servers for hosted tools, executes it and returns the result. - **Claim:** A strict schema makes a tool call safe. **Correction:** A strict schema makes the arguments match the expected shape. Whether the action is allowed, valid, and safe to repeat is decided by your own code. **Visual model (sequence):** The model asks and your code acts. Every step with a side effect runs in your application. **Visual description:** A five-step sequence: define the tools, the model requests a call, your application checks and runs it, the result goes back to the model, and the model answers or asks for another tool. **Related concepts:** [API](https://aigarage.in/jargons/api), [Idempotency](https://aigarage.in/jargons/idempotency), [Decision Model](https://aigarage.in/jargons/decision-model), [Hallucination (AI)](https://aigarage.in/jargons/ai-hallucination), [AI Agent](https://aigarage.in/jargons/ai-agent), [Human in the Loop](https://aigarage.in/jargons/human-in-the-loop), [MCP (Model Context Protocol)](https://aigarage.in/jargons/mcp) **Video explainer:** [Tool Calling: the model asks, your code acts](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/tool-calling/v1/tool-calling.mp4) (47 seconds) See how a model requests a refund through a tool, how your code checks and runs it, and why an ID keeps a retried call from refunding twice. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/tool-calling/captions.vtt) **Narration:** generated **Transcript:** A customer asks an assistant for a refund. The model cannot press buttons. It can only write text. So you give it tools, each with a name, a description, and the inputs it needs. The model decides a tool fits, and returns a request, like refund this order. Your code does the actual work. It checks the request, then runs the action. Your code sends the real result back to the model. Now the model can answer from what really happened. Without this, it might say the refund is on its way when nothing ran. And if the call is retried, an ID keeps it from refunding twice. The model asks. Your code acts. **Last researched:** 2026-10-12 **Sources:** - [Claude Docs - Tool use with Claude](https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview) - [Claude Docs - How tool use works](https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works) - [OpenAI API - Function calling](https://developers.openai.com/api/docs/guides/function-calling) **URL:** https://aigarage.in/jargons/tool-calling --- ### Agent Memory **Category:** LLM **Tags:** agents, memory, context, persistence Information an AI agent saves outside its context window, such as notes or files, and reads back later, so it can continue work across sessions or after its context is cleared. **In plain terms:** It is the agent's notebook. Its head holds only what fits right now, so it writes things down and looks them up when it needs them. **Use cases:** - A coding agent that resumes a project the next day - A support assistant that remembers a customer's preferences - A research agent that keeps findings across sessions **Why it matters:** Without memory, every session starts from nothing. With careless memory, an agent can fill its notes with stale, wrong, or sensitive content, so what to keep, for how long, and who can read it are design decisions. **Why now:** Agents now run tasks longer than one context window holds. Providers offer file-based memory tools and pair them with compaction and context clearing. Details differ by provider and change quickly, so check current documentation before relying on a specific behavior. **AI Garage example:** The coding agent used on this repository keeps a small memory folder: an index file plus one short file per lasting fact, such as how the team ships and where plans are saved. Each new session reads the index first, so those decisions carry over without being repeated. This describes how this repository is worked on, not a product claim. **Mental model:** The context window is what the model can see this moment. Memory is storage outside it. The agent saves what it learns, reads it back on demand, and the application, not the model, does the actual storing. That keeps the active context small and lets work survive interruptions. It is different from a larger context window, and from retrieval over documents someone else wrote. **Builder scenario: Let work survive a reset** - **Context:** A coding agent works on a project across many days, and each session starts with an empty context. - **Failure:** Every session re-explores the code and repeats questions that were already settled, and decisions made on day one are quietly reversed on day three. - **Intervention:** Give the agent a memory folder. At the start of each session it reads a progress log and a short list of decisions, and before it stops it updates both. The application stores the files, limits their size, and removes old ones. - **Outcome:** Each session resumes from the recorded state, and the same decisions are not reopened. **Common misconceptions:** - **Claim:** A bigger context window is the same as memory. **Correction:** A context window holds what the model reads in one call, and it starts fresh on the next call. Memory is stored outside it and read back when needed. - **Claim:** The model remembers by itself. **Correction:** With a memory tool, the model only requests file operations. Your application stores the data, controls where it lives, and decides what is kept or deleted. - **Claim:** Whatever is in memory can be trusted. **Correction:** Memory holds what the agent wrote, which may be stale or wrong. The documentation advises keeping sensitive information out, capping file sizes, expiring old files, and validating every path. **Visual model (comparison):** The context window is the desk and memory is the filing cabinet. Fetch only what this step needs. **Visual description:** Two columns compare the context window and memory. The context window holds what the model can read right now and starts fresh on the next call. Memory holds notes stored outside the model, read back when needed, and survives a reset, but needs size limits and cleanup. **Related concepts:** [Context Window](https://aigarage.in/jargons/context-window), [RAG (Retrieval-Augmented Generation)](https://aigarage.in/jargons/rag), [AI Agent](https://aigarage.in/jargons/ai-agent), [Tool Calling](https://aigarage.in/jargons/tool-calling), [Agent Skill](https://aigarage.in/jargons/agent-skill) **Video explainer:** [Agent Memory: notes that outlast the context window](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/agent-memory/v1/agent-memory.mp4) (48 seconds) See how an agent saves notes outside its context window, reads them in the next session, and why your app sets limits and keeps secrets out. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/agent-memory/captions.vtt) **Narration:** generated **Transcript:** A coding agent works on a project for many days. But every new session starts with an empty context window. So it re-reads the code and asks questions it already settled. Memory fixes this. It is storage outside the context window. The agent writes notes as it learns, like a progress log and a list of decisions. Next session, it reads the notes first, then picks up where it stopped. The model only asks to save and read. Your app does the storing. So your app sets the size limits and clears old notes. Memory can be stale or wrong, so keep secrets out of it. The context window is the desk. Memory is the filing cabinet. **Last researched:** 2026-10-12 **Sources:** - [Claude Docs - Memory tool](https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool) - [Anthropic Engineering - Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) **URL:** https://aigarage.in/jargons/agent-memory --- ### Human in the Loop **Category:** LLM **Tags:** agents, approval, safety, oversight A design where an automated or AI system pauses at chosen points for a person to approve, correct, or reject, before it continues with a consequential action. **In plain terms:** It is a checkpoint with a person at it. The agent does the work, stops at the risky step, shows what it is about to do, and waits for a yes or a no. **Use cases:** - Approving a refund or an outbound email - Reviewing a code change before it is applied - Signing off a page before it is published **Why it matters:** An agent can be wrong in a way that is hard to undo. A person at the right gate turns a possible mistake into a request that can be read and declined, and leaves a clear record of who approved what. **Why now:** Agents now take actions through tools, and frameworks add built-in approval pauses and ways to resume a paused run. Practices differ between products and change quickly, so check current documentation before relying on a specific behavior. **AI Garage example:** The AI Garage Jargons video workflow is built from approval gates. A person approves the script, then the narration, then the local video, then the upload, as separate steps, and the agent does not move past a gate without that approval. The agent does the work between the gates. This describes how this repository is worked on, not a product claim. **Mental model:** Decide which actions matter, then pause only there. The system declares that a step needs approval and stops with the pending action visible. A person approves or rejects it, and the run resumes from where it stopped. The skill is choosing the gates: sending an email, spending money, changing a record, running a command. Gating every step defeats the point of automation, and gating nothing leaves the agent unsupervised. **Builder scenario: Pause where it matters, not everywhere** - **Context:** An assistant can read orders, draft replies, and issue refunds. - **Failure:** Either every step needs a click and the team stops using it, or nothing needs approval and a wrong refund goes out before anyone sees it. - **Intervention:** Let the assistant read and draft freely, and mark only the refund and the outbound email as needing approval. When it reaches one, the run pauses and shows exactly what it will do. A signed-in reviewer approves or rejects, and the run resumes. - **Outcome:** Routine work flows without interruption, and every refund and email passes a person who sees the exact action first. **Common misconceptions:** - **Claim:** Human in the loop means a person watches every step. **Correction:** It means a person decides at chosen points. The guidance points to consequential actions such as sending emails, cancelling orders, running commands, or editing files, not to every step. - **Claim:** An approval prompt makes the action safe. **Correction:** An approval only helps if the reviewer sees the real action and is authorized to decide. The documentation warns that saved run state should come from trusted storage, and that the server should check who the reviewer is and validate their decision. **Visual model (sequence):** Pause at the actions that are hard to undo, and let the rest run. **Visual description:** A five-step sequence: the agent works until a gated step, the run pauses and shows the pending action, a person approves or rejects it, the run resumes, and the decision is recorded. **Related concepts:** [AI Agent](https://aigarage.in/jargons/ai-agent), [Tool Calling](https://aigarage.in/jargons/tool-calling), [Decision Model](https://aigarage.in/jargons/decision-model), [Idempotency](https://aigarage.in/jargons/idempotency), [Hallucination (AI)](https://aigarage.in/jargons/ai-hallucination) **Video explainer:** [Human in the Loop: pause where it matters](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/human-in-the-loop/v1/human-in-the-loop.mp4) (47 seconds) See how gating only refunds and outbound emails keeps routine work flowing, and why an approval helps only if the reviewer sees the real action. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/human-in-the-loop/captions.vtt) **Narration:** generated **Transcript:** An assistant can read orders, draft replies, and issue refunds to customers. If every step needs a click, the team stops using it. If nothing needs approval, a wrong refund goes out unseen. Human in the loop is the middle path. A person decides at chosen points. Reading and drafting run freely. Refunds and outbound emails are gated. At a gate, the run pauses and shows the exact action it will take. A signed-in reviewer approves or rejects it. Then the run resumes, and the decision is recorded. An approval only helps if the reviewer sees the real action and may decide. Pause where it is hard to undo. Let the rest run. **Last researched:** 2026-10-12 **Sources:** - [OpenAI Agents SDK - Human-in-the-loop](https://openai.github.io/openai-agents-python/human_in_the_loop/) - [Anthropic Engineering - Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) **URL:** https://aigarage.in/jargons/human-in-the-loop --- ### MCP (Model Context Protocol) **Category:** LLM **Tags:** protocol, tools, agents, integration An open standard for connecting AI applications to external systems, so one application can use tools, data, and prompts from many servers through the same interface. **In plain terms:** It is a USB-C port for AI apps. Instead of a different cable for every service, the app and the service agree on one plug. **Use cases:** - Connecting an assistant to a calendar, files, or a database - Letting a coding agent use a design tool - Giving several AI apps the same company data through one server **Why it matters:** Without a shared standard, every AI app needs a custom integration for every system. With MCP, a server built once can work with any application that supports it. It also moves the important questions to the server and the host: what the tools can do, who may call them, and what a person must approve. **Why now:** Anthropic open-sourced MCP in November 2024, and the project's documentation lists support across many AI assistants and developer tools. The specification is still evolving, and a recent version changed how connections and discovery work, so check the current specification before relying on a detail. **AI Garage example:** AI Garage runs a remote MCP connector that people can add to an AI assistant such as Claude. Connecting requires signing in, and an unauthenticated request is refused. Through it, an assistant can use AI Garage's tools without anyone opening the website. The server runs separately from this website's code. **Mental model:** MCP is a shared language between an AI application, the host, and the programs that provide context, the servers. The host keeps one client connection per server. Each server tells the client what it offers: tools the model can call, resources to read, and prompt templates. The host offers those tools to its model, and the model's calls go through the client to the server. MCP covers the connection, not the model's reasoning or what the application does with the results. **Builder scenario: Connect one system to many AI apps without rewriting it** - **Context:** A team wants assistants in two different AI apps to read the same project notes and create tasks in the same tracker. - **Failure:** They write a separate custom integration for each app. Each behaves slightly differently, and any change to the tracker means fixing both. - **Intervention:** Build one MCP server that exposes a resource for reading notes, a tool for searching notes, and a tool for creating tasks. Mark the task tool as one that changes things, require sign-in, and let each AI app connect to the same server. - **Outcome:** Both apps list the same tools from one server. A change to the tracker is made once, and the create-task action asks for approval in each app. **Common misconceptions:** - **Claim:** MCP is a tool or a model. **Correction:** It is a protocol, a set of rules for how an AI application and a server talk. It does not choose tools for the model, run the model, or decide how results are used. - **Claim:** An MCP server is safe because it follows a standard. **Correction:** The standard defines how a connection works, not whether a tool is safe. What a tool can do, who can call it, and what needs a person's approval are decisions for the server and the host. **Visual model (system):** The host connects to each server through the same standard. What a server can do, and who may use it, is still decided on the server. **Visual description:** A system map: an AI application (the host) keeps one MCP client per server. Each client connects to an MCP server through a standard connection. The server offers tools, resources, and prompts, and does the work in an external system such as a calendar or a database. **Related concepts:** [Tool Calling](https://aigarage.in/jargons/tool-calling), [AI Agent](https://aigarage.in/jargons/ai-agent), [API](https://aigarage.in/jargons/api), [Context Window](https://aigarage.in/jargons/context-window), [Agent Skill](https://aigarage.in/jargons/agent-skill), [Human in the Loop](https://aigarage.in/jargons/human-in-the-loop) **Video explainer:** [MCP: one plug for many AI apps](https://nqqbubjesbyuwrdhqxnk.supabase.co/storage/v1/object/public/aigarage-public-media/jargons/mcp/v1/mcp.mp4) (53 seconds) See how one shared MCP server replaces a separate connection for each AI app, and why a standard plug still leaves tool permissions to the server. **Published:** 2026-10-13T00:00:00+05:30 **Captions:** [English](https://aigarage.in/jargons/mcp/captions.vtt) **Narration:** generated **Transcript:** Two AI apps need the same project notes and the same task tracker. Each app could get its own connection, and every change means fixing both. MCP, the Model Context Protocol, offers one shared plug instead, like USB-C for AI apps. You build one server for the notes and the tracker. The server lists what it offers, such as tools to call, data to read, and prompt templates. Each app keeps a connection to it, and hands those tools to its model. Its requests go through to the server, which does the work. Change the tracker once, and both apps see it. But a standard is only a plug. It does not make a tool safe. The server still decides what a tool may do, and who may use it. **Last researched:** 2026-10-12 **Sources:** - [Model Context Protocol - What is MCP?](https://modelcontextprotocol.io/docs/getting-started/intro) - [Model Context Protocol - Architecture overview](https://modelcontextprotocol.io/docs/learn/architecture) - [Anthropic - Introducing the Model Context Protocol](https://www.anthropic.com/news/model-context-protocol) **URL:** https://aigarage.in/jargons/mcp --- ## About AI Garage AI Garage is a builder community and delivery studio in Bangalore that helps founders, executives, and operators ship real AI workflows. **Email:** hey@aigarage.in **Website:** https://aigarage.in