santismm-knowledge-mcp 0.2.1

package/content/governance/owasp-llm-top10.json

@@ -0,0 +1,301 @@
+{
+  "id": "GOV-008",
+  "slug": "owasp-llm-top10",
+  "category": "framework",
+  "updated": "2026-08-22",
+  "version": "1.0",
+  "evidence": {
+    "evidenceLevel": "industry_observation",
+    "confidenceLevel": "high",
+    "sourceType": [
+      "paper",
+      "industry_observation",
+      "personal_experience"
+    ]
+  },
+  "frameworks": [
+    "OWASP GenAI Security Project",
+    "NIST AI RMF",
+    "MITRE ATLAS"
+  ],
+  "patterns": [
+    "least-privilege-tooling",
+    "egress-allowlist",
+    "sandboxed-execution",
+    "human-approval-gate"
+  ],
+  "knowledge": [
+    "prompt-injection",
+    "ai-cyberdefense",
+    "agentic-threat-model",
+    "mcp-security",
+    "guardrails"
+  ],
+  "references": [
+    {
+      "title": "OWASP — Top 10 for LLM Applications",
+      "url": "https://genai.owasp.org/llm-top-10/"
+    },
+    {
+      "title": "OWASP — LLM01: Prompt Injection",
+      "url": "https://genai.owasp.org/llmrisk/llm01-prompt-injection/"
+    },
+    {
+      "title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems",
+      "url": "https://atlas.mitre.org/"
+    },
+    {
+      "title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
+      "url": "https://www.nist.gov/itl/ai-risk-management-framework"
+    }
+  ],
+  "related": [
+    "mitre-atlas",
+    "nist-ai-rmf",
+    "iso-42001",
+    "agentic-ai-governance-checklist",
+    "audit-framework-for-agentic-systems"
+  ],
+  "locales": {
+    "en": {
+      "name": "OWASP Top 10 for LLM Applications",
+      "summary": "The OWASP Top 10 for LLM Applications is the shared vocabulary for what goes wrong in systems built on language models. It is not a control framework and does not tell you what to implement — it names the vulnerability classes, from prompt injection through excessive agency to unbounded consumption, so that teams, auditors and vendors can argue about the same things. Its practical value is as a checklist over your own architecture and as the common language in which findings get reported.",
+      "definition": "The OWASP Top 10 for LLM Applications is a community-maintained list of the most critical vulnerability classes in applications built on large language models, published by the OWASP GenAI Security Project and revised periodically as the ecosystem changes.",
+      "scope": "Any application built on a large language model — chat interfaces, retrieval systems, agents and the tools they call. It is voluntary, non-certifiable and deliberately descriptive: it classifies risks, it does not prescribe controls or grant compliance.",
+      "keyPoints": [
+        "Prompt injection has led the list since the first edition, and remains the class with no clean fix — only layered containment.",
+        "The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation, and unbounded consumption. The list is revised periodically, so check the current edition rather than trusting a cached one.",
+        "Several entries are agent-specific in effect: excessive agency and improper output handling only become severe once the model can act.",
+        "It is a taxonomy, not a control set. Mapping a finding to LLM06 tells you what kind of problem it is, not what to build.",
+        "It is the lingua franca of the field: security reviews, vendor questionnaires and bug reports all reference it, which is most of why it is worth knowing by number.",
+        "Coverage of the list is not a security posture. Every entry needs a control in your architecture, and an entry with no control is an accepted risk whether or not anyone wrote that down."
+      ],
+      "controls": [
+        {
+          "control": "Map the list onto your own architecture",
+          "note": "Walk each entry against your actual inputs, tools, data stores and outputs. The exercise is worth more than the list, because it surfaces the entries that do not apply and the surfaces the list does not name."
+        },
+        {
+          "control": "Assign an owner and a control per entry",
+          "note": "Each applicable class needs a named component that bounds it and a person who maintains that component. An entry mapped to nothing is a gap with a reference number."
+        },
+        {
+          "control": "Treat prompt injection as containment, not prevention",
+          "note": "LLM01 has no reliable fix at the model layer. The controls that matter are least-privilege tooling, egress restriction, output handling and approval gates for high-impact actions."
+        },
+        {
+          "control": "Constrain agency explicitly",
+          "note": "For LLM06, write down what the agent may do, with which credentials, against which targets — and enforce it below the model rather than in the prompt."
+        },
+        {
+          "control": "Handle model output as untrusted input",
+          "note": "For LLM05, anything the model emits that reaches a renderer, a shell, a query or another system needs the same encoding and validation you would apply to input from a stranger."
+        },
+        {
+          "control": "Bound consumption",
+          "note": "For LLM10, rate limits, quotas and timeouts turn an availability and cost attack into a logged refusal. This is the entry teams most often skip because it does not look like security until the invoice arrives."
+        },
+        {
+          "control": "Re-run the mapping when the list or the system changes",
+          "note": "The list is revised and your tool catalogue grows. A mapping done once is a document about a system that no longer exists."
+        }
+      ],
+      "checklist": [
+        "Read the current edition rather than a summary — including this one.",
+        "Produce a mapping table: entry → applies? → control → owner.",
+        "For every applicable entry with no control, record it as an accepted risk with a reason and a compensating detection.",
+        "Write a test for each control, and see the test fail before trusting it.",
+        "Check the entries that only bite with tools: excessive agency, improper output handling, supply chain.",
+        "Confirm rate limits and quotas exist and return correct signals to well-behaved clients.",
+        "Re-run the mapping whenever a tool, a data source or an autonomy level changes.",
+        "Use the list's numbering in findings so reviewers and vendors are discussing the same class."
+      ],
+      "pitfalls": [
+        "Treating the list as a compliance target: covering ten headings while the actual architecture stays unexamined.",
+        "Assuming a model vendor's safety work covers LLM01. It reduces attempts; the consequences remain entirely yours.",
+        "Mapping to a cached edition. The list is revised, and an old mapping quietly stops covering current classes.",
+        "Skipping LLM10 because unbounded consumption looks like an operations problem rather than a security one.",
+        "Confusing naming a class with controlling it. A tidy mapping table with no enforcement is documentation of risk, not reduction of it."
+      ],
+      "examples": [
+        "An agent that summarises customer emails maps to LLM01 (the email body is untrusted instruction input), LLM02 (the summary can repeat data the requester should not see) and LLM06 (the CRM tool turns a hijack into an action) — three entries from one feature, each needing a different control.",
+        "A RAG system over an internal wiki maps to LLM01 via indirect injection from any page editor, LLM04 if the index can be poisoned, and LLM08 for retrieval that returns documents outside the requester's permissions.",
+        "A public MCP endpoint maps most sharply to LLM10: read-only, public data, so the consumption bound — rate limits with correct headers — is the entry doing the real work."
+      ],
+      "faqs": [
+        {
+          "q": "Is the OWASP LLM Top 10 something you can be compliant with?",
+          "a": "No. It is an awareness and classification document, not a certifiable standard. It pairs naturally with a management system such as ISO 42001 or a framework such as the NIST AI RMF, which is where governance obligations actually live."
+        },
+        {
+          "q": "Which entries change most when you add tools to a model?",
+          "a": "Excessive agency and improper output handling. Without tools they produce a wrong answer; with tools they produce an action, and severity moves from embarrassment to incident."
+        },
+        {
+          "q": "How does it relate to MITRE ATLAS?",
+          "a": "They answer different questions. OWASP names the vulnerability classes in your application; ATLAS catalogues the tactics and techniques an adversary uses against AI systems. One is a checklist over your design, the other is a map of the attacker's playbook."
+        }
+      ]
+    },
+    "es": {
+      "name": "OWASP Top 10 para Aplicaciones LLM",
+      "summary": "El OWASP Top 10 para aplicaciones LLM es el vocabulario común de lo que sale mal en sistemas construidos sobre modelos de lenguaje. No es un marco de controles y no dice qué implementar: nombra las clases de vulnerabilidad, de la inyección de prompts al exceso de agencia y al consumo sin límite, para que equipos, auditores y proveedores discutan sobre las mismas cosas. Su valor práctico es servir de lista de comprobación sobre tu propia arquitectura y de idioma común en el que se reportan los hallazgos.",
+      "definition": "El OWASP Top 10 para aplicaciones LLM es una lista mantenida por la comunidad con las clases de vulnerabilidad más críticas en aplicaciones construidas sobre grandes modelos de lenguaje, publicada por el OWASP GenAI Security Project y revisada periódicamente conforme cambia el ecosistema.",
+      "scope": "Cualquier aplicación construida sobre un gran modelo de lenguaje: interfaces de chat, sistemas de recuperación, agentes y las herramientas que invocan. Es voluntaria, no certificable y deliberadamente descriptiva: clasifica riesgos, no prescribe controles ni otorga conformidad.",
+      "keyPoints": [
+        "La inyección de prompts encabeza la lista desde la primera edición y sigue siendo la clase sin solución limpia: solo contención por capas.",
+        "La edición de 2025 cubre inyección de prompts, divulgación de información sensible, cadena de suministro, envenenamiento de datos y modelo, tratamiento indebido de la salida, exceso de agencia, filtración del system prompt, debilidades de vectores y embeddings, desinformación y consumo sin límite. La lista se revisa periódicamente, así que consulta la edición vigente y no una copia en caché.",
+        "Varias entradas son en la práctica específicas de agentes: el exceso de agencia y el tratamiento indebido de la salida solo se vuelven graves cuando el modelo puede actuar.",
+        "Es una taxonomía, no un conjunto de controles. Mapear un hallazgo a LLM06 te dice de qué tipo de problema se trata, no qué construir.",
+        "Es la lengua franca del campo: revisiones de seguridad, cuestionarios de proveedores y reportes de fallos la citan, y esa es buena parte del motivo para conocerla por número.",
+        "Cubrir la lista no es una postura de seguridad. Cada entrada necesita un control en tu arquitectura, y una entrada sin control es un riesgo aceptado lo haya escrito alguien o no."
+      ],
+      "controls": [
+        {
+          "control": "Mapea la lista sobre tu propia arquitectura",
+          "note": "Recorre cada entrada frente a tus entradas reales, herramientas, almacenes de datos y salidas. El ejercicio vale más que la lista, porque saca a la luz las entradas que no aplican y las superficies que la lista no nombra."
+        },
+        {
+          "control": "Asigna responsable y control por entrada",
+          "note": "Cada clase aplicable necesita un componente concreto que la acote y una persona que lo mantenga. Una entrada mapeada a nada es una brecha con número de referencia."
+        },
+        {
+          "control": "Trata la inyección de prompts como contención, no como prevención",
+          "note": "LLM01 no tiene solución fiable en la capa del modelo. Los controles que importan son herramientas con mínimo privilegio, restricción de salida, tratamiento de la salida y puertas de aprobación para acciones de alto impacto."
+        },
+        {
+          "control": "Acota la agencia de forma explícita",
+          "note": "Para LLM06, escribe qué puede hacer el agente, con qué credenciales y contra qué objetivos, y aplícalo por debajo del modelo en lugar de en el prompt."
+        },
+        {
+          "control": "Trata la salida del modelo como entrada no confiable",
+          "note": "Para LLM05, todo lo que el modelo emita y llegue a un renderizador, un shell, una consulta u otro sistema necesita la misma codificación y validación que aplicarías a la entrada de un desconocido."
+        },
+        {
+          "control": "Acota el consumo",
+          "note": "Para LLM10, los límites de tasa, las cuotas y los timeouts convierten un ataque de disponibilidad y coste en un rechazo registrado. Es la entrada que más se salta la gente porque no parece seguridad hasta que llega la factura."
+        },
+        {
+          "control": "Rehaz el mapeo cuando cambie la lista o el sistema",
+          "note": "La lista se revisa y tu catálogo de herramientas crece. Un mapeo hecho una vez es un documento sobre un sistema que ya no existe."
+        }
+      ],
+      "checklist": [
+        "Lee la edición vigente en lugar de un resumen, incluido este.",
+        "Produce una tabla de mapeo: entrada → ¿aplica? → control → responsable.",
+        "Para cada entrada aplicable sin control, regístrala como riesgo aceptado con motivo y detección compensatoria.",
+        "Escribe una prueba por control y ve fallar la prueba antes de confiar en ella.",
+        "Revisa las entradas que solo muerden con herramientas: exceso de agencia, tratamiento indebido de la salida, cadena de suministro.",
+        "Confirma que existen límites de tasa y cuotas y que devuelven señales correctas a los clientes bien educados.",
+        "Rehaz el mapeo siempre que cambie una herramienta, una fuente de datos o un nivel de autonomía.",
+        "Usa la numeración de la lista en los hallazgos para que revisores y proveedores hablen de la misma clase."
+      ],
+      "pitfalls": [
+        "Tratar la lista como objetivo de cumplimiento: cubrir diez titulares mientras la arquitectura real sigue sin examinarse.",
+        "Suponer que el trabajo de seguridad del proveedor del modelo cubre LLM01. Reduce los intentos; las consecuencias siguen siendo enteramente tuyas.",
+        "Mapear contra una edición en caché. La lista se revisa, y un mapeo antiguo deja de cubrir en silencio las clases actuales.",
+        "Saltarse LLM10 porque el consumo sin límite parece un problema de operaciones y no de seguridad.",
+        "Confundir nombrar una clase con controlarla. Una tabla de mapeo impecable sin aplicación es documentación del riesgo, no reducción."
+      ],
+      "examples": [
+        "Un agente que resume correos de clientes mapea a LLM01 (el cuerpo del correo es entrada de instrucciones no confiable), LLM02 (el resumen puede repetir datos que quien pregunta no debería ver) y LLM06 (la herramienta de CRM convierte el secuestro en acción): tres entradas de una sola funcionalidad, cada una con un control distinto.",
+        "Un sistema RAG sobre una wiki interna mapea a LLM01 por inyección indirecta desde cualquier editor de páginas, a LLM04 si el índice puede envenenarse y a LLM08 por recuperación que devuelve documentos fuera de los permisos de quien pregunta.",
+        "Un endpoint MCP público mapea sobre todo a LLM10: solo lectura y datos públicos, así que el límite de consumo —límites de tasa con cabeceras correctas— es la entrada que hace el trabajo de verdad."
+      ],
+      "faqs": [
+        {
+          "q": "¿Se puede ser conforme con el OWASP LLM Top 10?",
+          "a": "No. Es un documento de concienciación y clasificación, no una norma certificable. Encaja de forma natural con un sistema de gestión como ISO 42001 o un marco como el NIST AI RMF, que es donde viven de verdad las obligaciones de gobierno."
+        },
+        {
+          "q": "¿Qué entradas cambian más al dar herramientas al modelo?",
+          "a": "El exceso de agencia y el tratamiento indebido de la salida. Sin herramientas producen una respuesta equivocada; con herramientas producen una acción, y la gravedad pasa de bochorno a incidente."
+        },
+        {
+          "q": "¿Qué relación tiene con MITRE ATLAS?",
+          "a": "Responden preguntas distintas. OWASP nombra las clases de vulnerabilidad de tu aplicación; ATLAS cataloga las tácticas y técnicas que un adversario usa contra sistemas de IA. Una es una lista de comprobación sobre tu diseño, la otra un mapa del manual del atacante."
+        }
+      ]
+    },
+    "pt": {
+      "name": "OWASP Top 10 para Aplicações LLM",
+      "summary": "O OWASP Top 10 para aplicações LLM é o vocabulário comum do que dá errado em sistemas construídos sobre modelos de linguagem. Não é um framework de controles e não diz o que implementar: nomeia as classes de vulnerabilidade, da injeção de prompts ao excesso de agência e ao consumo sem limite, para que times, auditores e fornecedores discutam as mesmas coisas. Seu valor prático é servir de lista de verificação sobre a sua própria arquitetura e de idioma comum em que os achados são relatados.",
+      "definition": "O OWASP Top 10 para aplicações LLM é uma lista mantida pela comunidade com as classes de vulnerabilidade mais críticas em aplicações construídas sobre grandes modelos de linguagem, publicada pelo OWASP GenAI Security Project e revisada periodicamente conforme o ecossistema muda.",
+      "scope": "Qualquer aplicação construída sobre um grande modelo de linguagem: interfaces de chat, sistemas de recuperação, agentes e as ferramentas que eles invocam. É voluntária, não certificável e deliberadamente descritiva: classifica riscos, não prescreve controles nem concede conformidade.",
+      "keyPoints": [
+        "A injeção de prompts lidera a lista desde a primeira edição e continua sendo a classe sem solução limpa: apenas contenção em camadas.",
+        "A edição de 2025 cobre injeção de prompts, divulgação de informação sensível, cadeia de suprimentos, envenenamento de dados e modelo, tratamento indevido da saída, excesso de agência, vazamento do system prompt, fragilidades de vetores e embeddings, desinformação e consumo sem limite. A lista é revisada periodicamente, então consulte a edição vigente e não uma cópia em cache.",
+        "Várias entradas são na prática específicas de agentes: excesso de agência e tratamento indevido da saída só ficam graves quando o modelo pode agir.",
+        "É uma taxonomia, não um conjunto de controles. Mapear um achado para LLM06 diz que tipo de problema é, não o que construir.",
+        "É a língua franca da área: revisões de segurança, questionários de fornecedores e relatos de falha a citam, e essa é boa parte do motivo para conhecê-la por número.",
+        "Cobrir a lista não é uma postura de segurança. Cada entrada precisa de um controle na sua arquitetura, e uma entrada sem controle é um risco aceito, tenha alguém escrito isso ou não."
+      ],
+      "controls": [
+        {
+          "control": "Mapeie a lista sobre a sua própria arquitetura",
+          "note": "Percorra cada entrada diante das suas entradas reais, ferramentas, armazenamentos de dados e saídas. O exercício vale mais do que a lista, porque revela as entradas que não se aplicam e as superfícies que a lista não nomeia."
+        },
+        {
+          "control": "Atribua responsável e controle por entrada",
+          "note": "Cada classe aplicável precisa de um componente concreto que a limite e de uma pessoa que o mantenha. Uma entrada mapeada para nada é uma lacuna com número de referência."
+        },
+        {
+          "control": "Trate a injeção de prompts como contenção, não como prevenção",
+          "note": "LLM01 não tem solução confiável na camada do modelo. Os controles que importam são ferramentas com privilégio mínimo, restrição de saída, tratamento da saída e portões de aprovação para ações de alto impacto."
+        },
+        {
+          "control": "Limite a agência explicitamente",
+          "note": "Para LLM06, escreva o que o agente pode fazer, com quais credenciais e contra quais alvos — e aplique isso abaixo do modelo, não no prompt."
+        },
+        {
+          "control": "Trate a saída do modelo como entrada não confiável",
+          "note": "Para LLM05, tudo o que o modelo emite e chega a um renderizador, a um shell, a uma consulta ou a outro sistema precisa da mesma codificação e validação que você aplicaria à entrada de um desconhecido."
+        },
+        {
+          "control": "Limite o consumo",
+          "note": "Para LLM10, limites de taxa, cotas e timeouts transformam um ataque de disponibilidade e custo em uma recusa registrada. É a entrada que mais se pula porque não parece segurança até a fatura chegar."
+        },
+        {
+          "control": "Refaça o mapeamento quando a lista ou o sistema mudar",
+          "note": "A lista é revisada e o seu catálogo de ferramentas cresce. Um mapeamento feito uma vez é um documento sobre um sistema que já não existe."
+        }
+      ],
+      "checklist": [
+        "Leia a edição vigente em vez de um resumo, este incluído.",
+        "Produza uma tabela de mapeamento: entrada → aplica? → controle → responsável.",
+        "Para cada entrada aplicável sem controle, registre-a como risco aceito, com motivo e detecção compensatória.",
+        "Escreva um teste por controle e veja o teste falhar antes de confiar nele.",
+        "Revise as entradas que só mordem com ferramentas: excesso de agência, tratamento indevido da saída, cadeia de suprimentos.",
+        "Confirme que limites de taxa e cotas existem e devolvem sinais corretos a clientes bem-educados.",
+        "Refaça o mapeamento sempre que uma ferramenta, uma fonte de dados ou um nível de autonomia mudar.",
+        "Use a numeração da lista nos achados para que revisores e fornecedores falem da mesma classe."
+      ],
+      "pitfalls": [
+        "Tratar a lista como meta de conformidade: cobrir dez títulos enquanto a arquitetura real segue sem exame.",
+        "Supor que o trabalho de segurança do fornecedor do modelo cobre LLM01. Ele reduz as tentativas; as consequências continuam inteiramente suas.",
+        "Mapear contra uma edição em cache. A lista é revisada, e um mapeamento antigo deixa de cobrir em silêncio as classes atuais.",
+        "Pular LLM10 porque consumo sem limite parece problema de operações e não de segurança.",
+        "Confundir nomear uma classe com controlá-la. Uma tabela de mapeamento impecável sem aplicação é documentação do risco, não redução dele."
+      ],
+      "examples": [
+        "Um agente que resume e-mails de clientes mapeia para LLM01 (o corpo do e-mail é entrada de instruções não confiável), LLM02 (o resumo pode repetir dados que quem pergunta não deveria ver) e LLM06 (a ferramenta de CRM transforma o sequestro em ação): três entradas de uma única funcionalidade, cada uma com um controle diferente.",
+        "Um sistema RAG sobre uma wiki interna mapeia para LLM01 por injeção indireta a partir de qualquer editor de páginas, para LLM04 se o índice puder ser envenenado e para LLM08 por recuperação que devolve documentos fora das permissões de quem pergunta.",
+        "Um endpoint MCP público mapeia sobretudo para LLM10: somente leitura e dados públicos, então o limite de consumo — limites de taxa com cabeçalhos corretos — é a entrada que faz o trabalho de verdade."
+      ],
+      "faqs": [
+        {
+          "q": "É possível estar em conformidade com o OWASP LLM Top 10?",
+          "a": "Não. É um documento de conscientização e classificação, não uma norma certificável. Ele combina naturalmente com um sistema de gestão como a ISO 42001 ou um framework como o NIST AI RMF, que é onde as obrigações de governança de fato vivem."
+        },
+        {
+          "q": "Quais entradas mudam mais ao dar ferramentas ao modelo?",
+          "a": "Excesso de agência e tratamento indevido da saída. Sem ferramentas produzem uma resposta errada; com ferramentas produzem uma ação, e a gravidade passa de constrangimento a incidente."
+        },
+        {
+          "q": "Qual a relação com o MITRE ATLAS?",
+          "a": "Respondem perguntas diferentes. O OWASP nomeia as classes de vulnerabilidade da sua aplicação; o ATLAS cataloga as táticas e técnicas que um adversário usa contra sistemas de IA. Uma é uma lista de verificação sobre o seu design, a outra é um mapa do manual do atacante."
+        }
+      ]
+    }
+  }
+}

