{
  "generated": "2026-08-01T23:34:43.663Z",
  "count": 20,
  "license": "Content © Santiago Santa María Morales, licensed CC BY 4.0. Attribution required: credit the author and link the canonical URL.",
  "license_spdx": "CC-BY-4.0",
  "license_url": "https://creativecommons.org/licenses/by/4.0/",
  "entries": [
    {
      "slug": "agent-memory",
      "category": "harness",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/agent-memory",
      "api": "https://santismm.com/api/knowledge/agent-memory",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Packer et al. — MemGPT: Towards LLMs as Operating Systems (2023)",
          "url": "https://arxiv.org/abs/2310.08560"
        },
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        }
      ],
      "related": [
        "harness-engineering",
        "context-engineering",
        "ai-agent",
        "enterprise-rag"
      ],
      "locales": {
        "en": {
          "title": "What are Agent Memory Systems?",
          "summary": "Agent memory is how an AI agent retains and recalls information beyond a single context window — across steps, sessions and tasks. It typically separates short-term working memory (the current context) from long-term memory (durable stores the agent reads from and writes to). Memory is what lets an agent carry state through a long task, remember a user over time, and avoid repeating work. It is a core layer of harness engineering.",
          "definition": "Agent memory is the set of mechanisms an AI agent uses to store, organize and retrieve information beyond its immediate context window, spanning short-term working memory and long-term persistent memory.",
          "takeaways": [
            "Memory extends an agent beyond a single finite context window.",
            "Short-term (working) vs long-term (persistent) memory serve different roles.",
            "Long-term memory is often retrieved on demand, like RAG over the agent's own history.",
            "Good memory prevents repeated work and lost state on long tasks.",
            "What to write, keep and forget is a design decision, not automatic."
          ],
          "context": [
            "A model's context window is finite, so anything an agent must remember beyond it needs an external store. Without memory, an agent forgets earlier steps, repeats actions and cannot personalize across sessions.",
            "Memory turns a stateless model into a system with continuity. The hard part is curation: deciding what is worth writing down, how to organize it, and how to retrieve only what is relevant now — closely tied to context engineering."
          ],
          "architecture": [
            "Two layers: working memory (the current context window, holding the active task) and long-term memory (external stores — vector, key-value, document or graph — written during a task and retrieved later). Some designs add episodic (events), semantic (facts) and procedural (skills) memory.",
            "The agent reads relevant memories into context at each step and writes new ones as it learns. Retrieval, summarization and forgetting policies keep memory useful rather than overwhelming."
          ],
          "components": [
            "Working memory",
            "Long-term store (vector/KV/graph)",
            "Write policy",
            "Retrieval policy",
            "Summarization / consolidation",
            "Forgetting / expiry"
          ],
          "pros": [
            "Continuity across steps, sessions and tasks.",
            "Personalization that persists over time.",
            "Avoids repeated work and lost context.",
            "Enables long-horizon, stateful agents."
          ],
          "risks": [
            "Stale or wrong memories poison future answers.",
            "Privacy and governance obligations on stored data.",
            "Retrieval of irrelevant memories adds noise.",
            "Unbounded growth without consolidation or expiry."
          ],
          "tools": [
            "Vector databases",
            "Key-value / document stores",
            "MemGPT-style memory managers",
            "Agent frameworks (LangGraph, Agents SDKs)"
          ],
          "examples": [
            "An assistant remembering a user's preferences across sessions.",
            "A long-running agent summarizing progress so it never repeats a step.",
            "A support agent recalling a customer's prior tickets when relevant."
          ],
          "faqs": [
            {
              "q": "How is agent memory different from RAG?",
              "a": "RAG retrieves from an external knowledge base; agent memory retrieves from the agent's own accumulated state. The retrieval machinery is similar, but the source and write path differ."
            },
            {
              "q": "What is the difference between short- and long-term memory?",
              "a": "Short-term (working) memory is the live context window for the current task; long-term memory is a persistent store the agent reads from and writes to across tasks and sessions."
            },
            {
              "q": "Why not keep everything in the context window?",
              "a": "Windows are finite and quality drops as they fill. Externalizing state to memory and retrieving only what is relevant keeps the agent focused and affordable."
            },
            {
              "q": "What are the governance concerns?",
              "a": "Stored memory may contain personal or sensitive data, so it needs access control, retention limits and the ability to correct or delete entries."
            }
          ]
        },
        "es": {
          "title": "¿Qué son los Sistemas de Memoria de Agentes?",
          "summary": "La memoria de un agente es cómo un agente de IA retiene y recuerda información más allá de una sola ventana de contexto: entre pasos, sesiones y tareas. Suele separar la memoria de trabajo a corto plazo (el contexto actual) de la memoria a largo plazo (almacenes duraderos que el agente lee y escribe). La memoria es lo que permite a un agente arrastrar estado en una tarea larga, recordar a un usuario en el tiempo y evitar repetir trabajo. Es una capa central de la ingeniería de harness.",
          "definition": "La memoria de agente es el conjunto de mecanismos que un agente de IA usa para almacenar, organizar y recuperar información más allá de su ventana de contexto inmediata, abarcando memoria de trabajo a corto plazo y memoria persistente a largo plazo.",
          "takeaways": [
            "La memoria extiende a un agente más allá de una sola ventana de contexto finita.",
            "La memoria a corto plazo (de trabajo) y a largo plazo (persistente) cumplen roles distintos.",
            "La memoria a largo plazo suele recuperarse bajo demanda, como RAG sobre el historial del agente.",
            "Una buena memoria evita repetir trabajo y perder estado en tareas largas.",
            "Qué escribir, conservar y olvidar es una decisión de diseño, no automática."
          ],
          "context": [
            "La ventana de contexto de un modelo es finita, así que todo lo que un agente deba recordar más allá de ella necesita un almacén externo. Sin memoria, un agente olvida pasos previos, repite acciones y no puede personalizar entre sesiones.",
            "La memoria convierte un modelo sin estado en un sistema con continuidad. Lo difícil es la curación: decidir qué merece anotarse, cómo organizarlo y cómo recuperar solo lo relevante ahora, muy ligado a la ingeniería de contexto."
          ],
          "architecture": [
            "Dos capas: memoria de trabajo (la ventana de contexto actual, con la tarea activa) y memoria a largo plazo (almacenes externos —vectorial, clave-valor, documental o de grafo— escritos durante una tarea y recuperados después). Algunos diseños añaden memoria episódica (eventos), semántica (hechos) y procedimental (habilidades).",
            "El agente lee memorias relevantes al contexto en cada paso y escribe nuevas a medida que aprende. Las políticas de recuperación, resumen y olvido mantienen la memoria útil en vez de abrumadora."
          ],
          "components": [
            "Memoria de trabajo",
            "Almacén a largo plazo (vectorial/KV/grafo)",
            "Política de escritura",
            "Política de recuperación",
            "Resumen / consolidación",
            "Olvido / expiración"
          ],
          "pros": [
            "Continuidad entre pasos, sesiones y tareas.",
            "Personalización que persiste en el tiempo.",
            "Evita repetir trabajo y perder contexto.",
            "Habilita agentes con estado y de horizonte largo."
          ],
          "risks": [
            "Memorias obsoletas o erróneas contaminan respuestas futuras.",
            "Obligaciones de privacidad y gobernanza sobre los datos guardados.",
            "Recuperar memorias irrelevantes añade ruido.",
            "Crecimiento sin límite sin consolidación ni expiración."
          ],
          "tools": [
            "Bases de datos vectoriales",
            "Almacenes clave-valor / documentales",
            "Gestores de memoria estilo MemGPT",
            "Frameworks de agentes (LangGraph, SDKs de agentes)"
          ],
          "examples": [
            "Un asistente que recuerda las preferencias de un usuario entre sesiones.",
            "Un agente de larga duración que resume su progreso para no repetir un paso.",
            "Un agente de soporte que recuerda los tickets previos de un cliente cuando es relevante."
          ],
          "faqs": [
            {
              "q": "¿En qué se diferencia la memoria de agente de RAG?",
              "a": "RAG recupera de una base de conocimiento externa; la memoria de agente recupera del propio estado acumulado del agente. La maquinaria de recuperación es similar, pero la fuente y la ruta de escritura difieren."
            },
            {
              "q": "¿Cuál es la diferencia entre memoria a corto y largo plazo?",
              "a": "La memoria a corto plazo (de trabajo) es la ventana de contexto viva para la tarea actual; la de largo plazo es un almacén persistente que el agente lee y escribe entre tareas y sesiones."
            },
            {
              "q": "¿Por qué no guardar todo en la ventana de contexto?",
              "a": "Las ventanas son finitas y la calidad cae al llenarse. Externalizar el estado a memoria y recuperar solo lo relevante mantiene al agente enfocado y asequible."
            },
            {
              "q": "¿Cuáles son las preocupaciones de gobernanza?",
              "a": "La memoria guardada puede contener datos personales o sensibles, así que necesita control de acceso, límites de retención y capacidad de corregir o borrar entradas."
            }
          ]
        },
        "pt": {
          "title": "O que são Sistemas de Memória de Agentes?",
          "summary": "A memória de um agente é como um agente de IA retém e recupera informação além de uma única janela de contexto: entre passos, sessões e tarefas. Costuma separar a memória de trabalho de curto prazo (o contexto atual) da memória de longo prazo (armazenamentos duráveis que o agente lê e escreve). A memória é o que permite a um agente carregar estado numa tarefa longa, lembrar de um usuário ao longo do tempo e evitar repetir trabalho. É uma camada central da engenharia de harness.",
          "definition": "A memória de agente é o conjunto de mecanismos que um agente de IA usa para armazenar, organizar e recuperar informação além de sua janela de contexto imediata, abrangendo memória de trabalho de curto prazo e memória persistente de longo prazo.",
          "takeaways": [
            "A memória estende um agente além de uma única janela de contexto finita.",
            "Memória de curto prazo (de trabalho) e de longo prazo (persistente) cumprem papéis distintos.",
            "A memória de longo prazo costuma ser recuperada sob demanda, como RAG sobre o histórico do agente.",
            "Uma boa memória evita repetir trabalho e perder estado em tarefas longas.",
            "O que escrever, manter e esquecer é uma decisão de design, não automática."
          ],
          "context": [
            "A janela de contexto de um modelo é finita, então tudo o que um agente precise lembrar além dela precisa de um armazenamento externo. Sem memória, um agente esquece passos anteriores, repete ações e não consegue personalizar entre sessões.",
            "A memória transforma um modelo sem estado num sistema com continuidade. O difícil é a curadoria: decidir o que vale anotar, como organizá-lo e como recuperar só o relevante agora, muito ligado à engenharia de contexto."
          ],
          "architecture": [
            "Duas camadas: memória de trabalho (a janela de contexto atual, com a tarefa ativa) e memória de longo prazo (armazenamentos externos — vetorial, chave-valor, documental ou de grafo — escritos durante uma tarefa e recuperados depois). Alguns designs adicionam memória episódica (eventos), semântica (fatos) e procedural (habilidades).",
            "O agente lê memórias relevantes ao contexto a cada passo e escreve novas conforme aprende. Políticas de recuperação, resumo e esquecimento mantêm a memória útil em vez de avassaladora."
          ],
          "components": [
            "Memória de trabalho",
            "Armazenamento de longo prazo (vetorial/KV/grafo)",
            "Política de escrita",
            "Política de recuperação",
            "Resumo / consolidação",
            "Esquecimento / expiração"
          ],
          "pros": [
            "Continuidade entre passos, sessões e tarefas.",
            "Personalização que persiste ao longo do tempo.",
            "Evita repetir trabalho e perder contexto.",
            "Habilita agentes com estado e de horizonte longo."
          ],
          "risks": [
            "Memórias obsoletas ou erradas contaminam respostas futuras.",
            "Obrigações de privacidade e governança sobre os dados guardados.",
            "Recuperar memórias irrelevantes adiciona ruído.",
            "Crescimento sem limite sem consolidação nem expiração."
          ],
          "tools": [
            "Bancos de dados vetoriais",
            "Armazenamentos chave-valor / documentais",
            "Gerenciadores de memória estilo MemGPT",
            "Frameworks de agentes (LangGraph, SDKs de agentes)"
          ],
          "examples": [
            "Um assistente que lembra as preferências de um usuário entre sessões.",
            "Um agente de longa duração que resume seu progresso para não repetir um passo.",
            "Um agente de suporte que lembra os chamados anteriores de um cliente quando relevante."
          ],
          "faqs": [
            {
              "q": "Como a memória de agente difere do RAG?",
              "a": "O RAG recupera de uma base de conhecimento externa; a memória de agente recupera do próprio estado acumulado do agente. A maquinaria de recuperação é similar, mas a fonte e o caminho de escrita diferem."
            },
            {
              "q": "Qual a diferença entre memória de curto e longo prazo?",
              "a": "A memória de curto prazo (de trabalho) é a janela de contexto viva para a tarefa atual; a de longo prazo é um armazenamento persistente que o agente lê e escreve entre tarefas e sessões."
            },
            {
              "q": "Por que não guardar tudo na janela de contexto?",
              "a": "Janelas são finitas e a qualidade cai ao se encherem. Externalizar o estado para a memória e recuperar só o relevante mantém o agente focado e acessível."
            },
            {
              "q": "Quais são as preocupações de governança?",
              "a": "A memória guardada pode conter dados pessoais ou sensíveis, então precisa de controle de acesso, limites de retenção e capacidade de corrigir ou apagar entradas."
            }
          ]
        }
      }
    },
    {
      "slug": "agentic-ai",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/agentic-ai",
      "api": "https://santismm.com/api/knowledge/agentic-ai",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Yao et al. — ReAct: Synergizing Reasoning and Acting in Language Models (2022)",
          "url": "https://arxiv.org/abs/2210.03629"
        },
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        },
        {
          "title": "Model Context Protocol — Introduction",
          "url": "https://modelcontextprotocol.io"
        }
      ],
      "related": [
        "ai-agent",
        "harness-engineering",
        "multi-agent-architecture",
        "agentic-evaluation"
      ],
      "locales": {
        "en": {
          "title": "What is Agentic AI?",
          "summary": "Agentic AI refers to systems that pursue goals over multiple steps — planning, calling tools, acting on an environment and reacting to feedback — instead of producing a single response. It turns a language model from a text generator into an actor that can complete tasks. The shift it represents is from do-it-yourself software, where the human drives every step, to do-it-for-me software, where the system carries out the work and reports back.",
          "definition": "Agentic AI is the class of AI systems that autonomously plan and execute multi-step tasks by combining a model with memory, tools and a control loop.",
          "takeaways": [
            "An agent = model + tools + memory + a control loop that decides what to do next.",
            "Autonomy is a spectrum, from a single tool call to long-horizon task execution.",
            "Reliability comes mostly from the harness around the model, not raw model IQ.",
            "Tool use (function calling) is what connects the model to real systems and data.",
            "Evaluation must measure task completion (agency), not just answer quality (capability)."
          ],
          "context": [
            "For most of the LLM era, models were used as one-shot responders: a prompt in, an answer out. Agentic AI breaks that pattern by giving the model a loop — it can decide to call a tool, read the result, revise its plan and continue until the goal is met or a budget is exhausted.",
            "This is the dominant frontier of applied AI in the enterprise because it moves the value from answering questions to completing work: resolving a support ticket end to end, refactoring a codebase, running a research task, operating a workflow."
          ],
          "architecture": [
            "A minimal agent has four parts: a reasoning model, a set of tools it can invoke, some form of memory or state, and an orchestration loop that turns model outputs into actions and feeds observations back in.",
            "Patterns range from simple (a model with tools and a stop condition) to complex (planner-executor splits, reflection, and multi-agent teams). Anthropic's guidance is to prefer the simplest pattern that works and add structure only when measurably needed."
          ],
          "components": [
            "Reasoning model",
            "Tools / function calling",
            "Memory & state",
            "Orchestration loop",
            "Guardrails",
            "Observability"
          ],
          "pros": [
            "Completes multi-step work, not just single answers.",
            "Adapts to feedback and recovers from intermediate errors.",
            "Integrates with real systems through tools and APIs.",
            "Scales repetitive knowledge work that was previously human-only."
          ],
          "risks": [
            "Compounding errors over long task horizons.",
            "Unbounded cost and latency without budgets and stop conditions.",
            "Security exposure from tool access and prompt injection.",
            "Hard to evaluate and debug compared with single-shot prompts."
          ],
          "tools": [
            "LangGraph",
            "OpenAI Agents SDK",
            "Claude Agent SDK",
            "Model Context Protocol (MCP)",
            "Vertex AI Agent Engine"
          ],
          "examples": [
            "A customer-service agent that reads a ticket, looks up the order, applies a refund and replies — all through tools.",
            "A coding agent that edits files, runs tests and iterates until the suite passes.",
            "A research agent that searches, reads sources, verifies claims and writes a cited summary."
          ],
          "faqs": [
            {
              "q": "What is the difference between an AI agent and agentic AI?",
              "a": "An AI agent is a concrete system; agentic AI is the broader paradigm of building software around such goal-directed, multi-step systems."
            },
            {
              "q": "Do you need a more powerful model to be agentic?",
              "a": "Not necessarily. The same model can succeed or fail at a task depending almost entirely on the harness — the tools, memory, prompts and control loop around it."
            },
            {
              "q": "Is RAG agentic?",
              "a": "Plain retrieval-augmented generation is a single step. It becomes agentic when the system decides when and what to retrieve as part of a multi-step loop."
            },
            {
              "q": "What makes agents unreliable?",
              "a": "Long horizons compound small errors, tools fail, and context gets lost. Reliability comes from harness engineering: good tools, memory, guardrails and evaluation."
            },
            {
              "q": "How do you measure an agent?",
              "a": "With agentic benchmarks and task-based evals that score end-to-end task completion in an environment, not just the quality of a single answer."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la IA Agéntica (Agentic AI)?",
          "summary": "La IA agéntica designa sistemas que persiguen objetivos en varios pasos —planifican, llaman a herramientas, actúan sobre un entorno y reaccionan al feedback— en lugar de producir una única respuesta. Convierte a un modelo de lenguaje de generador de texto en un actor capaz de completar tareas. El cambio que representa es pasar del software 'hazlo tú', donde la persona conduce cada paso, al software 'hazlo por mí', donde el sistema ejecuta el trabajo y reporta el resultado.",
          "definition": "La IA agéntica es la clase de sistemas de IA que planifican y ejecutan de forma autónoma tareas de varios pasos combinando un modelo con memoria, herramientas y un bucle de control.",
          "takeaways": [
            "Un agente = modelo + herramientas + memoria + un bucle de control que decide el siguiente paso.",
            "La autonomía es un espectro, desde una sola llamada a herramienta hasta tareas de horizonte largo.",
            "La fiabilidad viene sobre todo del 'harness' alrededor del modelo, no del coeficiente del modelo.",
            "El uso de herramientas (function calling) es lo que conecta el modelo con sistemas y datos reales.",
            "La evaluación debe medir la finalización de la tarea (agencia), no solo la calidad de la respuesta (capacidad)."
          ],
          "context": [
            "Durante buena parte de la era LLM los modelos se usaron como respondedores de un solo turno: entra un prompt, sale una respuesta. La IA agéntica rompe ese patrón dándole al modelo un bucle: puede decidir llamar a una herramienta, leer el resultado, revisar su plan y continuar hasta cumplir el objetivo o agotar un presupuesto.",
            "Es la frontera dominante de la IA aplicada en la empresa porque mueve el valor de responder preguntas a completar trabajo: resolver un ticket de soporte de principio a fin, refactorizar un código, ejecutar una investigación, operar un flujo de trabajo."
          ],
          "architecture": [
            "Un agente mínimo tiene cuatro partes: un modelo de razonamiento, un conjunto de herramientas que puede invocar, alguna forma de memoria o estado, y un bucle de orquestación que convierte las salidas del modelo en acciones y reintroduce las observaciones.",
            "Los patrones van de lo simple (un modelo con herramientas y una condición de parada) a lo complejo (separación planificador-ejecutor, reflexión y equipos multiagente). La recomendación de Anthropic es preferir el patrón más simple que funcione y añadir estructura solo cuando aporte de forma medible."
          ],
          "components": [
            "Modelo de razonamiento",
            "Herramientas / function calling",
            "Memoria y estado",
            "Bucle de orquestación",
            "Guardarraíles",
            "Observabilidad"
          ],
          "pros": [
            "Completa trabajo de varios pasos, no solo respuestas sueltas.",
            "Se adapta al feedback y se recupera de errores intermedios.",
            "Se integra con sistemas reales mediante herramientas y APIs.",
            "Escala trabajo de conocimiento repetitivo antes exclusivamente humano."
          ],
          "risks": [
            "Acumulación de errores en horizontes de tarea largos.",
            "Coste y latencia sin límite si faltan presupuestos y condiciones de parada.",
            "Exposición de seguridad por el acceso a herramientas y la inyección de prompts.",
            "Difícil de evaluar y depurar frente a los prompts de un solo turno."
          ],
          "tools": [
            "LangGraph",
            "OpenAI Agents SDK",
            "Claude Agent SDK",
            "Model Context Protocol (MCP)",
            "Vertex AI Agent Engine"
          ],
          "examples": [
            "Un agente de atención al cliente que lee un ticket, consulta el pedido, aplica un reembolso y responde, todo a través de herramientas.",
            "Un agente de programación que edita ficheros, ejecuta tests e itera hasta que la suite pasa.",
            "Un agente de investigación que busca, lee fuentes, verifica afirmaciones y escribe un resumen con citas."
          ],
          "faqs": [
            {
              "q": "¿Cuál es la diferencia entre un agente de IA y la IA agéntica?",
              "a": "Un agente de IA es un sistema concreto; la IA agéntica es el paradigma más amplio de construir software en torno a esos sistemas dirigidos a objetivos y de varios pasos."
            },
            {
              "q": "¿Hace falta un modelo más potente para ser agéntico?",
              "a": "No necesariamente. El mismo modelo puede triunfar o fracasar en una tarea casi por completo según su harness: las herramientas, la memoria, los prompts y el bucle de control que lo rodean."
            },
            {
              "q": "¿RAG es agéntico?",
              "a": "El RAG simple es un único paso. Se vuelve agéntico cuando el sistema decide cuándo y qué recuperar como parte de un bucle de varios pasos."
            },
            {
              "q": "¿Qué hace poco fiables a los agentes?",
              "a": "Los horizontes largos acumulan errores pequeños, las herramientas fallan y se pierde contexto. La fiabilidad viene de la ingeniería de harness: buenas herramientas, memoria, guardarraíles y evaluación."
            },
            {
              "q": "¿Cómo se mide un agente?",
              "a": "Con benchmarks agénticos y evaluaciones basadas en tareas que puntúan la finalización de extremo a extremo en un entorno, no solo la calidad de una respuesta."
            }
          ]
        },
        "pt": {
          "title": "O que é IA Agêntica (Agentic AI)?",
          "summary": "A IA agêntica designa sistemas que perseguem objetivos em vários passos — planejam, chamam ferramentas, agem sobre um ambiente e reagem ao feedback — em vez de produzir uma única resposta. Transforma um modelo de linguagem de gerador de texto em um ator capaz de concluir tarefas. A mudança que representa é passar do software 'faça você mesmo', em que a pessoa conduz cada passo, ao software 'faça por mim', em que o sistema executa o trabalho e reporta o resultado.",
          "definition": "A IA agêntica é a classe de sistemas de IA que planejam e executam de forma autônoma tarefas de vários passos combinando um modelo com memória, ferramentas e um laço de controle.",
          "takeaways": [
            "Um agente = modelo + ferramentas + memória + um laço de controle que decide o próximo passo.",
            "A autonomia é um espectro, de uma única chamada de ferramenta a tarefas de horizonte longo.",
            "A confiabilidade vem sobretudo do 'harness' em torno do modelo, não do QI do modelo.",
            "O uso de ferramentas (function calling) é o que conecta o modelo a sistemas e dados reais.",
            "A avaliação deve medir a conclusão da tarefa (agência), não só a qualidade da resposta (capacidade)."
          ],
          "context": [
            "Durante boa parte da era LLM os modelos foram usados como respondedores de um único turno: entra um prompt, sai uma resposta. A IA agêntica quebra esse padrão dando ao modelo um laço: ele pode decidir chamar uma ferramenta, ler o resultado, revisar seu plano e continuar até cumprir o objetivo ou esgotar um orçamento.",
            "É a fronteira dominante da IA aplicada na empresa porque move o valor de responder perguntas para concluir trabalho: resolver um chamado de suporte de ponta a ponta, refatorar um código, executar uma pesquisa, operar um fluxo de trabalho."
          ],
          "architecture": [
            "Um agente mínimo tem quatro partes: um modelo de raciocínio, um conjunto de ferramentas que pode invocar, alguma forma de memória ou estado, e um laço de orquestração que converte as saídas do modelo em ações e realimenta as observações.",
            "Os padrões vão do simples (um modelo com ferramentas e uma condição de parada) ao complexo (separação planejador-executor, reflexão e equipes multiagente). A recomendação da Anthropic é preferir o padrão mais simples que funcione e adicionar estrutura só quando agregar de forma mensurável."
          ],
          "components": [
            "Modelo de raciocínio",
            "Ferramentas / function calling",
            "Memória e estado",
            "Laço de orquestração",
            "Guard-rails",
            "Observabilidade"
          ],
          "pros": [
            "Conclui trabalho de vários passos, não só respostas isoladas.",
            "Adapta-se ao feedback e se recupera de erros intermediários.",
            "Integra-se a sistemas reais por meio de ferramentas e APIs.",
            "Escala trabalho de conhecimento repetitivo antes exclusivamente humano."
          ],
          "risks": [
            "Acúmulo de erros em horizontes de tarefa longos.",
            "Custo e latência sem limite sem orçamentos e condições de parada.",
            "Exposição de segurança pelo acesso a ferramentas e pela injeção de prompts.",
            "Difícil de avaliar e depurar frente aos prompts de um único turno."
          ],
          "tools": [
            "LangGraph",
            "OpenAI Agents SDK",
            "Claude Agent SDK",
            "Model Context Protocol (MCP)",
            "Vertex AI Agent Engine"
          ],
          "examples": [
            "Um agente de atendimento que lê um chamado, consulta o pedido, aplica um reembolso e responde, tudo via ferramentas.",
            "Um agente de programação que edita arquivos, executa testes e itera até a suíte passar.",
            "Um agente de pesquisa que busca, lê fontes, verifica afirmações e escreve um resumo com citações."
          ],
          "faqs": [
            {
              "q": "Qual é a diferença entre um agente de IA e IA agêntica?",
              "a": "Um agente de IA é um sistema concreto; a IA agêntica é o paradigma mais amplo de construir software em torno desses sistemas orientados a objetivos e de vários passos."
            },
            {
              "q": "É preciso um modelo mais potente para ser agêntico?",
              "a": "Não necessariamente. O mesmo modelo pode ter sucesso ou falhar numa tarefa quase inteiramente conforme seu harness: as ferramentas, a memória, os prompts e o laço de controle ao seu redor."
            },
            {
              "q": "RAG é agêntico?",
              "a": "O RAG simples é um único passo. Torna-se agêntico quando o sistema decide quando e o que recuperar como parte de um laço de vários passos."
            },
            {
              "q": "O que torna os agentes pouco confiáveis?",
              "a": "Horizontes longos acumulam pequenos erros, ferramentas falham e contexto se perde. A confiabilidade vem da engenharia de harness: boas ferramentas, memória, guard-rails e avaliação."
            },
            {
              "q": "Como se mede um agente?",
              "a": "Com benchmarks agênticos e avaliações baseadas em tarefas que pontuam a conclusão de ponta a ponta num ambiente, não só a qualidade de uma resposta."
            }
          ]
        }
      }
    },
    {
      "slug": "agentic-evaluation",
      "category": "concept",
      "updated": "2026-06-24",
      "version": "1.1",
      "url": "https://santismm.com/en/knowledge/agentic-evaluation",
      "api": "https://santismm.com/api/knowledge/agentic-evaluation",
      "evidence": {
        "evidenceLevel": "production",
        "confidenceLevel": "medium",
        "sourceType": [
          "production_system",
          "personal_experience",
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Jimenez et al. — SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (2023)",
          "url": "https://arxiv.org/abs/2310.06770"
        },
        {
          "title": "Santiago Santa María — The Stopwatch and the Exam",
          "url": "https://articles.santismm.com/the-stopwatch-and-the-exam/"
        }
      ],
      "related": [
        "agentic-ai",
        "harness-engineering",
        "ai-agent",
        "ai-governance"
      ],
      "locales": {
        "en": {
          "title": "What is Agentic AI Evaluation?",
          "summary": "Agentic AI evaluation is the practice of measuring how well an agent completes multi-step, tool-using tasks in an environment — not just the quality of a single answer. As models saturate static knowledge benchmarks, evaluation is shifting from measuring capability (what a model knows) to measuring agency (what a system can actually get done). Good evals are the feedback loop that makes harness engineering possible.",
          "definition": "Agentic evaluation is the measurement of an AI agent's end-to-end task performance — success rate, reliability, cost and safety — on realistic, multi-step tasks in an environment.",
          "takeaways": [
            "Evaluate task completion (agency), not just answer quality (capability).",
            "Agentic benchmarks test tools, environments and long horizons.",
            "Static benchmarks saturate; agentic ones are the new frontier.",
            "Evals are the feedback loop for improving the harness.",
            "Measure success, reliability, cost, latency and safety together."
          ],
          "context": [
            "Traditional benchmarks ask a model questions and score the answers. That measures capability, but it tells you little about whether a system can complete real work. Agentic evaluation instead places an agent in an environment with tools and a goal, and scores whether it actually achieves it.",
            "This shift matters because production value comes from task completion. An agent that answers well but fails to finish tasks is not useful. Evaluation is also what lets teams improve harnesses systematically rather than by anecdote."
          ],
          "architecture": [
            "An agentic eval defines tasks, an environment (real or simulated) with tools, a success criterion, and metrics. The agent runs; its trajectory and outcome are scored automatically where possible, with human review for nuanced cases.",
            "Beyond a single success rate, mature evaluation tracks reliability across runs, cost and latency budgets, and safety (did the agent stay within authorization and avoid harmful actions). Traces from observability feed directly into eval design."
          ],
          "components": [
            "Task suite",
            "Environment & tools",
            "Success criteria",
            "Metrics (success, cost, latency, safety)",
            "Automated graders",
            "Human review",
            "Trajectory traces"
          ],
          "pros": [
            "Measures what actually matters: task completion.",
            "Catches regressions before they reach users.",
            "Turns harness improvement into a measurable loop.",
            "Surfaces reliability, cost and safety, not just accuracy."
          ],
          "risks": [
            "Hard to build realistic environments and graders.",
            "Overfitting to a benchmark instead of real performance.",
            "Saturation: benchmarks lose discriminative power over time.",
            "Automated grading can miss nuance; human review is costly."
          ],
          "tools": [
            "SWE-bench and other agentic benchmarks",
            "LangSmith / Langfuse",
            "OpenAI Evals",
            "Custom task harnesses",
            "LLM-as-judge graders"
          ],
          "examples": [
            "Scoring a coding agent on whether its patch makes a real test suite pass.",
            "Measuring a support agent's end-to-end ticket resolution rate.",
            "Tracking reliability of a workflow agent across repeated runs.",
            "In practice: evaluating an autonomous agent (OpenClaw) over 57 days straight from production traces — 161 sessions at 98.8% success (2 errors), with per-model reliability of 100% vs 95.7% across two model versions — a reliability baseline computed directly from operational traces rather than a curated benchmark set."
          ],
          "faqs": [
            {
              "q": "What is the difference between capability and agency?",
              "a": "Capability is what a model knows or can do in isolation; agency is what a full system can actually accomplish in an environment. Agentic evaluation measures the latter."
            },
            {
              "q": "Why are static benchmarks no longer enough?",
              "a": "Top models saturate them, so they stop discriminating. They also do not test tool use, environments or long-horizon tasks, which is where real agent performance lives."
            },
            {
              "q": "What is an agentic benchmark?",
              "a": "A test that scores an agent's ability to complete multi-step, tool-using tasks in an environment — for example resolving real software issues."
            },
            {
              "q": "How do evals relate to harness engineering?",
              "a": "Evals are the measurement loop that makes harness engineering possible: you change the harness, measure the effect, and keep what demonstrably improves task performance."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Evaluación de IA Agéntica?",
          "summary": "La evaluación de IA agéntica es la práctica de medir cómo de bien un agente completa tareas de varios pasos con uso de herramientas en un entorno, no solo la calidad de una única respuesta. A medida que los modelos saturan los benchmarks estáticos de conocimiento, la evaluación se desplaza de medir capacidad (lo que un modelo sabe) a medir agencia (lo que un sistema realmente logra hacer). Unas buenas evaluaciones son el bucle de feedback que hace posible la ingeniería de harness.",
          "definition": "La evaluación agéntica es la medición del rendimiento de extremo a extremo de un agente de IA —tasa de éxito, fiabilidad, coste y seguridad— en tareas realistas de varios pasos dentro de un entorno.",
          "takeaways": [
            "Evaluar la finalización de la tarea (agencia), no solo la calidad de la respuesta (capacidad).",
            "Los benchmarks agénticos prueban herramientas, entornos y horizontes largos.",
            "Los benchmarks estáticos se saturan; los agénticos son la nueva frontera.",
            "Las evaluaciones son el bucle de feedback para mejorar el harness.",
            "Medir juntos éxito, fiabilidad, coste, latencia y seguridad."
          ],
          "context": [
            "Los benchmarks tradicionales hacen preguntas a un modelo y puntúan las respuestas. Eso mide capacidad, pero dice poco sobre si un sistema puede completar trabajo real. La evaluación agéntica, en cambio, coloca a un agente en un entorno con herramientas y un objetivo, y puntúa si realmente lo alcanza.",
            "Este cambio importa porque el valor en producción viene de completar tareas. Un agente que responde bien pero no termina las tareas no es útil. La evaluación es también lo que permite mejorar los harness de forma sistemática y no por anécdota."
          ],
          "architecture": [
            "Una evaluación agéntica define tareas, un entorno (real o simulado) con herramientas, un criterio de éxito y métricas. El agente se ejecuta; su trayectoria y su resultado se puntúan automáticamente cuando es posible, con revisión humana para casos con matiz.",
            "Más allá de una sola tasa de éxito, la evaluación madura sigue la fiabilidad entre ejecuciones, los presupuestos de coste y latencia, y la seguridad (¿se mantuvo el agente dentro de su autorización y evitó acciones dañinas?). Las trazas de observabilidad alimentan directamente el diseño de las evaluaciones."
          ],
          "components": [
            "Suite de tareas",
            "Entorno y herramientas",
            "Criterios de éxito",
            "Métricas (éxito, coste, latencia, seguridad)",
            "Evaluadores automáticos",
            "Revisión humana",
            "Trazas de trayectoria"
          ],
          "pros": [
            "Mide lo que de verdad importa: la finalización de la tarea.",
            "Detecta regresiones antes de que lleguen a los usuarios.",
            "Convierte la mejora del harness en un bucle medible.",
            "Saca a la luz fiabilidad, coste y seguridad, no solo precisión."
          ],
          "risks": [
            "Difícil construir entornos y evaluadores realistas.",
            "Sobreajuste a un benchmark en vez del rendimiento real.",
            "Saturación: los benchmarks pierden poder discriminativo con el tiempo.",
            "La evaluación automática puede perder matices; la revisión humana es cara."
          ],
          "tools": [
            "SWE-bench y otros benchmarks agénticos",
            "LangSmith / Langfuse",
            "OpenAI Evals",
            "Harness de tareas a medida",
            "Evaluadores LLM-as-judge"
          ],
          "examples": [
            "Puntuar a un agente de programación según si su parche hace pasar una suite de tests real.",
            "Medir la tasa de resolución de tickets de extremo a extremo de un agente de soporte.",
            "Seguir la fiabilidad de un agente de flujo de trabajo en ejecuciones repetidas.",
            "En la práctica: evaluar un agente autónomo (OpenClaw) durante 57 días directamente desde trazas de producción — 161 sesiones con 98,8% de éxito (2 errores), con fiabilidad por modelo de 100% frente a 95,7% en dos versiones — una línea base de fiabilidad calculada directamente desde trazas operativas, no desde un set de benchmark curado."
          ],
          "faqs": [
            {
              "q": "¿Cuál es la diferencia entre capacidad y agencia?",
              "a": "La capacidad es lo que un modelo sabe o puede hacer de forma aislada; la agencia es lo que un sistema completo logra realmente en un entorno. La evaluación agéntica mide esto último."
            },
            {
              "q": "¿Por qué ya no bastan los benchmarks estáticos?",
              "a": "Los mejores modelos los saturan y dejan de discriminar. Además no prueban uso de herramientas, entornos ni tareas de horizonte largo, que es donde está el rendimiento real de un agente."
            },
            {
              "q": "¿Qué es un benchmark agéntico?",
              "a": "Una prueba que puntúa la capacidad de un agente para completar tareas de varios pasos con uso de herramientas en un entorno; por ejemplo, resolver incidencias reales de software."
            },
            {
              "q": "¿Cómo se relacionan las evaluaciones con la ingeniería de harness?",
              "a": "Las evaluaciones son el bucle de medición que hace posible la ingeniería de harness: cambias el harness, mides el efecto y conservas lo que demuestra mejorar el rendimiento en la tarea."
            }
          ]
        },
        "pt": {
          "title": "O que é Avaliação de IA Agêntica?",
          "summary": "A avaliação de IA agêntica é a prática de medir quão bem um agente conclui tarefas de vários passos com uso de ferramentas num ambiente, não só a qualidade de uma única resposta. À medida que os modelos saturam os benchmarks estáticos de conhecimento, a avaliação se desloca de medir capacidade (o que um modelo sabe) para medir agência (o que um sistema realmente consegue concluir). Boas avaliações são o laço de feedback que torna possível a engenharia de harness.",
          "definition": "A avaliação agêntica é a medição do desempenho de ponta a ponta de um agente de IA — taxa de sucesso, confiabilidade, custo e segurança — em tarefas realistas de vários passos dentro de um ambiente.",
          "takeaways": [
            "Avaliar a conclusão da tarefa (agência), não só a qualidade da resposta (capacidade).",
            "Os benchmarks agênticos testam ferramentas, ambientes e horizontes longos.",
            "Os benchmarks estáticos saturam; os agênticos são a nova fronteira.",
            "As avaliações são o laço de feedback para melhorar o harness.",
            "Medir juntos sucesso, confiabilidade, custo, latência e segurança."
          ],
          "context": [
            "Os benchmarks tradicionais fazem perguntas a um modelo e pontuam as respostas. Isso mede capacidade, mas diz pouco sobre se um sistema consegue concluir trabalho real. A avaliação agêntica, em vez disso, coloca um agente num ambiente com ferramentas e um objetivo, e pontua se ele realmente o alcança.",
            "Essa mudança importa porque o valor em produção vem de concluir tarefas. Um agente que responde bem mas não termina as tarefas não é útil. A avaliação é também o que permite melhorar os harnesses de forma sistemática e não por anedota."
          ],
          "architecture": [
            "Uma avaliação agêntica define tarefas, um ambiente (real ou simulado) com ferramentas, um critério de sucesso e métricas. O agente é executado; sua trajetória e seu resultado são pontuados automaticamente quando possível, com revisão humana para casos com nuance.",
            "Além de uma única taxa de sucesso, a avaliação madura acompanha a confiabilidade entre execuções, os orçamentos de custo e latência, e a segurança (o agente se manteve dentro de sua autorização e evitou ações nocivas?). Os rastros de observabilidade alimentam diretamente o design das avaliações."
          ],
          "components": [
            "Suíte de tarefas",
            "Ambiente e ferramentas",
            "Critérios de sucesso",
            "Métricas (sucesso, custo, latência, segurança)",
            "Avaliadores automáticos",
            "Revisão humana",
            "Rastros de trajetória"
          ],
          "pros": [
            "Mede o que de fato importa: a conclusão da tarefa.",
            "Detecta regressões antes de chegarem aos usuários.",
            "Transforma a melhoria do harness num laço mensurável.",
            "Revela confiabilidade, custo e segurança, não só precisão."
          ],
          "risks": [
            "Difícil construir ambientes e avaliadores realistas.",
            "Sobreajuste a um benchmark em vez do desempenho real.",
            "Saturação: os benchmarks perdem poder discriminativo com o tempo.",
            "A avaliação automática pode perder nuances; a revisão humana é cara."
          ],
          "tools": [
            "SWE-bench e outros benchmarks agênticos",
            "LangSmith / Langfuse",
            "OpenAI Evals",
            "Harness de tarefas sob medida",
            "Avaliadores LLM-as-judge"
          ],
          "examples": [
            "Pontuar um agente de programação conforme seu patch faça passar uma suíte de testes real.",
            "Medir a taxa de resolução de chamados de ponta a ponta de um agente de suporte.",
            "Acompanhar a confiabilidade de um agente de fluxo de trabalho em execuções repetidas.",
            "Na prática: avaliar um agente autônomo (OpenClaw) por 57 dias diretamente a partir de rastros de produção — 161 sessões com 98,8% de sucesso (2 erros), com confiabilidade por modelo de 100% ante 95,7% em duas versões — uma linha de base de confiabilidade calculada diretamente de rastros operacionais, não de um conjunto de benchmark curado."
          ],
          "faqs": [
            {
              "q": "Qual é a diferença entre capacidade e agência?",
              "a": "Capacidade é o que um modelo sabe ou pode fazer isoladamente; agência é o que um sistema completo realmente realiza num ambiente. A avaliação agêntica mede o segundo."
            },
            {
              "q": "Por que os benchmarks estáticos já não bastam?",
              "a": "Os melhores modelos os saturam e deixam de discriminar. Além disso não testam uso de ferramentas, ambientes nem tarefas de horizonte longo, que é onde está o desempenho real de um agente."
            },
            {
              "q": "O que é um benchmark agêntico?",
              "a": "Um teste que pontua a capacidade de um agente de concluir tarefas de vários passos com uso de ferramentas num ambiente; por exemplo, resolver issues reais de software."
            },
            {
              "q": "Como as avaliações se relacionam com a engenharia de harness?",
              "a": "As avaliações são o laço de medição que torna possível a engenharia de harness: você muda o harness, mede o efeito e mantém o que comprovadamente melhora o desempenho na tarefa."
            }
          ]
        }
      }
    },
    {
      "slug": "ai-agent",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/ai-agent",
      "api": "https://santismm.com/api/knowledge/ai-agent",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        },
        {
          "title": "Yao et al. — ReAct (2022)",
          "url": "https://arxiv.org/abs/2210.03629"
        }
      ],
      "related": [
        "agentic-ai",
        "harness-engineering",
        "model-context-protocol",
        "multi-agent-architecture"
      ],
      "locales": {
        "en": {
          "title": "What is an AI Agent?",
          "summary": "An AI agent is a system that combines a model with tools, memory and a control loop to take actions toward a goal, rather than just answering a single prompt. It perceives a situation, decides what to do, acts through tools, observes the result and repeats until done. Autonomy ranges from a single tool call to long-horizon execution of complex tasks.",
          "definition": "An AI agent is a system that pairs a reasoning model with tools, memory and an orchestration loop so it can plan and act over multiple steps to achieve a goal.",
          "takeaways": [
            "Agent = model + tools + memory + control loop.",
            "Agents act; chatbots answer.",
            "Tool use is the bridge to real systems and data.",
            "More autonomy means more need for guardrails and evaluation.",
            "Reliability is engineered through the harness, not assumed from the model."
          ],
          "context": [
            "A plain LLM produces text. An agent uses that text to decide and act: it can search, call APIs, write files or trigger workflows, then react to what happens. This loop is what lets it complete tasks instead of merely describing them.",
            "Agents sit on a spectrum of autonomy. Low-autonomy agents make one or two tool calls under tight control; high-autonomy agents run long, branching tasks with little supervision — and need correspondingly stronger guardrails."
          ],
          "architecture": [
            "The core loop is sense → decide → act → observe. The model decides the next action, an orchestrator executes it via a tool, the result is fed back as an observation, and the loop continues until a goal or stop condition is reached.",
            "Around this loop sit memory (to carry state), guardrails (to constrain behavior), and observability (to trace what happened). These are the parts of the harness that make an agent dependable."
          ],
          "components": [
            "Reasoning model",
            "Tools",
            "Memory",
            "Orchestration loop",
            "Guardrails",
            "Observability"
          ],
          "pros": [
            "Executes tasks end to end.",
            "Connects models to live systems.",
            "Recovers from intermediate failures.",
            "Automates multi-step knowledge work."
          ],
          "risks": [
            "Error compounding over long tasks.",
            "Cost and latency without budgets.",
            "Prompt injection and tool-misuse risks.",
            "Harder to test and debug than single prompts."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "CrewAI",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "A triage agent that classifies and routes incoming requests.",
            "A coding agent that fixes a bug and verifies it with tests.",
            "A data agent that queries a warehouse and assembles a report."
          ],
          "faqs": [
            {
              "q": "Is a chatbot an AI agent?",
              "a": "Not by default. A chatbot answers; an agent takes actions through tools across multiple steps to reach a goal."
            },
            {
              "q": "What is the simplest useful agent?",
              "a": "A model with one or two well-described tools and a clear stop condition. Start simple and add structure only when measurement shows you need it."
            },
            {
              "q": "What makes an agent reliable?",
              "a": "The harness: clean tool design, good memory, guardrails, observability and evaluation — not just a stronger model."
            },
            {
              "q": "Single agent or multi-agent?",
              "a": "Prefer a single agent until a task clearly benefits from specialized, separable roles. Multi-agent adds coordination overhead."
            }
          ]
        },
        "es": {
          "title": "¿Qué es un Agente de IA?",
          "summary": "Un agente de IA es un sistema que combina un modelo con herramientas, memoria y un bucle de control para tomar acciones hacia un objetivo, en lugar de solo responder a un prompt. Percibe una situación, decide qué hacer, actúa mediante herramientas, observa el resultado y repite hasta terminar. La autonomía va desde una sola llamada a herramienta hasta la ejecución de tareas complejas de horizonte largo.",
          "definition": "Un agente de IA es un sistema que une un modelo de razonamiento con herramientas, memoria y un bucle de orquestación para planificar y actuar en varios pasos hacia un objetivo.",
          "takeaways": [
            "Agente = modelo + herramientas + memoria + bucle de control.",
            "Los agentes actúan; los chatbots responden.",
            "El uso de herramientas es el puente hacia sistemas y datos reales.",
            "Más autonomía exige más guardarraíles y evaluación.",
            "La fiabilidad se diseña con el harness, no se da por sentada en el modelo."
          ],
          "context": [
            "Un LLM simple produce texto. Un agente usa ese texto para decidir y actuar: puede buscar, llamar APIs, escribir ficheros o disparar flujos, y luego reaccionar a lo que ocurre. Ese bucle es lo que le permite completar tareas en vez de solo describirlas.",
            "Los agentes están en un espectro de autonomía. Los de baja autonomía hacen una o dos llamadas bajo control estricto; los de alta autonomía ejecutan tareas largas y ramificadas con poca supervisión, y necesitan guardarraíles proporcionalmente más fuertes."
          ],
          "architecture": [
            "El bucle central es percibir → decidir → actuar → observar. El modelo decide la siguiente acción, un orquestador la ejecuta vía una herramienta, el resultado vuelve como observación, y el bucle continúa hasta alcanzar un objetivo o una condición de parada.",
            "Alrededor de ese bucle están la memoria (para arrastrar estado), los guardarraíles (para acotar el comportamiento) y la observabilidad (para trazar lo ocurrido). Son las partes del harness que hacen fiable a un agente."
          ],
          "components": [
            "Modelo de razonamiento",
            "Herramientas",
            "Memoria",
            "Bucle de orquestación",
            "Guardarraíles",
            "Observabilidad"
          ],
          "pros": [
            "Ejecuta tareas de principio a fin.",
            "Conecta modelos con sistemas en vivo.",
            "Se recupera de fallos intermedios.",
            "Automatiza trabajo de conocimiento de varios pasos."
          ],
          "risks": [
            "Acumulación de errores en tareas largas.",
            "Coste y latencia sin presupuestos.",
            "Riesgos de inyección de prompts y mal uso de herramientas.",
            "Más difícil de probar y depurar que un prompt simple."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "CrewAI",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "Un agente de triaje que clasifica y enruta solicitudes entrantes.",
            "Un agente de programación que corrige un bug y lo verifica con tests.",
            "Un agente de datos que consulta un warehouse y arma un informe."
          ],
          "faqs": [
            {
              "q": "¿Un chatbot es un agente de IA?",
              "a": "Por defecto no. Un chatbot responde; un agente toma acciones mediante herramientas en varios pasos para alcanzar un objetivo."
            },
            {
              "q": "¿Cuál es el agente útil más simple?",
              "a": "Un modelo con una o dos herramientas bien descritas y una condición de parada clara. Empieza simple y añade estructura solo cuando la medición lo justifique."
            },
            {
              "q": "¿Qué hace fiable a un agente?",
              "a": "El harness: diseño limpio de herramientas, buena memoria, guardarraíles, observabilidad y evaluación, no solo un modelo más potente."
            },
            {
              "q": "¿Un agente o multiagente?",
              "a": "Prefiere un solo agente hasta que la tarea se beneficie claramente de roles especializados y separables. El multiagente añade coste de coordinación."
            }
          ]
        },
        "pt": {
          "title": "O que é um Agente de IA?",
          "summary": "Um agente de IA é um sistema que combina um modelo com ferramentas, memória e um laço de controle para tomar ações rumo a um objetivo, em vez de só responder a um prompt. Ele percebe uma situação, decide o que fazer, age por meio de ferramentas, observa o resultado e repete até concluir. A autonomia vai de uma única chamada de ferramenta à execução de tarefas complexas de horizonte longo.",
          "definition": "Um agente de IA é um sistema que une um modelo de raciocínio a ferramentas, memória e um laço de orquestração para planejar e agir em vários passos rumo a um objetivo.",
          "takeaways": [
            "Agente = modelo + ferramentas + memória + laço de controle.",
            "Agentes agem; chatbots respondem.",
            "O uso de ferramentas é a ponte para sistemas e dados reais.",
            "Mais autonomia exige mais guard-rails e avaliação.",
            "A confiabilidade é projetada com o harness, não presumida do modelo."
          ],
          "context": [
            "Um LLM simples produz texto. Um agente usa esse texto para decidir e agir: pode buscar, chamar APIs, escrever arquivos ou disparar fluxos, e então reagir ao que acontece. Esse laço é o que lhe permite concluir tarefas em vez de só descrevê-las.",
            "Os agentes estão num espectro de autonomia. Os de baixa autonomia fazem uma ou duas chamadas sob controle estrito; os de alta autonomia executam tarefas longas e ramificadas com pouca supervisão, e precisam de guard-rails proporcionalmente mais fortes."
          ],
          "architecture": [
            "O laço central é perceber → decidir → agir → observar. O modelo decide a próxima ação, um orquestrador a executa via uma ferramenta, o resultado retorna como observação, e o laço continua até alcançar um objetivo ou uma condição de parada.",
            "Em torno desse laço estão a memória (para carregar estado), os guard-rails (para limitar o comportamento) e a observabilidade (para rastrear o ocorrido). São as partes do harness que tornam um agente confiável."
          ],
          "components": [
            "Modelo de raciocínio",
            "Ferramentas",
            "Memória",
            "Laço de orquestração",
            "Guard-rails",
            "Observabilidade"
          ],
          "pros": [
            "Executa tarefas de ponta a ponta.",
            "Conecta modelos a sistemas ao vivo.",
            "Recupera-se de falhas intermediárias.",
            "Automatiza trabalho de conhecimento de vários passos."
          ],
          "risks": [
            "Acúmulo de erros em tarefas longas.",
            "Custo e latência sem orçamentos.",
            "Riscos de injeção de prompts e mau uso de ferramentas.",
            "Mais difícil de testar e depurar que um prompt simples."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "CrewAI",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "Um agente de triagem que classifica e roteia solicitações recebidas.",
            "Um agente de programação que corrige um bug e o verifica com testes.",
            "Um agente de dados que consulta um warehouse e monta um relatório."
          ],
          "faqs": [
            {
              "q": "Um chatbot é um agente de IA?",
              "a": "Por padrão não. Um chatbot responde; um agente toma ações por meio de ferramentas em vários passos para alcançar um objetivo."
            },
            {
              "q": "Qual é o agente útil mais simples?",
              "a": "Um modelo com uma ou duas ferramentas bem descritas e uma condição de parada clara. Comece simples e adicione estrutura só quando a medição justificar."
            },
            {
              "q": "O que torna um agente confiável?",
              "a": "O harness: design limpo de ferramentas, boa memória, guard-rails, observabilidade e avaliação, não só um modelo mais potente."
            },
            {
              "q": "Um agente ou multiagente?",
              "a": "Prefira um único agente até a tarefa se beneficiar claramente de papéis especializados e separáveis. O multiagente adiciona custo de coordenação."
            }
          ]
        }
      }
    },
    {
      "slug": "ai-governance",
      "category": "governance",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/ai-governance",
      "api": "https://santismm.com/api/knowledge/ai-governance",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "paper",
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        },
        {
          "title": "European Union — AI Act (Regulation 2024/1689)",
          "url": "https://eur-lex.europa.eu/eli/reg/2024/1689/oj"
        },
        {
          "title": "ISO/IEC 42001:2023 — AI management systems",
          "url": "https://www.iso.org/standard/81230.html"
        }
      ],
      "related": [
        "enterprise-rag",
        "agentic-evaluation",
        "agentic-ai",
        "harness-engineering"
      ],
      "locales": {
        "en": {
          "title": "What is AI Governance?",
          "summary": "AI governance is the set of policies, processes, roles and controls that ensure AI is built and used responsibly, legally and safely. It spans risk management, accountability, transparency, security and compliance across the AI lifecycle. In practice it operationalizes recognized frameworks — the EU AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001 — into concrete controls an organization can implement, evidence and audit.",
          "definition": "AI governance is the framework of policies, processes, roles and controls an organization uses to manage AI risk and ensure AI systems are responsible, compliant, secure and accountable across their lifecycle.",
          "takeaways": [
            "Governance turns AI principles into enforceable, auditable controls.",
            "It spans the full lifecycle: data, build, deploy, monitor, retire.",
            "Major references: EU AI Act, NIST AI RMF, ISO/IEC 42001.",
            "Agentic AI raises the stakes: autonomy and tool access widen risk.",
            "Good governance enables adoption; it is not just a brake."
          ],
          "context": [
            "As AI moves into decisions that affect people and operations, organizations need a way to manage its risks systematically — not ad hoc. Governance provides that: clear ownership, documented risk assessment, controls, monitoring and the evidence to demonstrate compliance.",
            "Agentic systems sharpen the need. When software can act autonomously and call tools, the questions of authorization, accountability, auditability and human oversight become operational, not theoretical."
          ],
          "architecture": [
            "A practical governance program has layers: policy and principles; an AI risk catalog and assessment process; controls (access, data handling, evaluation, human oversight, logging); monitoring and incident response; and an audit trail that maps controls to external frameworks.",
            "Frameworks complement each other. The NIST AI RMF organizes practice around Govern, Map, Measure and Manage. ISO/IEC 42001 defines an auditable AI management system. The EU AI Act sets legal obligations by risk tier. Mature programs map their controls to all three."
          ],
          "components": [
            "Policy & principles",
            "AI risk catalog",
            "Risk assessment process",
            "Controls (access, data, oversight)",
            "Evaluation & monitoring",
            "Incident response",
            "Audit trail & framework mapping"
          ],
          "pros": [
            "Manages legal, ethical and operational risk systematically.",
            "Builds trust with customers, regulators and employees.",
            "Provides evidence for audits and certifications.",
            "Enables faster, safer adoption with clear guardrails."
          ],
          "risks": [
            "Bureaucracy that slows adoption if over-engineered.",
            "Paper compliance that does not change real behavior.",
            "Fragmented ownership across legal, security and product.",
            "Falling behind fast-moving regulation and capabilities."
          ],
          "tools": [
            "NIST AI RMF",
            "ISO/IEC 42001",
            "EU AI Act compliance mapping",
            "Model & system documentation (model cards)",
            "AI evaluation & monitoring platforms"
          ],
          "examples": [
            "An AI risk catalog with assessments per use case before deployment.",
            "Human-in-the-loop approval controls for high-impact agent actions.",
            "Logging and audit trails mapped to NIST AI RMF functions."
          ],
          "faqs": [
            {
              "q": "What frameworks should we follow?",
              "a": "Commonly the NIST AI Risk Management Framework, ISO/IEC 42001 and, where in scope, the EU AI Act. Mature programs map a single control set to all three."
            },
            {
              "q": "Is AI governance only about compliance?",
              "a": "No. Compliance is one part. Governance also covers risk, security, transparency, accountability and operational oversight that enable safe adoption."
            },
            {
              "q": "How does governance apply to agents?",
              "a": "Autonomy and tool access add risk, so agentic systems need authorization controls, human oversight for high-impact actions, logging and evaluation."
            },
            {
              "q": "Does governance slow innovation?",
              "a": "Done well, it accelerates it: clear guardrails let teams ship with confidence. Done poorly, it becomes bureaucracy. The goal is enforceable, lightweight controls."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Gobernanza de la IA (AI Governance)?",
          "summary": "La gobernanza de la IA es el conjunto de políticas, procesos, roles y controles que garantizan que la IA se construya y use de forma responsable, legal y segura. Abarca gestión de riesgos, rendición de cuentas, transparencia, seguridad y cumplimiento a lo largo del ciclo de vida de la IA. En la práctica operacionaliza marcos reconocidos —el Reglamento de IA de la UE, el NIST AI Risk Management Framework e ISO/IEC 42001— en controles concretos que una organización puede implementar, evidenciar y auditar.",
          "definition": "La gobernanza de la IA es el marco de políticas, procesos, roles y controles que una organización usa para gestionar el riesgo de la IA y asegurar que sus sistemas sean responsables, conformes, seguros y auditables a lo largo de su ciclo de vida.",
          "takeaways": [
            "La gobernanza convierte los principios de IA en controles exigibles y auditables.",
            "Abarca todo el ciclo de vida: datos, construcción, despliegue, monitorización, retirada.",
            "Referencias principales: Reglamento de IA de la UE, NIST AI RMF, ISO/IEC 42001.",
            "La IA agéntica eleva la apuesta: la autonomía y el acceso a herramientas amplían el riesgo.",
            "Una buena gobernanza habilita la adopción; no es solo un freno."
          ],
          "context": [
            "A medida que la IA entra en decisiones que afectan a personas y operaciones, las organizaciones necesitan gestionar sus riesgos de forma sistemática, no ad hoc. La gobernanza lo aporta: propiedad clara, evaluación de riesgos documentada, controles, monitorización y la evidencia para demostrar el cumplimiento.",
            "Los sistemas agénticos agudizan la necesidad. Cuando el software puede actuar de forma autónoma y llamar a herramientas, las cuestiones de autorización, rendición de cuentas, auditabilidad y supervisión humana se vuelven operativas, no teóricas."
          ],
          "architecture": [
            "Un programa práctico de gobernanza tiene capas: política y principios; un catálogo de riesgos de IA y un proceso de evaluación; controles (acceso, tratamiento de datos, evaluación, supervisión humana, registro); monitorización y respuesta a incidentes; y una traza de auditoría que mapea los controles a marcos externos.",
            "Los marcos se complementan. El NIST AI RMF organiza la práctica en Gobernar, Mapear, Medir y Gestionar. ISO/IEC 42001 define un sistema de gestión de IA auditable. El Reglamento de IA de la UE fija obligaciones legales por nivel de riesgo. Los programas maduros mapean sus controles a los tres."
          ],
          "components": [
            "Política y principios",
            "Catálogo de riesgos de IA",
            "Proceso de evaluación de riesgos",
            "Controles (acceso, datos, supervisión)",
            "Evaluación y monitorización",
            "Respuesta a incidentes",
            "Traza de auditoría y mapeo de marcos"
          ],
          "pros": [
            "Gestiona el riesgo legal, ético y operativo de forma sistemática.",
            "Genera confianza con clientes, reguladores y empleados.",
            "Aporta evidencia para auditorías y certificaciones.",
            "Habilita una adopción más rápida y segura con guardarraíles claros."
          ],
          "risks": [
            "Burocracia que ralentiza la adopción si se sobreingeniería.",
            "Cumplimiento de papel que no cambia el comportamiento real.",
            "Propiedad fragmentada entre legal, seguridad y producto.",
            "Quedarse atrás frente a una regulación y unas capacidades que cambian rápido."
          ],
          "tools": [
            "NIST AI RMF",
            "ISO/IEC 42001",
            "Mapeo de cumplimiento del Reglamento de IA de la UE",
            "Documentación de modelos y sistemas (model cards)",
            "Plataformas de evaluación y monitorización de IA"
          ],
          "examples": [
            "Un catálogo de riesgos de IA con evaluaciones por caso de uso antes del despliegue.",
            "Controles de aprobación con humano en el bucle para acciones de agente de alto impacto.",
            "Registro y trazas de auditoría mapeados a las funciones del NIST AI RMF."
          ],
          "faqs": [
            {
              "q": "¿Qué marcos deberíamos seguir?",
              "a": "Habitualmente el NIST AI Risk Management Framework, ISO/IEC 42001 y, cuando aplique, el Reglamento de IA de la UE. Los programas maduros mapean un único conjunto de controles a los tres."
            },
            {
              "q": "¿La gobernanza de IA es solo cumplimiento?",
              "a": "No. El cumplimiento es una parte. La gobernanza también cubre riesgo, seguridad, transparencia, rendición de cuentas y supervisión operativa que habilitan una adopción segura."
            },
            {
              "q": "¿Cómo aplica la gobernanza a los agentes?",
              "a": "La autonomía y el acceso a herramientas añaden riesgo, así que los sistemas agénticos necesitan controles de autorización, supervisión humana para acciones de alto impacto, registro y evaluación."
            },
            {
              "q": "¿La gobernanza frena la innovación?",
              "a": "Bien hecha, la acelera: unos guardarraíles claros permiten desplegar con confianza. Mal hecha, se vuelve burocracia. El objetivo son controles exigibles y ligeros."
            }
          ]
        },
        "pt": {
          "title": "O que é Governança de IA (AI Governance)?",
          "summary": "A governança de IA é o conjunto de políticas, processos, papéis e controles que garantem que a IA seja construída e usada de forma responsável, legal e segura. Abrange gestão de riscos, prestação de contas, transparência, segurança e conformidade ao longo do ciclo de vida da IA. Na prática operacionaliza marcos reconhecidos — o Regulamento de IA da UE, o NIST AI Risk Management Framework e a ISO/IEC 42001 — em controles concretos que uma organização pode implementar, evidenciar e auditar.",
          "definition": "A governança de IA é o marco de políticas, processos, papéis e controles que uma organização usa para gerir o risco da IA e assegurar que seus sistemas sejam responsáveis, conformes, seguros e auditáveis ao longo de seu ciclo de vida.",
          "takeaways": [
            "A governança converte os princípios de IA em controles exigíveis e auditáveis.",
            "Abrange todo o ciclo de vida: dados, construção, implantação, monitoramento, descarte.",
            "Referências principais: Regulamento de IA da UE, NIST AI RMF, ISO/IEC 42001.",
            "A IA agêntica eleva a aposta: a autonomia e o acesso a ferramentas ampliam o risco.",
            "Uma boa governança habilita a adoção; não é só um freio."
          ],
          "context": [
            "À medida que a IA entra em decisões que afetam pessoas e operações, as organizações precisam gerir seus riscos de forma sistemática, não ad hoc. A governança fornece isso: propriedade clara, avaliação de risco documentada, controles, monitoramento e a evidência para demonstrar conformidade.",
            "Os sistemas agênticos aguçam a necessidade. Quando o software pode agir de forma autônoma e chamar ferramentas, as questões de autorização, prestação de contas, auditabilidade e supervisão humana se tornam operacionais, não teóricas."
          ],
          "architecture": [
            "Um programa prático de governança tem camadas: política e princípios; um catálogo de riscos de IA e um processo de avaliação; controles (acesso, tratamento de dados, avaliação, supervisão humana, registro); monitoramento e resposta a incidentes; e uma trilha de auditoria que mapeia os controles a marcos externos.",
            "Os marcos se complementam. O NIST AI RMF organiza a prática em Governar, Mapear, Medir e Gerir. A ISO/IEC 42001 define um sistema de gestão de IA auditável. O Regulamento de IA da UE fixa obrigações legais por nível de risco. Programas maduros mapeiam seus controles aos três."
          ],
          "components": [
            "Política e princípios",
            "Catálogo de riscos de IA",
            "Processo de avaliação de riscos",
            "Controles (acesso, dados, supervisão)",
            "Avaliação e monitoramento",
            "Resposta a incidentes",
            "Trilha de auditoria e mapeamento de marcos"
          ],
          "pros": [
            "Gere o risco legal, ético e operacional de forma sistemática.",
            "Gera confiança com clientes, reguladores e funcionários.",
            "Fornece evidência para auditorias e certificações.",
            "Habilita uma adoção mais rápida e segura com guard-rails claros."
          ],
          "risks": [
            "Burocracia que freia a adoção se for superengenheirada.",
            "Conformidade de papel que não muda o comportamento real.",
            "Propriedade fragmentada entre jurídico, segurança e produto.",
            "Ficar para trás frente a uma regulação e capacidades que mudam rápido."
          ],
          "tools": [
            "NIST AI RMF",
            "ISO/IEC 42001",
            "Mapeamento de conformidade do Regulamento de IA da UE",
            "Documentação de modelos e sistemas (model cards)",
            "Plataformas de avaliação e monitoramento de IA"
          ],
          "examples": [
            "Um catálogo de riscos de IA com avaliações por caso de uso antes da implantação.",
            "Controles de aprovação com humano no laço para ações de agente de alto impacto.",
            "Registro e trilhas de auditoria mapeados às funções do NIST AI RMF."
          ],
          "faqs": [
            {
              "q": "Quais marcos devemos seguir?",
              "a": "Comumente o NIST AI Risk Management Framework, a ISO/IEC 42001 e, quando aplicável, o Regulamento de IA da UE. Programas maduros mapeiam um único conjunto de controles aos três."
            },
            {
              "q": "A governança de IA é só conformidade?",
              "a": "Não. A conformidade é uma parte. A governança também cobre risco, segurança, transparência, prestação de contas e supervisão operacional que habilitam uma adoção segura."
            },
            {
              "q": "Como a governança se aplica aos agentes?",
              "a": "A autonomia e o acesso a ferramentas adicionam risco, então os sistemas agênticos precisam de controles de autorização, supervisão humana para ações de alto impacto, registro e avaliação."
            },
            {
              "q": "A governança freia a inovação?",
              "a": "Bem feita, a acelera: guard-rails claros permitem implantar com confiança. Mal feita, vira burocracia. O objetivo são controles exigíveis e leves."
            }
          ]
        }
      }
    },
    {
      "slug": "ai-observability",
      "category": "harness",
      "updated": "2026-06-24",
      "version": "1.1",
      "url": "https://santismm.com/en/knowledge/ai-observability",
      "api": "https://santismm.com/api/knowledge/ai-observability",
      "evidence": {
        "evidenceLevel": "production",
        "confidenceLevel": "medium",
        "sourceType": [
          "production_system",
          "personal_experience",
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "OpenTelemetry — Semantic conventions for generative AI",
          "url": "https://opentelemetry.io/docs/specs/semconv/gen-ai/"
        },
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        }
      ],
      "related": [
        "harness-engineering",
        "agentic-evaluation",
        "ai-agent",
        "ai-governance"
      ],
      "locales": {
        "en": {
          "title": "What is AI Agent Observability?",
          "summary": "AI observability is the practice of instrumenting AI systems — especially agents — so you can see what they did and why. It captures traces of each step: prompts, tool calls, retrieved context, model outputs, tokens, latency and cost. Because agents are non-deterministic and multi-step, observability is what makes failures diagnosable and improvement systematic. It is the layer that feeds evaluation and closes the harness-engineering loop.",
          "definition": "AI observability is the practice of capturing traces, metrics and logs of an AI system's behavior — every prompt, tool call, retrieval, output, token, latency and cost — so its decisions can be understood, debugged and improved.",
          "takeaways": [
            "Observability makes non-deterministic agents debuggable.",
            "Traces record each step: prompts, tools, context, outputs, cost.",
            "It feeds evaluation — you improve what you can see and measure.",
            "Track quality, latency, cost and safety together.",
            "Emerging standards (OpenTelemetry GenAI) make traces portable."
          ],
          "context": [
            "Traditional software is deterministic and easy to log. Agents are not: the same input can take different paths, call different tools and produce different outputs. Without tracing, a failure is a black box.",
            "Observability opens that box. By recording the full trajectory of a run, teams can see where an agent went wrong, why a tool failed, where cost ballooned — and feed those findings into evals and harness changes."
          ],
          "architecture": [
            "Instrumentation captures spans for each step — model call, tool call, retrieval — with inputs, outputs, tokens, latency and errors, linked into a trace for the whole run. Metrics aggregate quality, cost, latency and failure rates over time.",
            "OpenTelemetry's GenAI semantic conventions standardize how these traces are structured, so they can flow into general observability backends rather than proprietary silos. Traces also become the raw material for evaluation datasets."
          ],
          "components": [
            "Tracing (spans per step)",
            "Metrics (quality, cost, latency)",
            "Logs",
            "Token & cost accounting",
            "Error tracking",
            "Trace-to-eval pipeline"
          ],
          "pros": [
            "Turns opaque agent runs into diagnosable traces.",
            "Surfaces cost, latency and failure hotspots.",
            "Feeds evaluation and continuous improvement.",
            "Supports incident response and governance audits."
          ],
          "risks": [
            "Traces may capture sensitive data needing redaction.",
            "Instrumentation overhead and storage cost at scale.",
            "Volume without good queries hides the signal.",
            "Privacy and retention obligations on logged prompts."
          ],
          "tools": [
            "OpenTelemetry (GenAI conventions)",
            "LangSmith",
            "Langfuse",
            "Arize / Phoenix",
            "Standard APM backends"
          ],
          "examples": [
            "Tracing a failed agent run to the exact tool call that errored.",
            "Tracking per-task token cost to find an expensive prompt.",
            "Turning production traces into an evaluation dataset.",
            "In practice: a 57-day single-operator autonomous deployment (OpenClaw) traced 161 sessions / 2,776 turns from local trajectory traces — 98.8% session success, p50 8.1s and p95 87.6s per turn, ~70% of tokens served from cache, and a blended $15.21 per 1M tokens (cost partially priced, so a floor). Every figure is derived from the agent's own traces."
          ],
          "faqs": [
            {
              "q": "Why do agents need observability more than chatbots?",
              "a": "Agents are multi-step and non-deterministic, so a single answer hides many internal decisions. Without traces of those steps, failures cannot be diagnosed."
            },
            {
              "q": "How does observability relate to evaluation?",
              "a": "Observability captures what happened; evaluation judges whether it was good. Traces become the data evals run on, closing the improvement loop."
            },
            {
              "q": "Is there a standard for AI traces?",
              "a": "OpenTelemetry's generative-AI semantic conventions are emerging as a portable standard, letting AI traces flow into mainstream observability tooling."
            },
            {
              "q": "What should you measure?",
              "a": "Quality (task success), cost (tokens), latency, and safety together — a fast, cheap agent that fails the task is not a good agent."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Observabilidad de Agentes de IA?",
          "summary": "La observabilidad de IA es la práctica de instrumentar sistemas de IA —sobre todo agentes— para poder ver qué hicieron y por qué. Captura trazas de cada paso: prompts, llamadas a herramientas, contexto recuperado, salidas del modelo, tokens, latencia y coste. Como los agentes son no deterministas y de varios pasos, la observabilidad es lo que hace diagnosticables los fallos y sistemática la mejora. Es la capa que alimenta la evaluación y cierra el bucle de la ingeniería de harness.",
          "definition": "La observabilidad de IA es la práctica de capturar trazas, métricas y registros del comportamiento de un sistema de IA —cada prompt, llamada a herramienta, recuperación, salida, token, latencia y coste— para poder entender, depurar y mejorar sus decisiones.",
          "takeaways": [
            "La observabilidad hace depurables a los agentes no deterministas.",
            "Las trazas registran cada paso: prompts, herramientas, contexto, salidas, coste.",
            "Alimenta la evaluación: mejoras lo que puedes ver y medir.",
            "Sigue juntos calidad, latencia, coste y seguridad.",
            "Estándares emergentes (OpenTelemetry GenAI) hacen portables las trazas."
          ],
          "context": [
            "El software tradicional es determinista y fácil de loguear. Los agentes no: la misma entrada puede tomar caminos distintos, llamar a herramientas distintas y producir salidas distintas. Sin trazado, un fallo es una caja negra.",
            "La observabilidad abre esa caja. Al registrar la trayectoria completa de una ejecución, los equipos pueden ver dónde se equivocó un agente, por qué falló una herramienta, dónde se disparó el coste, y llevar esos hallazgos a las evaluaciones y a los cambios de harness."
          ],
          "architecture": [
            "La instrumentación captura spans por cada paso —llamada al modelo, a herramienta, recuperación— con entradas, salidas, tokens, latencia y errores, enlazados en una traza de toda la ejecución. Las métricas agregan calidad, coste, latencia y tasas de fallo en el tiempo.",
            "Las convenciones semánticas GenAI de OpenTelemetry estandarizan cómo se estructuran estas trazas, para que fluyan a backends de observabilidad generales en vez de silos propietarios. Las trazas también son la materia prima de los datasets de evaluación."
          ],
          "components": [
            "Trazado (spans por paso)",
            "Métricas (calidad, coste, latencia)",
            "Registros (logs)",
            "Contabilidad de tokens y coste",
            "Seguimiento de errores",
            "Pipeline traza-a-evaluación"
          ],
          "pros": [
            "Convierte ejecuciones opacas en trazas diagnosticables.",
            "Saca a la luz puntos calientes de coste, latencia y fallo.",
            "Alimenta la evaluación y la mejora continua.",
            "Apoya la respuesta a incidentes y las auditorías de gobernanza."
          ],
          "risks": [
            "Las trazas pueden capturar datos sensibles que requieren redacción.",
            "Sobrecarga de instrumentación y coste de almacenamiento a escala.",
            "Volumen sin buenas consultas oculta la señal.",
            "Obligaciones de privacidad y retención sobre los prompts registrados."
          ],
          "tools": [
            "OpenTelemetry (convenciones GenAI)",
            "LangSmith",
            "Langfuse",
            "Arize / Phoenix",
            "Backends APM estándar"
          ],
          "examples": [
            "Trazar una ejecución fallida hasta la llamada a herramienta exacta que dio error.",
            "Seguir el coste de tokens por tarea para encontrar un prompt caro.",
            "Convertir trazas de producción en un dataset de evaluación.",
            "En la práctica: un despliegue autónomo mono-operador de 57 días (OpenClaw) trazó 161 sesiones / 2.776 turnos desde trazas locales — 98,8% de éxito por sesión, p50 8,1s y p95 87,6s por turno, ~70% de tokens servidos desde caché y $15,21 mezclado por 1M de tokens (coste parcialmente tarifado, por tanto un suelo). Todas las cifras derivan de las propias trazas del agente."
          ],
          "faqs": [
            {
              "q": "¿Por qué los agentes necesitan más observabilidad que los chatbots?",
              "a": "Los agentes son de varios pasos y no deterministas, así que una sola respuesta esconde muchas decisiones internas. Sin trazas de esos pasos, los fallos no se pueden diagnosticar."
            },
            {
              "q": "¿Cómo se relaciona la observabilidad con la evaluación?",
              "a": "La observabilidad captura lo que pasó; la evaluación juzga si fue bueno. Las trazas se convierten en los datos sobre los que corren las evaluaciones, cerrando el bucle de mejora."
            },
            {
              "q": "¿Hay un estándar para las trazas de IA?",
              "a": "Las convenciones semánticas de IA generativa de OpenTelemetry están emergiendo como estándar portable, permitiendo que las trazas de IA fluyan al tooling de observabilidad general."
            },
            {
              "q": "¿Qué hay que medir?",
              "a": "Calidad (éxito de la tarea), coste (tokens), latencia y seguridad juntos: un agente rápido y barato que falla la tarea no es un buen agente."
            }
          ]
        },
        "pt": {
          "title": "O que é Observabilidade de Agentes de IA?",
          "summary": "A observabilidade de IA é a prática de instrumentar sistemas de IA — sobretudo agentes — para poder ver o que fizeram e por quê. Captura rastros de cada passo: prompts, chamadas de ferramentas, contexto recuperado, saídas do modelo, tokens, latência e custo. Como os agentes são não determinísticos e de vários passos, a observabilidade é o que torna as falhas diagnosticáveis e a melhoria sistemática. É a camada que alimenta a avaliação e fecha o laço da engenharia de harness.",
          "definition": "A observabilidade de IA é a prática de capturar rastros, métricas e logs do comportamento de um sistema de IA — cada prompt, chamada de ferramenta, recuperação, saída, token, latência e custo — para poder entender, depurar e melhorar suas decisões.",
          "takeaways": [
            "A observabilidade torna depuráveis os agentes não determinísticos.",
            "Os rastros registram cada passo: prompts, ferramentas, contexto, saídas, custo.",
            "Alimenta a avaliação: você melhora o que pode ver e medir.",
            "Acompanhe juntos qualidade, latência, custo e segurança.",
            "Padrões emergentes (OpenTelemetry GenAI) tornam os rastros portáveis."
          ],
          "context": [
            "O software tradicional é determinístico e fácil de logar. Os agentes não: a mesma entrada pode tomar caminhos distintos, chamar ferramentas distintas e produzir saídas distintas. Sem rastreamento, uma falha é uma caixa-preta.",
            "A observabilidade abre essa caixa. Ao registrar a trajetória completa de uma execução, as equipes podem ver onde um agente errou, por que uma ferramenta falhou, onde o custo disparou, e levar esses achados às avaliações e às mudanças de harness."
          ],
          "architecture": [
            "A instrumentação captura spans para cada passo — chamada ao modelo, à ferramenta, recuperação — com entradas, saídas, tokens, latência e erros, ligados num rastro de toda a execução. As métricas agregam qualidade, custo, latência e taxas de falha ao longo do tempo.",
            "As convenções semânticas GenAI do OpenTelemetry padronizam como esses rastros são estruturados, para que fluam a backends de observabilidade gerais em vez de silos proprietários. Os rastros também são a matéria-prima dos datasets de avaliação."
          ],
          "components": [
            "Rastreamento (spans por passo)",
            "Métricas (qualidade, custo, latência)",
            "Logs",
            "Contabilidade de tokens e custo",
            "Acompanhamento de erros",
            "Pipeline rastro-para-avaliação"
          ],
          "pros": [
            "Transforma execuções opacas em rastros diagnosticáveis.",
            "Revela pontos críticos de custo, latência e falha.",
            "Alimenta a avaliação e a melhoria contínua.",
            "Apoia a resposta a incidentes e as auditorias de governança."
          ],
          "risks": [
            "Os rastros podem capturar dados sensíveis que exigem redação.",
            "Sobrecarga de instrumentação e custo de armazenamento em escala.",
            "Volume sem boas consultas esconde o sinal.",
            "Obrigações de privacidade e retenção sobre os prompts registrados."
          ],
          "tools": [
            "OpenTelemetry (convenções GenAI)",
            "LangSmith",
            "Langfuse",
            "Arize / Phoenix",
            "Backends APM padrão"
          ],
          "examples": [
            "Rastrear uma execução falha até a chamada de ferramenta exata que deu erro.",
            "Acompanhar o custo de tokens por tarefa para encontrar um prompt caro.",
            "Transformar rastros de produção num dataset de avaliação.",
            "Na prática: uma implantação autônoma de operador único de 57 dias (OpenClaw) rastreou 161 sessões / 2.776 turnos a partir de rastros locais — 98,8% de sucesso por sessão, p50 8,1s e p95 87,6s por turno, ~70% dos tokens servidos do cache e $15,21 combinado por 1M de tokens (custo parcialmente precificado, portanto um piso). Todos os números derivam dos próprios rastros do agente."
          ],
          "faqs": [
            {
              "q": "Por que os agentes precisam de mais observabilidade que os chatbots?",
              "a": "Os agentes são de vários passos e não determinísticos, então uma única resposta esconde muitas decisões internas. Sem rastros desses passos, as falhas não podem ser diagnosticadas."
            },
            {
              "q": "Como a observabilidade se relaciona com a avaliação?",
              "a": "A observabilidade captura o que aconteceu; a avaliação julga se foi bom. Os rastros se tornam os dados sobre os quais as avaliações rodam, fechando o laço de melhoria."
            },
            {
              "q": "Há um padrão para os rastros de IA?",
              "a": "As convenções semânticas de IA generativa do OpenTelemetry estão emergindo como padrão portável, permitindo que os rastros de IA fluam para o tooling de observabilidade geral."
            },
            {
              "q": "O que medir?",
              "a": "Qualidade (sucesso da tarefa), custo (tokens), latência e segurança juntos: um agente rápido e barato que falha a tarefa não é um bom agente."
            }
          ]
        }
      }
    },
    {
      "slug": "context-engineering",
      "category": "harness",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/context-engineering",
      "api": "https://santismm.com/api/knowledge/context-engineering",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Anthropic — Effective context engineering for AI agents (2025)",
          "url": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents"
        },
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        }
      ],
      "related": [
        "harness-engineering",
        "prompt-engineering",
        "agent-memory",
        "enterprise-rag"
      ],
      "locales": {
        "en": {
          "title": "What is Context Engineering?",
          "summary": "Context engineering is the discipline of deciding what information enters a model's limited context window at each step — and what stays out. As agents run over many steps, naively stuffing everything into context degrades quality and cost. Context engineering curates the right instructions, retrieved knowledge, tool results and memory so the model has exactly what it needs, when it needs it. It is a core part of harness engineering.",
          "definition": "Context engineering is the practice of curating, compressing and sequencing the information placed in a model's context window so it has the most relevant signal — and the least noise — at each step.",
          "takeaways": [
            "Context is a scarce resource; what you leave out matters as much as what you include.",
            "More context is not better — irrelevant tokens degrade quality and raise cost.",
            "Techniques: retrieval, summarization, compaction, and structured memory.",
            "It generalizes prompt engineering from one prompt to a whole agent run.",
            "It is a core layer of the harness around a model."
          ],
          "context": [
            "Every model has a finite context window, and quality degrades when it is filled with low-signal content. In single-turn use this is manageable, but agents accumulate history, tool outputs and retrieved documents across many steps, quickly overwhelming the window.",
            "Context engineering treats the window as a budget to be managed deliberately: keep the durable instructions, retrieve only what is relevant now, summarize or compact the rest, and store long-term state outside the window in memory."
          ],
          "architecture": [
            "Core moves: select (retrieve only relevant passages), compress (summarize prior steps), compact (drop or fold stale turns), and externalize (push long-term state to a memory store, pulling it back on demand).",
            "In an agent loop, context is reassembled each step from layered sources: stable system instructions, task state, relevant retrieved knowledge, recent tool results and selected long-term memories — ordered so the most important signal is most salient."
          ],
          "components": [
            "System instructions",
            "Task state",
            "Retrieved knowledge",
            "Tool results",
            "Long-term memory",
            "Summaries / compaction"
          ],
          "pros": [
            "Keeps quality high as tasks grow long.",
            "Controls token cost and latency.",
            "Reduces distraction and hallucination from noise.",
            "Enables long-horizon agents within finite context."
          ],
          "risks": [
            "Over-aggressive compression can drop needed information.",
            "Poor retrieval injects irrelevant or wrong context.",
            "Complexity in deciding what to keep each step.",
            "Bugs here surface as subtle quality regressions."
          ],
          "tools": [
            "Retrieval / RAG pipelines",
            "Summarization models",
            "Memory stores",
            "Context-management frameworks (e.g. LangGraph)"
          ],
          "examples": [
            "Summarizing earlier agent steps so the window stays focused on the current subtask.",
            "Retrieving only the policy section relevant to a question instead of the whole manual.",
            "Storing a user's preferences in memory and recalling them only when relevant."
          ],
          "faqs": [
            {
              "q": "How is context engineering different from prompt engineering?",
              "a": "Prompt engineering crafts a single instruction. Context engineering manages the full set of information in the window across an entire agent run — retrieval, memory, tool results and compression included."
            },
            {
              "q": "Why not just use a bigger context window?",
              "a": "Larger windows help but do not eliminate the problem: quality and cost degrade as windows fill with low-signal tokens. Curation still wins."
            },
            {
              "q": "How does it relate to RAG and memory?",
              "a": "RAG and memory are sources of context; context engineering decides what from them actually enters the window, when, and in what form."
            },
            {
              "q": "Is it part of harness engineering?",
              "a": "Yes. Context management is one of the core layers of the harness that turns model capability into reliable agent behavior."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Ingeniería de Contexto (Context Engineering)?",
          "summary": "La ingeniería de contexto es la disciplina de decidir qué información entra en la ventana de contexto limitada de un modelo en cada paso, y qué se queda fuera. Como los agentes se ejecutan en muchos pasos, meter todo ingenuamente en el contexto degrada calidad y coste. La ingeniería de contexto cura las instrucciones, el conocimiento recuperado, los resultados de herramientas y la memoria adecuados para que el modelo tenga justo lo que necesita cuando lo necesita. Es una parte central de la ingeniería de harness.",
          "definition": "La ingeniería de contexto es la práctica de curar, comprimir y secuenciar la información que se coloca en la ventana de contexto de un modelo para que tenga la señal más relevante —y el menor ruido— en cada paso.",
          "takeaways": [
            "El contexto es un recurso escaso; lo que dejas fuera importa tanto como lo que incluyes.",
            "Más contexto no es mejor: los tokens irrelevantes degradan calidad y suben el coste.",
            "Técnicas: recuperación, resumen, compactación y memoria estructurada.",
            "Generaliza la ingeniería de prompts de un prompt a toda una ejecución de agente.",
            "Es una capa central del harness alrededor del modelo."
          ],
          "context": [
            "Todo modelo tiene una ventana de contexto finita, y la calidad se degrada cuando se llena de contenido de baja señal. En uso de un solo turno es manejable, pero los agentes acumulan historial, salidas de herramientas y documentos recuperados a lo largo de muchos pasos, saturando rápido la ventana.",
            "La ingeniería de contexto trata la ventana como un presupuesto a gestionar de forma deliberada: conservar las instrucciones duraderas, recuperar solo lo relevante ahora, resumir o compactar el resto y guardar el estado a largo plazo fuera de la ventana en memoria."
          ],
          "architecture": [
            "Movimientos clave: seleccionar (recuperar solo pasajes relevantes), comprimir (resumir pasos previos), compactar (descartar o plegar turnos obsoletos) y externalizar (llevar el estado a largo plazo a un almacén de memoria y traerlo bajo demanda).",
            "En un bucle de agente, el contexto se reensambla en cada paso desde fuentes en capas: instrucciones de sistema estables, estado de la tarea, conocimiento recuperado relevante, resultados recientes de herramientas y memorias a largo plazo seleccionadas, ordenadas para que la señal más importante sea la más saliente."
          ],
          "components": [
            "Instrucciones de sistema",
            "Estado de la tarea",
            "Conocimiento recuperado",
            "Resultados de herramientas",
            "Memoria a largo plazo",
            "Resúmenes / compactación"
          ],
          "pros": [
            "Mantiene alta la calidad cuando las tareas se alargan.",
            "Controla el coste de tokens y la latencia.",
            "Reduce la distracción y la alucinación por ruido.",
            "Habilita agentes de horizonte largo dentro de un contexto finito."
          ],
          "risks": [
            "Una compresión demasiado agresiva puede descartar información necesaria.",
            "Una recuperación pobre inyecta contexto irrelevante o erróneo.",
            "Complejidad al decidir qué conservar en cada paso.",
            "Los errores aquí aparecen como regresiones sutiles de calidad."
          ],
          "tools": [
            "Pipelines de recuperación / RAG",
            "Modelos de resumen",
            "Almacenes de memoria",
            "Frameworks de gestión de contexto (p. ej. LangGraph)"
          ],
          "examples": [
            "Resumir pasos anteriores del agente para que la ventana siga enfocada en la subtarea actual.",
            "Recuperar solo la sección de la política relevante a una pregunta en vez de todo el manual.",
            "Guardar las preferencias de un usuario en memoria y recordarlas solo cuando son relevantes."
          ],
          "faqs": [
            {
              "q": "¿En qué se diferencia de la ingeniería de prompts?",
              "a": "La ingeniería de prompts crea una sola instrucción. La ingeniería de contexto gestiona todo el conjunto de información en la ventana a lo largo de una ejecución de agente, incluyendo recuperación, memoria, resultados de herramientas y compresión."
            },
            {
              "q": "¿Por qué no usar simplemente una ventana de contexto más grande?",
              "a": "Las ventanas más grandes ayudan pero no eliminan el problema: la calidad y el coste se degradan al llenarse de tokens de baja señal. La curación sigue ganando."
            },
            {
              "q": "¿Cómo se relaciona con RAG y la memoria?",
              "a": "RAG y la memoria son fuentes de contexto; la ingeniería de contexto decide qué de ellas entra realmente en la ventana, cuándo y en qué forma."
            },
            {
              "q": "¿Es parte de la ingeniería de harness?",
              "a": "Sí. La gestión de contexto es una de las capas centrales del harness que convierte la capacidad del modelo en comportamiento fiable del agente."
            }
          ]
        },
        "pt": {
          "title": "O que é Engenharia de Contexto (Context Engineering)?",
          "summary": "A engenharia de contexto é a disciplina de decidir qual informação entra na janela de contexto limitada de um modelo a cada passo, e o que fica de fora. Como os agentes rodam em muitos passos, enfiar tudo ingenuamente no contexto degrada qualidade e custo. A engenharia de contexto cura as instruções, o conhecimento recuperado, os resultados de ferramentas e a memória adequados para que o modelo tenha exatamente o que precisa quando precisa. É uma parte central da engenharia de harness.",
          "definition": "A engenharia de contexto é a prática de curar, comprimir e sequenciar a informação colocada na janela de contexto de um modelo para que ele tenha o sinal mais relevante — e o menor ruído — a cada passo.",
          "takeaways": [
            "O contexto é um recurso escasso; o que você deixa de fora importa tanto quanto o que inclui.",
            "Mais contexto não é melhor: tokens irrelevantes degradam a qualidade e elevam o custo.",
            "Técnicas: recuperação, resumo, compactação e memória estruturada.",
            "Generaliza a engenharia de prompts de um prompt para toda uma execução de agente.",
            "É uma camada central do harness em torno do modelo."
          ],
          "context": [
            "Todo modelo tem uma janela de contexto finita, e a qualidade se degrada quando ela é preenchida com conteúdo de baixo sinal. No uso de um único turno é gerenciável, mas os agentes acumulam histórico, saídas de ferramentas e documentos recuperados ao longo de muitos passos, saturando rápido a janela.",
            "A engenharia de contexto trata a janela como um orçamento a gerir de forma deliberada: manter as instruções duráveis, recuperar só o relevante agora, resumir ou compactar o resto e guardar o estado de longo prazo fora da janela na memória."
          ],
          "architecture": [
            "Movimentos centrais: selecionar (recuperar só trechos relevantes), comprimir (resumir passos anteriores), compactar (descartar ou dobrar turnos obsoletos) e externalizar (levar o estado de longo prazo a um armazenamento de memória e trazê-lo sob demanda).",
            "Num laço de agente, o contexto é remontado a cada passo a partir de fontes em camadas: instruções de sistema estáveis, estado da tarefa, conhecimento recuperado relevante, resultados recentes de ferramentas e memórias de longo prazo selecionadas, ordenados para que o sinal mais importante seja o mais saliente."
          ],
          "components": [
            "Instruções de sistema",
            "Estado da tarefa",
            "Conhecimento recuperado",
            "Resultados de ferramentas",
            "Memória de longo prazo",
            "Resumos / compactação"
          ],
          "pros": [
            "Mantém a qualidade alta quando as tarefas se alongam.",
            "Controla o custo de tokens e a latência.",
            "Reduz a distração e a alucinação por ruído.",
            "Habilita agentes de horizonte longo dentro de um contexto finito."
          ],
          "risks": [
            "Uma compressão agressiva demais pode descartar informação necessária.",
            "Uma recuperação ruim injeta contexto irrelevante ou errado.",
            "Complexidade ao decidir o que manter a cada passo.",
            "Bugs aqui aparecem como regressões sutis de qualidade."
          ],
          "tools": [
            "Pipelines de recuperação / RAG",
            "Modelos de resumo",
            "Armazenamentos de memória",
            "Frameworks de gestão de contexto (ex.: LangGraph)"
          ],
          "examples": [
            "Resumir passos anteriores do agente para a janela seguir focada na subtarefa atual.",
            "Recuperar só a seção da política relevante a uma pergunta em vez de todo o manual.",
            "Guardar as preferências de um usuário na memória e lembrá-las só quando relevantes."
          ],
          "faqs": [
            {
              "q": "Qual a diferença para a engenharia de prompts?",
              "a": "A engenharia de prompts cria uma única instrução. A engenharia de contexto gere todo o conjunto de informação na janela ao longo de uma execução de agente, incluindo recuperação, memória, resultados de ferramentas e compressão."
            },
            {
              "q": "Por que não usar simplesmente uma janela de contexto maior?",
              "a": "Janelas maiores ajudam mas não eliminam o problema: qualidade e custo se degradam ao se encherem de tokens de baixo sinal. A curadoria ainda vence."
            },
            {
              "q": "Como se relaciona com RAG e memória?",
              "a": "RAG e memória são fontes de contexto; a engenharia de contexto decide o que delas realmente entra na janela, quando e em que forma."
            },
            {
              "q": "É parte da engenharia de harness?",
              "a": "Sim. A gestão de contexto é uma das camadas centrais do harness que converte a capacidade do modelo em comportamento confiável do agente."
            }
          ]
        }
      }
    },
    {
      "slug": "embeddings",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/embeddings",
      "api": "https://santismm.com/api/knowledge/embeddings",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Reimers & Gurevych — Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks (2019)",
          "url": "https://arxiv.org/abs/1908.10084"
        },
        {
          "title": "Mikolov et al. — Efficient Estimation of Word Representations (word2vec, 2013)",
          "url": "https://arxiv.org/abs/1301.3781"
        }
      ],
      "related": [
        "enterprise-rag",
        "foundation-models",
        "fine-tuning",
        "agentic-ai"
      ],
      "locales": {
        "en": {
          "title": "What are Embeddings & Vector Search?",
          "summary": "An embedding is a numeric vector that represents the meaning of text (or images, audio, code) so that semantically similar items sit close together in vector space. Vector search finds the nearest embeddings to a query, enabling search by meaning rather than keywords. Embeddings are the backbone of retrieval-augmented generation, semantic search, clustering and recommendation.",
          "definition": "An embedding is a dense numeric vector that encodes the meaning of a piece of data, positioned so that similar items are close in vector space; vector search retrieves the nearest embeddings to a query.",
          "takeaways": [
            "Embeddings turn meaning into vectors; similar things sit close together.",
            "Vector search retrieves by semantic similarity, not exact keywords.",
            "They power RAG, semantic search, clustering and recommendation.",
            "Hybrid search (vector + keyword) usually beats either alone.",
            "Chunking and the embedding model choice drive retrieval quality."
          ],
          "context": [
            "Computers compare numbers, not meaning. Embeddings bridge that gap: an embedding model maps text to a vector such that 'cancel my subscription' and 'how do I unsubscribe' land near each other, even with no shared words.",
            "This is what makes semantic retrieval possible. Instead of matching keywords, a system embeds the query and finds the closest stored vectors — the foundation of how RAG and modern search retrieve relevant content."
          ],
          "architecture": [
            "Indexing: content is split into chunks, each passed through an embedding model to produce a vector, then stored in a vector index. Querying: the query is embedded and the index returns the nearest vectors by a similarity metric (e.g. cosine).",
            "Production systems add a re-ranker to refine the top results, combine vector search with keyword search (hybrid), and filter by metadata and permissions. Quality depends heavily on chunking and the embedding model."
          ],
          "components": [
            "Embedding model",
            "Chunking",
            "Vector index / database",
            "Similarity metric (cosine)",
            "Re-ranker",
            "Hybrid (keyword) search"
          ],
          "pros": [
            "Search by meaning, robust to wording.",
            "Cross-lingual and multimodal matching.",
            "The backbone of RAG and semantic search.",
            "Cheap to query at scale once indexed."
          ],
          "risks": [
            "Poor chunking degrades every downstream result.",
            "Embedding model mismatch hurts relevance.",
            "Vectors can leak sensitive info; secure the store.",
            "Pure vector search can miss exact-match needs (use hybrid)."
          ],
          "tools": [
            "Embedding models (OpenAI, Cohere, open-source)",
            "Vector databases (pgvector, Pinecone, Vertex AI Vector Search)",
            "Re-rankers",
            "Hybrid search engines"
          ],
          "examples": [
            "Semantic search over a help center that matches intent, not keywords.",
            "Retrieving relevant passages to ground a RAG answer.",
            "Clustering support tickets by topic using their embeddings."
          ],
          "faqs": [
            {
              "q": "How are embeddings different from keywords?",
              "a": "Keyword search matches exact words; embeddings match meaning, so paraphrases and synonyms still retrieve the right content."
            },
            {
              "q": "What is vector search?",
              "a": "Finding the stored embeddings nearest to a query embedding by a similarity metric like cosine distance — search by semantic closeness."
            },
            {
              "q": "Why combine vector and keyword search?",
              "a": "Vectors excel at meaning but can miss exact terms (codes, names). Hybrid search blends both for the best recall and precision."
            },
            {
              "q": "Do embeddings power RAG?",
              "a": "Yes. RAG embeds documents and queries, retrieves the nearest chunks by vector search, and grounds the model's answer in them."
            }
          ]
        },
        "es": {
          "title": "¿Qué son los Embeddings y la Búsqueda Vectorial?",
          "summary": "Un embedding es un vector numérico que representa el significado de un texto (o imágenes, audio, código) de modo que los elementos semánticamente similares quedan cerca en el espacio vectorial. La búsqueda vectorial encuentra los embeddings más cercanos a una consulta, permitiendo buscar por significado en vez de por palabras clave. Los embeddings son la columna vertebral de la generación aumentada por recuperación, la búsqueda semántica, el clustering y la recomendación.",
          "definition": "Un embedding es un vector numérico denso que codifica el significado de un dato, situado de forma que los elementos similares quedan cerca en el espacio vectorial; la búsqueda vectorial recupera los embeddings más cercanos a una consulta.",
          "takeaways": [
            "Los embeddings convierten el significado en vectores; lo similar queda cerca.",
            "La búsqueda vectorial recupera por similitud semántica, no por palabras exactas.",
            "Sustentan el RAG, la búsqueda semántica, el clustering y la recomendación.",
            "La búsqueda híbrida (vector + palabras clave) suele superar a cada una sola.",
            "El chunking y la elección del modelo de embeddings determinan la calidad."
          ],
          "context": [
            "Los ordenadores comparan números, no significado. Los embeddings salvan esa brecha: un modelo de embeddings mapea texto a un vector de modo que 'cancela mi suscripción' y 'cómo me doy de baja' caen cerca, aun sin palabras compartidas.",
            "Esto es lo que hace posible la recuperación semántica. En vez de casar palabras clave, el sistema embebe la consulta y encuentra los vectores almacenados más cercanos: la base de cómo el RAG y la búsqueda moderna recuperan contenido relevante."
          ],
          "architecture": [
            "Indexación: el contenido se divide en chunks, cada uno pasa por un modelo de embeddings para producir un vector y se guarda en un índice vectorial. Consulta: la consulta se embebe y el índice devuelve los vectores más cercanos por una métrica de similitud (p. ej. coseno).",
            "Los sistemas en producción añaden un re-ranker para refinar los mejores resultados, combinan búsqueda vectorial con búsqueda por palabras clave (híbrida) y filtran por metadatos y permisos. La calidad depende mucho del chunking y del modelo de embeddings."
          ],
          "components": [
            "Modelo de embeddings",
            "Chunking",
            "Índice / base de datos vectorial",
            "Métrica de similitud (coseno)",
            "Re-ranker",
            "Búsqueda híbrida (palabras clave)"
          ],
          "pros": [
            "Búsqueda por significado, robusta a la redacción.",
            "Coincidencia translingüe y multimodal.",
            "La columna vertebral del RAG y la búsqueda semántica.",
            "Barata de consultar a escala una vez indexada."
          ],
          "risks": [
            "Un chunking pobre degrada todo resultado posterior.",
            "Un modelo de embeddings inadecuado daña la relevancia.",
            "Los vectores pueden filtrar info sensible; asegura el almacén.",
            "La búsqueda vectorial pura puede fallar en coincidencias exactas (usa híbrida)."
          ],
          "tools": [
            "Modelos de embeddings (OpenAI, Cohere, open source)",
            "Bases de datos vectoriales (pgvector, Pinecone, Vertex AI Vector Search)",
            "Re-rankers",
            "Motores de búsqueda híbrida"
          ],
          "examples": [
            "Búsqueda semántica en un centro de ayuda que casa la intención, no las palabras.",
            "Recuperar pasajes relevantes para fundamentar una respuesta RAG.",
            "Agrupar tickets de soporte por tema usando sus embeddings."
          ],
          "faqs": [
            {
              "q": "¿En qué se diferencian los embeddings de las palabras clave?",
              "a": "La búsqueda por palabras clave casa palabras exactas; los embeddings casan significado, así que paráfrasis y sinónimos siguen recuperando el contenido correcto."
            },
            {
              "q": "¿Qué es la búsqueda vectorial?",
              "a": "Encontrar los embeddings almacenados más cercanos al embedding de una consulta por una métrica como la distancia coseno: búsqueda por cercanía semántica."
            },
            {
              "q": "¿Por qué combinar búsqueda vectorial y por palabras clave?",
              "a": "Los vectores destacan en significado pero pueden fallar en términos exactos (códigos, nombres). La búsqueda híbrida combina ambas para mejor recall y precisión."
            },
            {
              "q": "¿Los embeddings sustentan el RAG?",
              "a": "Sí. El RAG embebe documentos y consultas, recupera los chunks más cercanos por búsqueda vectorial y fundamenta en ellos la respuesta del modelo."
            }
          ]
        },
        "pt": {
          "title": "O que são Embeddings e Busca Vetorial?",
          "summary": "Um embedding é um vetor numérico que representa o significado de um texto (ou imagens, áudio, código) de modo que itens semanticamente similares ficam próximos no espaço vetorial. A busca vetorial encontra os embeddings mais próximos de uma consulta, permitindo buscar por significado em vez de palavras-chave. Os embeddings são a espinha dorsal da geração aumentada por recuperação, da busca semântica, do clustering e da recomendação.",
          "definition": "Um embedding é um vetor numérico denso que codifica o significado de um dado, posicionado de forma que itens similares ficam próximos no espaço vetorial; a busca vetorial recupera os embeddings mais próximos de uma consulta.",
          "takeaways": [
            "Embeddings transformam significado em vetores; o similar fica próximo.",
            "A busca vetorial recupera por similaridade semântica, não por palavras exatas.",
            "Sustentam o RAG, a busca semântica, o clustering e a recomendação.",
            "A busca híbrida (vetor + palavras-chave) costuma superar cada uma sozinha.",
            "O chunking e a escolha do modelo de embeddings determinam a qualidade."
          ],
          "context": [
            "Os computadores comparam números, não significado. Os embeddings preenchem essa lacuna: um modelo de embeddings mapeia texto a um vetor de modo que 'cancele minha assinatura' e 'como eu me descadastro' caem próximos, mesmo sem palavras em comum.",
            "Isso é o que torna possível a recuperação semântica. Em vez de casar palavras-chave, o sistema embeda a consulta e encontra os vetores armazenados mais próximos: a base de como o RAG e a busca moderna recuperam conteúdo relevante."
          ],
          "architecture": [
            "Indexação: o conteúdo é dividido em chunks, cada um passa por um modelo de embeddings para produzir um vetor e é guardado num índice vetorial. Consulta: a consulta é embedada e o índice devolve os vetores mais próximos por uma métrica de similaridade (ex.: cosseno).",
            "Os sistemas em produção adicionam um re-ranker para refinar os melhores resultados, combinam busca vetorial com busca por palavras-chave (híbrida) e filtram por metadados e permissões. A qualidade depende muito do chunking e do modelo de embeddings."
          ],
          "components": [
            "Modelo de embeddings",
            "Chunking",
            "Índice / banco de dados vetorial",
            "Métrica de similaridade (cosseno)",
            "Re-ranker",
            "Busca híbrida (palavras-chave)"
          ],
          "pros": [
            "Busca por significado, robusta à redação.",
            "Correspondência translíngue e multimodal.",
            "A espinha dorsal do RAG e da busca semântica.",
            "Barata de consultar em escala uma vez indexada."
          ],
          "risks": [
            "Um chunking ruim degrada todo resultado posterior.",
            "Um modelo de embeddings inadequado prejudica a relevância.",
            "Os vetores podem vazar info sensível; proteja o armazenamento.",
            "A busca vetorial pura pode falhar em correspondências exatas (use híbrida)."
          ],
          "tools": [
            "Modelos de embeddings (OpenAI, Cohere, open source)",
            "Bancos de dados vetoriais (pgvector, Pinecone, Vertex AI Vector Search)",
            "Re-rankers",
            "Motores de busca híbrida"
          ],
          "examples": [
            "Busca semântica numa central de ajuda que casa a intenção, não as palavras.",
            "Recuperar trechos relevantes para fundamentar uma resposta RAG.",
            "Agrupar chamados de suporte por tema usando seus embeddings."
          ],
          "faqs": [
            {
              "q": "Como os embeddings diferem das palavras-chave?",
              "a": "A busca por palavras-chave casa palavras exatas; os embeddings casam significado, então paráfrases e sinônimos ainda recuperam o conteúdo correto."
            },
            {
              "q": "O que é busca vetorial?",
              "a": "Encontrar os embeddings armazenados mais próximos do embedding de uma consulta por uma métrica como a distância cosseno: busca por proximidade semântica."
            },
            {
              "q": "Por que combinar busca vetorial e por palavras-chave?",
              "a": "Os vetores se destacam em significado mas podem falhar em termos exatos (códigos, nomes). A busca híbrida combina ambas para melhor recall e precisão."
            },
            {
              "q": "Os embeddings sustentam o RAG?",
              "a": "Sim. O RAG embeda documentos e consultas, recupera os chunks mais próximos por busca vetorial e fundamenta neles a resposta do modelo."
            }
          ]
        }
      }
    },
    {
      "slug": "enterprise-rag",
      "category": "pattern",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/enterprise-rag",
      "api": "https://santismm.com/api/knowledge/enterprise-rag",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper",
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020)",
          "url": "https://arxiv.org/abs/2005.11401"
        },
        {
          "title": "Model Context Protocol — Resources",
          "url": "https://modelcontextprotocol.io"
        }
      ],
      "related": [
        "agentic-ai",
        "model-context-protocol",
        "ai-governance",
        "ai-agent"
      ],
      "locales": {
        "en": {
          "title": "What is Enterprise RAG?",
          "summary": "Enterprise RAG (retrieval-augmented generation) is the pattern of grounding a model's answers in an organization's own documents, retrieved at query time, instead of relying on the model's parametric memory. It lets a company use private, current and governed knowledge — policies, manuals, tickets, contracts — without retraining a model, while keeping access control, citations and auditability that enterprises require.",
          "definition": "Enterprise RAG is a pattern that retrieves relevant passages from an organization's governed knowledge sources and supplies them to a model as context, so answers are grounded, current and citable.",
          "takeaways": [
            "RAG grounds answers in retrieved documents, reducing hallucination.",
            "It uses private and fresh knowledge without retraining.",
            "Retrieval quality (chunking + embeddings) drives answer quality.",
            "Enterprise-grade RAG adds access control, citations and audit.",
            "Becomes agentic when the system decides when and what to retrieve."
          ],
          "context": [
            "A base model only knows what it learned during training. Enterprise knowledge is private, changing and access-controlled. RAG bridges that gap by fetching the right passages at query time and grounding the answer in them.",
            "The enterprise difference is governance: who is allowed to see which documents, where the answer's sources came from, and whether the whole interaction can be audited. RAG that ignores these is a prototype, not a production system."
          ],
          "architecture": [
            "Ingestion: documents are parsed, split into self-contained chunks, embedded and stored in a vector index (often alongside keyword search). Retrieval: a query is embedded, the nearest chunks are fetched, optionally re-ranked and filtered by permissions. Generation: the model answers using those chunks and cites them.",
            "Quality hinges on the unglamorous parts: clean parsing, sensible chunking, hybrid (vector + keyword) retrieval, re-ranking, and permission filtering. Well-structured source content makes every one of these steps easier."
          ],
          "components": [
            "Ingestion & chunking",
            "Embeddings",
            "Vector / hybrid index",
            "Retriever & re-ranker",
            "Permission filter",
            "Generator (LLM)",
            "Citation layer"
          ],
          "pros": [
            "Grounded, citable, up-to-date answers.",
            "Uses private knowledge without retraining.",
            "Respects access control and auditability.",
            "Cheaper and faster to update than fine-tuning."
          ],
          "risks": [
            "Poor chunking or retrieval yields wrong or irrelevant context.",
            "Stale or unpermissioned data leaks into answers.",
            "Citations can be plausible but unsupported if not verified.",
            "Retrieval latency and cost at scale."
          ],
          "tools": [
            "Vector databases (e.g. pgvector, Pinecone, Vertex AI Vector Search)",
            "Embedding models",
            "Re-rankers",
            "Hybrid search engines",
            "MCP resource servers"
          ],
          "examples": [
            "An internal assistant answering HR policy questions with cited passages.",
            "A support agent retrieving product docs to resolve tickets.",
            "A legal assistant surfacing relevant clauses with source links."
          ],
          "faqs": [
            {
              "q": "Is RAG better than fine-tuning?",
              "a": "They solve different problems. RAG injects fresh, governed knowledge at query time; fine-tuning adapts behavior or style. They are often combined."
            },
            {
              "q": "Why does chunking matter so much?",
              "a": "Retrieval works on chunks. Self-contained, well-structured chunks retrieve cleanly; fragmented ones return noise. Chunk quality largely sets RAG quality."
            },
            {
              "q": "What makes RAG enterprise-grade?",
              "a": "Access control on retrieval, source citations, auditability, freshness, and evaluation — not just a vector store plus a model."
            },
            {
              "q": "When does RAG become agentic?",
              "a": "When retrieval is one step in a multi-step loop where the system decides whether, when and what to retrieve, rather than always retrieving once."
            }
          ]
        },
        "es": {
          "title": "¿Qué es el RAG empresarial (Enterprise RAG)?",
          "summary": "El RAG empresarial (generación aumentada por recuperación) es el patrón de fundamentar las respuestas de un modelo en los propios documentos de la organización, recuperados en el momento de la consulta, en lugar de depender de la memoria paramétrica del modelo. Permite usar conocimiento privado, actual y gobernado —políticas, manuales, tickets, contratos— sin reentrenar un modelo, manteniendo el control de acceso, las citas y la auditabilidad que exigen las empresas.",
          "definition": "El RAG empresarial es un patrón que recupera pasajes relevantes de las fuentes de conocimiento gobernadas de una organización y los entrega a un modelo como contexto, para que las respuestas estén fundamentadas, actualizadas y sean citables.",
          "takeaways": [
            "El RAG fundamenta las respuestas en documentos recuperados, reduciendo la alucinación.",
            "Usa conocimiento privado y fresco sin reentrenar.",
            "La calidad de recuperación (chunking + embeddings) determina la calidad de la respuesta.",
            "El RAG de grado empresarial añade control de acceso, citas y auditoría.",
            "Se vuelve agéntico cuando el sistema decide cuándo y qué recuperar."
          ],
          "context": [
            "Un modelo base solo sabe lo que aprendió durante el entrenamiento. El conocimiento empresarial es privado, cambiante y con control de acceso. El RAG salva esa brecha recuperando los pasajes adecuados en el momento de la consulta y fundamentando la respuesta en ellos.",
            "La diferencia empresarial es la gobernanza: quién puede ver qué documentos, de dónde vienen las fuentes de la respuesta y si toda la interacción puede auditarse. Un RAG que ignora esto es un prototipo, no un sistema en producción."
          ],
          "architecture": [
            "Ingesta: los documentos se parsean, se dividen en chunks autocontenidos, se embeben y se guardan en un índice vectorial (a menudo junto a búsqueda por palabras clave). Recuperación: la consulta se embebe, se traen los chunks más cercanos, se re-rankean y se filtran por permisos. Generación: el modelo responde usando esos chunks y los cita.",
            "La calidad depende de las partes poco glamurosas: parseo limpio, chunking sensato, recuperación híbrida (vector + palabras clave), re-ranking y filtrado por permisos. Un contenido fuente bien estructurado facilita cada uno de esos pasos."
          ],
          "components": [
            "Ingesta y chunking",
            "Embeddings",
            "Índice vectorial / híbrido",
            "Recuperador y re-ranker",
            "Filtro de permisos",
            "Generador (LLM)",
            "Capa de citas"
          ],
          "pros": [
            "Respuestas fundamentadas, citables y actualizadas.",
            "Usa conocimiento privado sin reentrenar.",
            "Respeta el control de acceso y la auditabilidad.",
            "Más barato y rápido de actualizar que el fine-tuning."
          ],
          "risks": [
            "Un chunking o recuperación pobres dan contexto erróneo o irrelevante.",
            "Datos desactualizados o sin permisos se filtran en las respuestas.",
            "Las citas pueden ser plausibles pero no respaldadas si no se verifican.",
            "Latencia y coste de recuperación a escala."
          ],
          "tools": [
            "Bases de datos vectoriales (p. ej. pgvector, Pinecone, Vertex AI Vector Search)",
            "Modelos de embeddings",
            "Re-rankers",
            "Motores de búsqueda híbrida",
            "Servidores de recursos MCP"
          ],
          "examples": [
            "Un asistente interno que responde preguntas de políticas de RRHH con pasajes citados.",
            "Un agente de soporte que recupera documentación de producto para resolver tickets.",
            "Un asistente legal que muestra cláusulas relevantes con enlaces a la fuente."
          ],
          "faqs": [
            {
              "q": "¿El RAG es mejor que el fine-tuning?",
              "a": "Resuelven problemas distintos. El RAG inyecta conocimiento fresco y gobernado en el momento de la consulta; el fine-tuning adapta comportamiento o estilo. A menudo se combinan."
            },
            {
              "q": "¿Por qué importa tanto el chunking?",
              "a": "La recuperación opera sobre chunks. Los chunks autocontenidos y bien estructurados se recuperan limpiamente; los fragmentados devuelven ruido. La calidad del chunk fija en gran medida la del RAG."
            },
            {
              "q": "¿Qué hace a un RAG de grado empresarial?",
              "a": "Control de acceso en la recuperación, citas de fuentes, auditabilidad, frescura y evaluación, no solo un almacén vectorial más un modelo."
            },
            {
              "q": "¿Cuándo se vuelve agéntico el RAG?",
              "a": "Cuando la recuperación es un paso de un bucle de varios pasos en el que el sistema decide si, cuándo y qué recuperar, en vez de recuperar siempre una vez."
            }
          ]
        },
        "pt": {
          "title": "O que é RAG empresarial (Enterprise RAG)?",
          "summary": "O RAG empresarial (geração aumentada por recuperação) é o padrão de fundamentar as respostas de um modelo nos próprios documentos da organização, recuperados no momento da consulta, em vez de depender da memória paramétrica do modelo. Permite usar conhecimento privado, atual e governado — políticas, manuais, chamados, contratos — sem retreinar um modelo, mantendo o controle de acesso, as citações e a auditabilidade que as empresas exigem.",
          "definition": "O RAG empresarial é um padrão que recupera trechos relevantes das fontes de conhecimento governadas de uma organização e os fornece a um modelo como contexto, para que as respostas sejam fundamentadas, atuais e citáveis.",
          "takeaways": [
            "O RAG fundamenta as respostas em documentos recuperados, reduzindo a alucinação.",
            "Usa conhecimento privado e fresco sem retreinar.",
            "A qualidade da recuperação (chunking + embeddings) determina a qualidade da resposta.",
            "O RAG de nível empresarial adiciona controle de acesso, citações e auditoria.",
            "Torna-se agêntico quando o sistema decide quando e o que recuperar."
          ],
          "context": [
            "Um modelo base só sabe o que aprendeu durante o treinamento. O conhecimento empresarial é privado, mutável e com controle de acesso. O RAG preenche essa lacuna recuperando os trechos adequados no momento da consulta e fundamentando a resposta neles.",
            "A diferença empresarial é a governança: quem pode ver quais documentos, de onde vieram as fontes da resposta e se toda a interação pode ser auditada. Um RAG que ignora isso é um protótipo, não um sistema em produção."
          ],
          "architecture": [
            "Ingestão: os documentos são parseados, divididos em chunks autocontidos, embedados e guardados num índice vetorial (muitas vezes junto à busca por palavras-chave). Recuperação: a consulta é embedada, os chunks mais próximos são trazidos, re-ranqueados e filtrados por permissões. Geração: o modelo responde usando esses chunks e os cita.",
            "A qualidade depende das partes pouco glamourosas: parsing limpo, chunking sensato, recuperação híbrida (vetor + palavras-chave), re-ranking e filtragem por permissões. Um conteúdo-fonte bem estruturado facilita cada um desses passos."
          ],
          "components": [
            "Ingestão e chunking",
            "Embeddings",
            "Índice vetorial / híbrido",
            "Recuperador e re-ranker",
            "Filtro de permissões",
            "Gerador (LLM)",
            "Camada de citações"
          ],
          "pros": [
            "Respostas fundamentadas, citáveis e atualizadas.",
            "Usa conhecimento privado sem retreinar.",
            "Respeita o controle de acesso e a auditabilidade.",
            "Mais barato e rápido de atualizar que o fine-tuning."
          ],
          "risks": [
            "Um chunking ou recuperação ruins dão contexto errado ou irrelevante.",
            "Dados desatualizados ou sem permissões vazam nas respostas.",
            "As citações podem ser plausíveis mas não comprovadas se não forem verificadas.",
            "Latência e custo de recuperação em escala."
          ],
          "tools": [
            "Bancos de dados vetoriais (ex.: pgvector, Pinecone, Vertex AI Vector Search)",
            "Modelos de embeddings",
            "Re-rankers",
            "Motores de busca híbrida",
            "Servidores de recursos MCP"
          ],
          "examples": [
            "Um assistente interno que responde perguntas de políticas de RH com trechos citados.",
            "Um agente de suporte que recupera documentação de produto para resolver chamados.",
            "Um assistente jurídico que mostra cláusulas relevantes com links para a fonte."
          ],
          "faqs": [
            {
              "q": "O RAG é melhor que o fine-tuning?",
              "a": "Resolvem problemas distintos. O RAG injeta conhecimento fresco e governado no momento da consulta; o fine-tuning adapta comportamento ou estilo. Muitas vezes são combinados."
            },
            {
              "q": "Por que o chunking importa tanto?",
              "a": "A recuperação opera sobre chunks. Chunks autocontidos e bem estruturados são recuperados de forma limpa; os fragmentados retornam ruído. A qualidade do chunk define em grande parte a do RAG."
            },
            {
              "q": "O que torna um RAG de nível empresarial?",
              "a": "Controle de acesso na recuperação, citações de fontes, auditabilidade, frescor e avaliação, não só um armazenamento vetorial mais um modelo."
            },
            {
              "q": "Quando o RAG se torna agêntico?",
              "a": "Quando a recuperação é um passo de um laço de vários passos em que o sistema decide se, quando e o que recuperar, em vez de recuperar sempre uma vez."
            }
          ]
        }
      }
    },
    {
      "slug": "fine-tuning",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/fine-tuning",
      "api": "https://santismm.com/api/knowledge/fine-tuning",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Hu et al. — LoRA: Low-Rank Adaptation of Large Language Models (2021)",
          "url": "https://arxiv.org/abs/2106.09685"
        },
        {
          "title": "Ouyang et al. — Training language models to follow instructions with human feedback (InstructGPT, 2022)",
          "url": "https://arxiv.org/abs/2203.02155"
        }
      ],
      "related": [
        "foundation-models",
        "enterprise-rag",
        "prompt-engineering",
        "embeddings"
      ],
      "locales": {
        "en": {
          "title": "What is Fine-tuning?",
          "summary": "Fine-tuning continues training a pretrained model on a smaller, targeted dataset to specialize its behavior, style or domain knowledge. It is far cheaper than pretraining and changes the model's weights — unlike prompting or retrieval, which leave the model unchanged. Use it to lock in a consistent format, tone or skill; use retrieval instead when you need fresh or private facts.",
          "definition": "Fine-tuning is the process of further training a pretrained model on a focused dataset to adapt its weights toward a specific behavior, style, format or domain.",
          "takeaways": [
            "Fine-tuning updates model weights; prompting and RAG do not.",
            "Best for consistent behavior, style or format — not for fresh facts.",
            "Parameter-efficient methods (LoRA) make it cheap and practical.",
            "RLHF is a form of fine-tuning using human preferences.",
            "Default to prompting and retrieval first; fine-tune when they plateau."
          ],
          "context": [
            "A pretrained foundation model is a generalist. Fine-tuning narrows it: shown enough examples of the target behavior, the model internalizes it, so you no longer need to specify it in every prompt.",
            "It is one of three adaptation levers, alongside prompting and retrieval. The art is choosing the right one: fine-tune for how the model should behave, retrieve for what it should know."
          ],
          "architecture": [
            "Full fine-tuning updates all weights — powerful but expensive. Parameter-efficient fine-tuning (PEFT), notably LoRA, trains small adapter weights while freezing the base, capturing most of the benefit at a fraction of the cost.",
            "Instruction tuning and RLHF are specialized fine-tuning stages that turn a raw base model into a helpful, aligned assistant. Quality of the dataset matters far more than its size."
          ],
          "components": [
            "Pretrained base model",
            "Curated training dataset",
            "Training objective",
            "PEFT / LoRA adapters",
            "Evaluation set"
          ],
          "pros": [
            "Bakes in consistent behavior, style or format.",
            "Reduces prompt length and per-call cost.",
            "Can teach narrow skills a base model lacks.",
            "PEFT makes it affordable and fast."
          ],
          "risks": [
            "Does not add fresh or private facts — use retrieval for that.",
            "Risk of catastrophic forgetting or overfitting.",
            "Needs a quality, well-labeled dataset and an eval set.",
            "Couples you to a model version; migration costs on upgrades."
          ],
          "tools": [
            "LoRA / PEFT libraries",
            "Provider fine-tuning APIs",
            "RLHF / preference-tuning pipelines",
            "Evaluation suites"
          ],
          "examples": [
            "Fine-tuning a model to always output a strict company JSON format.",
            "Teaching a consistent brand voice for generated copy.",
            "Adapting a model to a specialized domain's terminology."
          ],
          "faqs": [
            {
              "q": "Fine-tuning or RAG?",
              "a": "Fine-tune to change how the model behaves (style, format, skill); use retrieval (RAG) to give it fresh or private knowledge. They are complementary, not competing."
            },
            {
              "q": "Is fine-tuning expensive?",
              "a": "Full fine-tuning can be, but parameter-efficient methods like LoRA train tiny adapters and make it cheap and fast for most use cases."
            },
            {
              "q": "What is RLHF?",
              "a": "Reinforcement learning from human feedback is a fine-tuning stage that uses human preference judgments to make a model more helpful, harmless and honest."
            },
            {
              "q": "When should I fine-tune?",
              "a": "After prompting and retrieval plateau. If you can solve it with a better prompt or relevant context, do that first — it is cheaper and more flexible."
            }
          ]
        },
        "es": {
          "title": "¿Qué es el Fine-tuning (Ajuste fino)?",
          "summary": "El fine-tuning continúa el entrenamiento de un modelo preentrenado con un conjunto de datos más pequeño y dirigido para especializar su comportamiento, estilo o conocimiento de dominio. Es mucho más barato que el preentrenamiento y cambia los pesos del modelo, a diferencia del prompting o la recuperación, que lo dejan intacto. Úsalo para fijar un formato, tono o habilidad consistentes; usa recuperación cuando necesites hechos frescos o privados.",
          "definition": "El fine-tuning es el proceso de seguir entrenando un modelo preentrenado con un conjunto de datos enfocado para adaptar sus pesos hacia un comportamiento, estilo, formato o dominio específico.",
          "takeaways": [
            "El fine-tuning actualiza los pesos del modelo; el prompting y el RAG no.",
            "Mejor para comportamiento, estilo o formato consistentes, no para hechos frescos.",
            "Los métodos eficientes en parámetros (LoRA) lo hacen barato y práctico.",
            "El RLHF es una forma de fine-tuning que usa preferencias humanas.",
            "Empieza por prompting y recuperación; haz fine-tuning cuando se estanquen."
          ],
          "context": [
            "Un modelo fundacional preentrenado es un generalista. El fine-tuning lo estrecha: tras ver suficientes ejemplos del comportamiento objetivo, el modelo lo interioriza, así que ya no hace falta especificarlo en cada prompt.",
            "Es una de las tres palancas de adaptación, junto al prompting y la recuperación. El arte está en elegir la adecuada: fine-tuning para cómo debe comportarse el modelo, recuperación para qué debe saber."
          ],
          "architecture": [
            "El fine-tuning completo actualiza todos los pesos: potente pero caro. El fine-tuning eficiente en parámetros (PEFT), notablemente LoRA, entrena pequeños pesos adaptadores congelando la base, capturando casi todo el beneficio a una fracción del coste.",
            "El instruction tuning y el RLHF son etapas especializadas de fine-tuning que convierten un modelo base bruto en un asistente útil y alineado. La calidad del dataset importa mucho más que su tamaño."
          ],
          "components": [
            "Modelo base preentrenado",
            "Dataset de entrenamiento curado",
            "Objetivo de entrenamiento",
            "Adaptadores PEFT / LoRA",
            "Conjunto de evaluación"
          ],
          "pros": [
            "Fija un comportamiento, estilo o formato consistentes.",
            "Reduce la longitud del prompt y el coste por llamada.",
            "Puede enseñar habilidades estrechas que la base no tiene.",
            "PEFT lo hace asequible y rápido."
          ],
          "risks": [
            "No añade hechos frescos o privados: usa recuperación para eso.",
            "Riesgo de olvido catastrófico o sobreajuste.",
            "Necesita un dataset de calidad bien etiquetado y un set de evaluación.",
            "Te acopla a una versión de modelo; coste de migración al actualizar."
          ],
          "tools": [
            "Librerías LoRA / PEFT",
            "APIs de fine-tuning de proveedores",
            "Pipelines de RLHF / ajuste por preferencias",
            "Suites de evaluación"
          ],
          "examples": [
            "Hacer fine-tuning para que un modelo emita siempre un formato JSON estricto de la empresa.",
            "Enseñar una voz de marca consistente para textos generados.",
            "Adaptar un modelo a la terminología de un dominio especializado."
          ],
          "faqs": [
            {
              "q": "¿Fine-tuning o RAG?",
              "a": "Haz fine-tuning para cambiar cómo se comporta el modelo (estilo, formato, habilidad); usa recuperación (RAG) para darle conocimiento fresco o privado. Son complementarios, no rivales."
            },
            {
              "q": "¿El fine-tuning es caro?",
              "a": "El completo puede serlo, pero métodos eficientes como LoRA entrenan adaptadores diminutos y lo hacen barato y rápido para la mayoría de casos."
            },
            {
              "q": "¿Qué es el RLHF?",
              "a": "El aprendizaje por refuerzo con feedback humano es una etapa de fine-tuning que usa juicios de preferencia humana para hacer un modelo más útil, inofensivo y honesto."
            },
            {
              "q": "¿Cuándo debería hacer fine-tuning?",
              "a": "Cuando el prompting y la recuperación se estancan. Si puedes resolverlo con un mejor prompt o contexto relevante, hazlo primero: es más barato y flexible."
            }
          ]
        },
        "pt": {
          "title": "O que é Fine-tuning (Ajuste fino)?",
          "summary": "O fine-tuning continua o treinamento de um modelo pré-treinado com um conjunto de dados menor e direcionado para especializar seu comportamento, estilo ou conhecimento de domínio. É muito mais barato que o pré-treinamento e muda os pesos do modelo, ao contrário do prompting ou da recuperação, que o deixam intacto. Use-o para fixar um formato, tom ou habilidade consistentes; use recuperação quando precisar de fatos frescos ou privados.",
          "definition": "O fine-tuning é o processo de seguir treinando um modelo pré-treinado com um conjunto de dados focado para adaptar seus pesos rumo a um comportamento, estilo, formato ou domínio específico.",
          "takeaways": [
            "O fine-tuning atualiza os pesos do modelo; o prompting e o RAG não.",
            "Melhor para comportamento, estilo ou formato consistentes, não para fatos frescos.",
            "Métodos eficientes em parâmetros (LoRA) o tornam barato e prático.",
            "O RLHF é uma forma de fine-tuning que usa preferências humanas.",
            "Comece por prompting e recuperação; faça fine-tuning quando estagnarem."
          ],
          "context": [
            "Um modelo de fundação pré-treinado é um generalista. O fine-tuning o estreita: após ver exemplos suficientes do comportamento alvo, o modelo o internaliza, então não é mais preciso especificá-lo em cada prompt.",
            "É uma das três alavancas de adaptação, junto ao prompting e à recuperação. A arte está em escolher a adequada: fine-tuning para como o modelo deve se comportar, recuperação para o que deve saber."
          ],
          "architecture": [
            "O fine-tuning completo atualiza todos os pesos: potente mas caro. O fine-tuning eficiente em parâmetros (PEFT), notavelmente o LoRA, treina pequenos pesos adaptadores congelando a base, capturando quase todo o benefício a uma fração do custo.",
            "O instruction tuning e o RLHF são etapas especializadas de fine-tuning que transformam um modelo base bruto num assistente útil e alinhado. A qualidade do dataset importa muito mais que seu tamanho."
          ],
          "components": [
            "Modelo base pré-treinado",
            "Dataset de treinamento curado",
            "Objetivo de treinamento",
            "Adaptadores PEFT / LoRA",
            "Conjunto de avaliação"
          ],
          "pros": [
            "Fixa um comportamento, estilo ou formato consistentes.",
            "Reduz o comprimento do prompt e o custo por chamada.",
            "Pode ensinar habilidades estreitas que a base não tem.",
            "PEFT o torna acessível e rápido."
          ],
          "risks": [
            "Não adiciona fatos frescos ou privados: use recuperação para isso.",
            "Risco de esquecimento catastrófico ou sobreajuste.",
            "Precisa de um dataset de qualidade bem rotulado e um conjunto de avaliação.",
            "Acopla você a uma versão de modelo; custo de migração ao atualizar."
          ],
          "tools": [
            "Bibliotecas LoRA / PEFT",
            "APIs de fine-tuning de provedores",
            "Pipelines de RLHF / ajuste por preferências",
            "Suítes de avaliação"
          ],
          "examples": [
            "Fazer fine-tuning para um modelo emitir sempre um formato JSON estrito da empresa.",
            "Ensinar uma voz de marca consistente para textos gerados.",
            "Adaptar um modelo à terminologia de um domínio especializado."
          ],
          "faqs": [
            {
              "q": "Fine-tuning ou RAG?",
              "a": "Faça fine-tuning para mudar como o modelo se comporta (estilo, formato, habilidade); use recuperação (RAG) para dar-lhe conhecimento fresco ou privado. São complementares, não rivais."
            },
            {
              "q": "O fine-tuning é caro?",
              "a": "O completo pode ser, mas métodos eficientes como o LoRA treinam adaptadores minúsculos e o tornam barato e rápido para a maioria dos casos."
            },
            {
              "q": "O que é RLHF?",
              "a": "O aprendizado por reforço com feedback humano é uma etapa de fine-tuning que usa julgamentos de preferência humana para tornar um modelo mais útil, inofensivo e honesto."
            },
            {
              "q": "Quando devo fazer fine-tuning?",
              "a": "Quando o prompting e a recuperação estagnam. Se você pode resolver com um prompt melhor ou contexto relevante, faça isso primeiro: é mais barato e flexível."
            }
          ]
        }
      }
    },
    {
      "slug": "foundation-models",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/foundation-models",
      "api": "https://santismm.com/api/knowledge/foundation-models",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Bommasani et al. — On the Opportunities and Risks of Foundation Models (2021)",
          "url": "https://arxiv.org/abs/2108.07258"
        },
        {
          "title": "Vaswani et al. — Attention Is All You Need (2017)",
          "url": "https://arxiv.org/abs/1706.03762"
        }
      ],
      "related": [
        "fine-tuning",
        "embeddings",
        "agentic-ai",
        "harness-engineering"
      ],
      "locales": {
        "en": {
          "title": "What are Foundation Models?",
          "summary": "A foundation model is a large model pretrained on broad data at scale that can be adapted to a wide range of downstream tasks. Large language models (LLMs) and large multimodal models are the canonical examples. The term, coined at Stanford in 2021, captures a shift: instead of training a bespoke model per task, organizations build on a shared, general-purpose base — then specialize it through prompting, retrieval or fine-tuning.",
          "definition": "A foundation model is a large, general-purpose model pretrained on broad data that serves as a base which can be adapted — via prompting, retrieval or fine-tuning — to many downstream tasks.",
          "takeaways": [
            "Foundation models are general bases adapted to many tasks.",
            "LLMs and multimodal models are the leading examples.",
            "Most are built on the transformer architecture.",
            "Capabilities emerge with scale of data, parameters and compute.",
            "You adapt them by prompting, retrieval (RAG) or fine-tuning — rarely by training from scratch."
          ],
          "context": [
            "Before foundation models, teams trained narrow models for each task. The foundation-model paradigm flips this: one large model is pretrained once on broad data, then reused everywhere. That reuse is why a handful of models now underpin most AI products.",
            "It also concentrates capability — and risk. Because so much is built on a few bases, their biases, failures and security properties propagate downstream, which is part of why governance and evaluation matter."
          ],
          "architecture": [
            "Pretraining: a model with millions to trillions of parameters learns general patterns from massive datasets, typically with self-supervised objectives like next-token prediction. The transformer's attention mechanism makes this scalable.",
            "Adaptation: the same base is specialized for use — zero/few-shot prompting, retrieval-augmented generation for fresh or private knowledge, or fine-tuning for behavior and domain. Agents wrap the model in tools and a harness."
          ],
          "components": [
            "Transformer architecture",
            "Pretraining data & objective",
            "Parameters (weights)",
            "Tokenizer",
            "Adaptation layer (prompt / RAG / fine-tune)"
          ],
          "pros": [
            "One base reused across many tasks.",
            "Strong general capability out of the box.",
            "Rapid adaptation without training from scratch.",
            "Multimodal variants span text, image, audio and more."
          ],
          "risks": [
            "Concentrated risk: flaws propagate to everything built on them.",
            "Costly to pretrain; few organizations can.",
            "Inherit biases and gaps from training data.",
            "Knowledge is frozen at training time without retrieval."
          ],
          "tools": [
            "Frontier LLMs (Claude, GPT, Gemini)",
            "Open-weight models (Llama, Mistral)",
            "Multimodal models",
            "Model hosting / inference platforms"
          ],
          "examples": [
            "Using one LLM for summarization, classification and drafting across an org.",
            "Adapting a base model to a domain with retrieval instead of retraining.",
            "Building an agent on a frontier model plus tools and memory."
          ],
          "faqs": [
            {
              "q": "Is a foundation model the same as an LLM?",
              "a": "An LLM is the most common type of foundation model, specialized to language. Foundation models also include multimodal and other general-purpose models."
            },
            {
              "q": "Why are they called 'foundation' models?",
              "a": "Because they serve as a shared base that many applications are built on, rather than a model trained for a single task."
            },
            {
              "q": "Do I need to train one?",
              "a": "Almost never. Pretraining is extremely costly; nearly all value comes from adapting an existing base via prompting, retrieval or fine-tuning."
            },
            {
              "q": "How do agents relate to foundation models?",
              "a": "An agent uses a foundation model as its reasoning core, wrapped in tools, memory and a control loop — the harness — to take actions."
            }
          ]
        },
        "es": {
          "title": "¿Qué son los Modelos Fundacionales (Foundation Models)?",
          "summary": "Un modelo fundacional es un modelo grande preentrenado a escala con datos amplios que puede adaptarse a una gran variedad de tareas posteriores. Los modelos de lenguaje (LLM) y los multimodales son los ejemplos canónicos. El término, acuñado en Stanford en 2021, captura un cambio: en lugar de entrenar un modelo a medida por tarea, las organizaciones construyen sobre una base general compartida y luego la especializan mediante prompting, recuperación o fine-tuning.",
          "definition": "Un modelo fundacional es un modelo grande y de propósito general, preentrenado con datos amplios, que sirve de base adaptable —vía prompting, recuperación o fine-tuning— a muchas tareas posteriores.",
          "takeaways": [
            "Los modelos fundacionales son bases generales adaptadas a muchas tareas.",
            "Los LLM y los modelos multimodales son los ejemplos principales.",
            "La mayoría se construyen sobre la arquitectura transformer.",
            "Las capacidades emergen con la escala de datos, parámetros y cómputo.",
            "Se adaptan por prompting, recuperación (RAG) o fine-tuning; rara vez entrenando desde cero."
          ],
          "context": [
            "Antes de los modelos fundacionales, los equipos entrenaban modelos estrechos para cada tarea. El paradigma fundacional lo invierte: un modelo grande se preentrena una vez con datos amplios y se reutiliza en todas partes. Esa reutilización es la razón por la que un puñado de modelos sustenta hoy la mayoría de productos de IA.",
            "También concentra capacidad y riesgo. Como tanto se construye sobre unas pocas bases, sus sesgos, fallos y propiedades de seguridad se propagan aguas abajo, parte de por qué importan la gobernanza y la evaluación."
          ],
          "architecture": [
            "Preentrenamiento: un modelo con millones a billones de parámetros aprende patrones generales de conjuntos de datos masivos, normalmente con objetivos autosupervisados como la predicción del siguiente token. La atención del transformer lo hace escalable.",
            "Adaptación: la misma base se especializa para su uso —prompting zero/few-shot, RAG para conocimiento fresco o privado, o fine-tuning para comportamiento y dominio. Los agentes envuelven el modelo en herramientas y un harness."
          ],
          "components": [
            "Arquitectura transformer",
            "Datos y objetivo de preentrenamiento",
            "Parámetros (pesos)",
            "Tokenizador",
            "Capa de adaptación (prompt / RAG / fine-tune)"
          ],
          "pros": [
            "Una base reutilizada en muchas tareas.",
            "Fuerte capacidad general de fábrica.",
            "Adaptación rápida sin entrenar desde cero.",
            "Las variantes multimodales abarcan texto, imagen, audio y más."
          ],
          "risks": [
            "Riesgo concentrado: los fallos se propagan a todo lo construido sobre ellos.",
            "Costoso de preentrenar; pocas organizaciones pueden.",
            "Heredan sesgos y lagunas de los datos de entrenamiento.",
            "El conocimiento queda congelado en el momento del entrenamiento sin recuperación."
          ],
          "tools": [
            "LLM frontera (Claude, GPT, Gemini)",
            "Modelos de pesos abiertos (Llama, Mistral)",
            "Modelos multimodales",
            "Plataformas de hosting / inferencia"
          ],
          "examples": [
            "Usar un LLM para resumir, clasificar y redactar en toda una organización.",
            "Adaptar un modelo base a un dominio con recuperación en vez de reentrenar.",
            "Construir un agente sobre un modelo frontera más herramientas y memoria."
          ],
          "faqs": [
            {
              "q": "¿Un modelo fundacional es lo mismo que un LLM?",
              "a": "Un LLM es el tipo más común de modelo fundacional, especializado en lenguaje. Los modelos fundacionales también incluyen multimodales y otros de propósito general."
            },
            {
              "q": "¿Por qué se llaman 'fundacionales'?",
              "a": "Porque sirven de base compartida sobre la que se construyen muchas aplicaciones, en lugar de un modelo entrenado para una sola tarea."
            },
            {
              "q": "¿Necesito entrenar uno?",
              "a": "Casi nunca. El preentrenamiento es extremadamente costoso; casi todo el valor viene de adaptar una base existente vía prompting, recuperación o fine-tuning."
            },
            {
              "q": "¿Cómo se relacionan los agentes con los modelos fundacionales?",
              "a": "Un agente usa un modelo fundacional como núcleo de razonamiento, envuelto en herramientas, memoria y un bucle de control —el harness— para tomar acciones."
            }
          ]
        },
        "pt": {
          "title": "O que são Modelos de Fundação (Foundation Models)?",
          "summary": "Um modelo de fundação é um modelo grande pré-treinado em escala com dados amplos que pode ser adaptado a uma ampla variedade de tarefas posteriores. Os modelos de linguagem (LLMs) e os multimodais são os exemplos canônicos. O termo, cunhado em Stanford em 2021, captura uma mudança: em vez de treinar um modelo sob medida por tarefa, as organizações constroem sobre uma base geral compartilhada e depois a especializam via prompting, recuperação ou fine-tuning.",
          "definition": "Um modelo de fundação é um modelo grande e de propósito geral, pré-treinado com dados amplos, que serve de base adaptável — via prompting, recuperação ou fine-tuning — a muitas tarefas posteriores.",
          "takeaways": [
            "Os modelos de fundação são bases gerais adaptadas a muitas tarefas.",
            "Os LLMs e os modelos multimodais são os exemplos principais.",
            "A maioria é construída sobre a arquitetura transformer.",
            "As capacidades emergem com a escala de dados, parâmetros e computação.",
            "São adaptados por prompting, recuperação (RAG) ou fine-tuning; raramente treinando do zero."
          ],
          "context": [
            "Antes dos modelos de fundação, as equipes treinavam modelos estreitos para cada tarefa. O paradigma de fundação inverte isso: um modelo grande é pré-treinado uma vez com dados amplos e reutilizado em todo lugar. Essa reutilização é a razão pela qual um punhado de modelos sustenta hoje a maioria dos produtos de IA.",
            "Também concentra capacidade e risco. Como tanto se constrói sobre poucas bases, seus vieses, falhas e propriedades de segurança se propagam para baixo, parte do porquê governança e avaliação importam."
          ],
          "architecture": [
            "Pré-treinamento: um modelo com milhões a trilhões de parâmetros aprende padrões gerais de conjuntos de dados massivos, normalmente com objetivos autossupervisionados como a previsão do próximo token. A atenção do transformer torna isso escalável.",
            "Adaptação: a mesma base é especializada para uso — prompting zero/few-shot, RAG para conhecimento fresco ou privado, ou fine-tuning para comportamento e domínio. Os agentes envolvem o modelo em ferramentas e um harness."
          ],
          "components": [
            "Arquitetura transformer",
            "Dados e objetivo de pré-treinamento",
            "Parâmetros (pesos)",
            "Tokenizador",
            "Camada de adaptação (prompt / RAG / fine-tune)"
          ],
          "pros": [
            "Uma base reutilizada em muitas tarefas.",
            "Forte capacidade geral de fábrica.",
            "Adaptação rápida sem treinar do zero.",
            "As variantes multimodais abrangem texto, imagem, áudio e mais."
          ],
          "risks": [
            "Risco concentrado: as falhas se propagam a tudo o que é construído sobre eles.",
            "Custoso de pré-treinar; poucas organizações conseguem.",
            "Herdam vieses e lacunas dos dados de treinamento.",
            "O conhecimento fica congelado no momento do treinamento sem recuperação."
          ],
          "tools": [
            "LLMs de fronteira (Claude, GPT, Gemini)",
            "Modelos de pesos abertos (Llama, Mistral)",
            "Modelos multimodais",
            "Plataformas de hosting / inferência"
          ],
          "examples": [
            "Usar um LLM para resumir, classificar e redigir em toda uma organização.",
            "Adaptar um modelo base a um domínio com recuperação em vez de retreinar.",
            "Construir um agente sobre um modelo de fronteira mais ferramentas e memória."
          ],
          "faqs": [
            {
              "q": "Um modelo de fundação é o mesmo que um LLM?",
              "a": "Um LLM é o tipo mais comum de modelo de fundação, especializado em linguagem. Os modelos de fundação também incluem multimodais e outros de propósito geral."
            },
            {
              "q": "Por que são chamados de 'fundação'?",
              "a": "Porque servem de base compartilhada sobre a qual muitas aplicações são construídas, em vez de um modelo treinado para uma única tarefa."
            },
            {
              "q": "Preciso treinar um?",
              "a": "Quase nunca. O pré-treinamento é extremamente custoso; quase todo o valor vem de adaptar uma base existente via prompting, recuperação ou fine-tuning."
            },
            {
              "q": "Como os agentes se relacionam com os modelos de fundação?",
              "a": "Um agente usa um modelo de fundação como núcleo de raciocínio, envolvido em ferramentas, memória e um laço de controle — o harness — para tomar ações."
            }
          ]
        }
      }
    },
    {
      "slug": "guardrails",
      "category": "governance",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/guardrails",
      "api": "https://santismm.com/api/knowledge/guardrails",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "OWASP — Top 10 for LLM Applications",
          "url": "https://genai.owasp.org/llm-top-10/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        }
      ],
      "related": [
        "prompt-injection",
        "ai-governance",
        "human-in-the-loop",
        "ai-observability"
      ],
      "locales": {
        "en": {
          "title": "What are AI Guardrails?",
          "summary": "Guardrails are runtime controls that constrain what goes into and comes out of an AI system, keeping its behavior safe, on-policy and compliant. They check and filter inputs and outputs, validate tool actions, block disallowed content and enforce limits — sitting around the model as a safety layer. Guardrails are a primary, operational control in AI governance and a key defense against misuse and prompt injection.",
          "definition": "AI guardrails are runtime safeguards that validate, filter or constrain a model's inputs, outputs and actions to keep its behavior safe, compliant and within defined policy.",
          "takeaways": [
            "Guardrails act at runtime on inputs, outputs and actions.",
            "They enforce safety, policy and compliance, not model quality.",
            "Types: input filtering, output validation, action allow-lists, limits.",
            "A core defense against misuse and prompt injection.",
            "Guardrails complement — they do not replace — evaluation and oversight."
          ],
          "context": [
            "A model alone has no enforceable boundaries; it will attempt whatever the prompt elicits. Guardrails add those boundaries operationally: deterministic or model-based checks that sit between the user, the model and the systems it can touch.",
            "They are how governance policies become live controls. A policy that says 'never expose PII' or 'never execute payments without approval' is realized as a guardrail that actually checks and blocks at runtime."
          ],
          "architecture": [
            "Input guardrails screen prompts (e.g. for injection, policy violations, PII). Output guardrails validate responses (format, safety, factual constraints, PII redaction). Action guardrails gate tool calls with permissions and allow-lists. Rate, scope and budget limits cap blast radius.",
            "Guardrails can be deterministic (rules, schemas, regex, allow-lists) or model-based (a classifier or LLM judge). They pair with observability to log violations and with human-in-the-loop approval for high-impact actions."
          ],
          "components": [
            "Input filtering",
            "Output validation / redaction",
            "Action allow-lists & permissions",
            "Rate & scope limits",
            "Policy classifiers",
            "Violation logging"
          ],
          "pros": [
            "Enforces safety and policy at runtime, not just in guidance.",
            "Reduces misuse, unsafe output and injection impact.",
            "Operationalizes governance and compliance requirements.",
            "Bounds the blast radius of agent actions."
          ],
          "risks": [
            "Over-blocking harms usefulness (false positives).",
            "Under-blocking creates a false sense of safety.",
            "Model-based guardrails add latency and cost.",
            "They are not a complete defense; combine with oversight and evals."
          ],
          "tools": [
            "Guardrail frameworks (e.g. NeMo Guardrails, Guardrails AI)",
            "Content moderation / safety classifiers",
            "Schema & input validation",
            "Permission & policy engines",
            "Observability for violations"
          ],
          "examples": [
            "Redacting personal data from a model's output before it is shown.",
            "Blocking a tool call that falls outside an allow-list of safe actions.",
            "Rejecting responses that do not match a required JSON schema."
          ],
          "faqs": [
            {
              "q": "Are guardrails the same as alignment?",
              "a": "No. Alignment shapes the model's intrinsic behavior during training; guardrails are external runtime controls around the deployed system. They are complementary."
            },
            {
              "q": "Do guardrails stop prompt injection?",
              "a": "They reduce its impact — input screening and action allow-lists help — but no guardrail fully prevents injection. Use layered defenses plus human approval for sensitive actions."
            },
            {
              "q": "Deterministic or model-based guardrails?",
              "a": "Both. Deterministic checks (schemas, allow-lists) are cheap and reliable for clear rules; model-based checks handle nuanced content at the cost of latency."
            },
            {
              "q": "How do guardrails fit AI governance?",
              "a": "They are the operational layer: the runtime controls that turn governance policies into enforced behavior, evidenced through logging and audit."
            }
          ]
        },
        "es": {
          "title": "¿Qué son los Guardarraíles de IA (Guardrails)?",
          "summary": "Los guardarraíles son controles en tiempo de ejecución que acotan lo que entra y sale de un sistema de IA, manteniendo su comportamiento seguro, conforme a la política y al cumplimiento. Comprueban y filtran entradas y salidas, validan acciones de herramientas, bloquean contenido no permitido e imponen límites, situándose alrededor del modelo como capa de seguridad. Son un control primario y operativo en la gobernanza de IA y una defensa clave contra el mal uso y la inyección de prompts.",
          "definition": "Los guardarraíles de IA son salvaguardas en tiempo de ejecución que validan, filtran o acotan las entradas, salidas y acciones de un modelo para mantener su comportamiento seguro, conforme y dentro de la política definida.",
          "takeaways": [
            "Los guardarraíles actúan en tiempo de ejecución sobre entradas, salidas y acciones.",
            "Imponen seguridad, política y cumplimiento, no la calidad del modelo.",
            "Tipos: filtrado de entrada, validación de salida, listas de permitidos de acciones, límites.",
            "Una defensa central contra el mal uso y la inyección de prompts.",
            "Complementan —no reemplazan— la evaluación y la supervisión."
          ],
          "context": [
            "Un modelo por sí solo no tiene límites exigibles; intentará lo que el prompt provoque. Los guardarraíles añaden esos límites de forma operativa: comprobaciones deterministas o basadas en modelo que se sitúan entre el usuario, el modelo y los sistemas que puede tocar.",
            "Son la forma en que las políticas de gobernanza se vuelven controles vivos. Una política que dice 'nunca exponer datos personales' o 'nunca ejecutar pagos sin aprobación' se materializa como un guardarraíl que realmente comprueba y bloquea en tiempo de ejecución."
          ],
          "architecture": [
            "Los guardarraíles de entrada filtran prompts (p. ej. inyección, violaciones de política, datos personales). Los de salida validan respuestas (formato, seguridad, restricciones factuales, redacción de datos personales). Los de acción acotan las llamadas a herramientas con permisos y listas de permitidos. Los límites de tasa, alcance y presupuesto contienen el radio de impacto.",
            "Pueden ser deterministas (reglas, esquemas, regex, listas de permitidos) o basados en modelo (un clasificador o juez LLM). Se combinan con observabilidad para registrar violaciones y con aprobación con humano en el bucle para acciones de alto impacto."
          ],
          "components": [
            "Filtrado de entrada",
            "Validación / redacción de salida",
            "Listas de permitidos y permisos de acción",
            "Límites de tasa y alcance",
            "Clasificadores de política",
            "Registro de violaciones"
          ],
          "pros": [
            "Impone seguridad y política en ejecución, no solo en la guía.",
            "Reduce el mal uso, la salida insegura y el impacto de la inyección.",
            "Operacionaliza requisitos de gobernanza y cumplimiento.",
            "Acota el radio de impacto de las acciones del agente."
          ],
          "risks": [
            "El sobrebloqueo daña la utilidad (falsos positivos).",
            "El infrabloqueo crea una falsa sensación de seguridad.",
            "Los guardarraíles basados en modelo añaden latencia y coste.",
            "No son una defensa completa; combínalos con supervisión y evaluaciones."
          ],
          "tools": [
            "Frameworks de guardarraíles (p. ej. NeMo Guardrails, Guardrails AI)",
            "Clasificadores de moderación / seguridad",
            "Validación de esquemas y entradas",
            "Motores de permisos y políticas",
            "Observabilidad de violaciones"
          ],
          "examples": [
            "Redactar datos personales de la salida de un modelo antes de mostrarla.",
            "Bloquear una llamada a herramienta fuera de una lista de acciones seguras.",
            "Rechazar respuestas que no cumplen un esquema JSON requerido."
          ],
          "faqs": [
            {
              "q": "¿Los guardarraíles son lo mismo que la alineación?",
              "a": "No. La alineación moldea el comportamiento intrínseco del modelo durante el entrenamiento; los guardarraíles son controles externos en ejecución alrededor del sistema desplegado. Son complementarios."
            },
            {
              "q": "¿Los guardarraíles detienen la inyección de prompts?",
              "a": "Reducen su impacto —el filtrado de entrada y las listas de permitidos ayudan— pero ningún guardarraíl la previene por completo. Usa defensas por capas más aprobación humana para acciones sensibles."
            },
            {
              "q": "¿Guardarraíles deterministas o basados en modelo?",
              "a": "Ambos. Las comprobaciones deterministas (esquemas, listas) son baratas y fiables para reglas claras; las basadas en modelo manejan contenido con matices a costa de latencia."
            },
            {
              "q": "¿Cómo encajan los guardarraíles en la gobernanza de IA?",
              "a": "Son la capa operativa: los controles en ejecución que convierten las políticas de gobernanza en comportamiento exigido, evidenciado mediante registro y auditoría."
            }
          ]
        },
        "pt": {
          "title": "O que são Guard-rails de IA (Guardrails)?",
          "summary": "Os guard-rails são controles em tempo de execução que limitam o que entra e sai de um sistema de IA, mantendo seu comportamento seguro, em conformidade com a política e a regulação. Verificam e filtram entradas e saídas, validam ações de ferramentas, bloqueiam conteúdo não permitido e impõem limites, situando-se ao redor do modelo como camada de segurança. São um controle primário e operacional na governança de IA e uma defesa-chave contra o mau uso e a injeção de prompts.",
          "definition": "Os guard-rails de IA são salvaguardas em tempo de execução que validam, filtram ou limitam as entradas, saídas e ações de um modelo para manter seu comportamento seguro, conforme e dentro da política definida.",
          "takeaways": [
            "Os guard-rails atuam em tempo de execução sobre entradas, saídas e ações.",
            "Impõem segurança, política e conformidade, não a qualidade do modelo.",
            "Tipos: filtragem de entrada, validação de saída, listas de permitidos de ações, limites.",
            "Uma defesa central contra o mau uso e a injeção de prompts.",
            "Complementam — não substituem — a avaliação e a supervisão."
          ],
          "context": [
            "Um modelo sozinho não tem limites exigíveis; tentará o que o prompt provocar. Os guard-rails adicionam esses limites de forma operacional: verificações determinísticas ou baseadas em modelo que se situam entre o usuário, o modelo e os sistemas que ele pode tocar.",
            "São a forma como as políticas de governança se tornam controles vivos. Uma política que diz 'nunca expor dados pessoais' ou 'nunca executar pagamentos sem aprovação' se materializa como um guard-rail que realmente verifica e bloqueia em tempo de execução."
          ],
          "architecture": [
            "Os guard-rails de entrada filtram prompts (ex.: injeção, violações de política, dados pessoais). Os de saída validam respostas (formato, segurança, restrições factuais, redação de dados pessoais). Os de ação limitam as chamadas de ferramentas com permissões e listas de permitidos. Os limites de taxa, escopo e orçamento contêm o raio de impacto.",
            "Podem ser determinísticos (regras, esquemas, regex, listas de permitidos) ou baseados em modelo (um classificador ou juiz LLM). Combinam-se com observabilidade para registrar violações e com aprovação com humano no laço para ações de alto impacto."
          ],
          "components": [
            "Filtragem de entrada",
            "Validação / redação de saída",
            "Listas de permitidos e permissões de ação",
            "Limites de taxa e escopo",
            "Classificadores de política",
            "Registro de violações"
          ],
          "pros": [
            "Impõe segurança e política em execução, não só na orientação.",
            "Reduz o mau uso, a saída insegura e o impacto da injeção.",
            "Operacionaliza requisitos de governança e conformidade.",
            "Limita o raio de impacto das ações do agente."
          ],
          "risks": [
            "O bloqueio em excesso prejudica a utilidade (falsos positivos).",
            "O bloqueio insuficiente cria uma falsa sensação de segurança.",
            "Os guard-rails baseados em modelo adicionam latência e custo.",
            "Não são uma defesa completa; combine-os com supervisão e avaliações."
          ],
          "tools": [
            "Frameworks de guard-rails (ex.: NeMo Guardrails, Guardrails AI)",
            "Classificadores de moderação / segurança",
            "Validação de esquemas e entradas",
            "Motores de permissões e políticas",
            "Observabilidade de violações"
          ],
          "examples": [
            "Redigir dados pessoais da saída de um modelo antes de exibi-la.",
            "Bloquear uma chamada de ferramenta fora de uma lista de ações seguras.",
            "Rejeitar respostas que não cumprem um esquema JSON exigido."
          ],
          "faqs": [
            {
              "q": "Os guard-rails são o mesmo que alinhamento?",
              "a": "Não. O alinhamento molda o comportamento intrínseco do modelo durante o treinamento; os guard-rails são controles externos em execução ao redor do sistema implantado. São complementares."
            },
            {
              "q": "Os guard-rails detêm a injeção de prompts?",
              "a": "Reduzem seu impacto — a filtragem de entrada e as listas de permitidos ajudam — mas nenhum guard-rail a previne por completo. Use defesas em camadas mais aprovação humana para ações sensíveis."
            },
            {
              "q": "Guard-rails determinísticos ou baseados em modelo?",
              "a": "Ambos. As verificações determinísticas (esquemas, listas) são baratas e confiáveis para regras claras; as baseadas em modelo lidam com conteúdo com nuances ao custo de latência."
            },
            {
              "q": "Como os guard-rails se encaixam na governança de IA?",
              "a": "São a camada operacional: os controles em execução que convertem as políticas de governança em comportamento exigido, evidenciado por registro e auditoria."
            }
          ]
        }
      }
    },
    {
      "slug": "harness-engineering",
      "category": "harness",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/harness-engineering",
      "api": "https://santismm.com/api/knowledge/harness-engineering",
      "evidence": {
        "evidenceLevel": "theoretical",
        "confidenceLevel": "medium",
        "sourceType": [
          "personal_experience",
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        },
        {
          "title": "Yao et al. — ReAct (2022)",
          "url": "https://arxiv.org/abs/2210.03629"
        },
        {
          "title": "Santiago Santa María — The Stopwatch and the Exam",
          "url": "https://articles.santismm.com/the-stopwatch-and-the-exam/"
        }
      ],
      "related": [
        "agentic-ai",
        "ai-agent",
        "context-engineering",
        "agent-memory",
        "ai-observability",
        "multi-agent-architecture",
        "agentic-evaluation"
      ],
      "locales": {
        "en": {
          "title": "What is Harness Engineering?",
          "summary": "Harness engineering is the discipline of designing and optimizing the scaffolding around an AI model — the prompts, tools, memory, environment, control loop and guardrails — so the model performs reliably on real tasks. Its core premise: as base models converge in raw capability, competitive advantage shifts from the model itself to the harness built around it. The same model can pass or fail a task depending almost entirely on its harness.",
          "definition": "Harness engineering is the practice of designing, building and optimizing the scaffolding (tools, memory, prompts, environment and control loop) that turns a model's raw capability into reliable, goal-directed action.",
          "takeaways": [
            "The harness is everything around the model that converts capability into action.",
            "As frontier models converge, the harness becomes the main lever of differentiation.",
            "Tool design, context management and memory often matter more than model choice.",
            "Harnesses must be observable and evaluated — you cannot improve what you cannot measure.",
            "Harness engineering is to agents what platform engineering is to cloud applications."
          ],
          "context": [
            "Benchmarks long measured a model's capability in isolation. But in production, a model never acts alone: it acts through a harness. Give a strong model a poor harness and it fails; give a modest model an excellent harness and it succeeds. That gap is where harness engineering lives.",
            "The term names a shift in where engineering effort and competitive advantage sit. When everyone can call a comparable frontier model, the durable advantage is the system around it: the quality of the tools, the memory, the context strategy, the evaluation loop and the guardrails."
          ],
          "architecture": [
            "A harness has recurring layers: the prompt/instruction layer; the tool layer (what the model can do and how cleanly those tools are described); the memory layer (short-term context plus long-term stores); the environment (the systems the agent acts on); the control loop (how outputs become actions and observations return); and the cross-cutting layers of guardrails, observability and evaluation.",
            "Good harness engineering treats each layer as a design surface. Tools are written for a model to use, not just for a developer to read. Context is curated rather than dumped. Memory is structured. Every run is traced so failures can be diagnosed and fed back into evals."
          ],
          "components": [
            "Instruction / prompt layer",
            "Tooling",
            "Memory systems",
            "Environment",
            "Control loop / orchestration",
            "Guardrails",
            "Observability",
            "Evaluation"
          ],
          "pros": [
            "Turns the same model into a far more reliable system.",
            "A durable advantage that survives model upgrades and swaps.",
            "Makes failures diagnosable through observability and evals.",
            "Lets teams improve agents systematically, not by prompt luck."
          ],
          "risks": [
            "Complexity: more moving parts to build, secure and maintain.",
            "Over-engineering harnesses that simpler patterns would solve.",
            "Tight coupling to a model's quirks can create migration cost.",
            "Without evaluation, harness changes are guesswork."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)",
            "LangSmith / Langfuse (observability)"
          ],
          "examples": [
            "Rewriting a vague tool description so the model calls it correctly, lifting task success without touching the model.",
            "Adding a memory store so an agent stops repeating work across a long task.",
            "Introducing an evaluation harness that catches a regression before it ships."
          ],
          "faqs": [
            {
              "q": "Why does harness engineering matter now?",
              "a": "Because frontier models are converging. When raw capability is broadly available, the differentiator becomes the harness — the engineered system that turns that capability into dependable work."
            },
            {
              "q": "Is harness engineering the same as prompt engineering?",
              "a": "No. Prompt engineering is one layer of the harness. Harness engineering also covers tools, memory, environment, the control loop, guardrails, observability and evaluation."
            },
            {
              "q": "How is it different from agentic harness engineering?",
              "a": "Agentic harness engineering applies the same discipline specifically to autonomous, multi-step agents and their long-horizon needs (memory, tools, feedback loops)."
            },
            {
              "q": "What skills does it require?",
              "a": "Software and platform engineering, evaluation/measurement, systems design, security, and a working understanding of how models behave."
            },
            {
              "q": "How do you know a harness is good?",
              "a": "By measuring it. A good harness is observable and evaluated against task-based benchmarks, so improvements are demonstrated rather than assumed."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Ingeniería de Harness (Harness Engineering)?",
          "summary": "La ingeniería de harness es la disciplina de diseñar y optimizar el andamiaje alrededor de un modelo de IA —prompts, herramientas, memoria, entorno, bucle de control y guardarraíles— para que el modelo rinda de forma fiable en tareas reales. Su premisa central: a medida que los modelos base convergen en capacidad bruta, la ventaja competitiva se desplaza del modelo al harness que lo rodea. El mismo modelo puede aprobar o fallar una tarea casi por completo según su harness.",
          "definition": "La ingeniería de harness es la práctica de diseñar, construir y optimizar el andamiaje (herramientas, memoria, prompts, entorno y bucle de control) que convierte la capacidad bruta de un modelo en acción fiable y dirigida a objetivos.",
          "takeaways": [
            "El harness es todo lo que rodea al modelo y convierte capacidad en acción.",
            "A medida que los modelos frontera convergen, el harness se vuelve la principal palanca de diferenciación.",
            "El diseño de herramientas, la gestión de contexto y la memoria suelen importar más que el modelo elegido.",
            "Los harness deben ser observables y evaluados: no se mejora lo que no se mide.",
            "La ingeniería de harness es a los agentes lo que la ingeniería de plataforma a las aplicaciones cloud."
          ],
          "context": [
            "Los benchmarks midieron durante mucho tiempo la capacidad de un modelo de forma aislada. Pero en producción un modelo nunca actúa solo: actúa a través de un harness. Dale a un modelo fuerte un harness pobre y falla; dale a un modelo modesto un harness excelente y triunfa. En esa brecha vive la ingeniería de harness.",
            "El término nombra un desplazamiento en dónde están el esfuerzo de ingeniería y la ventaja competitiva. Cuando todos pueden llamar a un modelo frontera comparable, la ventaja duradera es el sistema que lo rodea: la calidad de las herramientas, la memoria, la estrategia de contexto, el bucle de evaluación y los guardarraíles."
          ],
          "architecture": [
            "Un harness tiene capas recurrentes: la capa de instrucción/prompt; la capa de herramientas (qué puede hacer el modelo y con qué limpieza se describen esas herramientas); la capa de memoria (contexto a corto plazo más almacenes a largo plazo); el entorno (los sistemas sobre los que actúa el agente); el bucle de control (cómo las salidas se vuelven acciones y vuelven las observaciones); y las capas transversales de guardarraíles, observabilidad y evaluación.",
            "La buena ingeniería de harness trata cada capa como una superficie de diseño. Las herramientas se escriben para que las use un modelo, no solo para que las lea un desarrollador. El contexto se cura en lugar de volcarse. La memoria se estructura. Cada ejecución se traza para diagnosticar fallos y realimentar las evaluaciones."
          ],
          "components": [
            "Capa de instrucción / prompt",
            "Herramientas (tooling)",
            "Sistemas de memoria",
            "Entorno",
            "Bucle de control / orquestación",
            "Guardarraíles",
            "Observabilidad",
            "Evaluación"
          ],
          "pros": [
            "Convierte el mismo modelo en un sistema mucho más fiable.",
            "Una ventaja duradera que sobrevive a actualizaciones y cambios de modelo.",
            "Hace los fallos diagnosticables mediante observabilidad y evaluaciones.",
            "Permite mejorar agentes de forma sistemática, no por suerte en el prompt."
          ],
          "risks": [
            "Complejidad: más piezas que construir, asegurar y mantener.",
            "Sobreingeniería de harness que patrones más simples resolverían.",
            "El acoplamiento a las peculiaridades de un modelo puede crear coste de migración.",
            "Sin evaluación, los cambios de harness son conjeturas."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)",
            "LangSmith / Langfuse (observabilidad)"
          ],
          "examples": [
            "Reescribir una descripción de herramienta ambigua para que el modelo la llame bien, subiendo el éxito sin tocar el modelo.",
            "Añadir un almacén de memoria para que un agente deje de repetir trabajo en una tarea larga.",
            "Introducir un harness de evaluación que detecta una regresión antes de publicarla."
          ],
          "faqs": [
            {
              "q": "¿Por qué importa ahora la ingeniería de harness?",
              "a": "Porque los modelos frontera están convergiendo. Cuando la capacidad bruta es ampliamente accesible, el diferenciador pasa a ser el harness: el sistema de ingeniería que convierte esa capacidad en trabajo fiable."
            },
            {
              "q": "¿Es lo mismo que la ingeniería de prompts?",
              "a": "No. La ingeniería de prompts es una capa del harness. La ingeniería de harness abarca además herramientas, memoria, entorno, bucle de control, guardarraíles, observabilidad y evaluación."
            },
            {
              "q": "¿En qué se diferencia de la ingeniería de harness agéntico?",
              "a": "La ingeniería de harness agéntico aplica la misma disciplina específicamente a agentes autónomos de varios pasos y sus necesidades de horizonte largo (memoria, herramientas, bucles de feedback)."
            },
            {
              "q": "¿Qué habilidades requiere?",
              "a": "Ingeniería de software y de plataforma, evaluación/medición, diseño de sistemas, seguridad y una comprensión práctica de cómo se comportan los modelos."
            },
            {
              "q": "¿Cómo sé si un harness es bueno?",
              "a": "Midiéndolo. Un buen harness es observable y se evalúa contra benchmarks basados en tareas, de modo que las mejoras se demuestran en vez de suponerse."
            }
          ]
        },
        "pt": {
          "title": "O que é Engenharia de Harness (Harness Engineering)?",
          "summary": "A engenharia de harness é a disciplina de projetar e otimizar o andaime ao redor de um modelo de IA — prompts, ferramentas, memória, ambiente, laço de controle e guard-rails — para que o modelo tenha desempenho confiável em tarefas reais. Sua premissa central: à medida que os modelos base convergem em capacidade bruta, a vantagem competitiva se desloca do modelo para o harness à sua volta. O mesmo modelo pode passar ou falhar numa tarefa quase inteiramente conforme seu harness.",
          "definition": "A engenharia de harness é a prática de projetar, construir e otimizar o andaime (ferramentas, memória, prompts, ambiente e laço de controle) que converte a capacidade bruta de um modelo em ação confiável e orientada a objetivos.",
          "takeaways": [
            "O harness é tudo o que rodeia o modelo e converte capacidade em ação.",
            "À medida que os modelos de fronteira convergem, o harness se torna a principal alavanca de diferenciação.",
            "O design de ferramentas, a gestão de contexto e a memória costumam importar mais que o modelo escolhido.",
            "Os harnesses devem ser observáveis e avaliados: não se melhora o que não se mede.",
            "A engenharia de harness está para os agentes assim como a engenharia de plataforma está para as aplicações cloud."
          ],
          "context": [
            "Os benchmarks mediram por muito tempo a capacidade de um modelo de forma isolada. Mas em produção um modelo nunca age sozinho: age através de um harness. Dê a um modelo forte um harness ruim e ele falha; dê a um modelo modesto um harness excelente e ele tem sucesso. Nessa lacuna vive a engenharia de harness.",
            "O termo nomeia um deslocamento de onde estão o esforço de engenharia e a vantagem competitiva. Quando todos podem chamar um modelo de fronteira comparável, a vantagem durável é o sistema ao seu redor: a qualidade das ferramentas, a memória, a estratégia de contexto, o laço de avaliação e os guard-rails."
          ],
          "architecture": [
            "Um harness tem camadas recorrentes: a camada de instrução/prompt; a camada de ferramentas (o que o modelo pode fazer e com que clareza essas ferramentas são descritas); a camada de memória (contexto de curto prazo mais armazenamentos de longo prazo); o ambiente (os sistemas sobre os quais o agente age); o laço de controle (como as saídas viram ações e as observações retornam); e as camadas transversais de guard-rails, observabilidade e avaliação.",
            "A boa engenharia de harness trata cada camada como uma superfície de design. As ferramentas são escritas para um modelo usar, não só para um desenvolvedor ler. O contexto é curado em vez de despejado. A memória é estruturada. Cada execução é rastreada para diagnosticar falhas e realimentar as avaliações."
          ],
          "components": [
            "Camada de instrução / prompt",
            "Ferramentas (tooling)",
            "Sistemas de memória",
            "Ambiente",
            "Laço de controle / orquestração",
            "Guard-rails",
            "Observabilidade",
            "Avaliação"
          ],
          "pros": [
            "Transforma o mesmo modelo em um sistema muito mais confiável.",
            "Uma vantagem durável que sobrevive a atualizações e trocas de modelo.",
            "Torna as falhas diagnosticáveis por meio de observabilidade e avaliações.",
            "Permite melhorar agentes de forma sistemática, não por sorte no prompt."
          ],
          "risks": [
            "Complexidade: mais peças para construir, proteger e manter.",
            "Superengenharia de harness que padrões mais simples resolveriam.",
            "O acoplamento às peculiaridades de um modelo pode criar custo de migração.",
            "Sem avaliação, as mudanças de harness são suposições."
          ],
          "tools": [
            "LangGraph",
            "Claude Agent SDK",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)",
            "LangSmith / Langfuse (observabilidade)"
          ],
          "examples": [
            "Reescrever uma descrição de ferramenta ambígua para o modelo chamá-la corretamente, elevando o sucesso sem tocar no modelo.",
            "Adicionar um armazenamento de memória para um agente parar de repetir trabalho numa tarefa longa.",
            "Introduzir um harness de avaliação que detecta uma regressão antes de publicá-la."
          ],
          "faqs": [
            {
              "q": "Por que a engenharia de harness importa agora?",
              "a": "Porque os modelos de fronteira estão convergindo. Quando a capacidade bruta é amplamente acessível, o diferencial passa a ser o harness: o sistema de engenharia que converte essa capacidade em trabalho confiável."
            },
            {
              "q": "É o mesmo que engenharia de prompts?",
              "a": "Não. A engenharia de prompts é uma camada do harness. A engenharia de harness abrange ainda ferramentas, memória, ambiente, laço de controle, guard-rails, observabilidade e avaliação."
            },
            {
              "q": "Como se diferencia da engenharia de harness agêntico?",
              "a": "A engenharia de harness agêntico aplica a mesma disciplina especificamente a agentes autônomos de vários passos e suas necessidades de horizonte longo (memória, ferramentas, laços de feedback)."
            },
            {
              "q": "Que habilidades exige?",
              "a": "Engenharia de software e de plataforma, avaliação/medição, design de sistemas, segurança e uma compreensão prática de como os modelos se comportam."
            },
            {
              "q": "Como sei se um harness é bom?",
              "a": "Medindo-o. Um bom harness é observável e avaliado contra benchmarks baseados em tarefas, de modo que as melhorias são demonstradas em vez de presumidas."
            }
          ]
        }
      }
    },
    {
      "slug": "human-in-the-loop",
      "category": "pattern",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/human-in-the-loop",
      "api": "https://santismm.com/api/knowledge/human-in-the-loop",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "European Union — AI Act, Article 14 (Human oversight)",
          "url": "https://artificialintelligenceact.eu/article/14/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        }
      ],
      "related": [
        "ai-governance",
        "agentic-ai",
        "ai-agent",
        "agentic-evaluation"
      ],
      "locales": {
        "en": {
          "title": "What is the Human-in-the-Loop Pattern?",
          "summary": "Human-in-the-loop (HITL) is a design pattern where a person reviews, approves or corrects an AI system's output before it takes effect — especially for high-impact actions. Instead of full autonomy, the agent proposes and a human disposes. It is a primary control for managing risk in agentic systems and a recurring requirement in AI governance frameworks like the EU AI Act and NIST AI RMF.",
          "definition": "Human-in-the-loop is a pattern in which a human reviews, approves, edits or rejects an AI system's proposed output or action before it is executed, inserting human judgment at defined decision points.",
          "takeaways": [
            "The agent proposes; a human approves, edits or rejects.",
            "Apply it to high-impact, irreversible or sensitive actions.",
            "It trades some autonomy and speed for control and trust.",
            "Governance frameworks often require human oversight by design.",
            "Approvals and overrides should be logged for auditability."
          ],
          "context": [
            "Full autonomy is risky when actions are costly, irreversible or regulated. HITL inserts a checkpoint: the AI does the work and a human makes the final call, capturing most of the efficiency while keeping accountability with a person.",
            "It is also a trust-building and adoption strategy. Teams often start with tight human review, then widen autonomy as evaluation shows the system is reliable for a given task."
          ],
          "architecture": [
            "Patterns: human-in-the-loop (a person approves each high-impact action), human-on-the-loop (a person monitors and can intervene), and human-over-the-loop (periodic review and policy setting). The right level depends on the action's risk.",
            "Implementation needs an approval interface, clear context for the reviewer, the ability to edit or reject, fallback behavior on timeout, and logging of every decision for audit."
          ],
          "components": [
            "Decision checkpoints",
            "Approval interface",
            "Reviewer context",
            "Edit / override",
            "Escalation & fallback",
            "Audit log"
          ],
          "pros": [
            "Catches errors before they cause harm.",
            "Keeps accountability with a human.",
            "Supports compliance and governance requirements.",
            "Builds trust and enables gradual autonomy."
          ],
          "risks": [
            "Adds latency and limits throughput.",
            "Rubber-stamping: reviewers approve without real scrutiny.",
            "Alert fatigue degrades the quality of oversight.",
            "Over-applying it negates the value of automation."
          ],
          "tools": [
            "Approval / workflow systems",
            "Agent frameworks with interrupt steps (e.g. LangGraph)",
            "Audit logging",
            "Case-management UIs"
          ],
          "examples": [
            "An agent drafting a refund that a human approves before it is issued.",
            "A content agent whose output a person reviews before publishing.",
            "An ops agent that pauses for sign-off before a production change."
          ],
          "faqs": [
            {
              "q": "When should you use human-in-the-loop?",
              "a": "For actions that are high-impact, irreversible, sensitive or regulated, where the cost of an error outweighs the latency of review."
            },
            {
              "q": "What is the difference between in-the-loop and on-the-loop?",
              "a": "In-the-loop means a human approves each action before it executes; on-the-loop means a human monitors and can intervene, but the system acts on its own by default."
            },
            {
              "q": "Does HITL conflict with autonomy?",
              "a": "It bounds autonomy deliberately. Many systems start with heavy review and widen autonomy as evaluation demonstrates reliability for a task."
            },
            {
              "q": "Is it required by regulation?",
              "a": "Human oversight is a recurring requirement — for example the EU AI Act mandates effective human oversight for high-risk AI systems."
            }
          ]
        },
        "es": {
          "title": "¿Qué es el Patrón Human-in-the-Loop?",
          "summary": "Human-in-the-loop (HITL) es un patrón de diseño en el que una persona revisa, aprueba o corrige la salida de un sistema de IA antes de que surta efecto, sobre todo en acciones de alto impacto. En lugar de autonomía total, el agente propone y un humano dispone. Es un control primario para gestionar el riesgo en sistemas agénticos y un requisito recurrente en marcos de gobernanza como el Reglamento de IA de la UE y el NIST AI RMF.",
          "definition": "Human-in-the-loop es un patrón en el que un humano revisa, aprueba, edita o rechaza la salida o acción propuesta por un sistema de IA antes de ejecutarse, insertando el juicio humano en puntos de decisión definidos.",
          "takeaways": [
            "El agente propone; un humano aprueba, edita o rechaza.",
            "Aplícalo a acciones de alto impacto, irreversibles o sensibles.",
            "Cambia algo de autonomía y velocidad por control y confianza.",
            "Los marcos de gobernanza suelen exigir supervisión humana por diseño.",
            "Las aprobaciones y anulaciones deben registrarse para la auditabilidad."
          ],
          "context": [
            "La autonomía total es arriesgada cuando las acciones son costosas, irreversibles o reguladas. HITL inserta un punto de control: la IA hace el trabajo y un humano toma la decisión final, capturando casi toda la eficiencia mientras la responsabilidad queda en una persona.",
            "También es una estrategia de confianza y adopción. Los equipos suelen empezar con revisión humana estricta y luego ampliar la autonomía a medida que la evaluación muestra que el sistema es fiable para una tarea dada."
          ],
          "architecture": [
            "Patrones: human-in-the-loop (una persona aprueba cada acción de alto impacto), human-on-the-loop (una persona monitoriza y puede intervenir) y human-over-the-loop (revisión periódica y fijación de políticas). El nivel adecuado depende del riesgo de la acción.",
            "La implementación necesita una interfaz de aprobación, contexto claro para el revisor, capacidad de editar o rechazar, comportamiento de respaldo ante timeout, y registro de cada decisión para auditoría."
          ],
          "components": [
            "Puntos de decisión",
            "Interfaz de aprobación",
            "Contexto para el revisor",
            "Edición / anulación",
            "Escalado y respaldo",
            "Registro de auditoría"
          ],
          "pros": [
            "Detecta errores antes de que causen daño.",
            "Mantiene la responsabilidad en un humano.",
            "Apoya requisitos de cumplimiento y gobernanza.",
            "Genera confianza y habilita una autonomía gradual."
          ],
          "risks": [
            "Añade latencia y limita el rendimiento.",
            "Aprobación automática: revisores que aprueban sin escrutinio real.",
            "La fatiga de alertas degrada la calidad de la supervisión.",
            "Aplicarlo en exceso anula el valor de la automatización."
          ],
          "tools": [
            "Sistemas de aprobación / workflow",
            "Frameworks de agentes con pasos de interrupción (p. ej. LangGraph)",
            "Registro de auditoría",
            "Interfaces de gestión de casos"
          ],
          "examples": [
            "Un agente que redacta un reembolso que un humano aprueba antes de emitirse.",
            "Un agente de contenido cuya salida una persona revisa antes de publicar.",
            "Un agente de operaciones que se pausa para una firma antes de un cambio en producción."
          ],
          "faqs": [
            {
              "q": "¿Cuándo usar human-in-the-loop?",
              "a": "Para acciones de alto impacto, irreversibles, sensibles o reguladas, donde el coste de un error supera a la latencia de la revisión."
            },
            {
              "q": "¿Cuál es la diferencia entre in-the-loop y on-the-loop?",
              "a": "In-the-loop significa que un humano aprueba cada acción antes de ejecutarse; on-the-loop significa que un humano monitoriza y puede intervenir, pero el sistema actúa por su cuenta por defecto."
            },
            {
              "q": "¿HITL choca con la autonomía?",
              "a": "La acota de forma deliberada. Muchos sistemas empiezan con revisión fuerte y amplían la autonomía a medida que la evaluación demuestra fiabilidad en una tarea."
            },
            {
              "q": "¿Lo exige la regulación?",
              "a": "La supervisión humana es un requisito recurrente; por ejemplo, el Reglamento de IA de la UE exige una supervisión humana efectiva para los sistemas de IA de alto riesgo."
            }
          ]
        },
        "pt": {
          "title": "O que é o Padrão Human-in-the-Loop?",
          "summary": "Human-in-the-loop (HITL) é um padrão de design em que uma pessoa revisa, aprova ou corrige a saída de um sistema de IA antes de surtir efeito, sobretudo em ações de alto impacto. Em vez de autonomia total, o agente propõe e um humano dispõe. É um controle primário para gerir o risco em sistemas agênticos e um requisito recorrente em marcos de governança como o Regulamento de IA da UE e o NIST AI RMF.",
          "definition": "Human-in-the-loop é um padrão em que um humano revisa, aprova, edita ou rejeita a saída ou ação proposta por um sistema de IA antes de ser executada, inserindo o julgamento humano em pontos de decisão definidos.",
          "takeaways": [
            "O agente propõe; um humano aprova, edita ou rejeita.",
            "Aplique-o a ações de alto impacto, irreversíveis ou sensíveis.",
            "Troca alguma autonomia e velocidade por controle e confiança.",
            "Os marcos de governança costumam exigir supervisão humana por design.",
            "As aprovações e anulações devem ser registradas para a auditabilidade."
          ],
          "context": [
            "A autonomia total é arriscada quando as ações são custosas, irreversíveis ou reguladas. O HITL insere um ponto de controle: a IA faz o trabalho e um humano toma a decisão final, capturando quase toda a eficiência enquanto a responsabilidade fica com uma pessoa.",
            "É também uma estratégia de confiança e adoção. As equipes costumam começar com revisão humana estrita e depois ampliar a autonomia conforme a avaliação mostra que o sistema é confiável para uma dada tarefa."
          ],
          "architecture": [
            "Padrões: human-in-the-loop (uma pessoa aprova cada ação de alto impacto), human-on-the-loop (uma pessoa monitora e pode intervir) e human-over-the-loop (revisão periódica e definição de políticas). O nível adequado depende do risco da ação.",
            "A implementação precisa de uma interface de aprovação, contexto claro para o revisor, capacidade de editar ou rejeitar, comportamento de fallback em timeout, e registro de cada decisão para auditoria."
          ],
          "components": [
            "Pontos de decisão",
            "Interface de aprovação",
            "Contexto para o revisor",
            "Edição / anulação",
            "Escalonamento e fallback",
            "Registro de auditoria"
          ],
          "pros": [
            "Detecta erros antes que causem dano.",
            "Mantém a responsabilidade com um humano.",
            "Apoia requisitos de conformidade e governança.",
            "Gera confiança e habilita uma autonomia gradual."
          ],
          "risks": [
            "Adiciona latência e limita a vazão.",
            "Aprovação automática: revisores que aprovam sem escrutínio real.",
            "A fadiga de alertas degrada a qualidade da supervisão.",
            "Aplicá-lo em excesso anula o valor da automação."
          ],
          "tools": [
            "Sistemas de aprovação / workflow",
            "Frameworks de agentes com passos de interrupção (ex.: LangGraph)",
            "Registro de auditoria",
            "Interfaces de gestão de casos"
          ],
          "examples": [
            "Um agente que redige um reembolso que um humano aprova antes de ser emitido.",
            "Um agente de conteúdo cuja saída uma pessoa revisa antes de publicar.",
            "Um agente de operações que pausa para uma assinatura antes de uma mudança em produção."
          ],
          "faqs": [
            {
              "q": "Quando usar human-in-the-loop?",
              "a": "Para ações de alto impacto, irreversíveis, sensíveis ou reguladas, em que o custo de um erro supera a latência da revisão."
            },
            {
              "q": "Qual a diferença entre in-the-loop e on-the-loop?",
              "a": "In-the-loop significa que um humano aprova cada ação antes de executar; on-the-loop significa que um humano monitora e pode intervir, mas o sistema age por conta própria por padrão."
            },
            {
              "q": "O HITL conflita com a autonomia?",
              "a": "Limita-a de forma deliberada. Muitos sistemas começam com revisão forte e ampliam a autonomia conforme a avaliação demonstra confiabilidade numa tarefa."
            },
            {
              "q": "É exigido por regulação?",
              "a": "A supervisão humana é um requisito recorrente; por exemplo, o Regulamento de IA da UE exige supervisão humana efetiva para sistemas de IA de alto risco."
            }
          ]
        }
      }
    },
    {
      "slug": "model-context-protocol",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/model-context-protocol",
      "api": "https://santismm.com/api/knowledge/model-context-protocol",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "Model Context Protocol — Official site & specification",
          "url": "https://modelcontextprotocol.io"
        },
        {
          "title": "Anthropic — Introducing the Model Context Protocol (2024)",
          "url": "https://www.anthropic.com/news/model-context-protocol"
        }
      ],
      "related": [
        "ai-agent",
        "agentic-ai",
        "enterprise-rag",
        "harness-engineering"
      ],
      "locales": {
        "en": {
          "title": "What is the Model Context Protocol (MCP)?",
          "summary": "The Model Context Protocol (MCP) is an open standard for connecting AI models and agents to external tools, data sources and systems through a single, uniform interface. Introduced by Anthropic in late 2024, it standardizes how an application exposes context and capabilities to a model — acting like a universal adapter so any compliant client can talk to any compliant server.",
          "definition": "MCP is an open protocol that standardizes how AI applications provide tools, resources and context to models through a common client–server interface.",
          "takeaways": [
            "MCP standardizes model-to-tool/data connections, like a universal adapter.",
            "It uses a client–server model: hosts run clients; integrations are servers.",
            "Servers expose tools, resources and prompts in a uniform shape.",
            "It reduces N×M custom integrations to reusable, shareable connectors.",
            "It is open and vendor-neutral, with growing multi-vendor adoption."
          ],
          "context": [
            "Before MCP, every agent-to-system integration was bespoke: each tool wired by hand to each application. MCP replaces that with a shared protocol, so a connector written once can be reused across any MCP-aware client.",
            "This matters for enterprises because integration — not model quality — is often the real bottleneck in shipping agents. A common protocol turns connectors into a reusable ecosystem rather than one-off glue code."
          ],
          "architecture": [
            "MCP defines three roles: a host application, an MCP client inside it, and one or more MCP servers. The client connects to servers over a transport, and servers expose capabilities the model can use.",
            "Servers offer three primitives: tools (actions the model can invoke), resources (data the model can read), and prompts (reusable templates). The model, via the host, discovers and uses these in a standard way."
          ],
          "components": [
            "Host application",
            "MCP client",
            "MCP server",
            "Tools",
            "Resources",
            "Prompts",
            "Transport"
          ],
          "pros": [
            "Eliminates bespoke N×M integrations.",
            "Connectors are reusable and shareable across clients.",
            "Open and vendor-neutral.",
            "Cleaner separation between agent logic and integrations."
          ],
          "risks": [
            "Server access expands the attack surface; permissions matter.",
            "Untrusted servers can attempt prompt injection or data exfiltration.",
            "A young standard, still evolving.",
            "Operational overhead of running and securing servers."
          ],
          "tools": [
            "MCP reference SDKs",
            "Claude Desktop / Code",
            "IDE MCP clients",
            "Community MCP server registries"
          ],
          "examples": [
            "An MCP server exposing a company knowledge base as readable resources to an agent.",
            "A filesystem or database MCP server giving an agent scoped, permissioned access.",
            "A shared connector for a SaaS API reused across several internal agents."
          ],
          "faqs": [
            {
              "q": "Who created MCP?",
              "a": "Anthropic introduced MCP as an open standard in late 2024, and it has since seen adoption across multiple vendors and tools."
            },
            {
              "q": "Is MCP the same as function calling?",
              "a": "No. Function calling lets a model invoke tools; MCP standardizes how those tools, data and prompts are exposed and discovered across applications."
            },
            {
              "q": "Why does MCP matter for the enterprise?",
              "a": "Integration is usually the bottleneck for agents. MCP turns one-off connectors into a reusable, governable ecosystem."
            },
            {
              "q": "What are the security considerations?",
              "a": "Each server is an access point. Apply least-privilege permissions, vet servers, and treat their outputs as untrusted input subject to prompt-injection risk."
            }
          ]
        },
        "es": {
          "title": "¿Qué es el Model Context Protocol (MCP)?",
          "summary": "El Model Context Protocol (MCP) es un estándar abierto para conectar modelos y agentes de IA con herramientas, fuentes de datos y sistemas externos a través de una interfaz única y uniforme. Presentado por Anthropic a finales de 2024, estandariza cómo una aplicación expone contexto y capacidades a un modelo, actuando como un adaptador universal para que cualquier cliente compatible hable con cualquier servidor compatible.",
          "definition": "MCP es un protocolo abierto que estandariza cómo las aplicaciones de IA proporcionan herramientas, recursos y contexto a los modelos mediante una interfaz cliente–servidor común.",
          "takeaways": [
            "MCP estandariza la conexión modelo-herramienta/datos, como un adaptador universal.",
            "Usa un modelo cliente–servidor: los hosts ejecutan clientes; las integraciones son servidores.",
            "Los servidores exponen herramientas, recursos y prompts con una forma uniforme.",
            "Reduce las integraciones a medida N×M a conectores reutilizables y compartibles.",
            "Es abierto y neutral respecto al proveedor, con adopción multifabricante creciente."
          ],
          "context": [
            "Antes de MCP, cada integración agente-sistema era a medida: cada herramienta cableada a mano a cada aplicación. MCP la sustituye por un protocolo compartido, de modo que un conector escrito una vez se reutiliza en cualquier cliente compatible.",
            "Importa para las empresas porque el cuello de botella real al desplegar agentes suele ser la integración, no la calidad del modelo. Un protocolo común convierte los conectores en un ecosistema reutilizable en vez de pegamento de un solo uso."
          ],
          "architecture": [
            "MCP define tres roles: una aplicación host, un cliente MCP dentro de ella y uno o varios servidores MCP. El cliente se conecta a los servidores por un transporte, y los servidores exponen capacidades que el modelo puede usar.",
            "Los servidores ofrecen tres primitivas: herramientas (acciones que el modelo puede invocar), recursos (datos que el modelo puede leer) y prompts (plantillas reutilizables). El modelo, vía el host, las descubre y usa de forma estándar."
          ],
          "components": [
            "Aplicación host",
            "Cliente MCP",
            "Servidor MCP",
            "Herramientas",
            "Recursos",
            "Prompts",
            "Transporte"
          ],
          "pros": [
            "Elimina las integraciones a medida N×M.",
            "Los conectores son reutilizables y compartibles entre clientes.",
            "Abierto y neutral respecto al proveedor.",
            "Separación más limpia entre la lógica del agente y las integraciones."
          ],
          "risks": [
            "El acceso de los servidores amplía la superficie de ataque; los permisos importan.",
            "Servidores no confiables pueden intentar inyección de prompts o exfiltración de datos.",
            "Es un estándar joven, todavía en evolución.",
            "Coste operativo de ejecutar y asegurar servidores."
          ],
          "tools": [
            "SDKs de referencia de MCP",
            "Claude Desktop / Code",
            "Clientes MCP en IDEs",
            "Registros comunitarios de servidores MCP"
          ],
          "examples": [
            "Un servidor MCP que expone la base de conocimiento de la empresa como recursos legibles para un agente.",
            "Un servidor MCP de sistema de ficheros o base de datos que da a un agente acceso acotado y con permisos.",
            "Un conector compartido para una API SaaS reutilizado en varios agentes internos."
          ],
          "faqs": [
            {
              "q": "¿Quién creó MCP?",
              "a": "Anthropic presentó MCP como estándar abierto a finales de 2024, y desde entonces ha tenido adopción en varios fabricantes y herramientas."
            },
            {
              "q": "¿MCP es lo mismo que function calling?",
              "a": "No. El function calling permite a un modelo invocar herramientas; MCP estandariza cómo se exponen y descubren esas herramientas, datos y prompts entre aplicaciones."
            },
            {
              "q": "¿Por qué importa MCP en la empresa?",
              "a": "La integración suele ser el cuello de botella de los agentes. MCP convierte los conectores de un solo uso en un ecosistema reutilizable y gobernable."
            },
            {
              "q": "¿Qué consideraciones de seguridad tiene?",
              "a": "Cada servidor es un punto de acceso. Aplica permisos de mínimo privilegio, valida los servidores y trata sus salidas como entrada no confiable sujeta a inyección de prompts."
            }
          ]
        },
        "pt": {
          "title": "O que é o Model Context Protocol (MCP)?",
          "summary": "O Model Context Protocol (MCP) é um padrão aberto para conectar modelos e agentes de IA a ferramentas, fontes de dados e sistemas externos por meio de uma interface única e uniforme. Apresentado pela Anthropic no fim de 2024, padroniza como uma aplicação expõe contexto e capacidades a um modelo, atuando como um adaptador universal para que qualquer cliente compatível converse com qualquer servidor compatível.",
          "definition": "MCP é um protocolo aberto que padroniza como as aplicações de IA fornecem ferramentas, recursos e contexto aos modelos por meio de uma interface cliente–servidor comum.",
          "takeaways": [
            "MCP padroniza a conexão modelo-ferramenta/dados, como um adaptador universal.",
            "Usa um modelo cliente–servidor: os hosts executam clientes; as integrações são servidores.",
            "Os servidores expõem ferramentas, recursos e prompts numa forma uniforme.",
            "Reduz as integrações sob medida N×M a conectores reutilizáveis e compartilháveis.",
            "É aberto e neutro quanto ao fornecedor, com adoção multifabricante crescente."
          ],
          "context": [
            "Antes do MCP, cada integração agente-sistema era sob medida: cada ferramenta ligada à mão a cada aplicação. O MCP a substitui por um protocolo compartilhado, de modo que um conector escrito uma vez é reutilizado em qualquer cliente compatível.",
            "Importa para as empresas porque o gargalo real ao implantar agentes costuma ser a integração, não a qualidade do modelo. Um protocolo comum transforma os conectores num ecossistema reutilizável em vez de cola de uso único."
          ],
          "architecture": [
            "O MCP define três papéis: uma aplicação host, um cliente MCP dentro dela e um ou mais servidores MCP. O cliente se conecta aos servidores por um transporte, e os servidores expõem capacidades que o modelo pode usar.",
            "Os servidores oferecem três primitivas: ferramentas (ações que o modelo pode invocar), recursos (dados que o modelo pode ler) e prompts (modelos reutilizáveis). O modelo, via host, os descobre e usa de forma padronizada."
          ],
          "components": [
            "Aplicação host",
            "Cliente MCP",
            "Servidor MCP",
            "Ferramentas",
            "Recursos",
            "Prompts",
            "Transporte"
          ],
          "pros": [
            "Elimina as integrações sob medida N×M.",
            "Os conectores são reutilizáveis e compartilháveis entre clientes.",
            "Aberto e neutro quanto ao fornecedor.",
            "Separação mais limpa entre a lógica do agente e as integrações."
          ],
          "risks": [
            "O acesso dos servidores amplia a superfície de ataque; as permissões importam.",
            "Servidores não confiáveis podem tentar injeção de prompts ou exfiltração de dados.",
            "É um padrão jovem, ainda em evolução.",
            "Custo operacional de executar e proteger servidores."
          ],
          "tools": [
            "SDKs de referência do MCP",
            "Claude Desktop / Code",
            "Clientes MCP em IDEs",
            "Registros comunitários de servidores MCP"
          ],
          "examples": [
            "Um servidor MCP que expõe a base de conhecimento da empresa como recursos legíveis para um agente.",
            "Um servidor MCP de sistema de arquivos ou banco de dados que dá a um agente acesso restrito e com permissões.",
            "Um conector compartilhado para uma API SaaS reutilizado em vários agentes internos."
          ],
          "faqs": [
            {
              "q": "Quem criou o MCP?",
              "a": "A Anthropic apresentou o MCP como padrão aberto no fim de 2024, e desde então teve adoção em vários fabricantes e ferramentas."
            },
            {
              "q": "MCP é o mesmo que function calling?",
              "a": "Não. O function calling permite a um modelo invocar ferramentas; o MCP padroniza como essas ferramentas, dados e prompts são expostos e descobertos entre aplicações."
            },
            {
              "q": "Por que o MCP importa na empresa?",
              "a": "A integração costuma ser o gargalo dos agentes. O MCP transforma os conectores de uso único num ecossistema reutilizável e governável."
            },
            {
              "q": "Quais as considerações de segurança?",
              "a": "Cada servidor é um ponto de acesso. Aplique permissões de privilégio mínimo, valide os servidores e trate suas saídas como entrada não confiável sujeita a injeção de prompts."
            }
          ]
        }
      }
    },
    {
      "slug": "multi-agent-architecture",
      "category": "architecture",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/multi-agent-architecture",
      "api": "https://santismm.com/api/knowledge/multi-agent-architecture",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Anthropic — Building Effective Agents (2024)",
          "url": "https://www.anthropic.com/research/building-effective-agents"
        },
        {
          "title": "Yao et al. — ReAct (2022)",
          "url": "https://arxiv.org/abs/2210.03629"
        }
      ],
      "related": [
        "agentic-ai",
        "ai-agent",
        "harness-engineering",
        "model-context-protocol"
      ],
      "locales": {
        "en": {
          "title": "What is a Multi-Agent Architecture?",
          "summary": "A multi-agent architecture divides a task among several specialized agents that collaborate, delegate or compete to reach a goal, instead of relying on one general agent. Common shapes include an orchestrator that delegates to workers, pipelines where each agent owns a stage, and debate or critic patterns. It can improve modularity and reliability for complex tasks, but adds coordination overhead and should be adopted only when a single agent demonstrably falls short.",
          "definition": "A multi-agent architecture is a system design in which multiple specialized AI agents coordinate — through an orchestrator, a pipeline or peer interaction — to accomplish a task that is decomposed across them.",
          "takeaways": [
            "Several specialized agents beat one generalist for some complex tasks.",
            "Common patterns: orchestrator-workers, pipelines, debate/critic.",
            "Specialization improves modularity and focus per role.",
            "Coordination, latency and cost overhead are the main costs.",
            "Default to a single agent; go multi-agent only when measurement justifies it."
          ],
          "context": [
            "As tasks grow, a single agent's context and reasoning get stretched. Splitting the work into focused roles — researcher, writer, reviewer; or planner and executors — can make each part more reliable and easier to evaluate.",
            "But multi-agent is not automatically better. Every added agent adds communication, failure modes and cost. The discipline is to decompose only where roles are genuinely separable and a single agent measurably underperforms."
          ],
          "architecture": [
            "Orchestrator-workers: a lead agent plans and delegates subtasks to worker agents, then synthesizes results. Pipeline: agents are arranged in stages, each transforming the output of the previous. Peer patterns: agents debate, critique or vote to improve quality.",
            "Cross-cutting concerns — shared memory, message passing, error handling, budgets and observability — are where most multi-agent systems succeed or fail. Clear contracts between agents matter more than clever role names."
          ],
          "components": [
            "Orchestrator / lead agent",
            "Worker / specialist agents",
            "Shared memory & state",
            "Message passing",
            "Tools (often via MCP)",
            "Guardrails & budgets",
            "Observability"
          ],
          "pros": [
            "Modular, specialized roles that are easier to evaluate.",
            "Parallelism for independent subtasks.",
            "Separation of concerns across complex workflows.",
            "Critic/debate patterns can raise output quality."
          ],
          "risks": [
            "Coordination overhead and added latency.",
            "More failure modes and harder debugging.",
            "Higher token cost from inter-agent communication.",
            "Premature complexity when one agent would suffice."
          ],
          "tools": [
            "LangGraph",
            "CrewAI",
            "AutoGen",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "An orchestrator delegating research, drafting and review to specialist agents.",
            "A pipeline that extracts, transforms and validates data across stages.",
            "A critic agent reviewing another agent's output before it is finalized."
          ],
          "faqs": [
            {
              "q": "Is multi-agent always better than a single agent?",
              "a": "No. It adds coordination, cost and failure modes. Prefer a single agent and adopt multi-agent only when a task is clearly separable and a single agent underperforms."
            },
            {
              "q": "What is the orchestrator-workers pattern?",
              "a": "A lead agent plans a task, delegates subtasks to specialized worker agents, and synthesizes their results into a final answer."
            },
            {
              "q": "How do multi-agent systems fail?",
              "a": "Through unclear contracts between agents, lost context, runaway loops, and compounding errors — which is why budgets and observability are essential."
            },
            {
              "q": "How does MCP relate to multi-agent systems?",
              "a": "MCP standardizes how each agent connects to tools and data, making integrations reusable across the agents in the system."
            }
          ]
        },
        "es": {
          "title": "¿Qué es una Arquitectura Multiagente?",
          "summary": "Una arquitectura multiagente divide una tarea entre varios agentes especializados que colaboran, delegan o compiten para alcanzar un objetivo, en lugar de depender de un único agente general. Formas habituales: un orquestador que delega en trabajadores, pipelines donde cada agente posee una etapa, y patrones de debate o crítico. Puede mejorar la modularidad y la fiabilidad en tareas complejas, pero añade coste de coordinación y solo debe adoptarse cuando un solo agente se queda corto de forma demostrable.",
          "definition": "Una arquitectura multiagente es un diseño de sistema en el que varios agentes de IA especializados se coordinan —mediante un orquestador, un pipeline o interacción entre pares— para realizar una tarea descompuesta entre ellos.",
          "takeaways": [
            "Varios agentes especializados superan a uno generalista en ciertas tareas complejas.",
            "Patrones habituales: orquestador-trabajadores, pipelines, debate/crítico.",
            "La especialización mejora la modularidad y el foco por rol.",
            "El coste principal es la coordinación, la latencia y el gasto.",
            "Por defecto, un solo agente; ir a multiagente solo cuando la medición lo justifique."
          ],
          "context": [
            "A medida que crecen las tareas, el contexto y el razonamiento de un solo agente se tensan. Dividir el trabajo en roles enfocados —investigador, redactor, revisor; o planificador y ejecutores— puede hacer cada parte más fiable y fácil de evaluar.",
            "Pero multiagente no es automáticamente mejor. Cada agente añadido suma comunicación, modos de fallo y coste. La disciplina es descomponer solo donde los roles sean realmente separables y un solo agente rinda peor de forma medible."
          ],
          "architecture": [
            "Orquestador-trabajadores: un agente líder planifica y delega subtareas a agentes trabajadores, y luego sintetiza los resultados. Pipeline: los agentes se disponen en etapas, cada una transformando la salida de la anterior. Patrones entre pares: los agentes debaten, critican o votan para mejorar la calidad.",
            "Las preocupaciones transversales —memoria compartida, paso de mensajes, gestión de errores, presupuestos y observabilidad— son donde la mayoría de sistemas multiagente triunfan o fracasan. Los contratos claros entre agentes importan más que los nombres ingeniosos de roles."
          ],
          "components": [
            "Orquestador / agente líder",
            "Agentes trabajadores / especialistas",
            "Memoria y estado compartidos",
            "Paso de mensajes",
            "Herramientas (a menudo vía MCP)",
            "Guardarraíles y presupuestos",
            "Observabilidad"
          ],
          "pros": [
            "Roles modulares y especializados, más fáciles de evaluar.",
            "Paralelismo para subtareas independientes.",
            "Separación de responsabilidades en flujos complejos.",
            "Los patrones de crítico/debate pueden elevar la calidad."
          ],
          "risks": [
            "Coste de coordinación y latencia añadida.",
            "Más modos de fallo y depuración más difícil.",
            "Mayor coste de tokens por la comunicación entre agentes.",
            "Complejidad prematura cuando bastaría un agente."
          ],
          "tools": [
            "LangGraph",
            "CrewAI",
            "AutoGen",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "Un orquestador que delega investigación, redacción y revisión a agentes especialistas.",
            "Un pipeline que extrae, transforma y valida datos por etapas.",
            "Un agente crítico que revisa la salida de otro agente antes de finalizarla."
          ],
          "faqs": [
            {
              "q": "¿Multiagente es siempre mejor que un solo agente?",
              "a": "No. Añade coordinación, coste y modos de fallo. Prefiere un solo agente y adopta multiagente solo cuando la tarea sea claramente separable y un agente rinda peor."
            },
            {
              "q": "¿Qué es el patrón orquestador-trabajadores?",
              "a": "Un agente líder planifica una tarea, delega subtareas a agentes trabajadores especializados y sintetiza sus resultados en una respuesta final."
            },
            {
              "q": "¿Cómo fallan los sistemas multiagente?",
              "a": "Por contratos poco claros entre agentes, pérdida de contexto, bucles descontrolados y acumulación de errores; por eso presupuestos y observabilidad son esenciales."
            },
            {
              "q": "¿Cómo se relaciona MCP con los sistemas multiagente?",
              "a": "MCP estandariza cómo cada agente se conecta a herramientas y datos, haciendo las integraciones reutilizables entre los agentes del sistema."
            }
          ]
        },
        "pt": {
          "title": "O que é uma Arquitetura Multiagente?",
          "summary": "Uma arquitetura multiagente divide uma tarefa entre vários agentes especializados que colaboram, delegam ou competem para alcançar um objetivo, em vez de depender de um único agente geral. Formas comuns: um orquestrador que delega a trabalhadores, pipelines em que cada agente possui uma etapa, e padrões de debate ou crítico. Pode melhorar a modularidade e a confiabilidade em tarefas complexas, mas adiciona custo de coordenação e só deve ser adotada quando um único agente fica aquém de forma demonstrável.",
          "definition": "Uma arquitetura multiagente é um design de sistema em que vários agentes de IA especializados se coordenam — por um orquestrador, um pipeline ou interação entre pares — para realizar uma tarefa decomposta entre eles.",
          "takeaways": [
            "Vários agentes especializados superam um generalista em certas tarefas complexas.",
            "Padrões comuns: orquestrador-trabalhadores, pipelines, debate/crítico.",
            "A especialização melhora a modularidade e o foco por papel.",
            "O custo principal é a coordenação, a latência e o gasto.",
            "Por padrão, um único agente; ir para multiagente só quando a medição justificar."
          ],
          "context": [
            "À medida que as tarefas crescem, o contexto e o raciocínio de um único agente se esticam. Dividir o trabalho em papéis focados — pesquisador, redator, revisor; ou planejador e executores — pode tornar cada parte mais confiável e fácil de avaliar.",
            "Mas multiagente não é automaticamente melhor. Cada agente adicionado soma comunicação, modos de falha e custo. A disciplina é decompor só onde os papéis sejam realmente separáveis e um único agente tenha desempenho mensuravelmente pior."
          ],
          "architecture": [
            "Orquestrador-trabalhadores: um agente líder planeja e delega subtarefas a agentes trabalhadores, e depois sintetiza os resultados. Pipeline: os agentes são dispostos em etapas, cada uma transformando a saída da anterior. Padrões entre pares: os agentes debatem, criticam ou votam para melhorar a qualidade.",
            "As preocupações transversais — memória compartilhada, passagem de mensagens, tratamento de erros, orçamentos e observabilidade — são onde a maioria dos sistemas multiagente tem sucesso ou falha. Contratos claros entre agentes importam mais que nomes engenhosos de papéis."
          ],
          "components": [
            "Orquestrador / agente líder",
            "Agentes trabalhadores / especialistas",
            "Memória e estado compartilhados",
            "Passagem de mensagens",
            "Ferramentas (muitas vezes via MCP)",
            "Guard-rails e orçamentos",
            "Observabilidade"
          ],
          "pros": [
            "Papéis modulares e especializados, mais fáceis de avaliar.",
            "Paralelismo para subtarefas independentes.",
            "Separação de responsabilidades em fluxos complexos.",
            "Padrões de crítico/debate podem elevar a qualidade."
          ],
          "risks": [
            "Custo de coordenação e latência adicional.",
            "Mais modos de falha e depuração mais difícil.",
            "Maior custo de tokens pela comunicação entre agentes.",
            "Complexidade prematura quando bastaria um agente."
          ],
          "tools": [
            "LangGraph",
            "CrewAI",
            "AutoGen",
            "OpenAI Agents SDK",
            "Model Context Protocol (MCP)"
          ],
          "examples": [
            "Um orquestrador que delega pesquisa, redação e revisão a agentes especialistas.",
            "Um pipeline que extrai, transforma e valida dados por etapas.",
            "Um agente crítico que revisa a saída de outro agente antes de finalizá-la."
          ],
          "faqs": [
            {
              "q": "Multiagente é sempre melhor que um único agente?",
              "a": "Não. Adiciona coordenação, custo e modos de falha. Prefira um único agente e adote multiagente só quando a tarefa for claramente separável e um agente tiver desempenho pior."
            },
            {
              "q": "O que é o padrão orquestrador-trabalhadores?",
              "a": "Um agente líder planeja uma tarefa, delega subtarefas a agentes trabalhadores especializados e sintetiza seus resultados numa resposta final."
            },
            {
              "q": "Como os sistemas multiagente falham?",
              "a": "Por contratos pouco claros entre agentes, perda de contexto, laços descontrolados e acúmulo de erros; por isso orçamentos e observabilidade são essenciais."
            },
            {
              "q": "Como o MCP se relaciona com sistemas multiagente?",
              "a": "O MCP padroniza como cada agente se conecta a ferramentas e dados, tornando as integrações reutilizáveis entre os agentes do sistema."
            }
          ]
        }
      }
    },
    {
      "slug": "prompt-engineering",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/prompt-engineering",
      "api": "https://santismm.com/api/knowledge/prompt-engineering",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper",
          "industry_observation"
        ]
      },
      "references": [
        {
          "title": "Wei et al. — Chain-of-Thought Prompting Elicits Reasoning in LLMs (2022)",
          "url": "https://arxiv.org/abs/2201.11903"
        },
        {
          "title": "Anthropic — Prompt engineering overview",
          "url": "https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview"
        }
      ],
      "related": [
        "context-engineering",
        "tool-use",
        "agentic-ai",
        "harness-engineering"
      ],
      "locales": {
        "en": {
          "title": "What is Prompt Engineering?",
          "summary": "Prompt engineering is the practice of designing the inputs given to a language model so it produces the desired output reliably. A good prompt specifies the role, the task, the constraints, the output format and, when useful, examples. It is the most accessible lever for steering model behavior — and one layer of the broader harness around a model — but on its own it does not make a system reliable at scale.",
          "definition": "Prompt engineering is the practice of designing and refining the instructions, context and examples given to a language model to reliably elicit a desired output.",
          "takeaways": [
            "A strong prompt states role, task, constraints, format and examples.",
            "Examples (few-shot) usually beat instructions alone for structured tasks.",
            "Chain-of-thought prompting improves multi-step reasoning.",
            "Prompts should be tested and versioned, not hand-tuned by feel.",
            "It is one layer of the harness, not a substitute for tools, memory and evaluation."
          ],
          "context": [
            "Because models follow instructions in natural language, the way a task is phrased materially changes the result. Prompt engineering is the discipline of phrasing it well: being explicit about the goal, the audience, the constraints and the format you want back.",
            "It is the fastest, cheapest way to improve output quality, which is why it is where most teams start. But as systems grow into agents, prompting becomes one component among tools, memory, retrieval and evaluation — the full harness."
          ],
          "architecture": [
            "Common techniques: zero-shot (instruction only), few-shot (instruction plus examples), chain-of-thought (ask for step-by-step reasoning), role and format specification, and decomposition (breaking a task into smaller prompts).",
            "Mature practice treats prompts as code: stored, versioned, tested against evals, and changed deliberately. Reusable prompt templates and structured output schemas reduce variance."
          ],
          "components": [
            "Role / persona",
            "Task instruction",
            "Constraints",
            "Output format",
            "Examples (few-shot)",
            "Reasoning cues"
          ],
          "pros": [
            "Fastest, cheapest way to change model behavior.",
            "No training or infrastructure required.",
            "Works across models and tasks.",
            "Easy to iterate and combine with other techniques."
          ],
          "risks": [
            "Fragile: small wording changes can shift behavior.",
            "Prompt injection when prompts include untrusted input.",
            "Hard to scale reliability by prompting alone.",
            "Hidden coupling to a specific model's quirks."
          ],
          "tools": [
            "Prompt templates",
            "Structured output / JSON schema",
            "LangSmith / Langfuse (prompt testing)",
            "Evaluation suites"
          ],
          "examples": [
            "Adding a few worked examples to make a model output consistent JSON.",
            "Asking for step-by-step reasoning to improve a math or logic answer.",
            "Specifying a strict format so downstream code can parse the response."
          ],
          "faqs": [
            {
              "q": "Is prompt engineering still relevant as models improve?",
              "a": "Yes, but its role narrows. Better models need less coaxing, yet clear instructions, examples and format specs still measurably improve reliability — especially inside agents."
            },
            {
              "q": "What is the difference from context engineering?",
              "a": "Prompt engineering focuses on the instruction. Context engineering is the broader task of deciding what information enters the model's limited context window at each step."
            },
            {
              "q": "Does chain-of-thought always help?",
              "a": "It helps most on multi-step reasoning tasks, at the cost of more tokens. For simple lookups it adds latency without benefit."
            },
            {
              "q": "How do you keep prompts reliable?",
              "a": "Treat them as code: version them, test them against evals, and change them deliberately rather than by trial and error."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Ingeniería de Prompts (Prompt Engineering)?",
          "summary": "La ingeniería de prompts es la práctica de diseñar las entradas que se dan a un modelo de lenguaje para que produzca la salida deseada de forma fiable. Un buen prompt especifica el rol, la tarea, las restricciones, el formato de salida y, cuando conviene, ejemplos. Es la palanca más accesible para guiar el comportamiento del modelo —y una capa del harness más amplio— pero por sí sola no hace fiable a un sistema a escala.",
          "definition": "La ingeniería de prompts es la práctica de diseñar y refinar las instrucciones, el contexto y los ejemplos que se dan a un modelo de lenguaje para obtener de forma fiable la salida deseada.",
          "takeaways": [
            "Un buen prompt indica rol, tarea, restricciones, formato y ejemplos.",
            "Los ejemplos (few-shot) suelen superar a las instrucciones solas en tareas estructuradas.",
            "El chain-of-thought mejora el razonamiento de varios pasos.",
            "Los prompts deben probarse y versionarse, no ajustarse a ojo.",
            "Es una capa del harness, no un sustituto de herramientas, memoria y evaluación."
          ],
          "context": [
            "Como los modelos siguen instrucciones en lenguaje natural, la forma de plantear una tarea cambia materialmente el resultado. La ingeniería de prompts es la disciplina de plantearla bien: ser explícito sobre el objetivo, la audiencia, las restricciones y el formato que quieres recibir.",
            "Es la forma más rápida y barata de mejorar la calidad, por eso es donde empiezan la mayoría de equipos. Pero al crecer hacia agentes, el prompting pasa a ser un componente entre herramientas, memoria, recuperación y evaluación: el harness completo."
          ],
          "architecture": [
            "Técnicas habituales: zero-shot (solo instrucción), few-shot (instrucción más ejemplos), chain-of-thought (pedir razonamiento paso a paso), especificación de rol y formato, y descomposición (dividir una tarea en prompts más pequeños).",
            "La práctica madura trata los prompts como código: se guardan, se versionan, se prueban contra evaluaciones y se cambian de forma deliberada. Las plantillas reutilizables y los esquemas de salida estructurada reducen la varianza."
          ],
          "components": [
            "Rol / persona",
            "Instrucción de tarea",
            "Restricciones",
            "Formato de salida",
            "Ejemplos (few-shot)",
            "Pistas de razonamiento"
          ],
          "pros": [
            "La forma más rápida y barata de cambiar el comportamiento del modelo.",
            "No requiere entrenamiento ni infraestructura.",
            "Funciona entre modelos y tareas.",
            "Fácil de iterar y combinar con otras técnicas."
          ],
          "risks": [
            "Frágil: pequeños cambios de redacción alteran el comportamiento.",
            "Inyección de prompts cuando incluyen entrada no confiable.",
            "Difícil escalar la fiabilidad solo con prompting.",
            "Acoplamiento oculto a las peculiaridades de un modelo."
          ],
          "tools": [
            "Plantillas de prompts",
            "Salida estructurada / JSON schema",
            "LangSmith / Langfuse (pruebas de prompts)",
            "Suites de evaluación"
          ],
          "examples": [
            "Añadir ejemplos para que un modelo devuelva JSON consistente.",
            "Pedir razonamiento paso a paso para mejorar una respuesta de lógica o matemáticas.",
            "Especificar un formato estricto para que el código posterior pueda parsear la respuesta."
          ],
          "faqs": [
            {
              "q": "¿Sigue siendo relevante el prompt engineering según mejoran los modelos?",
              "a": "Sí, pero su papel se estrecha. Los mejores modelos necesitan menos persuasión, pero instrucciones claras, ejemplos y formato siguen mejorando la fiabilidad de forma medible, sobre todo dentro de agentes."
            },
            {
              "q": "¿En qué se diferencia de la ingeniería de contexto?",
              "a": "El prompt engineering se centra en la instrucción. La ingeniería de contexto es la tarea más amplia de decidir qué información entra en la ventana de contexto limitada del modelo en cada paso."
            },
            {
              "q": "¿El chain-of-thought ayuda siempre?",
              "a": "Ayuda sobre todo en tareas de razonamiento de varios pasos, a costa de más tokens. Para búsquedas simples añade latencia sin beneficio."
            },
            {
              "q": "¿Cómo se mantienen fiables los prompts?",
              "a": "Tratándolos como código: versionarlos, probarlos contra evaluaciones y cambiarlos de forma deliberada en vez de por ensayo y error."
            }
          ]
        },
        "pt": {
          "title": "O que é Engenharia de Prompts (Prompt Engineering)?",
          "summary": "A engenharia de prompts é a prática de projetar as entradas dadas a um modelo de linguagem para que ele produza a saída desejada de forma confiável. Um bom prompt especifica o papel, a tarefa, as restrições, o formato de saída e, quando útil, exemplos. É a alavanca mais acessível para guiar o comportamento do modelo — e uma camada do harness mais amplo — mas sozinha não torna um sistema confiável em escala.",
          "definition": "A engenharia de prompts é a prática de projetar e refinar as instruções, o contexto e os exemplos dados a um modelo de linguagem para obter de forma confiável a saída desejada.",
          "takeaways": [
            "Um bom prompt indica papel, tarefa, restrições, formato e exemplos.",
            "Exemplos (few-shot) costumam superar instruções sozinhas em tarefas estruturadas.",
            "O chain-of-thought melhora o raciocínio de vários passos.",
            "Os prompts devem ser testados e versionados, não ajustados no olho.",
            "É uma camada do harness, não um substituto de ferramentas, memória e avaliação."
          ],
          "context": [
            "Como os modelos seguem instruções em linguagem natural, a forma de formular uma tarefa muda materialmente o resultado. A engenharia de prompts é a disciplina de formulá-la bem: ser explícito sobre o objetivo, o público, as restrições e o formato que você quer receber.",
            "É a forma mais rápida e barata de melhorar a qualidade, por isso é onde a maioria das equipes começa. Mas ao crescer rumo a agentes, o prompting passa a ser um componente entre ferramentas, memória, recuperação e avaliação: o harness completo."
          ],
          "architecture": [
            "Técnicas comuns: zero-shot (só instrução), few-shot (instrução mais exemplos), chain-of-thought (pedir raciocínio passo a passo), especificação de papel e formato, e decomposição (dividir uma tarefa em prompts menores).",
            "A prática madura trata os prompts como código: são guardados, versionados, testados contra avaliações e alterados de forma deliberada. Modelos reutilizáveis e esquemas de saída estruturada reduzem a variância."
          ],
          "components": [
            "Papel / persona",
            "Instrução de tarefa",
            "Restrições",
            "Formato de saída",
            "Exemplos (few-shot)",
            "Pistas de raciocínio"
          ],
          "pros": [
            "A forma mais rápida e barata de mudar o comportamento do modelo.",
            "Não requer treinamento nem infraestrutura.",
            "Funciona entre modelos e tarefas.",
            "Fácil de iterar e combinar com outras técnicas."
          ],
          "risks": [
            "Frágil: pequenas mudanças de redação alteram o comportamento.",
            "Injeção de prompts quando incluem entrada não confiável.",
            "Difícil escalar a confiabilidade só com prompting.",
            "Acoplamento oculto às peculiaridades de um modelo."
          ],
          "tools": [
            "Modelos de prompts",
            "Saída estruturada / JSON schema",
            "LangSmith / Langfuse (testes de prompts)",
            "Suítes de avaliação"
          ],
          "examples": [
            "Adicionar exemplos para um modelo devolver JSON consistente.",
            "Pedir raciocínio passo a passo para melhorar uma resposta de lógica ou matemática.",
            "Especificar um formato estrito para o código posterior poder parsear a resposta."
          ],
          "faqs": [
            {
              "q": "A engenharia de prompts ainda é relevante conforme os modelos melhoram?",
              "a": "Sim, mas seu papel se estreita. Modelos melhores precisam de menos persuasão, mas instruções claras, exemplos e formato continuam melhorando a confiabilidade de forma mensurável, sobretudo dentro de agentes."
            },
            {
              "q": "Qual a diferença para a engenharia de contexto?",
              "a": "A engenharia de prompts foca na instrução. A engenharia de contexto é a tarefa mais ampla de decidir qual informação entra na janela de contexto limitada do modelo a cada passo."
            },
            {
              "q": "O chain-of-thought sempre ajuda?",
              "a": "Ajuda sobretudo em tarefas de raciocínio de vários passos, ao custo de mais tokens. Para buscas simples adiciona latência sem benefício."
            },
            {
              "q": "Como manter os prompts confiáveis?",
              "a": "Tratando-os como código: versioná-los, testá-los contra avaliações e alterá-los de forma deliberada em vez de por tentativa e erro."
            }
          ]
        }
      }
    },
    {
      "slug": "prompt-injection",
      "category": "governance",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/prompt-injection",
      "api": "https://santismm.com/api/knowledge/prompt-injection",
      "evidence": {
        "evidenceLevel": "industry_observation",
        "confidenceLevel": "high",
        "sourceType": [
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "OWASP — Top 10 for LLM Applications (LLM01: Prompt Injection)",
          "url": "https://genai.owasp.org/llmrisk/llm01-prompt-injection/"
        },
        {
          "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
          "url": "https://www.nist.gov/itl/ai-risk-management-framework"
        }
      ],
      "related": [
        "guardrails",
        "tool-use",
        "ai-governance",
        "model-context-protocol"
      ],
      "locales": {
        "en": {
          "title": "What is Prompt Injection?",
          "summary": "Prompt injection is an attack in which malicious instructions hidden in the input to a language model hijack its behavior — making it ignore its rules, leak data or misuse tools. It tops the OWASP Top 10 for LLM applications. The root cause is that models cannot reliably separate trusted instructions from untrusted content, so any text an agent reads — a web page, a document, a tool result — can carry an attack.",
          "definition": "Prompt injection is a security attack where adversarial instructions embedded in untrusted input cause a language model to deviate from its intended behavior, bypass safeguards, or perform unintended actions.",
          "takeaways": [
            "Untrusted text a model reads can contain hidden instructions.",
            "It is the #1 risk in the OWASP Top 10 for LLM applications.",
            "Indirect injection hides payloads in documents, pages or tool outputs.",
            "Risk grows with tool access — injection can trigger real actions.",
            "There is no single fix; defense is layered (least privilege, isolation, human approval)."
          ],
          "context": [
            "Models follow instructions in natural language and cannot reliably tell trusted system instructions from untrusted user or document content. An attacker exploits this by planting instructions like 'ignore previous instructions and…' where the model will read them.",
            "Direct injection comes from the user; indirect (and more dangerous) injection hides in content the agent retrieves — a web page, an email, a file, an MCP tool result. As agents gain tool access, a successful injection can exfiltrate data or take harmful actions."
          ],
          "architecture": [
            "Defense is layered, not a single control: least-privilege tool permissions, isolating and clearly delimiting untrusted content, output and action validation, allow-lists for sensitive operations, and human-in-the-loop approval for high-impact actions.",
            "Treat all tool and retrieval outputs as untrusted input. Monitor and log agent actions (observability) so injection attempts are detectable, and red-team the system regularly."
          ],
          "components": [
            "Untrusted input boundary",
            "Least-privilege permissions",
            "Content isolation / delimiting",
            "Output & action validation",
            "Human approval for high-impact actions",
            "Monitoring & red teaming"
          ],
          "pros": [],
          "risks": [
            "Data exfiltration of sensitive context or credentials.",
            "Unauthorized tool actions in connected systems.",
            "Bypassed safety policies and guardrails.",
            "Indirect attacks via documents, web pages or tool results."
          ],
          "tools": [
            "Input/output guardrail libraries",
            "Permission & sandboxing layers",
            "Allow-lists for tool actions",
            "Monitoring / observability",
            "Red-teaming frameworks"
          ],
          "examples": [
            "A web page the agent reads contains hidden text telling it to email private data.",
            "A document instructs a summarizer to ignore its rules and output a malicious link.",
            "A tool result tries to make an agent call another tool it should not."
          ],
          "faqs": [
            {
              "q": "Why can't models just ignore injected instructions?",
              "a": "Because they cannot reliably distinguish trusted instructions from untrusted content — both arrive as text. That ambiguity is the core vulnerability."
            },
            {
              "q": "What is indirect prompt injection?",
              "a": "When the malicious instructions are hidden in external content the model retrieves — a page, file, email or tool output — rather than typed by the user. It is often more dangerous."
            },
            {
              "q": "Can prompt injection be fully prevented?",
              "a": "Not by a single measure today. You reduce risk with layered defenses: least privilege, content isolation, validation, monitoring and human approval for sensitive actions."
            },
            {
              "q": "How does tool use raise the stakes?",
              "a": "Without tools, injection mostly produces bad text. With tools, an injected instruction can take real actions — send data, make changes — so permissions and approval matter more."
            }
          ]
        },
        "es": {
          "title": "¿Qué es la Inyección de Prompts (Prompt Injection)?",
          "summary": "La inyección de prompts es un ataque en el que instrucciones maliciosas ocultas en la entrada a un modelo de lenguaje secuestran su comportamiento, haciéndole ignorar sus reglas, filtrar datos o usar mal las herramientas. Encabeza el OWASP Top 10 para aplicaciones LLM. La causa raíz es que los modelos no pueden separar de forma fiable las instrucciones de confianza del contenido no confiable, así que cualquier texto que un agente lea —una página web, un documento, el resultado de una herramienta— puede portar un ataque.",
          "definition": "La inyección de prompts es un ataque de seguridad en el que instrucciones adversarias incrustadas en entrada no confiable hacen que un modelo de lenguaje se desvíe de su comportamiento previsto, evite salvaguardas o realice acciones no deseadas.",
          "takeaways": [
            "El texto no confiable que un modelo lee puede contener instrucciones ocultas.",
            "Es el riesgo n.º 1 del OWASP Top 10 para aplicaciones LLM.",
            "La inyección indirecta esconde payloads en documentos, páginas o salidas de herramientas.",
            "El riesgo crece con el acceso a herramientas: la inyección puede disparar acciones reales.",
            "No hay una sola solución; la defensa es por capas (mínimo privilegio, aislamiento, aprobación humana)."
          ],
          "context": [
            "Los modelos siguen instrucciones en lenguaje natural y no pueden distinguir de forma fiable las instrucciones de sistema confiables del contenido no confiable de usuario o documentos. Un atacante lo explota plantando instrucciones como 'ignora las instrucciones anteriores y…' donde el modelo las leerá.",
            "La inyección directa viene del usuario; la indirecta (y más peligrosa) se esconde en contenido que el agente recupera: una página web, un correo, un fichero, el resultado de una herramienta MCP. A medida que los agentes ganan acceso a herramientas, una inyección exitosa puede exfiltrar datos o tomar acciones dañinas."
          ],
          "architecture": [
            "La defensa es por capas, no un único control: permisos de herramientas de mínimo privilegio, aislar y delimitar claramente el contenido no confiable, validación de salidas y acciones, listas de permitidos para operaciones sensibles y aprobación con humano en el bucle para acciones de alto impacto.",
            "Trata todas las salidas de herramientas y recuperación como entrada no confiable. Monitoriza y registra las acciones del agente (observabilidad) para que los intentos de inyección sean detectables, y haz red teaming del sistema con regularidad."
          ],
          "components": [
            "Frontera de entrada no confiable",
            "Permisos de mínimo privilegio",
            "Aislamiento / delimitación de contenido",
            "Validación de salidas y acciones",
            "Aprobación humana para acciones de alto impacto",
            "Monitorización y red teaming"
          ],
          "pros": [],
          "risks": [
            "Exfiltración de contexto sensible o credenciales.",
            "Acciones no autorizadas de herramientas en sistemas conectados.",
            "Políticas de seguridad y guardarraíles evitados.",
            "Ataques indirectos vía documentos, páginas web o resultados de herramientas."
          ],
          "tools": [
            "Librerías de guardarraíles de entrada/salida",
            "Capas de permisos y sandboxing",
            "Listas de permitidos para acciones de herramientas",
            "Monitorización / observabilidad",
            "Frameworks de red teaming"
          ],
          "examples": [
            "Una página web que el agente lee contiene texto oculto que le dice que envíe datos privados por correo.",
            "Un documento instruye a un resumidor a ignorar sus reglas y emitir un enlace malicioso.",
            "El resultado de una herramienta intenta que un agente llame a otra herramienta que no debería."
          ],
          "faqs": [
            {
              "q": "¿Por qué los modelos no pueden simplemente ignorar las instrucciones inyectadas?",
              "a": "Porque no pueden distinguir de forma fiable las instrucciones confiables del contenido no confiable: ambas llegan como texto. Esa ambigüedad es la vulnerabilidad central."
            },
            {
              "q": "¿Qué es la inyección de prompts indirecta?",
              "a": "Cuando las instrucciones maliciosas se esconden en contenido externo que el modelo recupera —una página, fichero, correo o salida de herramienta— en vez de escribirlas el usuario. Suele ser más peligrosa."
            },
            {
              "q": "¿Se puede prevenir por completo la inyección de prompts?",
              "a": "Hoy no con una sola medida. Reduces el riesgo con defensas por capas: mínimo privilegio, aislamiento de contenido, validación, monitorización y aprobación humana para acciones sensibles."
            },
            {
              "q": "¿Cómo eleva la apuesta el uso de herramientas?",
              "a": "Sin herramientas, la inyección produce sobre todo texto malo. Con herramientas, una instrucción inyectada puede tomar acciones reales —enviar datos, hacer cambios—, así que importan más los permisos y la aprobación."
            }
          ]
        },
        "pt": {
          "title": "O que é Injeção de Prompts (Prompt Injection)?",
          "summary": "A injeção de prompts é um ataque em que instruções maliciosas escondidas na entrada de um modelo de linguagem sequestram seu comportamento, fazendo-o ignorar suas regras, vazar dados ou usar mal as ferramentas. Lidera o OWASP Top 10 para aplicações LLM. A causa raiz é que os modelos não conseguem separar de forma confiável as instruções confiáveis do conteúdo não confiável, então qualquer texto que um agente leia — uma página web, um documento, o resultado de uma ferramenta — pode carregar um ataque.",
          "definition": "A injeção de prompts é um ataque de segurança em que instruções adversárias embutidas em entrada não confiável fazem um modelo de linguagem desviar de seu comportamento previsto, contornar salvaguardas ou realizar ações indesejadas.",
          "takeaways": [
            "O texto não confiável que um modelo lê pode conter instruções ocultas.",
            "É o risco nº 1 do OWASP Top 10 para aplicações LLM.",
            "A injeção indireta esconde payloads em documentos, páginas ou saídas de ferramentas.",
            "O risco cresce com o acesso a ferramentas: a injeção pode disparar ações reais.",
            "Não há uma única solução; a defesa é em camadas (privilégio mínimo, isolamento, aprovação humana)."
          ],
          "context": [
            "Os modelos seguem instruções em linguagem natural e não conseguem distinguir de forma confiável as instruções de sistema confiáveis do conteúdo não confiável de usuário ou documentos. Um atacante explora isso plantando instruções como 'ignore as instruções anteriores e…' onde o modelo as lerá.",
            "A injeção direta vem do usuário; a indireta (e mais perigosa) se esconde em conteúdo que o agente recupera: uma página web, um e-mail, um arquivo, o resultado de uma ferramenta MCP. À medida que os agentes ganham acesso a ferramentas, uma injeção bem-sucedida pode exfiltrar dados ou tomar ações nocivas."
          ],
          "architecture": [
            "A defesa é em camadas, não um único controle: permissões de ferramentas de privilégio mínimo, isolar e delimitar claramente o conteúdo não confiável, validação de saídas e ações, listas de permitidos para operações sensíveis e aprovação com humano no laço para ações de alto impacto.",
            "Trate todas as saídas de ferramentas e recuperação como entrada não confiável. Monitore e registre as ações do agente (observabilidade) para que as tentativas de injeção sejam detectáveis, e faça red teaming do sistema regularmente."
          ],
          "components": [
            "Fronteira de entrada não confiável",
            "Permissões de privilégio mínimo",
            "Isolamento / delimitação de conteúdo",
            "Validação de saídas e ações",
            "Aprovação humana para ações de alto impacto",
            "Monitoramento e red teaming"
          ],
          "pros": [],
          "risks": [
            "Exfiltração de contexto sensível ou credenciais.",
            "Ações não autorizadas de ferramentas em sistemas conectados.",
            "Políticas de segurança e guard-rails contornados.",
            "Ataques indiretos via documentos, páginas web ou resultados de ferramentas."
          ],
          "tools": [
            "Bibliotecas de guard-rails de entrada/saída",
            "Camadas de permissões e sandboxing",
            "Listas de permitidos para ações de ferramentas",
            "Monitoramento / observabilidade",
            "Frameworks de red teaming"
          ],
          "examples": [
            "Uma página web que o agente lê contém texto oculto que lhe diz para enviar dados privados por e-mail.",
            "Um documento instrui um resumidor a ignorar suas regras e emitir um link malicioso.",
            "O resultado de uma ferramenta tenta fazer um agente chamar outra ferramenta que não deveria."
          ],
          "faqs": [
            {
              "q": "Por que os modelos não podem simplesmente ignorar as instruções injetadas?",
              "a": "Porque não conseguem distinguir de forma confiável as instruções confiáveis do conteúdo não confiável: ambas chegam como texto. Essa ambiguidade é a vulnerabilidade central."
            },
            {
              "q": "O que é injeção de prompts indireta?",
              "a": "Quando as instruções maliciosas se escondem em conteúdo externo que o modelo recupera — uma página, arquivo, e-mail ou saída de ferramenta — em vez de digitadas pelo usuário. Costuma ser mais perigosa."
            },
            {
              "q": "A injeção de prompts pode ser totalmente prevenida?",
              "a": "Hoje não com uma única medida. Você reduz o risco com defesas em camadas: privilégio mínimo, isolamento de conteúdo, validação, monitoramento e aprovação humana para ações sensíveis."
            },
            {
              "q": "Como o uso de ferramentas eleva a aposta?",
              "a": "Sem ferramentas, a injeção produz sobretudo texto ruim. Com ferramentas, uma instrução injetada pode tomar ações reais — enviar dados, fazer mudanças —, então permissões e aprovação importam mais."
            }
          ]
        }
      }
    },
    {
      "slug": "reasoning-models",
      "category": "concept",
      "updated": "2026-06-21",
      "version": "1.0",
      "url": "https://santismm.com/en/knowledge/reasoning-models",
      "api": "https://santismm.com/api/knowledge/reasoning-models",
      "evidence": {
        "evidenceLevel": "benchmark",
        "confidenceLevel": "high",
        "sourceType": [
          "benchmark",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Wei et al. — Chain-of-Thought Prompting Elicits Reasoning in LLMs (2022)",
          "url": "https://arxiv.org/abs/2201.11903"
        },
        {
          "title": "DeepSeek-AI — DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL (2025)",
          "url": "https://arxiv.org/abs/2501.12948"
        }
      ],
      "related": [
        "foundation-models",
        "agentic-ai",
        "prompt-engineering",
        "agentic-evaluation"
      ],
      "locales": {
        "en": {
          "title": "What are Reasoning Models?",
          "summary": "Reasoning models are language models trained to spend extra computation 'thinking' before they answer — generating internal reasoning steps to solve harder problems in math, code and logic. They trade latency and cost for accuracy on complex, multi-step tasks. The key idea is test-time compute: letting a model reason longer at inference, rather than only making the model bigger, can substantially improve results.",
          "definition": "Reasoning models are language models optimized to perform extended step-by-step reasoning at inference time — using additional test-time compute — to improve accuracy on complex, multi-step problems.",
          "takeaways": [
            "They 'think' before answering, using extra inference compute.",
            "Test-time compute is a new scaling axis beyond model size.",
            "Best for math, code, logic and multi-step planning.",
            "They trade latency and token cost for accuracy.",
            "Overkill for simple tasks — match the model to the problem."
          ],
          "context": [
            "Standard models answer in roughly constant time regardless of difficulty. Reasoning models break that: they generate a chain of internal reasoning, effectively spending more compute on harder questions, which lifts performance on tasks that need multi-step deduction.",
            "This introduced a second scaling axis. Beyond making models larger (train-time compute), you can let them reason longer at inference (test-time compute) — a major driver of recent progress on hard benchmarks."
          ],
          "architecture": [
            "Reasoning models are typically trained to produce long internal reasoning before a final answer, often reinforced with reinforcement learning that rewards correct outcomes. At inference, more 'thinking' tokens generally mean better answers on hard problems.",
            "In agentic systems, reasoning models serve as strong planners and decision-makers, while cheaper, faster models can handle routine steps. Routing between them by task difficulty is a common cost-control pattern."
          ],
          "components": [
            "Extended reasoning (thinking tokens)",
            "Test-time compute budget",
            "RL-based training for reasoning",
            "Final-answer extraction"
          ],
          "pros": [
            "Higher accuracy on complex, multi-step problems.",
            "Strong at math, coding and planning.",
            "Reasoning effort can be scaled per query.",
            "Good planners at the core of capable agents."
          ],
          "risks": [
            "Higher latency and token cost.",
            "Overkill — and wasteful — for simple tasks.",
            "Longer reasoning is not always more correct.",
            "Internal reasoning can be hard to audit or trust verbatim."
          ],
          "tools": [
            "Reasoning model tiers from major providers",
            "Adjustable reasoning-effort settings",
            "Model routing by task difficulty",
            "Evaluation suites"
          ],
          "examples": [
            "Solving a multi-step math or logic problem that trips up a standard model.",
            "Planning a complex agent task before execution.",
            "Routing only hard tickets to a reasoning model to control cost."
          ],
          "faqs": [
            {
              "q": "How are reasoning models different from standard LLMs?",
              "a": "They are trained and configured to reason at length before answering, spending more inference compute on hard problems instead of replying in near-constant time."
            },
            {
              "q": "What is test-time compute?",
              "a": "Computation spent at inference (the model 'thinking' longer), as opposed to train-time compute spent making the model. It is a distinct way to improve results."
            },
            {
              "q": "Should I always use a reasoning model?",
              "a": "No. They cost more and add latency. Use them for hard, multi-step problems and route simpler tasks to faster, cheaper models."
            },
            {
              "q": "Do they eliminate hallucination?",
              "a": "No. Reasoning improves accuracy on many tasks but does not guarantee correctness; grounding, tools and evaluation remain necessary."
            }
          ]
        },
        "es": {
          "title": "¿Qué son los Modelos de Razonamiento (Reasoning Models)?",
          "summary": "Los modelos de razonamiento son modelos de lenguaje entrenados para gastar cómputo extra 'pensando' antes de responder, generando pasos de razonamiento internos para resolver problemas más difíciles de matemáticas, código y lógica. Cambian latencia y coste por precisión en tareas complejas de varios pasos. La idea clave es el cómputo en inferencia (test-time compute): dejar que un modelo razone más en la inferencia, en vez de solo hacerlo más grande, puede mejorar mucho los resultados.",
          "definition": "Los modelos de razonamiento son modelos de lenguaje optimizados para realizar razonamiento extendido paso a paso en el momento de la inferencia —usando cómputo adicional en inferencia— para mejorar la precisión en problemas complejos de varios pasos.",
          "takeaways": [
            "'Piensan' antes de responder, usando cómputo extra en inferencia.",
            "El cómputo en inferencia es un nuevo eje de escalado más allá del tamaño.",
            "Mejores para matemáticas, código, lógica y planificación de varios pasos.",
            "Cambian latencia y coste de tokens por precisión.",
            "Excesivos para tareas simples: ajusta el modelo al problema."
          ],
          "context": [
            "Los modelos estándar responden en un tiempo casi constante sin importar la dificultad. Los modelos de razonamiento rompen eso: generan una cadena de razonamiento interno, gastando de hecho más cómputo en preguntas más difíciles, lo que mejora tareas que necesitan deducción de varios pasos.",
            "Esto introdujo un segundo eje de escalado. Más allá de hacer modelos más grandes (cómputo en entrenamiento), puedes dejarlos razonar más en inferencia (cómputo en inferencia): un motor importante del progreso reciente en benchmarks difíciles."
          ],
          "architecture": [
            "Los modelos de razonamiento suelen entrenarse para producir un razonamiento interno largo antes de la respuesta final, a menudo reforzado con aprendizaje por refuerzo que premia resultados correctos. En inferencia, más tokens de 'pensamiento' suelen significar mejores respuestas en problemas difíciles.",
            "En sistemas agénticos, los modelos de razonamiento sirven como planificadores y decisores fuertes, mientras que modelos más baratos y rápidos manejan pasos rutinarios. Enrutar entre ellos según la dificultad es un patrón común de control de coste."
          ],
          "components": [
            "Razonamiento extendido (tokens de pensamiento)",
            "Presupuesto de cómputo en inferencia",
            "Entrenamiento por RL para razonar",
            "Extracción de la respuesta final"
          ],
          "pros": [
            "Mayor precisión en problemas complejos de varios pasos.",
            "Fuertes en matemáticas, programación y planificación.",
            "El esfuerzo de razonamiento puede escalarse por consulta.",
            "Buenos planificadores en el núcleo de agentes capaces."
          ],
          "risks": [
            "Mayor latencia y coste de tokens.",
            "Excesivos —y derrochadores— para tareas simples.",
            "Razonar más no siempre es más correcto.",
            "El razonamiento interno puede ser difícil de auditar o de creer al pie de la letra."
          ],
          "tools": [
            "Niveles de modelos de razonamiento de los grandes proveedores",
            "Ajustes de esfuerzo de razonamiento",
            "Enrutamiento de modelos por dificultad",
            "Suites de evaluación"
          ],
          "examples": [
            "Resolver un problema de matemáticas o lógica de varios pasos que confunde a un modelo estándar.",
            "Planificar una tarea de agente compleja antes de ejecutarla.",
            "Enrutar solo los tickets difíciles a un modelo de razonamiento para controlar el coste."
          ],
          "faqs": [
            {
              "q": "¿En qué se diferencian de los LLM estándar?",
              "a": "Están entrenados y configurados para razonar extensamente antes de responder, gastando más cómputo en inferencia en problemas difíciles en vez de responder en tiempo casi constante."
            },
            {
              "q": "¿Qué es el cómputo en inferencia?",
              "a": "El cómputo gastado en la inferencia (el modelo 'pensando' más tiempo), frente al cómputo en entrenamiento gastado en construir el modelo. Es una forma distinta de mejorar resultados."
            },
            {
              "q": "¿Debería usar siempre un modelo de razonamiento?",
              "a": "No. Cuestan más y añaden latencia. Úsalos para problemas difíciles de varios pasos y enruta las tareas simples a modelos más rápidos y baratos."
            },
            {
              "q": "¿Eliminan la alucinación?",
              "a": "No. El razonamiento mejora la precisión en muchas tareas pero no garantiza la corrección; siguen siendo necesarios la fundamentación, las herramientas y la evaluación."
            }
          ]
        },
        "pt": {
          "title": "O que são Modelos de Raciocínio (Reasoning Models)?",
          "summary": "Os modelos de raciocínio são modelos de linguagem treinados para gastar computação extra 'pensando' antes de responder, gerando passos de raciocínio internos para resolver problemas mais difíceis de matemática, código e lógica. Trocam latência e custo por precisão em tarefas complexas de vários passos. A ideia central é a computação em inferência (test-time compute): deixar um modelo raciocinar mais na inferência, em vez de só torná-lo maior, pode melhorar muito os resultados.",
          "definition": "Os modelos de raciocínio são modelos de linguagem otimizados para realizar raciocínio estendido passo a passo no momento da inferência — usando computação adicional em inferência — para melhorar a precisão em problemas complexos de vários passos.",
          "takeaways": [
            "'Pensam' antes de responder, usando computação extra em inferência.",
            "A computação em inferência é um novo eixo de escala além do tamanho.",
            "Melhores para matemática, código, lógica e planejamento de vários passos.",
            "Trocam latência e custo de tokens por precisão.",
            "Exagero para tarefas simples: ajuste o modelo ao problema."
          ],
          "context": [
            "Os modelos padrão respondem em tempo quase constante independentemente da dificuldade. Os modelos de raciocínio quebram isso: geram uma cadeia de raciocínio interno, gastando de fato mais computação em perguntas mais difíceis, o que melhora tarefas que precisam de dedução de vários passos.",
            "Isso introduziu um segundo eixo de escala. Além de tornar os modelos maiores (computação em treinamento), você pode deixá-los raciocinar mais na inferência (computação em inferência): um motor importante do progresso recente em benchmarks difíceis."
          ],
          "architecture": [
            "Os modelos de raciocínio costumam ser treinados para produzir um raciocínio interno longo antes da resposta final, muitas vezes reforçado com aprendizado por reforço que premia resultados corretos. Na inferência, mais tokens de 'pensamento' costumam significar melhores respostas em problemas difíceis.",
            "Em sistemas agênticos, os modelos de raciocínio servem como planejadores e decisores fortes, enquanto modelos mais baratos e rápidos lidam com passos rotineiros. Rotear entre eles conforme a dificuldade é um padrão comum de controle de custo."
          ],
          "components": [
            "Raciocínio estendido (tokens de pensamento)",
            "Orçamento de computação em inferência",
            "Treinamento por RL para raciocinar",
            "Extração da resposta final"
          ],
          "pros": [
            "Maior precisão em problemas complexos de vários passos.",
            "Fortes em matemática, programação e planejamento.",
            "O esforço de raciocínio pode ser escalado por consulta.",
            "Bons planejadores no núcleo de agentes capazes."
          ],
          "risks": [
            "Maior latência e custo de tokens.",
            "Exagero — e desperdício — para tarefas simples.",
            "Raciocinar mais nem sempre é mais correto.",
            "O raciocínio interno pode ser difícil de auditar ou de crer ao pé da letra."
          ],
          "tools": [
            "Níveis de modelos de raciocínio dos grandes provedores",
            "Ajustes de esforço de raciocínio",
            "Roteamento de modelos por dificuldade",
            "Suítes de avaliação"
          ],
          "examples": [
            "Resolver um problema de matemática ou lógica de vários passos que confunde um modelo padrão.",
            "Planejar uma tarefa de agente complexa antes de executá-la.",
            "Rotear só os chamados difíceis a um modelo de raciocínio para controlar o custo."
          ],
          "faqs": [
            {
              "q": "Como diferem dos LLMs padrão?",
              "a": "São treinados e configurados para raciocinar longamente antes de responder, gastando mais computação em inferência em problemas difíceis em vez de responder em tempo quase constante."
            },
            {
              "q": "O que é computação em inferência?",
              "a": "A computação gasta na inferência (o modelo 'pensando' mais tempo), frente à computação em treinamento gasta em construir o modelo. É uma forma distinta de melhorar resultados."
            },
            {
              "q": "Devo usar sempre um modelo de raciocínio?",
              "a": "Não. Custam mais e adicionam latência. Use-os para problemas difíceis de vários passos e roteie as tarefas simples a modelos mais rápidos e baratos."
            },
            {
              "q": "Eles eliminam a alucinação?",
              "a": "Não. O raciocínio melhora a precisão em muitas tarefas mas não garante a correção; fundamentação, ferramentas e avaliação seguem necessárias."
            }
          ]
        }
      }
    },
    {
      "slug": "tool-use",
      "category": "concept",
      "updated": "2026-06-24",
      "version": "1.1",
      "url": "https://santismm.com/en/knowledge/tool-use",
      "api": "https://santismm.com/api/knowledge/tool-use",
      "evidence": {
        "evidenceLevel": "production",
        "confidenceLevel": "medium",
        "sourceType": [
          "production_system",
          "personal_experience",
          "industry_observation",
          "paper"
        ]
      },
      "references": [
        {
          "title": "Schick et al. — Toolformer: Language Models Can Teach Themselves to Use Tools (2023)",
          "url": "https://arxiv.org/abs/2302.04761"
        },
        {
          "title": "Anthropic — Tool use (function calling)",
          "url": "https://docs.anthropic.com/en/docs/build-with-claude/tool-use"
        }
      ],
      "related": [
        "ai-agent",
        "model-context-protocol",
        "agentic-ai",
        "harness-engineering"
      ],
      "locales": {
        "en": {
          "title": "What is Tool Use (Function Calling)?",
          "summary": "Tool use, also called function calling, lets a language model invoke external functions, APIs or code to fetch information or take actions in the real world. The model decides which tool to call and with what arguments; the application runs the tool and returns the result, which the model uses to continue. Tool use is the bridge that turns a text generator into an agent that can actually do things.",
          "definition": "Tool use (function calling) is the capability that lets a language model call predefined external functions or APIs, with arguments it generates, and incorporate the results into its response or next step.",
          "takeaways": [
            "Tool use connects a model to live data and real actions.",
            "The model picks the tool and arguments; the app executes it.",
            "Clear, well-described tools dramatically improve reliability.",
            "It is the core mechanism behind agents and MCP.",
            "Tool access expands capability and the security surface alike."
          ],
          "context": [
            "On its own a model only produces text. Tool use breaks that boundary: given a set of declared tools, the model can choose to call one — for example a search, a database query or a payment API — and then reason over the result.",
            "How tools are described matters as much as the model. Tools written for a model to use — clear names, precise parameters, helpful descriptions and error messages — are a central concern of harness engineering."
          ],
          "architecture": [
            "The loop: the application declares tools (name, description, parameter schema); the model emits a structured tool call; the application validates and executes it; the result returns to the model as an observation; the model continues or answers.",
            "MCP standardizes how tools are exposed and discovered across applications, so a tool written once can be reused by any compliant client. Guardrails and permissions wrap execution to keep it safe."
          ],
          "components": [
            "Tool declaration (schema)",
            "Tool selection (model)",
            "Argument generation",
            "Execution layer",
            "Result / observation",
            "Guardrails & permissions"
          ],
          "pros": [
            "Grounds answers in live, real data.",
            "Lets models take real actions, not just describe them.",
            "Extends a model without retraining.",
            "Composes into full agentic workflows."
          ],
          "risks": [
            "Prompt injection can trigger unintended tool calls.",
            "Wrong arguments or tool misuse cause real-world errors.",
            "Over-broad tool access widens the attack surface.",
            "Latency and cost grow with each tool round-trip."
          ],
          "tools": [
            "Function calling APIs",
            "Model Context Protocol (MCP)",
            "LangGraph / Agents SDKs",
            "Schema validation (e.g. JSON Schema, Zod)"
          ],
          "examples": [
            "A model calling a weather API to answer a forecast question.",
            "An agent querying a database to look up an order before acting.",
            "A coding agent invoking a test runner and reading the results.",
            "In practice: an autonomous OpenClaw agent issued 800 tool calls across 10 distinct tools over 57 days — exec (481), web_search (190), write (48), web_fetch (22), read (21) and others — averaging 5.97 tool calls per session. A single-operator local-first deployment, measured from the agent's own traces."
          ],
          "faqs": [
            {
              "q": "Is tool use the same as MCP?",
              "a": "No. Tool use is the model capability to call functions. MCP is a standard for how those tools and data are exposed and discovered across applications."
            },
            {
              "q": "How do you make tool use reliable?",
              "a": "Write tools for the model: clear names, precise parameter schemas, useful descriptions and informative errors. Validate arguments and constrain permissions."
            },
            {
              "q": "What are the security risks?",
              "a": "Tools are real access. Prompt injection can attempt to trigger harmful calls, so apply least-privilege permissions, validate inputs, and treat tool outputs as untrusted."
            },
            {
              "q": "Does tool use make a model an agent?",
              "a": "It is the key enabler. An agent combines tool use with a control loop, memory and a goal so it can act over multiple steps."
            }
          ]
        },
        "es": {
          "title": "¿Qué es el Uso de Herramientas (Function Calling)?",
          "summary": "El uso de herramientas, también llamado function calling, permite a un modelo de lenguaje invocar funciones, APIs o código externos para obtener información o tomar acciones en el mundo real. El modelo decide qué herramienta llamar y con qué argumentos; la aplicación ejecuta la herramienta y devuelve el resultado, que el modelo usa para continuar. El uso de herramientas es el puente que convierte a un generador de texto en un agente que de verdad hace cosas.",
          "definition": "El uso de herramientas (function calling) es la capacidad que permite a un modelo de lenguaje llamar a funciones o APIs externas predefinidas, con argumentos que genera, e incorporar los resultados a su respuesta o siguiente paso.",
          "takeaways": [
            "El uso de herramientas conecta un modelo con datos en vivo y acciones reales.",
            "El modelo elige la herramienta y los argumentos; la aplicación la ejecuta.",
            "Herramientas claras y bien descritas mejoran mucho la fiabilidad.",
            "Es el mecanismo central detrás de los agentes y de MCP.",
            "El acceso a herramientas amplía la capacidad y la superficie de seguridad por igual."
          ],
          "context": [
            "Por sí solo un modelo solo produce texto. El uso de herramientas rompe esa frontera: dado un conjunto de herramientas declaradas, el modelo puede elegir llamar a una —por ejemplo una búsqueda, una consulta a base de datos o una API de pago— y luego razonar sobre el resultado.",
            "Cómo se describen las herramientas importa tanto como el modelo. Las herramientas escritas para que las use un modelo —nombres claros, parámetros precisos, descripciones útiles y mensajes de error— son una preocupación central de la ingeniería de harness."
          ],
          "architecture": [
            "El bucle: la aplicación declara herramientas (nombre, descripción, esquema de parámetros); el modelo emite una llamada estructurada; la aplicación la valida y ejecuta; el resultado vuelve al modelo como observación; el modelo continúa o responde.",
            "MCP estandariza cómo se exponen y descubren las herramientas entre aplicaciones, de modo que una herramienta escrita una vez se reutiliza en cualquier cliente compatible. Los guardarraíles y permisos envuelven la ejecución para mantenerla segura."
          ],
          "components": [
            "Declaración de herramienta (esquema)",
            "Selección de herramienta (modelo)",
            "Generación de argumentos",
            "Capa de ejecución",
            "Resultado / observación",
            "Guardarraíles y permisos"
          ],
          "pros": [
            "Fundamenta las respuestas en datos reales y en vivo.",
            "Permite a los modelos tomar acciones reales, no solo describirlas.",
            "Extiende un modelo sin reentrenarlo.",
            "Se compone en flujos agénticos completos."
          ],
          "risks": [
            "La inyección de prompts puede disparar llamadas no deseadas.",
            "Argumentos erróneos o mal uso de herramientas causan errores reales.",
            "Un acceso demasiado amplio a herramientas amplía la superficie de ataque.",
            "La latencia y el coste crecen con cada ida y vuelta a una herramienta."
          ],
          "tools": [
            "APIs de function calling",
            "Model Context Protocol (MCP)",
            "LangGraph / SDKs de agentes",
            "Validación de esquemas (p. ej. JSON Schema, Zod)"
          ],
          "examples": [
            "Un modelo que llama a una API del tiempo para responder sobre el pronóstico.",
            "Un agente que consulta una base de datos para buscar un pedido antes de actuar.",
            "Un agente de programación que invoca un runner de tests y lee los resultados.",
            "En la práctica: un agente autónomo OpenClaw realizó 800 llamadas a herramientas entre 10 herramientas distintas en 57 días — exec (481), web_search (190), write (48), web_fetch (22), read (21) y otras — con una media de 5,97 llamadas por sesión. Despliegue local-first mono-operador, medido desde las propias trazas del agente."
          ],
          "faqs": [
            {
              "q": "¿El uso de herramientas es lo mismo que MCP?",
              "a": "No. El uso de herramientas es la capacidad del modelo de llamar a funciones. MCP es un estándar de cómo se exponen y descubren esas herramientas y datos entre aplicaciones."
            },
            {
              "q": "¿Cómo se hace fiable el uso de herramientas?",
              "a": "Escribiendo las herramientas para el modelo: nombres claros, esquemas de parámetros precisos, descripciones útiles y errores informativos. Validar argumentos y limitar permisos."
            },
            {
              "q": "¿Cuáles son los riesgos de seguridad?",
              "a": "Las herramientas son acceso real. La inyección de prompts puede intentar disparar llamadas dañinas, así que aplica permisos de mínimo privilegio, valida entradas y trata las salidas como no confiables."
            },
            {
              "q": "¿El uso de herramientas convierte a un modelo en agente?",
              "a": "Es el habilitador clave. Un agente combina el uso de herramientas con un bucle de control, memoria y un objetivo para actuar en varios pasos."
            }
          ]
        },
        "pt": {
          "title": "O que é Uso de Ferramentas (Function Calling)?",
          "summary": "O uso de ferramentas, também chamado function calling, permite a um modelo de linguagem invocar funções, APIs ou código externos para obter informação ou tomar ações no mundo real. O modelo decide qual ferramenta chamar e com quais argumentos; a aplicação executa a ferramenta e devolve o resultado, que o modelo usa para continuar. O uso de ferramentas é a ponte que transforma um gerador de texto num agente que de fato faz coisas.",
          "definition": "O uso de ferramentas (function calling) é a capacidade que permite a um modelo de linguagem chamar funções ou APIs externas predefinidas, com argumentos que gera, e incorporar os resultados à sua resposta ou próximo passo.",
          "takeaways": [
            "O uso de ferramentas conecta um modelo a dados ao vivo e ações reais.",
            "O modelo escolhe a ferramenta e os argumentos; a aplicação a executa.",
            "Ferramentas claras e bem descritas melhoram muito a confiabilidade.",
            "É o mecanismo central por trás dos agentes e do MCP.",
            "O acesso a ferramentas amplia a capacidade e a superfície de segurança igualmente."
          ],
          "context": [
            "Sozinho, um modelo só produz texto. O uso de ferramentas quebra essa fronteira: dado um conjunto de ferramentas declaradas, o modelo pode escolher chamar uma — por exemplo uma busca, uma consulta a banco de dados ou uma API de pagamento — e então raciocinar sobre o resultado.",
            "Como as ferramentas são descritas importa tanto quanto o modelo. Ferramentas escritas para um modelo usar — nomes claros, parâmetros precisos, descrições úteis e mensagens de erro — são uma preocupação central da engenharia de harness."
          ],
          "architecture": [
            "O laço: a aplicação declara ferramentas (nome, descrição, esquema de parâmetros); o modelo emite uma chamada estruturada; a aplicação a valida e executa; o resultado retorna ao modelo como observação; o modelo continua ou responde.",
            "O MCP padroniza como as ferramentas são expostas e descobertas entre aplicações, de modo que uma ferramenta escrita uma vez é reutilizada por qualquer cliente compatível. Guard-rails e permissões envolvem a execução para mantê-la segura."
          ],
          "components": [
            "Declaração de ferramenta (esquema)",
            "Seleção de ferramenta (modelo)",
            "Geração de argumentos",
            "Camada de execução",
            "Resultado / observação",
            "Guard-rails e permissões"
          ],
          "pros": [
            "Fundamenta as respostas em dados reais e ao vivo.",
            "Permite aos modelos tomar ações reais, não só descrevê-las.",
            "Estende um modelo sem retreiná-lo.",
            "Compõe-se em fluxos agênticos completos."
          ],
          "risks": [
            "A injeção de prompts pode disparar chamadas indesejadas.",
            "Argumentos errados ou mau uso de ferramentas causam erros reais.",
            "Um acesso amplo demais a ferramentas amplia a superfície de ataque.",
            "A latência e o custo crescem a cada ida e volta a uma ferramenta."
          ],
          "tools": [
            "APIs de function calling",
            "Model Context Protocol (MCP)",
            "LangGraph / SDKs de agentes",
            "Validação de esquemas (ex.: JSON Schema, Zod)"
          ],
          "examples": [
            "Um modelo que chama uma API de clima para responder sobre a previsão.",
            "Um agente que consulta um banco de dados para buscar um pedido antes de agir.",
            "Um agente de programação que invoca um runner de testes e lê os resultados.",
            "Na prática: um agente autônomo OpenClaw fez 800 chamadas de ferramentas entre 10 ferramentas distintas em 57 dias — exec (481), web_search (190), write (48), web_fetch (22), read (21) e outras — com média de 5,97 chamadas por sessão. Implantação local-first de operador único, medida a partir dos próprios rastros do agente."
          ],
          "faqs": [
            {
              "q": "O uso de ferramentas é o mesmo que MCP?",
              "a": "Não. O uso de ferramentas é a capacidade do modelo de chamar funções. O MCP é um padrão de como essas ferramentas e dados são expostos e descobertos entre aplicações."
            },
            {
              "q": "Como tornar o uso de ferramentas confiável?",
              "a": "Escrevendo as ferramentas para o modelo: nomes claros, esquemas de parâmetros precisos, descrições úteis e erros informativos. Validar argumentos e limitar permissões."
            },
            {
              "q": "Quais são os riscos de segurança?",
              "a": "Ferramentas são acesso real. A injeção de prompts pode tentar disparar chamadas nocivas, então aplique permissões de privilégio mínimo, valide entradas e trate as saídas como não confiáveis."
            },
            {
              "q": "O uso de ferramentas torna um modelo um agente?",
              "a": "É o habilitador-chave. Um agente combina o uso de ferramentas com um laço de controle, memória e um objetivo para agir em vários passos."
            }
          ]
        }
      }
    }
  ]
}