santismm-knowledge-mcp 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +62 -0
- package/content/CONVENTIONS.md +77 -0
- package/content/LICENSE +55 -0
- package/content/architectures/ai-workforce.json +280 -0
- package/content/architectures/customer-service-agent.json +292 -0
- package/content/architectures/enterprise-knowledge-assistant.json +292 -0
- package/content/architectures/operations-center.json +280 -0
- package/content/architectures/sales-copilot.json +280 -0
- package/content/governance/agentic-ai-governance-checklist.json +323 -0
- package/content/governance/audit-framework-for-agentic-systems.json +280 -0
- package/content/governance/enterprise-ai-governance-framework.json +277 -0
- package/content/governance/eu-ai-act.json +162 -0
- package/content/governance/human-oversight-and-accountability-policy.json +275 -0
- package/content/governance/iso-42001.json +161 -0
- package/content/governance/mitre-atlas.json +280 -0
- package/content/governance/nist-ai-rmf.json +161 -0
- package/content/governance/owasp-llm-top10.json +301 -0
- package/content/harness/HRN-001-definition-and-overview.es.md +76 -0
- package/content/harness/HRN-001-definition-and-overview.md +125 -0
- package/content/harness/HRN-001-definition-and-overview.pt.md +76 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.es.md +83 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.md +113 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.pt.md +83 -0
- package/content/harness/HRN-003-the-harness-taxonomy.es.md +105 -0
- package/content/harness/HRN-003-the-harness-taxonomy.md +158 -0
- package/content/harness/HRN-003-the-harness-taxonomy.pt.md +105 -0
- package/content/harness/HRN-004-harness-engineering-principles.es.md +91 -0
- package/content/harness/HRN-004-harness-engineering-principles.md +135 -0
- package/content/harness/HRN-004-harness-engineering-principles.pt.md +91 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.es.md +98 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.md +145 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.pt.md +98 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.es.md +97 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.md +139 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.pt.md +97 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.es.md +96 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.md +145 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.pt.md +96 -0
- package/content/harness/HRN-008-governance-within-the-harness.es.md +105 -0
- package/content/harness/HRN-008-governance-within-the-harness.md +146 -0
- package/content/harness/HRN-008-governance-within-the-harness.pt.md +105 -0
- package/content/harness/HRN-009-planning-and-goal-management.es.md +102 -0
- package/content/harness/HRN-009-planning-and-goal-management.md +142 -0
- package/content/harness/HRN-009-planning-and-goal-management.pt.md +102 -0
- package/content/harness/HRN-010-orchestration.es.md +107 -0
- package/content/harness/HRN-010-orchestration.md +149 -0
- package/content/harness/HRN-010-orchestration.pt.md +107 -0
- package/content/harness/HRN-011-security-for-agentic-systems.es.md +107 -0
- package/content/harness/HRN-011-security-for-agentic-systems.md +147 -0
- package/content/harness/HRN-011-security-for-agentic-systems.pt.md +107 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.es.md +120 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.md +157 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.pt.md +120 -0
- package/content/harness/HRN-013-glossary.es.md +109 -0
- package/content/harness/HRN-013-glossary.md +124 -0
- package/content/harness/HRN-013-glossary.pt.md +109 -0
- package/content/harness/HRN-014-bibliography.es.md +89 -0
- package/content/harness/HRN-014-bibliography.md +109 -0
- package/content/harness/HRN-014-bibliography.pt.md +89 -0
- package/content/homeric/episodes/achilles-and-hector.json +139 -0
- package/content/homeric/episodes/aeolus-and-the-winds.json +131 -0
- package/content/homeric/episodes/agamemnons-murder.json +162 -0
- package/content/homeric/episodes/calypso-ogygia.json +157 -0
- package/content/homeric/episodes/catalogue-of-ships.json +177 -0
- package/content/homeric/episodes/cattle-of-the-sun.json +131 -0
- package/content/homeric/episodes/chryse-and-the-plague.json +131 -0
- package/content/homeric/episodes/cicones-at-ismarus.json +131 -0
- package/content/homeric/episodes/circe-on-aeaea.json +131 -0
- package/content/homeric/episodes/cyclops-polyphemus.json +162 -0
- package/content/homeric/episodes/laestrygonians.json +153 -0
- package/content/homeric/episodes/lotus-eaters.json +138 -0
- package/content/homeric/episodes/menelaus-and-proteus.json +130 -0
- package/content/homeric/episodes/nekyia.json +160 -0
- package/content/homeric/episodes/phaeacians-on-scheria.json +129 -0
- package/content/homeric/episodes/priams-ransom.json +131 -0
- package/content/homeric/episodes/return-to-ithaca.json +167 -0
- package/content/homeric/episodes/scylla-and-charybdis.json +131 -0
- package/content/homeric/episodes/suitors-ambush-at-asteris.json +131 -0
- package/content/homeric/episodes/telemachus-at-pylos.json +130 -0
- package/content/homeric/episodes/telemachus-in-sparta.json +130 -0
- package/content/homeric/episodes/the-achaean-camp.json +138 -0
- package/content/homeric/episodes/the-sirens.json +129 -0
- package/content/homeric/episodes/wooden-horse.json +168 -0
- package/content/homeric/places/aeaea.json +129 -0
- package/content/homeric/places/aeolia.json +161 -0
- package/content/homeric/places/asteris.json +120 -0
- package/content/homeric/places/aulis.json +122 -0
- package/content/homeric/places/cape-malea.json +126 -0
- package/content/homeric/places/chryse.json +120 -0
- package/content/homeric/places/dodona.json +129 -0
- package/content/homeric/places/dulichium.json +177 -0
- package/content/homeric/places/egypt.json +125 -0
- package/content/homeric/places/ephyra-acheron.json +127 -0
- package/content/homeric/places/hellespont.json +125 -0
- package/content/homeric/places/house-of-hades.json +91 -0
- package/content/homeric/places/ismarus.json +120 -0
- package/content/homeric/places/ithaca.json +240 -0
- package/content/homeric/places/knossos.json +132 -0
- package/content/homeric/places/laestrygonia.json +168 -0
- package/content/homeric/places/land-of-the-cyclopes.json +169 -0
- package/content/homeric/places/land-of-the-lotus-eaters.json +122 -0
- package/content/homeric/places/mount-ida.json +126 -0
- package/content/homeric/places/mycenae.json +152 -0
- package/content/homeric/places/ogygia.json +125 -0
- package/content/homeric/places/pharos.json +120 -0
- package/content/homeric/places/planctae.json +77 -0
- package/content/homeric/places/pylos.json +188 -0
- package/content/homeric/places/same.json +177 -0
- package/content/homeric/places/scheria.json +129 -0
- package/content/homeric/places/scylla-and-charybdis.json +135 -0
- package/content/homeric/places/sirens.json +127 -0
- package/content/homeric/places/sparta.json +179 -0
- package/content/homeric/places/tenedos.json +129 -0
- package/content/homeric/places/thrinacia.json +116 -0
- package/content/homeric/places/tiryns.json +123 -0
- package/content/homeric/places/troy.json +224 -0
- package/content/homeric/places/zacynthus.json +126 -0
- package/content/homeric/routes/achaean-expedition.json +132 -0
- package/content/homeric/routes/nostoi-of-the-others.json +205 -0
- package/content/homeric/routes/odysseus-nostos.json +307 -0
- package/content/homeric/routes/telemachy.json +134 -0
- package/content/knowledge/agent-memory.json +153 -0
- package/content/knowledge/agentic-ai.json +158 -0
- package/content/knowledge/agentic-evaluation.json +156 -0
- package/content/knowledge/agentic-threat-model.json +287 -0
- package/content/knowledge/ai-agent.json +153 -0
- package/content/knowledge/ai-cyberdefense.json +274 -0
- package/content/knowledge/ai-governance.json +155 -0
- package/content/knowledge/ai-observability.json +156 -0
- package/content/knowledge/context-engineering.json +153 -0
- package/content/knowledge/embeddings.json +153 -0
- package/content/knowledge/enterprise-rag.json +154 -0
- package/content/knowledge/fine-tuning.json +153 -0
- package/content/knowledge/foundation-models.json +154 -0
- package/content/knowledge/guardrails.json +153 -0
- package/content/knowledge/harness-engineering.json +158 -0
- package/content/knowledge/human-in-the-loop.json +153 -0
- package/content/knowledge/mcp-security.json +284 -0
- package/content/knowledge/model-context-protocol.json +154 -0
- package/content/knowledge/multi-agent-architecture.json +153 -0
- package/content/knowledge/prompt-engineering.json +153 -0
- package/content/knowledge/prompt-injection.json +138 -0
- package/content/knowledge/reasoning-models.json +153 -0
- package/content/knowledge/tool-use.json +156 -0
- package/content/library/cognitive-architecture-emergent-ai.md +15 -0
- package/content/library/devready-ep108-ai-customer-experiences.md +14 -0
- package/content/library/how-genai-impact-business.md +12 -0
- package/content/library/lmm-reshaping-industries-2024.md +12 -0
- package/content/library/rethinking-ai-pause.md +12 -0
- package/content/library/rise-of-agentic-ai.md +16 -0
- package/content/library/self-improving-autonomous-ai.md +16 -0
- package/content/library/the-stopwatch-and-the-exam.md +12 -0
- package/content/library/unlock-gpt4-secrets.md +12 -0
- package/content/library/vibe-coding-enterprise.md +15 -0
- package/content/library/video-transformando-negocios-genai.md +14 -0
- package/content/library/video-volando-alto-sky-airlines.md +13 -0
- package/content/matrix/agentic-control-matrix.json +967 -0
- package/content/patterns/attributed-memory.json +237 -0
- package/content/patterns/context-compression.json +304 -0
- package/content/patterns/egress-allowlist.json +310 -0
- package/content/patterns/evaluator-optimizer.json +180 -0
- package/content/patterns/goal-decomposition.json +290 -0
- package/content/patterns/human-approval-gate.json +311 -0
- package/content/patterns/human-escalation.json +288 -0
- package/content/patterns/least-privilege-tooling.json +333 -0
- package/content/patterns/long-term-memory.json +305 -0
- package/content/patterns/orchestrator-workers.json +202 -0
- package/content/patterns/parallelization.json +180 -0
- package/content/patterns/prompt-chaining.json +181 -0
- package/content/patterns/recovery-strategy.json +305 -0
- package/content/patterns/reflection.json +298 -0
- package/content/patterns/routing.json +294 -0
- package/content/patterns/sandboxed-execution.json +311 -0
- package/content/patterns/semantic-caching.json +201 -0
- package/content/patterns/supervisor-agent.json +290 -0
- package/content/patterns/task-prioritization.json +307 -0
- package/dist/content.js +181 -0
- package/dist/index.js +27 -0
- package/dist/shape.js +649 -0
- package/dist/tools.js +652 -0
- package/package.json +47 -0
|
@@ -0,0 +1,158 @@
|
|
|
1
|
+
{
|
|
2
|
+
"slug": "harness-engineering",
|
|
3
|
+
"category": "harness",
|
|
4
|
+
"updated": "2026-06-21",
|
|
5
|
+
"version": "1.0",
|
|
6
|
+
"featured": true,
|
|
7
|
+
"related": ["agentic-ai", "ai-agent", "context-engineering", "agent-memory", "ai-observability", "multi-agent-architecture", "agentic-evaluation"],
|
|
8
|
+
"references": [
|
|
9
|
+
{ "title": "Anthropic — Building Effective Agents (2024)", "url": "https://www.anthropic.com/research/building-effective-agents" },
|
|
10
|
+
{ "title": "Yao et al. — ReAct (2022)", "url": "https://arxiv.org/abs/2210.03629" },
|
|
11
|
+
{ "title": "Santiago Santa María — The Stopwatch and the Exam", "url": "https://articles.santismm.com/the-stopwatch-and-the-exam/" }
|
|
12
|
+
],
|
|
13
|
+
"evidence": {
|
|
14
|
+
"evidenceLevel": "theoretical",
|
|
15
|
+
"confidenceLevel": "medium",
|
|
16
|
+
"sourceType": ["personal_experience", "industry_observation"]
|
|
17
|
+
},
|
|
18
|
+
"locales": {
|
|
19
|
+
"en": {
|
|
20
|
+
"title": "What is Harness Engineering?",
|
|
21
|
+
"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.",
|
|
22
|
+
"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.",
|
|
23
|
+
"takeaways": [
|
|
24
|
+
"The harness is everything around the model that converts capability into action.",
|
|
25
|
+
"As frontier models converge, the harness becomes the main lever of differentiation.",
|
|
26
|
+
"Tool design, context management and memory often matter more than model choice.",
|
|
27
|
+
"Harnesses must be observable and evaluated — you cannot improve what you cannot measure.",
|
|
28
|
+
"Harness engineering is to agents what platform engineering is to cloud applications."
|
|
29
|
+
],
|
|
30
|
+
"context": [
|
|
31
|
+
"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.",
|
|
32
|
+
"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."
|
|
33
|
+
],
|
|
34
|
+
"architecture": [
|
|
35
|
+
"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.",
|
|
36
|
+
"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."
|
|
37
|
+
],
|
|
38
|
+
"components": ["Instruction / prompt layer", "Tooling", "Memory systems", "Environment", "Control loop / orchestration", "Guardrails", "Observability", "Evaluation"],
|
|
39
|
+
"pros": [
|
|
40
|
+
"Turns the same model into a far more reliable system.",
|
|
41
|
+
"A durable advantage that survives model upgrades and swaps.",
|
|
42
|
+
"Makes failures diagnosable through observability and evals.",
|
|
43
|
+
"Lets teams improve agents systematically, not by prompt luck."
|
|
44
|
+
],
|
|
45
|
+
"risks": [
|
|
46
|
+
"Complexity: more moving parts to build, secure and maintain.",
|
|
47
|
+
"Over-engineering harnesses that simpler patterns would solve.",
|
|
48
|
+
"Tight coupling to a model's quirks can create migration cost.",
|
|
49
|
+
"Without evaluation, harness changes are guesswork."
|
|
50
|
+
],
|
|
51
|
+
"tools": ["LangGraph", "Claude Agent SDK", "OpenAI Agents SDK", "Model Context Protocol (MCP)", "LangSmith / Langfuse (observability)"],
|
|
52
|
+
"examples": [
|
|
53
|
+
"Rewriting a vague tool description so the model calls it correctly, lifting task success without touching the model.",
|
|
54
|
+
"Adding a memory store so an agent stops repeating work across a long task.",
|
|
55
|
+
"Introducing an evaluation harness that catches a regression before it ships."
|
|
56
|
+
],
|
|
57
|
+
"faqs": [
|
|
58
|
+
{ "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." },
|
|
59
|
+
{ "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." },
|
|
60
|
+
{ "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)." },
|
|
61
|
+
{ "q": "What skills does it require?", "a": "Software and platform engineering, evaluation/measurement, systems design, security, and a working understanding of how models behave." },
|
|
62
|
+
{ "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." }
|
|
63
|
+
]
|
|
64
|
+
},
|
|
65
|
+
"es": {
|
|
66
|
+
"title": "¿Qué es la Ingeniería de Harness (Harness Engineering)?",
|
|
67
|
+
"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.",
|
|
68
|
+
"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.",
|
|
69
|
+
"takeaways": [
|
|
70
|
+
"El harness es todo lo que rodea al modelo y convierte capacidad en acción.",
|
|
71
|
+
"A medida que los modelos frontera convergen, el harness se vuelve la principal palanca de diferenciación.",
|
|
72
|
+
"El diseño de herramientas, la gestión de contexto y la memoria suelen importar más que el modelo elegido.",
|
|
73
|
+
"Los harness deben ser observables y evaluados: no se mejora lo que no se mide.",
|
|
74
|
+
"La ingeniería de harness es a los agentes lo que la ingeniería de plataforma a las aplicaciones cloud."
|
|
75
|
+
],
|
|
76
|
+
"context": [
|
|
77
|
+
"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.",
|
|
78
|
+
"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."
|
|
79
|
+
],
|
|
80
|
+
"architecture": [
|
|
81
|
+
"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.",
|
|
82
|
+
"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."
|
|
83
|
+
],
|
|
84
|
+
"components": ["Capa de instrucción / prompt", "Herramientas (tooling)", "Sistemas de memoria", "Entorno", "Bucle de control / orquestación", "Guardarraíles", "Observabilidad", "Evaluación"],
|
|
85
|
+
"pros": [
|
|
86
|
+
"Convierte el mismo modelo en un sistema mucho más fiable.",
|
|
87
|
+
"Una ventaja duradera que sobrevive a actualizaciones y cambios de modelo.",
|
|
88
|
+
"Hace los fallos diagnosticables mediante observabilidad y evaluaciones.",
|
|
89
|
+
"Permite mejorar agentes de forma sistemática, no por suerte en el prompt."
|
|
90
|
+
],
|
|
91
|
+
"risks": [
|
|
92
|
+
"Complejidad: más piezas que construir, asegurar y mantener.",
|
|
93
|
+
"Sobreingeniería de harness que patrones más simples resolverían.",
|
|
94
|
+
"El acoplamiento a las peculiaridades de un modelo puede crear coste de migración.",
|
|
95
|
+
"Sin evaluación, los cambios de harness son conjeturas."
|
|
96
|
+
],
|
|
97
|
+
"tools": ["LangGraph", "Claude Agent SDK", "OpenAI Agents SDK", "Model Context Protocol (MCP)", "LangSmith / Langfuse (observabilidad)"],
|
|
98
|
+
"examples": [
|
|
99
|
+
"Reescribir una descripción de herramienta ambigua para que el modelo la llame bien, subiendo el éxito sin tocar el modelo.",
|
|
100
|
+
"Añadir un almacén de memoria para que un agente deje de repetir trabajo en una tarea larga.",
|
|
101
|
+
"Introducir un harness de evaluación que detecta una regresión antes de publicarla."
|
|
102
|
+
],
|
|
103
|
+
"faqs": [
|
|
104
|
+
{ "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." },
|
|
105
|
+
{ "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." },
|
|
106
|
+
{ "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)." },
|
|
107
|
+
{ "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." },
|
|
108
|
+
{ "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." }
|
|
109
|
+
]
|
|
110
|
+
},
|
|
111
|
+
"pt": {
|
|
112
|
+
"title": "O que é Engenharia de Harness (Harness Engineering)?",
|
|
113
|
+
"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.",
|
|
114
|
+
"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.",
|
|
115
|
+
"takeaways": [
|
|
116
|
+
"O harness é tudo o que rodeia o modelo e converte capacidade em ação.",
|
|
117
|
+
"À medida que os modelos de fronteira convergem, o harness se torna a principal alavanca de diferenciação.",
|
|
118
|
+
"O design de ferramentas, a gestão de contexto e a memória costumam importar mais que o modelo escolhido.",
|
|
119
|
+
"Os harnesses devem ser observáveis e avaliados: não se melhora o que não se mede.",
|
|
120
|
+
"A engenharia de harness está para os agentes assim como a engenharia de plataforma está para as aplicações cloud."
|
|
121
|
+
],
|
|
122
|
+
"context": [
|
|
123
|
+
"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.",
|
|
124
|
+
"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."
|
|
125
|
+
],
|
|
126
|
+
"architecture": [
|
|
127
|
+
"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.",
|
|
128
|
+
"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."
|
|
129
|
+
],
|
|
130
|
+
"components": ["Camada de instrução / prompt", "Ferramentas (tooling)", "Sistemas de memória", "Ambiente", "Laço de controle / orquestração", "Guard-rails", "Observabilidade", "Avaliação"],
|
|
131
|
+
"pros": [
|
|
132
|
+
"Transforma o mesmo modelo em um sistema muito mais confiável.",
|
|
133
|
+
"Uma vantagem durável que sobrevive a atualizações e trocas de modelo.",
|
|
134
|
+
"Torna as falhas diagnosticáveis por meio de observabilidade e avaliações.",
|
|
135
|
+
"Permite melhorar agentes de forma sistemática, não por sorte no prompt."
|
|
136
|
+
],
|
|
137
|
+
"risks": [
|
|
138
|
+
"Complexidade: mais peças para construir, proteger e manter.",
|
|
139
|
+
"Superengenharia de harness que padrões mais simples resolveriam.",
|
|
140
|
+
"O acoplamento às peculiaridades de um modelo pode criar custo de migração.",
|
|
141
|
+
"Sem avaliação, as mudanças de harness são suposições."
|
|
142
|
+
],
|
|
143
|
+
"tools": ["LangGraph", "Claude Agent SDK", "OpenAI Agents SDK", "Model Context Protocol (MCP)", "LangSmith / Langfuse (observabilidade)"],
|
|
144
|
+
"examples": [
|
|
145
|
+
"Reescrever uma descrição de ferramenta ambígua para o modelo chamá-la corretamente, elevando o sucesso sem tocar no modelo.",
|
|
146
|
+
"Adicionar um armazenamento de memória para um agente parar de repetir trabalho numa tarefa longa.",
|
|
147
|
+
"Introduzir um harness de avaliação que detecta uma regressão antes de publicá-la."
|
|
148
|
+
],
|
|
149
|
+
"faqs": [
|
|
150
|
+
{ "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." },
|
|
151
|
+
{ "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." },
|
|
152
|
+
{ "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)." },
|
|
153
|
+
{ "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." },
|
|
154
|
+
{ "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." }
|
|
155
|
+
]
|
|
156
|
+
}
|
|
157
|
+
}
|
|
158
|
+
}
|
|
@@ -0,0 +1,153 @@
|
|
|
1
|
+
{
|
|
2
|
+
"slug": "human-in-the-loop",
|
|
3
|
+
"category": "pattern",
|
|
4
|
+
"updated": "2026-06-21",
|
|
5
|
+
"version": "1.0",
|
|
6
|
+
"related": ["ai-governance", "agentic-ai", "ai-agent", "agentic-evaluation"],
|
|
7
|
+
"references": [
|
|
8
|
+
{ "title": "European Union — AI Act, Article 14 (Human oversight)", "url": "https://artificialintelligenceact.eu/article/14/" },
|
|
9
|
+
{ "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" }
|
|
10
|
+
],
|
|
11
|
+
"evidence": {
|
|
12
|
+
"evidenceLevel": "industry_observation",
|
|
13
|
+
"confidenceLevel": "high",
|
|
14
|
+
"sourceType": ["industry_observation", "paper"]
|
|
15
|
+
},
|
|
16
|
+
"locales": {
|
|
17
|
+
"en": {
|
|
18
|
+
"title": "What is the Human-in-the-Loop Pattern?",
|
|
19
|
+
"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.",
|
|
20
|
+
"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.",
|
|
21
|
+
"takeaways": [
|
|
22
|
+
"The agent proposes; a human approves, edits or rejects.",
|
|
23
|
+
"Apply it to high-impact, irreversible or sensitive actions.",
|
|
24
|
+
"It trades some autonomy and speed for control and trust.",
|
|
25
|
+
"Governance frameworks often require human oversight by design.",
|
|
26
|
+
"Approvals and overrides should be logged for auditability."
|
|
27
|
+
],
|
|
28
|
+
"context": [
|
|
29
|
+
"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.",
|
|
30
|
+
"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."
|
|
31
|
+
],
|
|
32
|
+
"architecture": [
|
|
33
|
+
"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.",
|
|
34
|
+
"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."
|
|
35
|
+
],
|
|
36
|
+
"components": ["Decision checkpoints", "Approval interface", "Reviewer context", "Edit / override", "Escalation & fallback", "Audit log"],
|
|
37
|
+
"pros": [
|
|
38
|
+
"Catches errors before they cause harm.",
|
|
39
|
+
"Keeps accountability with a human.",
|
|
40
|
+
"Supports compliance and governance requirements.",
|
|
41
|
+
"Builds trust and enables gradual autonomy."
|
|
42
|
+
],
|
|
43
|
+
"risks": [
|
|
44
|
+
"Adds latency and limits throughput.",
|
|
45
|
+
"Rubber-stamping: reviewers approve without real scrutiny.",
|
|
46
|
+
"Alert fatigue degrades the quality of oversight.",
|
|
47
|
+
"Over-applying it negates the value of automation."
|
|
48
|
+
],
|
|
49
|
+
"tools": ["Approval / workflow systems", "Agent frameworks with interrupt steps (e.g. LangGraph)", "Audit logging", "Case-management UIs"],
|
|
50
|
+
"examples": [
|
|
51
|
+
"An agent drafting a refund that a human approves before it is issued.",
|
|
52
|
+
"A content agent whose output a person reviews before publishing.",
|
|
53
|
+
"An ops agent that pauses for sign-off before a production change."
|
|
54
|
+
],
|
|
55
|
+
"faqs": [
|
|
56
|
+
{ "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." },
|
|
57
|
+
{ "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." },
|
|
58
|
+
{ "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." },
|
|
59
|
+
{ "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." }
|
|
60
|
+
]
|
|
61
|
+
},
|
|
62
|
+
"es": {
|
|
63
|
+
"title": "¿Qué es el Patrón Human-in-the-Loop?",
|
|
64
|
+
"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.",
|
|
65
|
+
"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.",
|
|
66
|
+
"takeaways": [
|
|
67
|
+
"El agente propone; un humano aprueba, edita o rechaza.",
|
|
68
|
+
"Aplícalo a acciones de alto impacto, irreversibles o sensibles.",
|
|
69
|
+
"Cambia algo de autonomía y velocidad por control y confianza.",
|
|
70
|
+
"Los marcos de gobernanza suelen exigir supervisión humana por diseño.",
|
|
71
|
+
"Las aprobaciones y anulaciones deben registrarse para la auditabilidad."
|
|
72
|
+
],
|
|
73
|
+
"context": [
|
|
74
|
+
"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.",
|
|
75
|
+
"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."
|
|
76
|
+
],
|
|
77
|
+
"architecture": [
|
|
78
|
+
"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.",
|
|
79
|
+
"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."
|
|
80
|
+
],
|
|
81
|
+
"components": ["Puntos de decisión", "Interfaz de aprobación", "Contexto para el revisor", "Edición / anulación", "Escalado y respaldo", "Registro de auditoría"],
|
|
82
|
+
"pros": [
|
|
83
|
+
"Detecta errores antes de que causen daño.",
|
|
84
|
+
"Mantiene la responsabilidad en un humano.",
|
|
85
|
+
"Apoya requisitos de cumplimiento y gobernanza.",
|
|
86
|
+
"Genera confianza y habilita una autonomía gradual."
|
|
87
|
+
],
|
|
88
|
+
"risks": [
|
|
89
|
+
"Añade latencia y limita el rendimiento.",
|
|
90
|
+
"Aprobación automática: revisores que aprueban sin escrutinio real.",
|
|
91
|
+
"La fatiga de alertas degrada la calidad de la supervisión.",
|
|
92
|
+
"Aplicarlo en exceso anula el valor de la automatización."
|
|
93
|
+
],
|
|
94
|
+
"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"],
|
|
95
|
+
"examples": [
|
|
96
|
+
"Un agente que redacta un reembolso que un humano aprueba antes de emitirse.",
|
|
97
|
+
"Un agente de contenido cuya salida una persona revisa antes de publicar.",
|
|
98
|
+
"Un agente de operaciones que se pausa para una firma antes de un cambio en producción."
|
|
99
|
+
],
|
|
100
|
+
"faqs": [
|
|
101
|
+
{ "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." },
|
|
102
|
+
{ "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." },
|
|
103
|
+
{ "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." },
|
|
104
|
+
{ "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." }
|
|
105
|
+
]
|
|
106
|
+
},
|
|
107
|
+
"pt": {
|
|
108
|
+
"title": "O que é o Padrão Human-in-the-Loop?",
|
|
109
|
+
"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.",
|
|
110
|
+
"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.",
|
|
111
|
+
"takeaways": [
|
|
112
|
+
"O agente propõe; um humano aprova, edita ou rejeita.",
|
|
113
|
+
"Aplique-o a ações de alto impacto, irreversíveis ou sensíveis.",
|
|
114
|
+
"Troca alguma autonomia e velocidade por controle e confiança.",
|
|
115
|
+
"Os marcos de governança costumam exigir supervisão humana por design.",
|
|
116
|
+
"As aprovações e anulações devem ser registradas para a auditabilidade."
|
|
117
|
+
],
|
|
118
|
+
"context": [
|
|
119
|
+
"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.",
|
|
120
|
+
"É 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."
|
|
121
|
+
],
|
|
122
|
+
"architecture": [
|
|
123
|
+
"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.",
|
|
124
|
+
"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."
|
|
125
|
+
],
|
|
126
|
+
"components": ["Pontos de decisão", "Interface de aprovação", "Contexto para o revisor", "Edição / anulação", "Escalonamento e fallback", "Registro de auditoria"],
|
|
127
|
+
"pros": [
|
|
128
|
+
"Detecta erros antes que causem dano.",
|
|
129
|
+
"Mantém a responsabilidade com um humano.",
|
|
130
|
+
"Apoia requisitos de conformidade e governança.",
|
|
131
|
+
"Gera confiança e habilita uma autonomia gradual."
|
|
132
|
+
],
|
|
133
|
+
"risks": [
|
|
134
|
+
"Adiciona latência e limita a vazão.",
|
|
135
|
+
"Aprovação automática: revisores que aprovam sem escrutínio real.",
|
|
136
|
+
"A fadiga de alertas degrada a qualidade da supervisão.",
|
|
137
|
+
"Aplicá-lo em excesso anula o valor da automação."
|
|
138
|
+
],
|
|
139
|
+
"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"],
|
|
140
|
+
"examples": [
|
|
141
|
+
"Um agente que redige um reembolso que um humano aprova antes de ser emitido.",
|
|
142
|
+
"Um agente de conteúdo cuja saída uma pessoa revisa antes de publicar.",
|
|
143
|
+
"Um agente de operações que pausa para uma assinatura antes de uma mudança em produção."
|
|
144
|
+
],
|
|
145
|
+
"faqs": [
|
|
146
|
+
{ "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." },
|
|
147
|
+
{ "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." },
|
|
148
|
+
{ "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." },
|
|
149
|
+
{ "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." }
|
|
150
|
+
]
|
|
151
|
+
}
|
|
152
|
+
}
|
|
153
|
+
}
|