package/content/harness/HRN-001-definition-and-overview.es.md

@@ -0,0 +1,76 @@
+---
+title: "Ingeniería de Harness: definición y panorama"
+summary: "La Ingeniería de Harness es la disciplina que construye sistemas agénticos fiables para entornos empresariales: el andamiaje de ingeniería —memoria, herramientas, orquestación, observabilidad, evaluación, gobernanza y seguridad— que rodea al modelo."
+---
+
+# Ingeniería de Harness: definición y panorama
+
+## Resumen ejecutivo
+La Ingeniería de Harness es la disciplina responsable de construir sistemas agénticos fiables para entornos empresariales. Un modelo de lenguaje es un predictor probabilístico del siguiente token; una empresa necesita un sistema de confianza que haga el trabajo, respete la política y falle de forma segura. El harness es todo lo que se construye *alrededor* del modelo —memoria, herramientas, planificación, orquestación, observabilidad, evaluación, gobernanza y seguridad— para cerrar esa distancia. Este capítulo define la disciplina, enuncia su tesis y enmarca el resto del manual.
+
+## Conceptos clave
+- **Modelo:** el núcleo probabilístico (un LLM o un modelo multimodal) que transforma un contexto en una distribución sobre los siguientes tokens. Potente, pero sin estado, sin gobernanza y no determinista por defecto.
+- **Harness:** el andamiaje de ingeniería, determinista y semidetermista, que envuelve a uno o varios modelos para producir un sistema de confianza.
+- **Sistema agéntico:** aquel en el que un modelo dirige un bucle de percepción, razonamiento y acción sobre herramientas y un entorno para perseguir un objetivo.
+- **Fiabilidad:** la probabilidad de que el sistema produzca un resultado correcto, seguro y conforme a la política en condiciones y carga reales.
+- **Frontera de determinismo:** la línea deliberada que separa lo que el modelo puede decidir de lo que el harness fija en código.
+- **Entorno empresarial:** un contexto con riesgo real: datos regulados, requisitos de auditoría, acuerdos de nivel de servicio y adversarios.
+
+## Definición
+La **Ingeniería de Harness** es la disciplina de ingeniería que se ocupa del diseño, la construcción y la operación de los sistemas que rodean a los modelos probabilísticos, de modo que el sistema agéntico resultante sea suficientemente fiable, observable, gobernable y seguro para uso empresarial. Donde el aprendizaje automático produce el *modelo*, la Ingeniería de Harness produce el *sistema*. Su unidad de trabajo no es un prompt ni una matriz de pesos, sino el bucle completo que convierte un objetivo en un resultado verificado y auditable.
+
+## Explicación detallada
+La industria pasó de 2020 a 2023 aprendiendo que un modelo mejor es necesario pero no suficiente. Las demos que deslumbran con un prompt cuidado se derrumban en producción frente a entradas ambiguas, usuarios hostiles, datos obsoletos, fallos parciales de herramientas y el simple hecho de que la misma entrada puede dar dos salidas distintas. La respuesta no fue «un modelo más listo» sino *un sistema de ingeniería alrededor del modelo*. Ese sistema es el harness, y construirlo bien es una disciplina propia.
+
+La tesis central de este manual es una **separación de responsabilidades**: el modelo aporta razonamiento abierto y lenguaje; el harness aporta todo lo que hace que ese razonamiento sea *de fiar*. Trata al modelo como a un contratista brillante, rápido y poco fiable. No le darías a alguien así acceso sin supervisión a producción, sin alcance definido, sin registro, sin revisión y sin marcha atrás. El harness es el alcance, el registro, la revisión y la marcha atrás.
+
+**El modelo no es el sistema.** Un ejercicio mental útil es restar el modelo y preguntarse qué queda. Lo que queda es el harness, y ahí vive la inmensa mayoría del esfuerzo de ingeniería empresarial:
+
+- La **memoria** decide qué ve el modelo: qué se recupera, se comprime, se recuerda y se olvida (véase HRN-005).
+- Las **herramientas** son cómo actúa el agente sobre el mundo, con contratos tipados y semántica de fallo.
+- La **planificación** descompone objetivos y gestiona subobjetivos y replanificación.
+- La **orquestación** ejecuta el bucle: quién llama al modelo, con qué contexto y qué ocurre con la salida.
+- La **observabilidad** convierte cada paso en una traza reproducible (véase HRN-006).
+- La **evaluación** transforma «parece que funciona» en calidad medida y protegida frente a regresiones (véase HRN-007).
+- La **gobernanza** codifica política, aprobaciones y rendición de cuentas como controles aplicados.
+- La **seguridad** trata al modelo como componente no confiable y manipulable, y se defiende en consecuencia.
+
+No son extras opcionales: son la estructura portante. La taxonomía de HRN-003 precisa la descomposición, y HRN-004 enuncia los principios de ingeniería que valen para todas ellas.
+
+**¿Por qué una disciplina nueva?** Porque los modos de fallo son nuevos. El software clásico es determinista: dada una entrada, calcula la misma salida, y lo pruebas con aserciones. Los sistemas agénticos son *estocásticos y autodirigidos*: la misma entrada puede tomar caminos distintos, invocar herramientas distintas y llegar a conclusiones distintas (a veces erróneas). No puedes llegar a la confianza a base de aserciones; tienes que *medir distribuciones*, acotar la autoridad del modelo e instrumentarlo todo. Las capacidades que exige —fiabilidad probabilística, diseño de evaluación, ingeniería de contexto, diseño de contratos de herramientas y seguridad adversaria— no encajan limpiamente ni en el aprendizaje automático tradicional ni en la ingeniería de backend. Ese hueco es la disciplina.
+
+**Para quién es.** La Ingeniería de Harness es para los equipos responsables de poner agentes en producción donde importa: ingeniería de plataforma que construye runtimes de agentes, ingeniería de IA aplicada que entrega funcionalidades agénticas, las funciones de seguridad y gobernanza que deben dar el visto bueno, y los arquitectos que responden del conjunto. Es explícitamente *enterprise-first*: las restricciones que definen la disciplina —auditoría, regulación, SLA, adversarios, escala— son precisamente las que el utillaje de aficionado ignora.
+
+**Una opinión, dicha sin rodeos:** el modelo es cada vez más una materia prima; el harness es el activo de ingeniería duradero y el foso defensivo. A medida que los modelos frontera convergen y se vuelven intercambiables, el valor diferencial y defendible de un sistema de IA empresarial migra hacia el harness: su arquitectura de memoria, su corpus de evaluación, sus controles de gobernanza, su observabilidad. Invertir en el harness es invertir en la parte que compone.
+
+## Modos de fallo observados
+- **Pensamiento centrado en el modelo:** los equipos sobreinvierten en ajustar prompts y elegir modelo mientras infrainvierten en el harness, y luego culpan al modelo de fallos sistémicos.
+- **El precipicio de la demo a producción:** un sistema que funciona en demos de camino feliz no tiene disciplina de memoria, ni observabilidad, ni evaluación, así que no sobrevive al contacto con la carga real.
+- **Autoridad sin límites:** se permite al modelo decidir cosas que deberían estar fijadas en código determinista, produciendo acciones irreversibles o no auditables.
+- **Ausencia de medición:** sin evaluación, las regresiones se despliegan en silencio y las «mejoras» son intuiciones, no evidencia.
+
+## Métricas de coste
+En un sistema ingenuo, el coste dominante es la inferencia del modelo (tokens de entrada y salida). Un harness bien construido *reduce* ese coste mediante compresión de memoria, caché, enrutado de peticiones baratas a modelos baratos y cortocircuitos con lógica determinista, a cambio de costes fijos modestos de almacenamiento de observabilidad y ejecuciones de evaluación. Los harness maduros suelen desplazar el gasto de la inferencia por llamada hacia infraestructura amortizada, bajando el coste por tarea exitosa aunque crezca la instrumentación por petición.
+
+## Características de escalado
+Es el harness, no el modelo, quien determina cómo escala el sistema. La concurrencia, el estado de la memoria, el abanico de la orquestación y la contrapresión de las herramientas gobiernan el rendimiento y la latencia de cola. La fiabilidad tiende a *degradarse de forma no lineal* con la complejidad de la tarea (número de pasos y herramientas), y por eso el harness debe diseñarse para degradar con elegancia en lugar de asumir una tasa de éxito fija.
+
+## Contenido relacionado
+- HRN-002 — Breve historia de la Ingeniería de Harness
+- HRN-003 — La taxonomía del harness
+- HRN-004 — Principios de Ingeniería de Harness
+
+## Referencias
+- Observación de industria sobre la «brecha demo-producción» en sistemas agénticos (2023–2026).
+- Literatura de práctica sobre arquitecturas de agentes, uso de herramientas y marcos de orquestación de LLM.
+- Santa María, S. — Notas de trabajo sobre la Ingeniería de Harness como disciplina.
+
+## Preguntas frecuentes
+**P:** ¿La Ingeniería de Harness es ingeniería de prompts con otro nombre?
+**R:** No. La ingeniería de prompts optimiza una única interacción con el modelo. La Ingeniería de Harness construye todo el sistema fiable que lo rodea: memoria, herramientas, orquestación, observabilidad, evaluación, gobernanza y seguridad. El prompt es una entrada pequeña a un solo componente.
+
+**P:** Si los modelos siguen mejorando, ¿no dejará de hacer falta el harness?
+**R:** Al contrario. Modelos mejores elevan el techo de lo que los agentes intentan, lo que aumenta el riesgo y la superficie que el harness debe gobernar, observar y proteger. El harness es donde viven la fiabilidad empresarial y la diferenciación.
+
+**P:** ¿Por dónde empiezo?
+**R:** Lee HRN-003 (la taxonomía) para situar los componentes y luego HRN-004 (los principios). Empieza instrumentando con observabilidad (HRN-006) antes de optimizar nada: no puedes mejorar lo que no puedes medir.

package/content/harness/HRN-001-definition-and-overview.md

@@ -0,0 +1,125 @@
+---
+id: HRN-001
+title: "Harness Engineering: Definition and Overview"
+domain: Harness
+category: Foundations
+status: Draft
+author: Santiago Santa María
+created: 2026-06-21
+updated: 2026-06-21
+summary: Harness Engineering is the discipline of building reliable agentic systems for enterprise environments — the engineered scaffolding of memory, tools, orchestration, observability, evaluation, governance, and security that surrounds the model.
+evidence_level: theoretical
+confidence_level: medium
+source_type:
+  - industry_observation
+  - personal_experience
+related:
+  - HRN-002
+  - HRN-003
+  - HRN-004
+tags:
+  - harness-engineering
+  - agentic-systems
+  - foundations
+  - reliability
+  - enterprise-ai
+---
+
+# Harness Engineering: Definition and Overview
+
+## Executive Summary
+Harness Engineering is the discipline responsible for building reliable agentic systems for enterprise environments. A large language model is a probabilistic next-token predictor; an enterprise needs a dependable system that performs work, respects policy, and fails safely. The harness is everything engineered *around* the model — memory, tools, planning, orchestration, observability, evaluation, governance, and security — that closes the gap between the two. This chapter defines the discipline, states its thesis, and frames the rest of the handbook.
+
+## Key Concepts
+- **Model:** The probabilistic core (an LLM or multimodal model) that maps a context to a distribution over next tokens. Powerful, but stateless, ungoverned, and non-deterministic by default.
+- **Harness:** The deterministic and semi-deterministic engineering scaffolding wrapped around one or more models to produce a dependable system.
+- **Agentic system:** A system in which a model drives a loop of perception, reasoning, and action against tools and an environment to pursue a goal.
+- **Reliability:** The probability that the system produces a correct, safe, and policy-compliant outcome under real conditions and load.
+- **Determinism boundary:** The deliberate line separating what the model is allowed to decide from what the harness fixes in code.
+- **Enterprise environment:** A setting with real stakes — regulated data, audit requirements, SLAs, and adversaries.
+
+## Definition
+**Harness Engineering** is the engineering discipline concerned with the design, construction, and operation of the systems that surround probabilistic models so that the resulting agentic system is reliable, observable, governable, and secure enough for enterprise use. Where machine learning produces the *model*, Harness Engineering produces the *system*. Its unit of work is not a prompt or a weight matrix but the end-to-end loop that turns a goal into a verified, auditable outcome.
+
+## Architecture Diagram
+```mermaid
+flowchart TB
+  subgraph Harness["The Harness (engineered scaffolding)"]
+    direction TB
+    PL[Planning & Goal Mgmt]
+    OR[Orchestration]
+    MEM[Memory]
+    TL[Tools / Actuation]
+    OBS[Observability]
+    EVAL[Evaluation]
+    GOV[Governance]
+    SEC[Security]
+  end
+  USER([Goal / Request]) --> PL
+  PL --> OR
+  OR <--> MODEL{{Probabilistic Model}}
+  OR <--> MEM
+  OR <--> TL
+  TL <--> ENV[(Enterprise Systems & Data)]
+  OBS -.instruments.- OR
+  EVAL -.scores.- OR
+  GOV -.constrains.- OR
+  SEC -.guards.- TL
+  OR --> OUT([Verified, Auditable Outcome])
+```
+
+## Detailed Explanation
+The industry spent 2020–2023 learning that a better model is necessary but not sufficient. Demos that dazzle on a curated prompt collapse in production against ambiguous inputs, hostile users, stale data, partial tool failures, and the simple fact that the same input can yield a different output twice. The response was not "a smarter model" but *an engineered system around the model*. That system is the harness, and building it well is its own discipline.
+
+The central claim of this handbook is a **separation of concerns**: the model supplies open-ended reasoning and language; the harness supplies everything that makes that reasoning *dependable*. Treat the model as a brilliant, fast, and unreliable contractor. You would not hand such a contractor unmonitored access to production with no scope, no logging, no review, and no rollback. The harness is the scope, the logging, the review, and the rollback.
+
+**The model is not the system.** A useful mental model is to subtract the model and ask what remains. What remains is the harness, and it is where the overwhelming majority of enterprise engineering effort lives:
+
+- **Memory** decides what the model sees: what is retrieved, compressed, remembered, and forgotten (see HRN-005).
+- **Tools** are how the agent acts on the world, with typed contracts and failure semantics.
+- **Planning** decomposes goals and manages sub-goals and re-planning.
+- **Orchestration** runs the loop: who calls the model, with what context, and what happens to the output.
+- **Observability** makes every step a traceable, replayable span (see HRN-006).
+- **Evaluation** turns "it seems to work" into measured, regression-guarded quality (see HRN-007).
+- **Governance** encodes policy, approvals, and accountability as enforced controls.
+- **Security** treats the model as an untrusted, manipulable component and defends accordingly.
+
+These are not optional add-ons; they are the load-bearing structure. The taxonomy in HRN-003 makes the decomposition precise, and HRN-004 states the engineering principles that hold across all of them.
+
+**Why a new discipline?** Because the failure modes are new. Classical software is deterministic: given an input, it computes the same output, and you test it with assertions. Agentic systems are *stochastic and self-directed*: the same input may take different paths, invoke different tools, and reach different (sometimes wrong) conclusions. You cannot assert your way to confidence; you must *measure distributions*, bound the model's authority, and instrument everything. The skills required — probabilistic reliability, evaluation design, prompt-and-context engineering, tool contract design, and adversarial security — do not map cleanly onto either traditional ML or traditional backend engineering. That gap is the discipline.
+
+**Who it is for.** Harness Engineering is for the teams accountable for putting agents into production where it matters: platform engineers building agent runtimes, ML and applied-AI engineers shipping agentic features, security and governance functions who must sign off, and the architects who own the whole. It is explicitly *enterprise-first* — the constraints that define the discipline (audit, regulation, SLAs, adversaries, scale) are precisely the ones hobbyist tooling ignores.
+
+**An opinion, stated plainly:** the model is increasingly a commodity; the harness is the durable engineering asset and the moat. As frontier models converge and become swappable, the differentiated, defensible value of an enterprise AI system migrates into the harness — its memory architecture, its evaluation corpus, its governance controls, its observability. Investing in the harness is investing in the part that compounds.
+
+## Observed Failure Modes
+- **Model-centric thinking:** Teams over-invest in prompt tweaking and model selection while under-investing in the harness, then blame the model for systemic failures.
+- **Demo-to-production cliff:** A system that works on happy-path demos has no memory discipline, no observability, and no evaluation, so it cannot survive contact with real load.
+- **Unbounded authority:** The model is allowed to decide things that should be fixed in deterministic code, producing unrecoverable or non-auditable actions.
+- **No measurement:** Without evaluation, regressions ship silently and "improvements" are vibes, not evidence.
+
+## Cost Metrics
+The dominant cost driver in a naive system is model inference (tokens in/out). A well-engineered harness *reduces* this through memory compression, caching, routing cheap requests to cheap models, and short-circuiting with deterministic logic — while adding modest fixed costs for observability storage and evaluation runs. Mature harnesses typically shift spend from per-call inference toward amortized infrastructure, lowering cost per successful task even as per-request instrumentation grows.
+
+## Scaling Characteristics
+The harness, not the model, determines how the system scales. Concurrency, statefulness of memory, orchestration fan-out, and tool back-pressure govern throughput and tail latency. Reliability tends to *degrade non-linearly* with task complexity (number of steps and tools), which is why the harness must be designed for graceful degradation rather than assuming a fixed success rate.
+
+## Related Content
+- HRN-002 — A Brief History of Harness Engineering
+- HRN-003 — The Harness Taxonomy
+- HRN-004 — Harness Engineering Principles
+
+## References
+- Industry observation on the "demo-to-production gap" in agentic systems (2023–2026).
+- Practitioner literature on agent architectures, tool use, and LLM orchestration frameworks.
+- Santa María, S. — Working notes on Harness Engineering as a discipline.
+
+## FAQs
+**Q:** Is Harness Engineering just prompt engineering with a new name?
+**A:** No. Prompt engineering optimizes a single model interaction. Harness Engineering builds the whole reliable system around the model — memory, tools, orchestration, observability, evaluation, governance, and security. Prompting is one small input to one component.
+
+**Q:** If models keep getting better, won't the harness become unnecessary?
+**A:** The opposite. Better models raise the ceiling of what agents attempt, which increases the stakes and the surface area the harness must govern, observe, and secure. The harness is where enterprise reliability and differentiation live.
+
+**Q:** Where do I start?
+**A:** Read HRN-003 (the taxonomy) to map the components, then HRN-004 (principles). Begin instrumenting with observability (HRN-006) before optimizing anything — you cannot improve what you cannot measure.

package/content/harness/HRN-001-definition-and-overview.pt.md

@@ -0,0 +1,76 @@
+---
+title: "Engenharia de Harness: definição e panorama"
+summary: "A Engenharia de Harness é a disciplina que constrói sistemas agênticos confiáveis para ambientes empresariais: o andaime de engenharia — memória, ferramentas, orquestração, observabilidade, avaliação, governança e segurança — que rodeia o modelo."
+---
+
+# Engenharia de Harness: definição e panorama
+
+## Resumo executivo
+A Engenharia de Harness é a disciplina responsável por construir sistemas agênticos confiáveis para ambientes empresariais. Um modelo de linguagem é um preditor probabilístico do próximo token; uma empresa precisa de um sistema de confiança que faça o trabalho, respeite a política e falhe em segurança. O harness é tudo aquilo que se constrói *em torno* do modelo — memória, ferramentas, planejamento, orquestração, observabilidade, avaliação, governança e segurança — para fechar essa distância. Este capítulo define a disciplina, enuncia sua tese e enquadra o resto do manual.
+
+## Conceitos-chave
+- **Modelo:** o núcleo probabilístico (um LLM ou um modelo multimodal) que transforma um contexto numa distribuição sobre os próximos tokens. Poderoso, mas sem estado, sem governança e não determinista por padrão.
+- **Harness:** o andaime de engenharia, determinista e semideterminista, que envolve um ou vários modelos para produzir um sistema de confiança.
+- **Sistema agêntico:** aquele em que um modelo conduz um ciclo de percepção, raciocínio e ação sobre ferramentas e um ambiente para perseguir um objetivo.
+- **Confiabilidade:** a probabilidade de o sistema produzir um resultado correto, seguro e conforme à política em condições e carga reais.
+- **Fronteira de determinismo:** a linha deliberada que separa o que o modelo pode decidir daquilo que o harness fixa em código.
+- **Ambiente empresarial:** um contexto com risco real: dados regulados, requisitos de auditoria, acordos de nível de serviço e adversários.
+
+## Definição
+A **Engenharia de Harness** é a disciplina de engenharia que se ocupa da concepção, construção e operação dos sistemas que rodeiam modelos probabilísticos, de modo que o sistema agêntico resultante seja suficientemente confiável, observável, governável e seguro para uso empresarial. Onde a aprendizagem automática produz o *modelo*, a Engenharia de Harness produz o *sistema*. Sua unidade de trabalho não é um prompt nem uma matriz de pesos, mas o ciclo completo que converte um objetivo num resultado verificado e auditável.
+
+## Explicação detalhada
+A indústria passou de 2020 a 2023 a aprender que um modelo melhor é necessário mas não suficiente. As demonstrações que deslumbram com um prompt cuidado se desmoronam em produção perante entradas ambíguas, usuários hostis, dados desatualizados, falhas parciais de ferramentas e o simples fato de a mesma entrada poder dar duas saídas diferentes. A resposta não foi “um modelo mais inteligente”, mas *um sistema de engenharia em torno do modelo*. Esse sistema é o harness, e construí-lo bem é uma disciplina própria.
+
+A tese central deste manual é uma **separação de responsabilidades**: o modelo fornece raciocínio aberto e linguagem; o harness fornece tudo o que torna esse raciocínio *de confiança*. Trate o modelo como um empreiteiro brilhante, rápido e pouco confiável. Não daria a alguém assim acesso sem supervisão a produção, sem âmbito definido, sem registro, sem revisão e sem marcha-atrás. O harness é o âmbito, o registro, a revisão e a marcha-atrás.
+
+**O modelo não é o sistema.** Um exercício mental útil é subtrair o modelo e perguntar o que resta. O que resta é o harness, e é aí que vive a esmagadora maioria do esforço de engenharia empresarial:
+
+- A **memória** decide o que o modelo vê: o que é recuperado, comprimido, recordado e esquecido (ver HRN-005).
+- As **ferramentas** são a forma como o agente atua sobre o mundo, com contratos tipados e semântica de falha.
+- O **planejamento** decompõe objetivos e gerencia subobjetivos e replanejamento.
+- A **orquestração** executa o ciclo: quem chama o modelo, com que contexto e o que acontece à saída.
+- A **observabilidade** transforma cada passo num traço reproduzível (ver HRN-006).
+- A **avaliação** converte “parece que funciona” em qualidade medida e protegida contra regressões (ver HRN-007).
+- A **governança** codifica política, aprovações e prestação de contas como controles aplicados.
+- A **segurança** trata o modelo como componente não confiável e manipulável, e se defende em conformidade.
+
+Não são extras opcionais: são a estrutura portante. A taxonomia de HRN-003 torna a decomposição precisa, e HRN-004 enuncia os princípios de engenharia que valem para todas elas.
+
+**Por que uma disciplina nova?** Porque os modos de falha são novos. O software clássico é determinista: dada uma entrada, calcula a mesma saída, e se testa com asserções. Os sistemas agênticos são *estocásticos e autodirigidos*: a mesma entrada pode seguir caminhos diferentes, invocar ferramentas diferentes e chegar a conclusões diferentes (por vezes erradas). Não se chega à confiança à custa de asserções; é preciso *medir distribuições*, limitar a autoridade do modelo e instrumentar tudo. As competências exigidas — confiabilidade probabilística, concepção de avaliação, engenharia de contexto, concepção de contratos de ferramentas e segurança adversária — não encaixam de forma limpa nem na aprendizagem automática tradicional nem na engenharia de backend. Essa lacuna é a disciplina.
+
+**Para quem é.** A Engenharia de Harness é para as equipes responsáveis por colocar agentes em produção onde isso importa: engenharia de plataforma que constrói runtimes de agentes, engenharia de IA aplicada que entrega funcionalidades agênticas, as funções de segurança e governança que têm de dar o aval, e os arquitetos que respondem pelo conjunto. É explicitamente *enterprise-first*: as restrições que definem a disciplina — auditoria, regulação, SLA, adversários, escala — são precisamente as que a ferramentaria de amador ignora.
+
+**Uma opinião, dita sem rodeios:** o modelo é cada vez mais uma matéria-prima; o harness é o ativo de engenharia duradouro e o fosso defensivo. À medida que os modelos de fronteira convergem e se tornam intermutáveis, o valor diferenciador e defensável de um sistema de IA empresarial migra para o harness: sua arquitetura de memória, seu corpus de avaliação, seus controles de governança, sua observabilidade. Investir no harness é investir na parte que compõe.
+
+## Modos de falha observados
+- **Pensamento centrado no modelo:** as equipes sobreinvestem em ajustar prompts e escolher modelo enquanto subinvestem no harness, e depois culpam o modelo por falhas sistêmicas.
+- **O precipício da demonstração para produção:** um sistema que funciona em demonstrações de caminho feliz não tem disciplina de memória, nem observabilidade, nem avaliação, portanto não sobrevive ao contato com a carga real.
+- **Autoridade sem limites:** permite-se ao modelo decidir coisas que deveriam estar fixadas em código determinista, produzindo ações irreversíveis ou não auditáveis.
+- **Ausência de medição:** sem avaliação, as regressões são implantadas em silêncio e as “melhorias” são intuições, não evidência.
+
+## Métricas de custo
+Num sistema ingênuo, o custo dominante é a inferência do modelo (tokens de entrada e saída). Um harness bem construído *reduz* esse custo através de compressão de memória, cache, encaminhamento de pedidos baratos para modelos baratos e curto-circuitos com lógica determinista, em troca de custos fixos modestos de armazenamento de observabilidade e execuções de avaliação. Os harnesses maduros tendem a deslocar a despesa da inferência por chamada para infraestrutura amortizada, baixando o custo por tarefa bem-sucedida mesmo com o crescimento da instrumentação por pedido.
+
+## Características de escalabilidade
+É o harness, não o modelo, que determina como o sistema escala. A concorrência, o estado da memória, o leque da orquestração e a contrapressão das ferramentas governam o débito e a latência de cauda. A confiabilidade tende a *degradar-se de forma não linear* com a complexidade da tarefa (número de passos e ferramentas), e é por isso que o harness deve ser concebido para degradar com elegância em vez de assumir uma taxa de sucesso fixa.
+
+## Conteúdo relacionado
+- HRN-002 — Breve história da Engenharia de Harness
+- HRN-003 — A taxonomia do harness
+- HRN-004 — Princípios de Engenharia de Harness
+
+## Referências
+- Observação de indústria sobre a “lacuna demonstração-produção” em sistemas agênticos (2023–2026).
+- Literatura de prática sobre arquiteturas de agentes, uso de ferramentas e frameworks de orquestração de LLM.
+- Santa María, S. — Notas de trabalho sobre a Engenharia de Harness como disciplina.
+
+## Perguntas frequentes
+**P:** A Engenharia de Harness é engenharia de prompts com outro nome?
+**R:** Não. A engenharia de prompts otimiza uma única interação com o modelo. A Engenharia de Harness constrói todo o sistema confiável que o rodeia: memória, ferramentas, orquestração, observabilidade, avaliação, governança e segurança. O prompt é uma entrada pequena para um único componente.
+
+**P:** Se os modelos continuam a melhorar, o harness não deixará de ser necessário?
+**R:** Pelo contrário. Modelos melhores elevam o teto daquilo que os agentes tentam, o que aumenta o risco e a superfície que o harness tem de governar, observar e proteger. O harness é onde vivem a confiabilidade empresarial e a diferenciação.
+
+**P:** Por onde começo?
+**R:** Leia HRN-003 (a taxonomia) para situar os componentes e depois HRN-004 (os princípios). Comece por instrumentar com observabilidade (HRN-006) antes de otimizar seja o que for: não se pode melhorar o que não se consegue medir.