{ "schemaVersion": "1.0.0", "id": "https://aisdlc.ai/agentic-engineering/catalog.json", "title": "Agentic Engineering knowledge catalog", "edition": "2026.08", "reviewedAt": "2026-08-09", "authorityBoundary": "This library synthesizes cited research, standards, official documentation, and clearly attributed practitioner perspectives. Maturity describes the state of a concept—not vendor endorsement, production readiness, or permission to deploy. Benchmarks and demonstrations do not replace use-case evaluation, governed controls, independent verification, or named human release authority.", "entries": [ { "id": "agentic-engineering", "index": "", "title": "Agentic engineering", "shortTitle": "Agentic engineering", "aliases": [ "Discipline", "AI-native engineering" ], "declaredRoute": "/agentic-engineering/agentic-engineering", "entryType": "core-concept", "domain": "Foundations", "maturity": "emerging", "maturityNote": "The name is emerging; the underlying practices are becoming operational.", "question": "", "oneLine": "The discipline of designing intent, context, memory, tools, execution, verification, control, and evidence so goal-directed agents can perform meaningful work while humans remain accountable.", "definition": "The discipline of designing intent, context, memory, tools, execution, verification, control, and evidence so goal-directed agents can perform meaningful work while humans remain accountable. The unit of engineering expands from code to the complete system that makes bounded agency useful.", "whyItMatters": [ "The unit of engineering expands from code to the complete system that makes bounded agency useful.", "The operating shift is from “AI that suggests code” to “Engineered systems that delegate outcomes.”" ], "anatomy": [ { "label": "Practice 1", "description": "Design the environment around the model" }, { "label": "Practice 2", "description": "Make authority and stop conditions explicit" }, { "label": "Practice 3", "description": "Treat evidence as a first-class output" } ], "mechanism": [], "distinctions": [ { "label": "AI that suggests code", "description": "This concept moves the engineering system toward engineered systems that delegate outcomes." } ], "practices": [ "Design the environment around the model", "Make authority and stop conditions explicit", "Treat evidence as a first-class output" ], "failureModes": [ "Equating model capability with system reliability", "Treating autonomy as the goal instead of bounded outcomes" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-harness-engineering", "karpathy-software-3", "google-dora-ai-development" ], "videoSourceIds": [ "karpathy-software-3" ], "relatedEntryIds": [ "harness-engineering", "agent-identity", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "agentic-engineering", "lifecyclePhases": [ "01", "02", "03", "07" ], "controlIds": [ "GOV-001", "GOV-003", "ARC-001", "RUN-002" ], "seoTitle": "Agentic engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "The discipline of designing intent, context, memory, tools, execution, verification, control, and evidence so goal-directed agents can perform meaningful work while humans remain accountable." }, { "id": "intent-engineering", "index": "", "title": "Intent engineering", "shortTitle": "Intent engineering", "aliases": [ "Intent", "specification engineering" ], "declaredRoute": "/agentic-engineering/intent-engineering", "entryType": "core-concept", "domain": "Foundations", "maturity": "maturing", "maturityNote": "Spec-driven practice is growing, but spec-as-source is not a universal consensus.", "question": "", "oneLine": "The practice of turning goals into versioned specifications, constraints, interfaces, invariants, decision rights, acceptance criteria, and testable outcomes before agents implement them.", "definition": "The practice of turning goals into versioned specifications, constraints, interfaces, invariants, decision rights, acceptance criteria, and testable outcomes before agents implement them. A prompt requests work. A durable intent system defines what correct, safe, and complete work means.", "whyItMatters": [ "A prompt requests work. A durable intent system defines what correct, safe, and complete work means.", "The operating shift is from “Prompt as instruction” to “Specification as executable intent.”" ], "anatomy": [ { "label": "Practice 1", "description": "Version requirements beside implementation" }, { "label": "Practice 2", "description": "Encode invariants and acceptance criteria" }, { "label": "Practice 3", "description": "Trace design decisions back to intent" } ], "mechanism": [], "distinctions": [ { "label": "Prompt as instruction", "description": "This concept moves the engineering system toward specification as executable intent." } ], "practices": [ "Version requirements beside implementation", "Encode invariants and acceptance criteria", "Trace design decisions back to intent" ], "failureModes": [ "Verbose specifications without enforceable tests", "Assuming generated implementation keeps the specification current" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "github-spec-driven", "github-spec-persistence", "openai-harness-engineering" ], "videoSourceIds": [], "relatedEntryIds": [ "context-engineering", "eval-driven-development", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "intent-engineering", "lifecyclePhases": [ "01", "02", "03" ], "controlIds": [ "GOV-001", "GOV-003", "ARC-001", "BLD-001" ], "seoTitle": "Intent engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "The practice of turning goals into versioned specifications, constraints, interfaces, invariants, decision rights, acceptance criteria, and testable outcomes before agents implement them." }, { "id": "context-engineering", "index": "", "title": "Context engineering", "shortTitle": "Context engineering", "aliases": [ "Context" ], "declaredRoute": "/agentic-engineering/context-engineering", "entryType": "core-concept", "domain": "Context & knowledge", "maturity": "maturing", "maturityNote": "A concrete practice with rapidly evolving techniques and tooling.", "question": "", "oneLine": "The deliberate selection and maintenance of instructions, knowledge, tools, state, examples, and artifacts within a finite model attention budget.", "definition": "The deliberate selection and maintenance of instructions, knowledge, tools, state, examples, and artifacts within a finite model attention budget. The control surface is no longer only the prompt; it is everything the model can see at the moment of decision.", "whyItMatters": [ "The control surface is no longer only the prompt; it is everything the model can see at the moment of decision.", "The operating shift is from “More tokens and larger prompts” to “Smallest sufficient high-signal state.”" ], "anatomy": [ { "label": "Practice 1", "description": "Use progressive disclosure and just-in-time retrieval" }, { "label": "Practice 2", "description": "Budget and prune model-visible state" }, { "label": "Practice 3", "description": "Reset context with structured handoff artifacts" } ], "mechanism": [], "distinctions": [ { "label": "More tokens and larger prompts", "description": "This concept moves the engineering system toward smallest sufficient high-signal state." } ], "practices": [ "Use progressive disclosure and just-in-time retrieval", "Budget and prune model-visible state", "Reset context with structured handoff artifacts" ], "failureModes": [ "Context accumulation that buries the objective", "Untrusted retrieved content silently steering action" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "anthropic-long-running-harness", "owasp-memory" ], "videoSourceIds": [], "relatedEntryIds": [ "durable-memory", "harness-engineering", "tools-and-protocols" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "context-engineering", "lifecyclePhases": [ "02", "03", "04", "07" ], "controlIds": [ "DAT-001", "ARC-002", "VER-002" ], "seoTitle": "Context engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "The deliberate selection and maintenance of instructions, knowledge, tools, state, examples, and artifacts within a finite model attention budget." }, { "id": "durable-memory", "index": "", "title": "Durable project memory", "shortTitle": "Durable project memory", "aliases": [ "Memory", "project memory" ], "declaredRoute": "/agentic-engineering/durable-memory", "entryType": "core-concept", "domain": "Context & knowledge", "maturity": "emerging", "maturityNote": "Useful patterns exist; no settled enterprise memory architecture has emerged.", "question": "", "oneLine": "Persistent, attributable project knowledge that carries decisions, outcomes, requirements, failures, and operating state across agent sessions without assuming that every stored item remains true or safe.", "definition": "Persistent, attributable project knowledge that carries decisions, outcomes, requirements, failures, and operating state across agent sessions without assuming that every stored item remains true or safe. What survives a context reset becomes institutional infrastructure—and a new integrity boundary.", "whyItMatters": [ "What survives a context reset becomes institutional infrastructure—and a new integrity boundary.", "The operating shift is from “Chat history as memory” to “Governed institutional state.”" ], "anatomy": [ { "label": "Practice 1", "description": "Store decisions and progress as reviewable artifacts" }, { "label": "Practice 2", "description": "Attach provenance, permissions, and freshness rules" }, { "label": "Practice 3", "description": "Validate memory before it re-enters context" } ], "mechanism": [], "distinctions": [ { "label": "Chat history as memory", "description": "This concept moves the engineering system toward governed institutional state." } ], "practices": [ "Store decisions and progress as reviewable artifacts", "Attach provenance, permissions, and freshness rules", "Validate memory before it re-enters context" ], "failureModes": [ "Memory poisoning that persists across sessions", "Stale summaries becoming invisible policy" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "anthropic-managed-agents", "owasp-memory" ], "videoSourceIds": [], "relatedEntryIds": [ "context-engineering", "execution-substrate", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "durable-memory", "lifecyclePhases": [ "03", "04", "07", "08" ], "controlIds": [ "DAT-001", "DAT-002", "RUN-001", "LIF-002" ], "seoTitle": "Durable project memory | Agentic Engineering Knowledge Atlas", "seoDescription": "Persistent, attributable project knowledge that carries decisions, outcomes, requirements, failures, and operating state across agent sessions without assuming that every stored item remains true or safe." }, { "id": "harness-engineering", "index": "", "title": "Harness engineering", "shortTitle": "Harness engineering", "aliases": [ "Harness", "agent harness" ], "declaredRoute": "/agentic-engineering/harness-engineering", "entryType": "core-concept", "domain": "Harness & runtime", "maturity": "maturing", "maturityNote": "A fast-forming production discipline whose terminology is still new.", "question": "", "oneLine": "Engineering the agent loop, task decomposition, tools, permissions, session state, checks, retries, feedback, checkpoints, and stop conditions that surround a model.", "definition": "Engineering the agent loop, task decomposition, tools, permissions, session state, checks, retries, feedback, checkpoints, and stop conditions that surround a model. The model supplies capability; the harness turns capability into repeatable, inspectable work.", "whyItMatters": [ "The model supplies capability; the harness turns capability into repeatable, inspectable work.", "The operating shift is from “Tune the prompt” to “Engineer the working environment.”" ], "anatomy": [ { "label": "Practice 1", "description": "Expose tests, logs, and interfaces directly to agents" }, { "label": "Practice 2", "description": "Encode recovery and back-pressure" }, { "label": "Practice 3", "description": "Make the repository legible to future agent runs" } ], "mechanism": [], "distinctions": [ { "label": "Tune the prompt", "description": "This concept moves the engineering system toward engineer the working environment." } ], "practices": [ "Expose tests, logs, and interfaces directly to agents", "Encode recovery and back-pressure", "Make the repository legible to future agent runs" ], "failureModes": [ "Retry loops without new evidence", "A powerful model operating in an underspecified environment" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-harness-engineering", "anthropic-long-running-harness", "anthropic-harness-design" ], "videoSourceIds": [], "relatedEntryIds": [ "context-engineering", "execution-substrate", "multi-agent-verification" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "harness-engineering", "lifecyclePhases": [ "02", "03", "04", "05" ], "controlIds": [ "ARC-001", "ARC-002", "BLD-001", "VER-001" ], "seoTitle": "Harness engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "Engineering the agent loop, task decomposition, tools, permissions, session state, checks, retries, feedback, checkpoints, and stop conditions that surround a model." }, { "id": "tools-and-protocols", "index": "", "title": "Tools, skills & protocols", "shortTitle": "Tools, skills & protocols", "aliases": [ "Interfaces", "agent tools" ], "declaredRoute": "/agentic-engineering/tools-and-protocols", "entryType": "core-concept", "domain": "Multi-agent & protocols", "maturity": "maturing", "maturityNote": "Protocol milestones exist, while security and governance profiles continue to evolve.", "question": "", "oneLine": "The action and knowledge interfaces through which agents use tools, load procedural skills, access enterprise context, and collaborate with other agents.", "definition": "The action and knowledge interfaces through which agents use tools, load procedural skills, access enterprise context, and collaborate with other agents. Interoperability expands what agents can do; it does not decide what they should be trusted to do.", "whyItMatters": [ "Interoperability expands what agents can do; it does not decide what they should be trusted to do.", "The operating shift is from “One assistant with plugins” to “Composable capability fabric.”" ], "anatomy": [ { "label": "Practice 1", "description": "Keep tool contracts narrow and typed" }, { "label": "Practice 2", "description": "Separate protocol compatibility from authorization" }, { "label": "Practice 3", "description": "Record tool source, version, identity, and effect" } ], "mechanism": [], "distinctions": [ { "label": "One assistant with plugins", "description": "This concept moves the engineering system toward composable capability fabric." } ], "practices": [ "Keep tool contracts narrow and typed", "Separate protocol compatibility from authorization", "Record tool source, version, identity, and effect" ], "failureModes": [ "Tool descriptions granting accidental authority", "Protocol support being mistaken for trust" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "mcp-enterprise-auth", "a2a-v1", "nist-agent-standards" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-identity", "execution-substrate", "context-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "tools-and-protocols", "lifecyclePhases": [ "03", "04", "05", "07" ], "controlIds": [ "ARC-002", "BLD-002", "VER-003", "RUN-001" ], "seoTitle": "Tools, skills & protocols | Agentic Engineering Knowledge Atlas", "seoDescription": "The action and knowledge interfaces through which agents use tools, load procedural skills, access enterprise context, and collaborate with other agents." }, { "id": "execution-substrate", "index": "", "title": "Agent execution substrate", "shortTitle": "Agent execution substrate", "aliases": [ "Substrate", "agent substrate", "execution environment" ], "declaredRoute": "/agentic-engineering/execution-substrate", "entryType": "core-concept", "domain": "Harness & runtime", "maturity": "emerging", "maturityNote": "Sandboxing is established; agent-specific substrates are still taking shape.", "question": "", "oneLine": "The isolated, stateful environment in which agents observe and act, including compute, filesystem, browser, network, credentials, resource limits, and session lifecycle.", "definition": "The isolated, stateful environment in which agents observe and act, including compute, filesystem, browser, network, credentials, resource limits, and session lifecycle. The workspace, browser, shell, network, and identity are part of the agent—not background infrastructure.", "whyItMatters": [ "The workspace, browser, shell, network, and identity are part of the agent—not background infrastructure.", "The operating shift is from “Run the model somewhere” to “Engineer the place where action occurs.”" ], "anatomy": [ { "label": "Practice 1", "description": "Isolate work by task and identity" }, { "label": "Practice 2", "description": "Constrain network, secrets, and resource use" }, { "label": "Practice 3", "description": "Capture environment transitions as evidence" } ], "mechanism": [], "distinctions": [ { "label": "Run the model somewhere", "description": "This concept moves the engineering system toward engineer the place where action occurs." } ], "practices": [ "Isolate work by task and identity", "Constrain network, secrets, and resource use", "Capture environment transitions as evidence" ], "failureModes": [ "Hidden environmental side effects", "Shared credentials and unbounded egress" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "google-agent-substrate", "openai-harness-engineering", "owasp-agentic-top10" ], "videoSourceIds": [], "relatedEntryIds": [ "harness-engineering", "agent-identity", "observability-control" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "execution-substrate", "lifecyclePhases": [ "03", "04", "06", "07" ], "controlIds": [ "ARC-001", "ARC-002", "RUN-001", "RUN-002" ], "seoTitle": "Agent execution substrate | Agentic Engineering Knowledge Atlas", "seoDescription": "The isolated, stateful environment in which agents observe and act, including compute, filesystem, browser, network, credentials, resource limits, and session lifecycle." }, { "id": "agent-identity", "index": "", "title": "Agent identity & delegated authority", "shortTitle": "Agent identity & delegated authority", "aliases": [ "Authority", "non-human identity", "delegated authority" ], "declaredRoute": "/agentic-engineering/agent-identity", "entryType": "core-concept", "domain": "Security & governance", "maturity": "emerging", "maturityNote": "IAM foundations are established; agent-specific standards and profiles are still developing.", "question": "", "oneLine": "The identity and authorization discipline that treats an enterprise agent as a non-human principal with attributable, purpose-bound, time-bound permissions.", "definition": "The identity and authorization discipline that treats an enterprise agent as a non-human principal with attributable, purpose-bound, time-bound permissions. Every consequential agent action needs a principal, a delegator, a purpose, a policy decision, and an expiry.", "whyItMatters": [ "Every consequential agent action needs a principal, a delegator, a purpose, a policy decision, and an expiry.", "The operating shift is from “Borrowed user credentials” to “Explicit non-human authority.”" ], "anatomy": [ { "label": "Practice 1", "description": "Bind authority to action, resource, purpose, and time" }, { "label": "Practice 2", "description": "Preserve the human or service delegation chain" }, { "label": "Practice 3", "description": "Expire or suspend agents without a valid owner" } ], "mechanism": [], "distinctions": [ { "label": "Borrowed user credentials", "description": "This concept moves the engineering system toward explicit non-human authority." } ], "practices": [ "Bind authority to action, resource, purpose, and time", "Preserve the human or service delegation chain", "Expire or suspend agents without a valid owner" ], "failureModes": [ "Agents impersonating users", "Permissions surviving ownership or purpose changes" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "nist-agent-identity", "nist-agent-standards", "mcp-enterprise-auth" ], "videoSourceIds": [], "relatedEntryIds": [ "tools-and-protocols", "execution-substrate", "observability-control" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "agent-identity", "lifecyclePhases": [ "01", "03", "06", "08" ], "controlIds": [ "GOV-001", "GOV-003", "ARC-002", "LIF-001" ], "seoTitle": "Agent identity & delegated authority | Agentic Engineering Knowledge Atlas", "seoDescription": "The identity and authorization discipline that treats an enterprise agent as a non-human principal with attributable, purpose-bound, time-bound permissions." }, { "id": "multi-agent-verification", "index": "", "title": "Independent verifier systems", "shortTitle": "Independent verifier systems", "aliases": [ "Verifiers", "independent verifier systems", "verifier plane" ], "declaredRoute": "/agentic-engineering/multi-agent-verification", "entryType": "core-concept", "domain": "Evaluation & verification", "maturity": "emerging", "maturityNote": "Independent assurance is established; multi-agent implementations remain experimental.", "question": "", "oneLine": "A separation-of-judgment architecture in which builder agents, evaluator agents, deterministic checks, domain experts, and authorization authorities challenge different failure surfaces.", "definition": "A separation-of-judgment architecture in which builder agents, evaluator agents, deterministic checks, domain experts, and authorization authorities challenge different failure surfaces. A builder can test its work. It cannot independently accept the risk created by its work.", "whyItMatters": [ "A builder can test its work. It cannot independently accept the risk created by its work.", "The operating shift is from “Self-review before merge” to “Independent challenge across the lifecycle.”" ], "anatomy": [ { "label": "Practice 1", "description": "Separate builder and verifier context" }, { "label": "Practice 2", "description": "Use heterogeneous verification methods" }, { "label": "Practice 3", "description": "Route unresolved disagreement to accountable humans" } ], "mechanism": [], "distinctions": [ { "label": "Self-review before merge", "description": "This concept moves the engineering system toward independent challenge across the lifecycle." } ], "practices": [ "Separate builder and verifier context", "Use heterogeneous verification methods", "Route unresolved disagreement to accountable humans" ], "failureModes": [ "Multiple agents sharing the same blind spot", "Model graders treated as independent authorities" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-harness-design", "anthropic-evals", "nist-benchmark-evals" ], "videoSourceIds": [], "relatedEntryIds": [ "eval-driven-development", "evidence-engineering", "agentic-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "multi-agent-verification", "lifecyclePhases": [ "02", "05", "06", "07" ], "controlIds": [ "VER-001", "VER-003", "VER-004", "AUT-002" ], "seoTitle": "Independent verifier systems | Agentic Engineering Knowledge Atlas", "seoDescription": "A separation-of-judgment architecture in which builder agents, evaluator agents, deterministic checks, domain experts, and authorization authorities challenge different failure surfaces." }, { "id": "eval-driven-development", "index": "", "title": "Eval-driven development", "shortTitle": "Eval-driven development", "aliases": [ "Evals", "EDD", "agent evals" ], "declaredRoute": "/agentic-engineering/eval-driven-development", "entryType": "core-concept", "domain": "Evaluation & verification", "maturity": "maturing", "maturityNote": "The discipline is becoming concrete while measurement standards remain nascent.", "question": "", "oneLine": "An engineering loop that converts expected behavior and observed failures into repeatable evaluations combining deterministic checks, environment inspection, security testing, model graders, repeated trials, and human judgment.", "definition": "An engineering loop that converts expected behavior and observed failures into repeatable evaluations combining deterministic checks, environment inspection, security testing, model graders, repeated trials, and human judgment. The test target is the whole agent system: outcome, trajectory, environment, side effects, and policy adherence.", "whyItMatters": [ "The test target is the whole agent system: outcome, trajectory, environment, side effects, and policy adherence.", "The operating shift is from “A benchmark score” to “A living system-level assurance suite.”" ], "anatomy": [ { "label": "Practice 1", "description": "Evaluate outcomes and trajectories" }, { "label": "Practice 2", "description": "Calibrate graders against expert judgment" }, { "label": "Practice 3", "description": "Turn production corrections into regression cases" } ], "mechanism": [], "distinctions": [ { "label": "A benchmark score", "description": "This concept moves the engineering system toward a living system-level assurance suite." } ], "practices": [ "Evaluate outcomes and trajectories", "Calibrate graders against expert judgment", "Turn production corrections into regression cases" ], "failureModes": [ "Broken tasks producing authoritative scores", "Optimizing the benchmark instead of the operating outcome" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-evals", "nist-benchmark-evals", "openai-self-improving" ], "videoSourceIds": [], "relatedEntryIds": [ "multi-agent-verification", "observability-control", "intent-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "eval-driven-development", "lifecyclePhases": [ "02", "04", "05", "07" ], "controlIds": [ "VER-001", "VER-003", "VER-004", "RUN-001" ], "seoTitle": "Eval-driven development | Agentic Engineering Knowledge Atlas", "seoDescription": "An engineering loop that converts expected behavior and observed failures into repeatable evaluations combining deterministic checks, environment inspection, security testing, model graders, repeated trials, and human judgment." }, { "id": "observability-control", "index": "", "title": "Observability & control", "shortTitle": "Observability & control", "aliases": [ "Control plane", "agent control plane" ], "declaredRoute": "/agentic-engineering/observability-control", "entryType": "core-concept", "domain": "Security & governance", "maturity": "emerging", "maturityNote": "Telemetry conventions are maturing; a unified agent control plane is not yet one settled standard.", "question": "", "oneLine": "The combined telemetry and enforcement architecture for tracing agent behavior, evaluating policy, obtaining approval, constraining action, revoking authority, quarantining execution, and stopping systems.", "definition": "The combined telemetry and enforcement architecture for tracing agent behavior, evaluating policy, obtaining approval, constraining action, revoking authority, quarantining execution, and stopping systems. Observability explains what happened. A control plane determines what is allowed to happen next.", "whyItMatters": [ "Observability explains what happened. A control plane determines what is allowed to happen next.", "The operating shift is from “Logs after execution” to “Evidence-aware intervention during execution.”" ], "anatomy": [ { "label": "Practice 1", "description": "Trace model, tool, policy, approval, and outcome events" }, { "label": "Practice 2", "description": "Keep deny, hold, revoke, and stop paths operational" }, { "label": "Practice 3", "description": "Connect anomalies to accountable response" } ], "mechanism": [], "distinctions": [ { "label": "Logs after execution", "description": "This concept moves the engineering system toward evidence-aware intervention during execution." } ], "practices": [ "Trace model, tool, policy, approval, and outcome events", "Keep deny, hold, revoke, and stop paths operational", "Connect anomalies to accountable response" ], "failureModes": [ "Rich traces with no intervention authority", "A kill switch that is not continuously tested" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "nist-deployed-monitoring", "opentelemetry-genai", "openai-monitoring" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-identity", "execution-substrate", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "observability-control", "lifecyclePhases": [ "03", "06", "07", "08" ], "controlIds": [ "AUT-001", "RUN-001", "RUN-002", "LIF-001" ], "seoTitle": "Observability & control | Agentic Engineering Knowledge Atlas", "seoDescription": "The combined telemetry and enforcement architecture for tracing agent behavior, evaluating policy, obtaining approval, constraining action, revoking authority, quarantining execution, and stopping systems." }, { "id": "evidence-engineering", "index": "", "title": "Evidence engineering", "shortTitle": "Evidence engineering", "aliases": [ "Evidence", "evidence chain" ], "declaredRoute": "/agentic-engineering/evidence-engineering", "entryType": "core-concept", "domain": "Evaluation & verification", "maturity": "maturing", "maturityNote": "Software provenance is established; complete AI and agent lifecycle evidence models are emerging.", "question": "", "oneLine": "The design of versioned, queryable evidence linking requirements, decisions, implementations, tests, evaluations, approvals, deployments, runtime signals, and lifecycle actions.", "definition": "The design of versioned, queryable evidence linking requirements, decisions, implementations, tests, evaluations, approvals, deployments, runtime signals, and lifecycle actions. The durable handoff is not the conversation. It is the attributable chain from intent to deployed outcome.", "whyItMatters": [ "The durable handoff is not the conversation. It is the attributable chain from intent to deployed outcome.", "The operating shift is from “Screenshots and chat transcripts” to “Machine-readable chain of proof.”" ], "anatomy": [ { "label": "Practice 1", "description": "Bind evidence to the exact released artifact" }, { "label": "Practice 2", "description": "Preserve verifier identity and decision authority" }, { "label": "Practice 3", "description": "Carry runtime outcomes into recertification" } ], "mechanism": [], "distinctions": [ { "label": "Screenshots and chat transcripts", "description": "This concept moves the engineering system toward machine-readable chain of proof." } ], "practices": [ "Bind evidence to the exact released artifact", "Preserve verifier identity and decision authority", "Carry runtime outcomes into recertification" ], "failureModes": [ "Evidence assembled after the decision", "Artifacts that cannot be traced to what actually ran" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "slsa-provenance", "openai-harness-engineering", "openai-self-improving" ], "videoSourceIds": [], "relatedEntryIds": [ "intent-engineering", "multi-agent-verification", "observability-control" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "evidence-engineering", "lifecyclePhases": [ "01", "03", "04", "05", "06", "07", "08" ], "controlIds": [ "BLD-002", "AUT-001", "RUN-001", "LIF-002" ], "seoTitle": "Evidence engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "The design of versioned, queryable evidence linking requirements, decisions, implementations, tests, evaluations, approvals, deployments, runtime signals, and lifecycle actions." }, { "id": "human-accountability", "index": "", "title": "Human accountability", "shortTitle": "Human accountability", "aliases": [ "Accountability", "human release authority" ], "declaredRoute": "/agentic-engineering/human-accountability", "entryType": "core-concept", "domain": "Security & governance", "maturity": "maturing", "maturityNote": "Human accountability is established; agent-specific roles and decision models are still being operationalized.", "question": "", "oneLine": "The operating discipline that assigns a named human role authority and answerability for an agent’s purpose, risk, decision rights, authorization, intervention, outcomes, and lifecycle.", "definition": "The operating discipline that assigns a named human role authority and answerability for an agent’s purpose, risk, decision rights, authorization, intervention, outcomes, and lifecycle. Agency can be delegated. Enterprise accountability cannot.", "whyItMatters": [ "Agency can be delegated. Enterprise accountability cannot.", "The operating shift is from “A human somewhere in the loop” to “A named human with decision authority.”" ], "anatomy": [ { "label": "Practice 1", "description": "Assign exactly one accountable role per consequential decision" }, { "label": "Practice 2", "description": "Publish decision rights and escalation paths" }, { "label": "Practice 3", "description": "Keep override, suspension, and risk acceptance human-authorized" } ], "mechanism": [], "distinctions": [ { "label": "A human somewhere in the loop", "description": "This concept moves the engineering system toward a named human with decision authority." } ], "practices": [ "Assign exactly one accountable role per consequential decision", "Publish decision rights and escalation paths", "Keep override, suspension, and risk acceptance human-authorized" ], "failureModes": [ "Accountability diffused across a committee or vendor", "A review click treated as ownership of the outcome" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "microsoft-agent-accountability", "microsoft-agent-owners-sponsors", "nist-agent-identity" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-identity", "risk-tiered-autonomy", "continuous-recertification-retirement" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "human-accountability", "lifecyclePhases": [ "01", "02", "06", "07", "08" ], "controlIds": [ "GOV-001", "GOV-003", "AUT-001", "LIF-001" ], "seoTitle": "Human accountability | Agentic Engineering Knowledge Atlas", "seoDescription": "The operating discipline that assigns a named human role authority and answerability for an agent’s purpose, risk, decision rights, authorization, intervention, outcomes, and lifecycle." }, { "id": "risk-tiered-autonomy", "index": "", "title": "Risk-tiered autonomy", "shortTitle": "Risk-tiered autonomy", "aliases": [ "Autonomy", "bounded autonomy" ], "declaredRoute": "/agentic-engineering/risk-tiered-autonomy", "entryType": "core-concept", "domain": "Security & governance", "maturity": "maturing", "maturityNote": "Risk-tiering is established; consistent mappings from agent capability to permitted autonomy are still evolving.", "question": "", "oneLine": "The practice of classifying an agent by impact, data sensitivity, action scope, and reversibility, then binding that tier to maximum autonomy, required controls, approval authorities, and monitoring depth.", "definition": "The practice of classifying an agent by impact, data sensitivity, action scope, and reversibility, then binding that tier to maximum autonomy, required controls, approval authorities, and monitoring depth. Autonomy is an evidence-backed risk budget, not a feature toggle.", "whyItMatters": [ "Autonomy is an evidence-backed risk budget, not a feature toggle.", "The operating shift is from “Automation on or off” to “Graduated, bounded decision authority.”" ], "anatomy": [ { "label": "Practice 1", "description": "Classify risk before architecture and build" }, { "label": "Practice 2", "description": "Separate assistive, read-only, transactional, and consequential authority" }, { "label": "Practice 3", "description": "Reclassify when tools, data, users, or impacts change" } ], "mechanism": [], "distinctions": [ { "label": "Automation on or off", "description": "This concept moves the engineering system toward graduated, bounded decision authority." } ], "practices": [ "Classify risk before architecture and build", "Separate assistive, read-only, transactional, and consequential authority", "Reclassify when tools, data, users, or impacts change" ], "failureModes": [ "A low-risk label surviving material scope expansion", "One checklist applied to both drafting and consequential action" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "microsoft-agent-risk-governance", "nist-ai-rmf", "nist-agent-identity" ], "videoSourceIds": [], "relatedEntryIds": [ "human-accountability", "agent-identity", "deterministic-containment" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "risk-tiered-autonomy", "lifecyclePhases": [ "01", "02", "05", "06", "07" ], "controlIds": [ "GOV-002", "GOV-003", "VER-001", "AUT-002" ], "seoTitle": "Risk-tiered autonomy | Agentic Engineering Knowledge Atlas", "seoDescription": "The practice of classifying an agent by impact, data sensitivity, action scope, and reversibility, then binding that tier to maximum autonomy, required controls, approval authorities, and monitoring depth." }, { "id": "deterministic-containment", "index": "", "title": "Deterministic containment", "shortTitle": "Deterministic containment", "aliases": [ "Containment", "containment envelope" ], "declaredRoute": "/agentic-engineering/deterministic-containment", "entryType": "core-concept", "domain": "Security & governance", "maturity": "maturing", "maturityNote": "Isolation and policy primitives are established; agent-specific containment architectures are still converging.", "question": "", "oneLine": "The enforcement envelope outside the model: isolation, deny-by-default access, typed allowlists, quotas, transaction ceilings, network boundaries, timeouts, rollback, quarantine, and tested stop controls.", "definition": "The enforcement envelope outside the model: isolation, deny-by-default access, typed allowlists, quotas, transaction ceilings, network boundaries, timeouts, rollback, quarantine, and tested stop controls. Probabilistic decisions must terminate inside deterministic boundaries.", "whyItMatters": [ "Probabilistic decisions must terminate inside deterministic boundaries.", "The operating shift is from “Ask the model to be careful” to “Make unsafe effects mechanically unreachable.”" ], "anatomy": [ { "label": "Practice 1", "description": "Default-deny tools, data, network, and credentials" }, { "label": "Practice 2", "description": "Validate every consequential action before effect" }, { "label": "Practice 3", "description": "Exercise rollback, quarantine, and kill paths independently" } ], "mechanism": [], "distinctions": [ { "label": "Ask the model to be careful", "description": "This concept moves the engineering system toward make unsafe effects mechanically unreachable." } ], "practices": [ "Default-deny tools, data, network, and credentials", "Validate every consequential action before effect", "Exercise rollback, quarantine, and kill paths independently" ], "failureModes": [ "Natural-language guardrails used as the only boundary", "A kill switch sharing the same compromised control path" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "google-agent-substrate", "owasp-agentic-security-state", "opa-policy-enforcement" ], "videoSourceIds": [], "relatedEntryIds": [ "execution-substrate", "runtime-policy-enforcement", "agent-incident-response" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "deterministic-containment", "lifecyclePhases": [ "03", "04", "05", "06", "07" ], "controlIds": [ "ARC-001", "ARC-002", "VER-003", "RUN-002" ], "seoTitle": "Deterministic containment | Agentic Engineering Knowledge Atlas", "seoDescription": "The enforcement envelope outside the model: isolation, deny-by-default access, typed allowlists, quotas, transaction ceilings, network boundaries, timeouts, rollback, quarantine, and tested stop controls." }, { "id": "runtime-policy-enforcement", "index": "", "title": "Runtime policy enforcement", "shortTitle": "Runtime policy enforcement", "aliases": [ "Policy", "policy enforcement point" ], "declaredRoute": "/agentic-engineering/runtime-policy-enforcement", "entryType": "core-concept", "domain": "Security & governance", "maturity": "maturing", "maturityNote": "Distributed policy engines are established; agent-aware decision inputs and enforcement points are emerging.", "question": "", "oneLine": "The pre-action decision and enforcement layer that evaluates identity, purpose, risk tier, tool, resource, data class, limits, approval state, and current evidence before allowing an agent action.", "definition": "The pre-action decision and enforcement layer that evaluates identity, purpose, risk tier, tool, resource, data class, limits, approval state, and current evidence before allowing an agent action. A policy observed after action is audit. A policy checked before effect is control.", "whyItMatters": [ "A policy observed after action is audit. A policy checked before effect is control.", "The operating shift is from “Post-hoc policy review” to “Policy at every action boundary.”" ], "anatomy": [ { "label": "Practice 1", "description": "Keep the policy decision outside the acting agent" }, { "label": "Practice 2", "description": "Version policy and record every decision input and result" }, { "label": "Practice 3", "description": "Fail closed when authority, evidence, or policy state is unavailable" } ], "mechanism": [], "distinctions": [ { "label": "Post-hoc policy review", "description": "This concept moves the engineering system toward policy at every action boundary." } ], "practices": [ "Keep the policy decision outside the acting agent", "Version policy and record every decision input and result", "Fail closed when authority, evidence, or policy state is unavailable" ], "failureModes": [ "Detailed policy logs with no enforcement point", "Stale or unreachable policy silently causing fail-open behavior" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "opa-policy-enforcement", "nist-deployed-monitoring", "microsoft-agent-risk-governance" ], "videoSourceIds": [], "relatedEntryIds": [ "observability-control", "deterministic-containment", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "runtime-policy-enforcement", "lifecyclePhases": [ "03", "05", "06", "07" ], "controlIds": [ "ARC-002", "VER-003", "RUN-001", "RUN-002" ], "seoTitle": "Runtime policy enforcement | Agentic Engineering Knowledge Atlas", "seoDescription": "The pre-action decision and enforcement layer that evaluates identity, purpose, risk tier, tool, resource, data class, limits, approval state, and current evidence before allowing an agent action." }, { "id": "agent-estate-governance", "index": "", "title": "Agent estate governance", "shortTitle": "Agent estate governance", "aliases": [ "Estate", "agent inventory", "agent registry" ], "declaredRoute": "/agentic-engineering/agent-estate-governance", "entryType": "core-concept", "domain": "Operating model", "maturity": "emerging", "maturityNote": "Agent registries are arriving, while cross-platform discovery and enforcement remain fragmented.", "question": "", "oneLine": "Portfolio governance for discovering and registering every enterprise agent with its identity, sponsor, owner, purpose, risk tier, platform, models, tools, data, dependencies, status, value, and exceptions.", "definition": "Portfolio governance for discovering and registering every enterprise agent with its identity, sponsor, owner, purpose, risk tier, platform, models, tools, data, dependencies, status, value, and exceptions. Each agent can look acceptable while the unmanaged estate becomes ungovernable.", "whyItMatters": [ "Each agent can look acceptable while the unmanaged estate becomes ungovernable.", "The operating shift is from “Project-by-project inventory” to “A continuously governed agent estate.”" ], "anatomy": [ { "label": "Practice 1", "description": "Discover and register agents across every build surface" }, { "label": "Practice 2", "description": "Block ownerless, duplicate, expired, or unapproved agents" }, { "label": "Practice 3", "description": "Measure risk, value, control coverage, and exception debt as a portfolio" } ], "mechanism": [], "distinctions": [ { "label": "Project-by-project inventory", "description": "This concept moves the engineering system toward a continuously governed agent estate." } ], "practices": [ "Discover and register agents across every build surface", "Block ownerless, duplicate, expired, or unapproved agents", "Measure risk, value, control coverage, and exception debt as a portfolio" ], "failureModes": [ "Shadow agents operating outside inventory", "A registry that is stale, voluntary, or disconnected from enforcement" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "microsoft-agent-lifecycle", "microsoft-agent-id-governance", "nist-agent-identity" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-identity", "continuous-recertification-retirement", "agent-incident-response" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "agent-estate-governance", "lifecyclePhases": [ "01", "06", "07", "08" ], "controlIds": [ "GOV-001", "ARC-002", "RUN-001", "LIF-001", "LIF-002" ], "seoTitle": "Agent estate governance | Agentic Engineering Knowledge Atlas", "seoDescription": "Portfolio governance for discovering and registering every enterprise agent with its identity, sponsor, owner, purpose, risk tier, platform, models, tools, data, dependencies, status, value, and exceptions." }, { "id": "continuous-recertification-retirement", "index": "", "title": "Continuous recertification & retirement", "shortTitle": "Continuous recertification & retirement", "aliases": [ "Lifecycle", "agent recertification", "agent retirement" ], "declaredRoute": "/agentic-engineering/continuous-recertification-retirement", "entryType": "core-concept", "domain": "Operating model", "maturity": "maturing", "maturityNote": "Access recertification is established; complete agent product-lifecycle governance is still developing.", "question": "", "oneLine": "Scheduled and event-driven reassessment that renews, restricts, transfers, suspends, or ends an agent’s authority—and verifiably revokes its identities, credentials, tools, dependencies, and retained data at retirement.", "definition": "Scheduled and event-driven reassessment that renews, restricts, transfers, suspends, or ends an agent’s authority—and verifiably revokes its identities, credentials, tools, dependencies, and retained data at retirement. Production authorization decays as owners, models, data, tools, and operating conditions change.", "whyItMatters": [ "Production authorization decays as owners, models, data, tools, and operating conditions change.", "The operating shift is from “One-time launch approval” to “Expiring, continuously renewed authority.”" ], "anatomy": [ { "label": "Practice 1", "description": "Require an owner heartbeat and authorization expiry" }, { "label": "Practice 2", "description": "Trigger reassessment after change, drift, incident, or organizational transfer" }, { "label": "Practice 3", "description": "Prove credential revocation, dependency removal, and data disposition" } ], "mechanism": [], "distinctions": [ { "label": "One-time launch approval", "description": "This concept moves the engineering system toward expiring, continuously renewed authority." } ], "practices": [ "Require an owner heartbeat and authorization expiry", "Trigger reassessment after change, drift, incident, or organizational transfer", "Prove credential revocation, dependency removal, and data disposition" ], "failureModes": [ "Dormant agents retaining valid credentials and integrations", "Ownership transfer assumed rather than explicitly authorized" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "microsoft-agent-lifecycle", "microsoft-agent-id-governance", "microsoft-agent-owners-sponsors" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-estate-governance", "agent-identity", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "continuous-recertification-retirement", "lifecyclePhases": [ "06", "07", "08" ], "controlIds": [ "AUT-002", "RUN-002", "LIF-001", "LIF-002" ], "seoTitle": "Continuous recertification & retirement | Agentic Engineering Knowledge Atlas", "seoDescription": "Scheduled and event-driven reassessment that renews, restricts, transfers, suspends, or ends an agent’s authority—and verifiably revokes its identities, credentials, tools, dependencies, and retained data at retirement." }, { "id": "instruction-data-trust-boundary", "index": "", "title": "Instruction–data trust boundary", "shortTitle": "Instruction–data trust boundary", "aliases": [ "Trust boundary", "instruction-data separation" ], "declaredRoute": "/agentic-engineering/instruction-data-trust-boundary", "entryType": "core-concept", "domain": "Security & governance", "maturity": "emerging", "maturityNote": "Prompt injection remains unsolved; layered controls reduce consequence but cannot perfectly classify intent.", "question": "", "oneLine": "An architecture that distinguishes authoritative instructions from retrieved content, memory, tool results, and external data through provenance, trust labels, privilege separation, validation, and mediated action.", "definition": "An architecture that distinguishes authoritative instructions from retrieved content, memory, tool results, and external data through provenance, trust labels, privilege separation, validation, and mediated action. Untrusted data can look like instructions to a model; syntax must never decide authority.", "whyItMatters": [ "Untrusted data can look like instructions to a model; syntax must never decide authority.", "The operating shift is from “All context treated as text” to “Provenance-aware context trust zones.”" ], "anatomy": [ { "label": "Practice 1", "description": "Label origin, authority, and trust for model-visible content" }, { "label": "Practice 2", "description": "Never let retrieved content grant tools or permissions" }, { "label": "Practice 3", "description": "Isolate and independently validate actions induced by untrusted data" } ], "mechanism": [], "distinctions": [ { "label": "All context treated as text", "description": "This concept moves the engineering system toward provenance-aware context trust zones." } ], "practices": [ "Label origin, authority, and trust for model-visible content", "Never let retrieved content grant tools or permissions", "Isolate and independently validate actions induced by untrusted data" ], "failureModes": [ "Prompt-only filtering presented as a security boundary", "External content entering durable memory and later appearing trusted" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "owasp-agentic-security-state", "owasp-agentic-top10", "anthropic-context" ], "videoSourceIds": [], "relatedEntryIds": [ "context-engineering", "durable-memory", "deterministic-containment" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "instruction-data-trust-boundary", "lifecyclePhases": [ "02", "03", "04", "05", "07" ], "controlIds": [ "DAT-001", "DAT-002", "ARC-001", "VER-002", "RUN-002" ], "seoTitle": "Instruction–data trust boundary | Agentic Engineering Knowledge Atlas", "seoDescription": "An architecture that distinguishes authoritative instructions from retrieved content, memory, tool results, and external data through provenance, trust labels, privilege separation, validation, and mediated action." }, { "id": "agent-incident-response", "index": "", "title": "Agent incident response", "shortTitle": "Agent incident response", "aliases": [ "Response", "agentic incident response" ], "declaredRoute": "/agentic-engineering/agent-incident-response", "entryType": "core-concept", "domain": "Security & governance", "maturity": "emerging", "maturityNote": "Incident response is established; playbooks for agent identity, memory, tools, and autonomous side effects are still forming.", "question": "", "oneLine": "An agent-specific response discipline that detects unsafe behavior, contains execution, revokes authority, preserves evidence, reconciles external effects, involves accountable owners, restores safely, and converts incidents into controls and evaluations.", "definition": "An agent-specific response discipline that detects unsafe behavior, contains execution, revokes authority, preserves evidence, reconciles external effects, involves accountable owners, restores safely, and converts incidents into controls and evaluations. Stop, revoke, quarantine, reconstruct, and reconcile must be designed before the first action.", "whyItMatters": [ "Stop, revoke, quarantine, reconstruct, and reconcile must be designed before the first action.", "The operating shift is from “Generic application incident handling” to “Identity-, action-, and outcome-aware response.”" ], "anatomy": [ { "label": "Practice 1", "description": "Correlate intent, identity, tool, policy, approval, and outcome traces" }, { "label": "Practice 2", "description": "Rehearse revoke, quarantine, rollback, and human escalation paths" }, { "label": "Practice 3", "description": "Reconcile external effects and turn failures into regression evaluations" } ], "mechanism": [], "distinctions": [ { "label": "Generic application incident handling", "description": "This concept moves the engineering system toward identity-, action-, and outcome-aware response." } ], "practices": [ "Correlate intent, identity, tool, policy, approval, and outcome traces", "Rehearse revoke, quarantine, rollback, and human escalation paths", "Reconcile external effects and turn failures into regression evaluations" ], "failureModes": [ "Stopping one process while credentials or delegated tasks remain active", "Destroying the evidence needed to reconstruct scope and downstream impact" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "owasp-agentic-security-state", "microsoft-agent-risk-governance", "microsoft-agent-owners-sponsors", "openai-monitoring" ], "videoSourceIds": [], "relatedEntryIds": [ "observability-control", "deterministic-containment", "agent-estate-governance" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "agent-incident-response", "lifecyclePhases": [ "03", "05", "06", "07", "08" ], "controlIds": [ "GOV-003", "VER-003", "RUN-001", "RUN-002", "LIF-001" ], "seoTitle": "Agent incident response | Agentic Engineering Knowledge Atlas", "seoDescription": "An agent-specific response discipline that detects unsafe behavior, contains execution, revokes authority, preserves evidence, reconciles external effects, involves accountable owners, restores safely, and converts incidents into controls and evaluations." }, { "id": "ai-agent", "index": "", "title": "AI agent", "shortTitle": "AI agent", "aliases": [ "agent", "artificial intelligence agent", "LLM agent" ], "declaredRoute": "/agentic-engineering/ai-agent", "entryType": "technical-term", "domain": "Foundations", "maturity": "maturing", "maturityNote": "The core loop is established, while architecture boundaries, assurance practices, and standards for consequential agents are still converging.", "question": "What is an AI agent?", "oneLine": "A goal-directed software system in which a model dynamically chooses steps and tools, observes results, updates working state, and continues until an exit condition or human handoff.", "definition": "An AI agent is a goal-directed software system in which a model dynamically chooses steps and tools, observes the results, updates its working state, and continues until it reaches an exit condition or hands control to a human. The model is only the reasoning component: a production agent also needs governed instructions, context, tools, identity, permissions, state, an execution harness, constraints, telemetry, evaluation, independent verification, and accountable human authority.", "whyItMatters": [ "Agency begins when the model can select the next action from observed state rather than merely return one response along a fixed application path.", "The loop makes the system useful across uncertain, multi-step work—and also creates new failure surfaces because one model output can change the next context, tool call, or real-world effect.", "Enterprise readiness comes from the surrounding system: bounded standing, deterministic enforcement, independently owned checks, recorded evidence, and a named human disposition.", "An agent can be assistive, read-only, transactional, or consequential. “Agent” describes an execution pattern; it does not grant autonomy, authority, or trust." ], "anatomy": [ { "label": "Goal", "description": "A bounded outcome and success condition the system is trying to reach." }, { "label": "Model", "description": "The probabilistic reasoning component that interprets state and proposes the next step." }, { "label": "Instructions & policy", "description": "Behavioral direction plus enforceable rules that constrain what actions may take effect." }, { "label": "Context", "description": "The selected information made visible for the current decision—not every available document." }, { "label": "Tools", "description": "Typed interfaces through which the agent can retrieve information or change an environment." }, { "label": "Identity & standing", "description": "An attributable non-human identity with purpose-bound, time-bound permissions conferred by governance." }, { "label": "Working state & memory", "description": "Task progress, observations, decisions, and durable knowledge carried across steps or sessions." }, { "label": "Execution harness", "description": "The runtime loop, checkpoints, retries, budgets, environments, and stop conditions around the model." }, { "label": "Verification", "description": "Deterministic and agentic checks, independently owned where acceptance or risk disposition is involved." }, { "label": "Evidence & observability", "description": "Attributable traces and artifacts showing inputs, decisions, actions, checks, approvals, and outcomes." }, { "label": "Exit & human handoff", "description": "A finite completion, block, escalation, or named human disposition—not an endless retry loop." } ], "mechanism": [], "distinctions": [ { "label": "Chatbot", "description": "A chatbot primarily exchanges messages; an agent selects and executes steps against an environment." }, { "label": "Agentic workflow", "description": "A workflow follows largely predetermined control flow; an agent dynamically determines at least part of the path." }, { "label": "Large language model", "description": "A model predicts outputs from inputs; the agent is the surrounding goal-directed software system." }, { "label": "Robotic process automation", "description": "Traditional automation follows explicit rules; agents can choose among actions under uncertainty, within enforced bounds." }, { "label": "Authority", "description": "Technical ability to call a tool is not organizational standing to take the action. Governance confers standing; the control plane enforces its limits." } ], "practices": [ "Start with the smallest degree of agency that can produce the intended value", "Give every consequential action an attributable identity, purpose, scope, and expiry", "Use typed, narrow tools and validate inputs and effects outside the model", "Separate instructions from untrusted data and retrieved content", "Combine deterministic checks with independent agentic verification", "Define budgets, retries, completion, hold, escalation, and stop paths before runtime", "Preserve an evidence chain from intent through human disposition and production outcome", "Reclassify and recertify when models, tools, data, owners, or impact change" ], "failureModes": [ "An open-ended loop that retries without new evidence or a finite stop condition", "Tool access being mistaken for permission or business authority", "The same model lineage building and independently accepting its own output", "Retrieved or user-authored content overriding trusted instructions", "Long contexts hiding stale, contradictory, or irrelevant state", "Rich traces with no tested path to block, hold, revoke, or escalate", "A named agent remaining active after purpose, owner, or authorization expires" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-building-effective-agents", "anthropic-trustworthy-agents", "openai-practical-agent-guide", "react-paper", "nist-agent-identity", "video-linear-production-agents" ], "videoSourceIds": [ "video-linear-production-agents" ], "relatedEntryIds": [ "agent-loop", "agentic-system", "harness-engineering", "agent-identity", "deterministic-containment", "multi-agent-verification", "human-accountability" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "AI agent | Agentic Engineering Knowledge Atlas", "seoDescription": "A goal-directed software system in which a model dynamically chooses steps and tools, observes results, updates working state, and continues until an exit condition or human handoff." }, { "id": "agentic-system", "index": "", "title": "Agentic system", "shortTitle": "Agentic system", "aliases": [ "agent system" ], "declaredRoute": "/agentic-engineering/agentic-system", "entryType": "technical-term", "domain": "Foundations", "maturity": "maturing", "maturityNote": "The system boundary is increasingly recognized, but product architectures and assurance patterns remain diverse.", "question": "", "oneLine": "A software system that delegates some path selection or action choice to one or more model-driven agents within an engineered operating boundary.", "definition": "An agentic system combines one or more agents with deterministic software, tools, data, environments, policies, verification, evidence, and human decision rights. The system—not the model alone—is the correct unit for architecture, risk classification, evaluation, and accountability.", "whyItMatters": [ "The adjective “agentic” describes where control flow is partly model-directed.", "A useful design names which choices are dynamic, which effects are mechanically bounded, and which decisions remain human." ], "anatomy": [ { "label": "Agent layer", "description": "Model-directed planning and action." }, { "label": "Deterministic layer", "description": "Software boundaries, transactions, limits, and enforcement." }, { "label": "Accountability layer", "description": "Named owners, verifiers, and release authorities." } ], "mechanism": [], "distinctions": [ { "label": "AI-enabled application", "description": "An application may use a model without allowing it to choose a multi-step path or take actions." }, { "label": "AI agent", "description": "The agent is one operating component; the agentic system includes every dependency and governing boundary." } ], "practices": [ "Draw the system boundary around every model, tool, identity, datastore, verifier, and human authority", "Evaluate end-to-end outcomes and side effects rather than model responses alone" ], "failureModes": [ "Treating the model as the whole product", "Leaving vendor tools or human work outside the risk boundary" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-trustworthy-agents", "anthropic-building-effective-agents", "nist-ai-rmf" ], "videoSourceIds": [], "relatedEntryIds": [ "ai-agent", "agentic-workflow", "agentic-engineering", "eval-driven-development" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agentic system | Agentic Engineering Knowledge Atlas", "seoDescription": "A software system that delegates some path selection or action choice to one or more model-driven agents within an engineered operating boundary." }, { "id": "agentic-workflow", "index": "", "title": "Agentic workflow", "shortTitle": "Agentic workflow", "aliases": [ "LLM workflow", "AI workflow" ], "declaredRoute": "/agentic-engineering/agentic-workflow", "entryType": "technical-term", "domain": "Foundations", "maturity": "foundational", "maturityNote": "Workflow orchestration is established; the term is sometimes blurred with agents in marketing and product language.", "question": "", "oneLine": "A model-enabled process whose major control path is defined in code, even when models perform individual steps.", "definition": "An agentic workflow orchestrates models, tools, and checks through substantially predetermined branches, sequences, or routers. It can use planning or generation inside a step without delegating the overall process to an autonomous agent.", "whyItMatters": [ "Workflows trade some flexibility for predictability, inspectability, and simpler testing.", "Many enterprise problems need a workflow with one bounded agentic step—not a fully dynamic agent." ], "anatomy": [ { "label": "Explicit control flow", "description": "Code decides the major sequence and branches." }, { "label": "Model steps", "description": "Models transform, classify, generate, or evaluate within bounded nodes." }, { "label": "Deterministic transitions", "description": "Typed conditions move work between steps." } ], "mechanism": [], "distinctions": [ { "label": "AI agent", "description": "An agent dynamically chooses more of its process and tool use; a workflow follows code-defined control flow." }, { "label": "Traditional workflow", "description": "An agentic workflow contains probabilistic model steps even if its topology remains fixed." } ], "practices": [ "Prefer workflows when paths and approvals are known", "Make probabilistic nodes explicit and independently testable" ], "failureModes": [ "Calling every multi-step automation an agent", "Hiding model uncertainty behind a deterministic-looking diagram" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-building-effective-agents", "openai-practical-agent-guide" ], "videoSourceIds": [], "relatedEntryIds": [ "ai-agent", "agentic-system", "orchestrator-supervisor", "structured-output" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agentic workflow | Agentic Engineering Knowledge Atlas", "seoDescription": "A model-enabled process whose major control path is defined in code, even when models perform individual steps." }, { "id": "agent-loop", "index": "", "title": "Agent loop", "shortTitle": "Agent loop", "aliases": [ "reason-act-observe loop", "plan-act-observe-adjust loop" ], "declaredRoute": "/agentic-engineering/agent-loop", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "maturing", "maturityNote": "The loop pattern is well established; robust long-running recovery and control remain active engineering areas.", "question": "", "oneLine": "The finite runtime cycle in which an agent interprets state, selects an action, observes the result, updates state, and decides what happens next.", "definition": "The agent loop is the control cycle that turns a model call into goal-directed behavior: construct context, reason or plan, choose a tool or response, validate the proposed action, execute inside bounds, observe the effect, update working state, verify progress, then finish, retry, correct, hold, or escalate.", "whyItMatters": [ "Each loop turn changes the next decision context, so small errors can compound.", "Finite verbs and budgets make loop behavior testable: bind, block, correct, hold, release, escalate, stop." ], "anatomy": [ { "label": "Orient", "description": "Construct the current state and bounded context." }, { "label": "Decide", "description": "Select a next action or termination state." }, { "label": "Act", "description": "Validate and execute through a governed tool." }, { "label": "Observe", "description": "Capture the result and environmental change." }, { "label": "Disposition", "description": "Continue, correct, finish, hold, or escalate." } ], "mechanism": [], "distinctions": [ { "label": "Infinite retry", "description": "A production loop has budgets, state changes, and an explicit terminal condition." }, { "label": "Chain of thought", "description": "The loop is an observable software control structure; private model reasoning is not the system boundary." } ], "practices": [ "Make each transition and side effect observable", "Require new evidence before retrying", "Test completion and failure paths as first-class behavior" ], "failureModes": [ "Retrying the same prompt without changing state", "Tool side effects occurring before policy and argument checks", "No durable checkpoint before context loss" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-trustworthy-agents", "react-paper", "openai-practical-agent-guide" ], "videoSourceIds": [], "relatedEntryIds": [ "ai-agent", "goal-exit-condition", "harness-engineering", "durable-execution", "loop-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agent loop | Agentic Engineering Knowledge Atlas", "seoDescription": "The finite runtime cycle in which an agent interprets state, selects an action, observes the result, updates state, and decides what happens next." }, { "id": "goal-exit-condition", "index": "", "title": "Goal and exit condition", "shortTitle": "Goal and exit condition", "aliases": [ "termination condition", "stop condition", "success condition" ], "declaredRoute": "/agentic-engineering/goal-exit-condition", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "foundational", "maturityNote": "Termination is a basic software principle, but agents make underspecified goals and endless retries unusually consequential.", "question": "", "oneLine": "A testable target paired with the finite states that determine when an agent completes, blocks, escalates, or stops.", "definition": "A goal specifies the bounded outcome an agent should pursue; exit conditions specify when the runtime must stop pursuing it. Together they define success, failure, maximum effort, blocked states, required evidence, human handoff, and safe termination.", "whyItMatters": [ "A goal without evidence criteria encourages plausible-looking completion.", "An exit condition is a runtime control, not merely a sentence asking the model to stop." ], "anatomy": [ { "label": "Outcome", "description": "The intended result in observable terms." }, { "label": "Acceptance evidence", "description": "The checks and artifacts required to claim completion." }, { "label": "Budgets", "description": "Limits on steps, time, spend, tools, and retries." }, { "label": "Terminal states", "description": "Complete, blocked, held, escalated, cancelled, or failed." } ], "mechanism": [], "distinctions": [ { "label": "Prompt request", "description": "A request expresses intent; a goal and exit contract defines measurable completion and safe non-completion." } ], "practices": [ "Write acceptance evidence before execution", "Define blocked and escalation states alongside success", "Enforce budgets outside the model" ], "failureModes": [ "The agent declares done based on its own prose", "Timeout is the only stop mechanism" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-practical-agent-guide", "anthropic-long-running-harness" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-loop", "intent-engineering", "eval-driven-development" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Goal and exit condition | Agentic Engineering Knowledge Atlas", "seoDescription": "A testable target paired with the finite states that determine when an agent completes, blocks, escalates, or stops." }, { "id": "large-language-model", "index": "", "title": "Large language model", "shortTitle": "Large language model", "aliases": [ "LLM", "foundation language model" ], "declaredRoute": "/agentic-engineering/large-language-model", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "The model class is established and rapidly evolving; capabilities and limitations differ materially by model, configuration, and task.", "question": "", "oneLine": "A learned model that produces or scores token sequences from context; in an agent, it is the reasoning component rather than the complete system.", "definition": "A large language model estimates language-conditioned outputs from a context of tokens. It may generate text, structured data, code, or tool-call arguments, but it does not by itself provide identity, permission, durable memory, execution, verification, evidence, or accountability.", "whyItMatters": [ "Model behavior is probabilistic and context-dependent.", "Enterprise claims must be measured on the complete deployed system and workload, not inferred from a public leaderboard." ], "anatomy": [ { "label": "Parameters", "description": "Learned weights encoding statistical patterns." }, { "label": "Context", "description": "The finite token sequence supplied at inference time." }, { "label": "Decoder", "description": "The process that selects output tokens under configured sampling." } ], "mechanism": [], "distinctions": [ { "label": "AI agent", "description": "A model generates candidate decisions; an agent loops, uses tools, maintains state, and operates inside a governed system." }, { "label": "Knowledge base", "description": "Model weights are not a current, attributable store of enterprise truth." } ], "practices": [ "Select models through workload-specific evaluations", "Record model identity, version, configuration, and routing decisions" ], "failureModes": [ "Treating fluency as factual authority", "Assuming one benchmark ranking predicts production fitness" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "artificial-analysis-methodology", "nist-benchmark-evals", "openai-practical-agent-guide" ], "videoSourceIds": [], "relatedEntryIds": [ "ai-agent", "context-window", "model-routing", "mixture-of-experts" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Large language model | Agentic Engineering Knowledge Atlas", "seoDescription": "A learned model that produces or scores token sequences from context; in an agent, it is the reasoning component rather than the complete system." }, { "id": "tool-calling", "index": "", "title": "Tool calling", "shortTitle": "Tool calling", "aliases": [ "function calling", "agent tool use" ], "declaredRoute": "/agentic-engineering/tool-calling", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "maturing", "maturityNote": "Tool-call interfaces are widely available; authorization, semantic safety, and cross-tool composition remain active risk areas.", "question": "", "oneLine": "A model-mediated interface in which the system selects a named function and proposes structured arguments for software to validate and execute.", "definition": "Tool calling lets a model request information or action through declared interfaces. The request remains a proposal until trusted software validates identity, standing, policy, arguments, limits, approvals, and expected effects before execution.", "whyItMatters": [ "Tools convert language output into environmental effects.", "The security boundary belongs at the executor and policy enforcement point, not in a tool description or model instruction alone." ], "anatomy": [ { "label": "Tool contract", "description": "A narrow name, purpose, typed input, and typed result." }, { "label": "Policy check", "description": "An external allow, deny, hold, or escalation decision." }, { "label": "Executor", "description": "Code that performs the validated operation." }, { "label": "Evidence", "description": "Recorded request, decision, effect, and result." } ], "mechanism": [], "distinctions": [ { "label": "Authority", "description": "The ability to form a tool call does not grant permission to execute it." }, { "label": "Model Context Protocol", "description": "Tool calling is an interaction pattern; MCP is one protocol for exposing capabilities." } ], "practices": [ "Use narrow schemas and least privilege", "Validate arguments and postconditions outside the model", "Make high-impact tools reversible or approval-gated" ], "failureModes": [ "A broad shell or database tool with borrowed credentials", "Tool output injected back as trusted instructions" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-practical-agent-guide", "mcp-architecture", "owasp-agentic-top10" ], "videoSourceIds": [], "relatedEntryIds": [ "ai-agent", "tools-and-protocols", "runtime-policy-enforcement", "model-context-protocol" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Tool calling | Agentic Engineering Knowledge Atlas", "seoDescription": "A model-mediated interface in which the system selects a named function and proposes structured arguments for software to validate and execute." }, { "id": "system-instructions", "index": "", "title": "System instructions", "shortTitle": "System instructions", "aliases": [ "system prompt", "agent instructions" ], "declaredRoute": "/agentic-engineering/system-instructions", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "foundational", "maturityNote": "Instruction layers are established; their priority semantics and robustness vary across models and platforms.", "question": "", "oneLine": "Trusted behavioral direction supplied by the application to shape how a model performs a task.", "definition": "System instructions define role, objectives, process guidance, response contracts, and behavioral constraints for a model or agent. They influence behavior but are not a deterministic security boundary, policy enforcement mechanism, or substitute for authorization.", "whyItMatters": [ "Instructions are code-like inputs whose wording and placement can materially change behavior.", "Critical restrictions must also be enforced outside the model because natural-language adherence is probabilistic." ], "anatomy": [ { "label": "Role", "description": "The bounded function the model should perform." }, { "label": "Objective", "description": "The intended outcome and acceptance conditions." }, { "label": "Constraints", "description": "Behavioral rules, escalation conditions, and prohibited actions." }, { "label": "Contract", "description": "Expected format, evidence, and handoff behavior." } ], "mechanism": [], "distinctions": [ { "label": "Policy enforcement", "description": "Instructions request behavior; an enforcement point mechanically allows, denies, holds, or constrains action." }, { "label": "Retrieved content", "description": "Instructions come from a trusted control layer; retrieved documents remain data unless explicitly promoted through governance." } ], "practices": [ "Keep trusted instructions separate from user and retrieved data", "Version instructions and test them against adversarial cases", "Move critical prohibitions into deterministic controls" ], "failureModes": [ "Prompt injection changes the apparent instruction hierarchy", "A long system prompt becomes an unaudited policy document" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "owasp-agentic-security-state", "openai-practical-agent-guide" ], "videoSourceIds": [], "relatedEntryIds": [ "instruction-data-trust-boundary", "context-engineering", "runtime-policy-enforcement" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "System instructions | Agentic Engineering Knowledge Atlas", "seoDescription": "Trusted behavioral direction supplied by the application to shape how a model performs a task." }, { "id": "context-window", "index": "", "title": "Context window", "shortTitle": "Context window", "aliases": [ "model context window", "token window" ], "declaredRoute": "/agentic-engineering/context-window", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "foundational", "maturityNote": "Finite model context is established; effective use remains workload- and model-dependent.", "question": "", "oneLine": "The finite sequence of tokens a model can directly condition on during a single inference operation.", "definition": "The context window contains the active instructions, user input, selected history, retrieved knowledge, tool results, and other state presented to the model. A larger window increases capacity but does not ensure relevance, consistency, truth, or correct attention.", "whyItMatters": [ "Context is a scarce runtime resource even when nominal token limits are large.", "Selection, ordering, provenance, compression, and removal are engineering decisions." ], "anatomy": [ { "label": "Capacity", "description": "The maximum token budget available to the inference." }, { "label": "Composition", "description": "The mix and ordering of instructions, state, examples, evidence, and retrieved data." }, { "label": "Provenance", "description": "Where each context item came from and what trust level it carries." } ], "mechanism": [], "distinctions": [ { "label": "Memory", "description": "Memory persists or retrieves information across time; context is what is visible for this decision." }, { "label": "Knowledge", "description": "Presence in context does not make a statement true or authoritative." } ], "practices": [ "Load the smallest sufficient context for the decision", "Label source, recency, and trust level", "Measure performance under realistic context length and noise" ], "failureModes": [ "Context stuffing hides the governing requirement", "Stale summaries silently replace primary evidence" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "video-linear-production-agents" ], "videoSourceIds": [ "video-linear-production-agents" ], "relatedEntryIds": [ "context-engineering", "working-state", "retrieval-augmented-generation" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Context window | Agentic Engineering Knowledge Atlas", "seoDescription": "The finite sequence of tokens a model can directly condition on during a single inference operation." }, { "id": "working-state", "index": "", "title": "Working state", "shortTitle": "Working state", "aliases": [ "agent state", "task state" ], "declaredRoute": "/agentic-engineering/working-state", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "maturing", "maturityNote": "State-machine techniques are established; consistent agent-state models and portability are still emerging.", "question": "", "oneLine": "The current, inspectable record of an agent’s task position, observations, decisions, pending actions, and budgets.", "definition": "Working state is the operational state needed to continue an agent run safely: goal, plan, completed steps, tool results, unresolved questions, checkpoints, resource budgets, verifier dispositions, and terminal status. It should be explicit and durable where recovery matters.", "whyItMatters": [ "State should survive model calls and, for long-running work, process or context loss.", "A transcript is useful evidence but often a poor canonical state representation." ], "anatomy": [ { "label": "Task position", "description": "What has completed and what remains." }, { "label": "Observations", "description": "Validated results from tools and the environment." }, { "label": "Budgets", "description": "Remaining time, steps, spend, and action limits." }, { "label": "Disposition", "description": "Running, blocked, held, escalated, completed, or failed." } ], "mechanism": [], "distinctions": [ { "label": "Conversation history", "description": "History records exchanges; working state is a structured, current operating record." }, { "label": "Durable memory", "description": "Working state belongs to a run; durable memory can outlive it and requires separate governance." } ], "practices": [ "Use typed, versioned state transitions", "Checkpoint before irreversible or long-running actions", "Separate observed facts from model hypotheses" ], "failureModes": [ "The model reconstructs critical state from a truncated transcript", "Two agents update shared state without concurrency control" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-long-running-harness", "anthropic-managed-agents", "openai-symphony" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-loop", "durable-memory", "durable-execution", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Working state | Agentic Engineering Knowledge Atlas", "seoDescription": "The current, inspectable record of an agent’s task position, observations, decisions, pending actions, and budgets." }, { "id": "retrieval-augmented-generation", "index": "", "title": "Retrieval-augmented generation", "shortTitle": "Retrieval-augmented generation", "aliases": [ "RAG", "retrieval augmented generation" ], "declaredRoute": "/agentic-engineering/retrieval-augmented-generation", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "foundational", "maturityNote": "The architecture is established; production quality depends heavily on corpus governance, retrieval evaluation, and trust boundaries.", "question": "", "oneLine": "A pattern that retrieves external information at inference time and supplies selected results to a generative model.", "definition": "Retrieval-augmented generation combines a retrieval system with a model so responses can be conditioned on external, updateable sources. Retrieval can improve grounding and attribution, but it does not guarantee that selected content is relevant, current, complete, authorized, or true.", "whyItMatters": [ "RAG changes the evidence available to the model without changing model weights.", "The retrieval pipeline is part of the assurance surface: ingestion, indexing, access control, ranking, provenance, and citation all require evaluation." ], "anatomy": [ { "label": "Corpus", "description": "The governed source material available for retrieval." }, { "label": "Retriever", "description": "The method that selects candidates for a query." }, { "label": "Context assembly", "description": "Ranking, filtering, and formatting the material shown to the model." }, { "label": "Attribution", "description": "Links between claims and the exact retrieved sources." } ], "mechanism": [], "distinctions": [ { "label": "Memory", "description": "RAG is a retrieval pattern; it is not automatically an agent’s validated personal or project memory." }, { "label": "Ground truth", "description": "Retrieved content can be incorrect, stale, conflicting, or poisoned." } ], "practices": [ "Enforce source-level access before retrieval", "Evaluate retrieval separately from generation", "Carry provenance and trust labels into context" ], "failureModes": [ "Prompt injection stored inside the corpus", "A plausible answer cites irrelevant chunks", "Sensitive content is filtered after rather than before retrieval" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "rag-paper", "anthropic-context", "owasp-memory" ], "videoSourceIds": [], "relatedEntryIds": [ "context-engineering", "context-window", "durable-memory", "instruction-data-trust-boundary" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Retrieval-augmented generation | Agentic Engineering Knowledge Atlas", "seoDescription": "A pattern that retrieves external information at inference time and supplies selected results to a generative model." }, { "id": "reflection", "index": "", "title": "Reflection", "shortTitle": "Reflection", "aliases": [ "agent reflection", "self-reflection" ], "declaredRoute": "/agentic-engineering/reflection", "entryType": "technical-term", "domain": "Evaluation & verification", "maturity": "emerging", "maturityNote": "Research and practical use show promise, while reliability, calibration, and independence remain task-dependent.", "question": "", "oneLine": "A feedback pattern in which a model critiques an attempt and records lessons or a revised approach for another attempt.", "definition": "Reflection asks an agent or model to inspect an outcome, feedback, or trajectory and produce a critique, diagnosis, or revised plan. It can improve later attempts, but it remains correlated self-review unless a separate verifier, model lineage, deterministic tool, or accountable expert independently challenges the result.", "whyItMatters": [ "Reflection creates a feedback artifact that can alter the next loop turn.", "It should be treated as a builder improvement mechanism, not the final acceptance authority." ], "anatomy": [ { "label": "Signal", "description": "Test output, tool result, user correction, or other evidence." }, { "label": "Critique", "description": "A diagnosis of why the attempt succeeded or failed." }, { "label": "Update", "description": "A revised plan, memory item, or candidate output." } ], "mechanism": [], "distinctions": [ { "label": "Independent verification", "description": "Self-reflection shares model context and blind spots; independent verification separates judgment and block authority." }, { "label": "Retry", "description": "Reflection should introduce new evidence or a changed strategy before another attempt." } ], "practices": [ "Ground critique in external evidence", "Keep builder reflection separate from release acceptance", "Evaluate whether reflections improve outcomes rather than merely sound persuasive" ], "failureModes": [ "Confident rationalization of the original error", "Poisoned feedback becomes durable memory" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "reflexion-paper", "deeplearning-agentic-ai-course", "anthropic-evals" ], "videoSourceIds": [], "relatedEntryIds": [ "agent-loop", "multi-agent-verification", "eval-driven-development", "llm-as-judge" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Reflection | Agentic Engineering Knowledge Atlas", "seoDescription": "A feedback pattern in which a model critiques an attempt and records lessons or a revised approach for another attempt." }, { "id": "sandbox", "index": "", "title": "Sandbox", "shortTitle": "Sandbox", "aliases": [ "agent sandbox", "isolated environment" ], "declaredRoute": "/agentic-engineering/sandbox", "entryType": "technical-term", "domain": "Security & governance", "maturity": "maturing", "maturityNote": "Isolation primitives are established; agent-specific stateful sandboxes and control integrations are still evolving.", "question": "", "oneLine": "An isolated execution environment that restricts an agent’s resources, credentials, network, persistence, and blast radius.", "definition": "A sandbox places agent execution inside a controlled environment with explicit filesystem, process, network, secret, compute, and lifecycle boundaries. Isolation limits effects; it does not by itself determine whether an action is authorized or whether output is correct.", "whyItMatters": [ "The execution environment is part of the agent system, not background infrastructure.", "Strong designs combine isolation with least privilege, policy enforcement, evidence, rollback, and tested termination." ], "anatomy": [ { "label": "Isolation", "description": "Separation from other tasks, tenants, hosts, and credentials." }, { "label": "Resource policy", "description": "Limits on network, CPU, memory, storage, time, and processes." }, { "label": "Lifecycle", "description": "Provisioning, checkpointing, teardown, and evidence capture." } ], "mechanism": [], "distinctions": [ { "label": "Authorization", "description": "A sandbox limits where execution occurs; policy decides whether a particular effect is allowed." }, { "label": "Container", "description": "A container can be one isolation primitive but is not automatically a complete security boundary." } ], "practices": [ "Use per-task identity and isolated workspaces", "Default-deny egress and secret access", "Destroy or quarantine environments on terminal states" ], "failureModes": [ "Shared credentials defeat task isolation", "A sandbox has unrestricted network or host mounts" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "google-agent-substrate", "owasp-agentic-top10", "nist-zero-trust" ], "videoSourceIds": [], "relatedEntryIds": [ "execution-substrate", "deterministic-containment", "agent-identity" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Sandbox | Agentic Engineering Knowledge Atlas", "seoDescription": "An isolated execution environment that restricts an agent’s resources, credentials, network, persistence, and blast radius." }, { "id": "structured-output", "index": "", "title": "Structured output", "shortTitle": "Structured output", "aliases": [ "schema-constrained output", "typed model output" ], "declaredRoute": "/agentic-engineering/structured-output", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "maturing", "maturityNote": "Schema-constrained generation is widely supported, though guarantees and failure handling differ across model APIs.", "question": "", "oneLine": "Model output constrained to a declared machine-readable schema so software can parse and validate its shape.", "definition": "Structured output makes a probabilistic model produce data against a defined schema, improving interoperability and reducing parsing ambiguity. Schema validity establishes shape—not factual correctness, business validity, authorization, or safe effect.", "whyItMatters": [ "Typed boundaries make model decisions easier to inspect, test, reject, and route.", "Semantic validation and policy evaluation must still occur in trusted code." ], "anatomy": [ { "label": "Schema", "description": "Allowed fields, types, enumerations, and required values." }, { "label": "Validation", "description": "Trusted checks for structure and domain constraints." }, { "label": "Disposition", "description": "Accept, repair, reject, or escalate invalid output." } ], "mechanism": [], "distinctions": [ { "label": "Correct output", "description": "A response can satisfy the schema while containing false or unsafe values." }, { "label": "Tool authorization", "description": "Typed arguments make validation possible but do not grant permission to execute." } ], "practices": [ "Keep schemas narrow and versioned", "Validate domain invariants after parsing", "Fail closed for consequential actions" ], "failureModes": [ "Automatic repair changes meaning without review", "Free-form strings smuggle unvalidated instructions into typed fields" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-practical-agent-guide", "mcp-architecture" ], "videoSourceIds": [], "relatedEntryIds": [ "tool-calling", "agentic-workflow", "runtime-policy-enforcement" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Structured output | Agentic Engineering Knowledge Atlas", "seoDescription": "Model output constrained to a declared machine-readable schema so software can parse and validate its shape." }, { "id": "llm-as-judge", "index": "", "title": "LLM as judge", "shortTitle": "LLM as judge", "aliases": [ "model grader", "LLM judge", "AI grader" ], "declaredRoute": "/agentic-engineering/llm-as-judge", "entryType": "technical-term", "domain": "Evaluation & verification", "maturity": "emerging", "maturityNote": "Use is widespread and evaluation methods are developing; bias, stability, contamination, and calibration remain material limitations.", "question": "", "oneLine": "The use of a language model to score, compare, classify, or critique another system’s output or trajectory.", "definition": "An LLM judge applies a rubric to candidate outputs or agent traces and returns a score, preference, explanation, or failure label. Model graders can scale subjective evaluation, but they require calibration against experts and are not automatically independent, unbiased, or authorized to accept risk.", "whyItMatters": [ "A judge can measure qualities that deterministic tests cannot easily express.", "The verification design must disclose judge model lineage, rubric, sampling, disagreement handling, and human calibration." ], "anatomy": [ { "label": "Rubric", "description": "Observable criteria and decision labels." }, { "label": "Judge", "description": "The model, version, context, and configuration performing evaluation." }, { "label": "Calibration set", "description": "Expert-scored examples used to measure agreement and bias." }, { "label": "Disposition", "description": "What the score is allowed to block, route, or inform." } ], "mechanism": [], "distinctions": [ { "label": "Independent verifier", "description": "A judge becomes one verifier method only when ownership, lineage, scope, trigger, block authority, and recorded disposition satisfy independence requirements." }, { "label": "Deterministic test", "description": "A model grader is probabilistic and rubric-dependent; a deterministic test has reproducible program logic." } ], "practices": [ "Calibrate against domain experts", "Randomize or counterbalance comparison order", "Fuse model judgment with deterministic checks and human review" ], "failureModes": [ "Position or verbosity bias determines the winner", "Builder and judge share the same model lineage and blind spots", "A scalar score hides disqualifying failures" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-evals", "llm-judge-position-bias", "nist-benchmark-evals" ], "videoSourceIds": [], "relatedEntryIds": [ "eval-driven-development", "multi-agent-verification", "reflection" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "LLM as judge | Agentic Engineering Knowledge Atlas", "seoDescription": "The use of a language model to score, compare, classify, or critique another system’s output or trajectory." }, { "id": "guardrail", "index": "", "title": "Guardrail", "shortTitle": "Guardrail", "aliases": [ "AI guardrail", "agent guardrail" ], "declaredRoute": "/agentic-engineering/guardrail", "entryType": "technical-term", "domain": "Security & governance", "maturity": "contested", "maturityNote": "The label is common but imprecise; underlying control techniques range from established to experimental.", "question": "", "oneLine": "An overloaded label for a check or constraint intended to reduce unsafe inputs, outputs, decisions, or effects.", "definition": "“Guardrail” can mean a prompt instruction, content filter, schema validator, policy check, permission boundary, rate limit, verifier, or containment mechanism. Because these mechanisms have different timing and authority, serious designs name the specific control, owner, trigger, scope, block authority, evidence, and failure behavior instead.", "whyItMatters": [ "Calling a component a guardrail says little about whether it observes, recommends, blocks, or contains.", "Natural-language safety instructions are useful behavioral guidance but not deterministic enforcement." ], "anatomy": [ { "label": "Timing", "description": "Before generation, inline during work, at a release gate, or after release." }, { "label": "Mechanism", "description": "Deterministic rule, model classifier, verifier, sandbox, or human decision." }, { "label": "Authority", "description": "Advisory, correct, hold, block, revoke, or escalate." } ], "mechanism": [], "distinctions": [ { "label": "Control", "description": "A control has a defined objective, owner, trigger, evidence, and effect; “guardrail” alone does not communicate those properties." }, { "label": "Observability", "description": "Seeing unsafe behavior after it happens does not prevent or block it." } ], "practices": [ "Replace the generic label with the actual mechanism and authority", "Test bypass, fail-open, and unavailable-service behavior", "Layer probabilistic detection with deterministic containment" ], "failureModes": [ "A content filter is presented as a complete safety system", "A monitor is described as an enforcement control" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "owasp-agentic-top10", "owasp-agentic-security-state", "nist-ai-rmf" ], "videoSourceIds": [], "relatedEntryIds": [ "deterministic-containment", "runtime-policy-enforcement", "multi-agent-verification", "observability" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Guardrail | Agentic Engineering Knowledge Atlas", "seoDescription": "An overloaded label for a check or constraint intended to reduce unsafe inputs, outputs, decisions, or effects." }, { "id": "observability", "index": "", "title": "Observability", "shortTitle": "Observability", "aliases": [ "agent observability", "AI observability" ], "declaredRoute": "/agentic-engineering/observability", "entryType": "technical-term", "domain": "Evaluation & verification", "maturity": "maturing", "maturityNote": "Telemetry foundations are established and agent-specific conventions are developing; causal interpretation remains difficult.", "question": "", "oneLine": "The ability to understand an agent system’s internal behavior and outcomes from attributable traces, metrics, events, state, and evidence.", "definition": "Observability instruments model calls, context construction, tool requests, policy decisions, approvals, state transitions, verifier results, costs, latency, errors, and outcomes so people and systems can explain what happened. Observability informs decisions; it does not itself allow, deny, hold, revoke, or stop an action.", "whyItMatters": [ "Observability tells you what happened. A control plane determines what is allowed to happen. Governance sets the rules; the control plane enforces them.", "Useful telemetry connects technical events to identity, purpose, policy, risk, evidence, and accountable decisions." ], "anatomy": [ { "label": "Traces", "description": "Correlated model, tool, policy, verifier, and workflow spans." }, { "label": "Metrics", "description": "Aggregated reliability, quality, cost, latency, and intervention signals." }, { "label": "Events", "description": "Immutable state changes, approvals, blocks, incidents, and lifecycle actions." }, { "label": "Evidence links", "description": "References to exact artifacts and dispositions." } ], "mechanism": [], "distinctions": [ { "label": "Control plane", "description": "Observability provides information; a control plane evaluates and enforces governed constraints." }, { "label": "Evidence package", "description": "Telemetry is raw or structured runtime data; an evidence package binds relevant proof to a decision." } ], "practices": [ "Correlate events to agent, owner, model, tool, policy, and release", "Minimize sensitive payload capture", "Test that alerts connect to a real intervention path" ], "failureModes": [ "Faux “live” telemetry with no attributable source", "Detailed logs leak prompts, credentials, or sensitive data", "A dashboard creates confidence without tested controls" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "opentelemetry-genai", "nist-deployed-monitoring", "openai-monitoring" ], "videoSourceIds": [], "relatedEntryIds": [ "observability-control", "evidence-engineering", "agent-incident-response" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Observability | Agentic Engineering Knowledge Atlas", "seoDescription": "The ability to understand an agent system’s internal behavior and outcomes from attributable traces, metrics, events, state, and evidence." }, { "id": "model-context-protocol", "index": "", "title": "Model Context Protocol", "shortTitle": "Model Context Protocol", "aliases": [ "MCP" ], "declaredRoute": "/agentic-engineering/model-context-protocol", "entryType": "technical-term", "domain": "Multi-agent & protocols", "maturity": "maturing", "maturityNote": "The protocol has broad adoption and continues to evolve, including enterprise authorization profiles and versioned extensions.", "question": "", "oneLine": "An open protocol for connecting AI applications to servers that expose context, tools, prompts, and related capabilities.", "definition": "Model Context Protocol standardizes how a host application creates clients, negotiates capabilities, and exchanges messages with servers that expose resources and actions. MCP improves interoperability; it does not determine whether a capability is trustworthy, whether a caller has business standing, or whether a proposed effect should be allowed.", "whyItMatters": [ "MCP separates an AI application from many capability implementations through shared contracts.", "Security still requires server trust, identity, authorization, input validation, output handling, network boundaries, and evidence." ], "anatomy": [ { "label": "Host", "description": "The application that coordinates user intent, permissions, and one or more clients." }, { "label": "Client", "description": "A protocol connection maintained by the host for a server." }, { "label": "Server", "description": "A process or service exposing declared resources, tools, prompts, or capabilities." }, { "label": "Transport & messages", "description": "The negotiated communication and request-response layer." } ], "mechanism": [], "distinctions": [ { "label": "Tool calling", "description": "Tool calling is a model interaction pattern; MCP is one protocol for capability discovery and exchange." }, { "label": "Control plane", "description": "MCP transports capability requests; it does not grant authority or replace policy enforcement." } ], "practices": [ "Pin and govern protocol versions", "Authenticate every principal and authorize every effect", "Treat server descriptions and results as untrusted input", "Register server ownership, purpose, data access, and incident path" ], "failureModes": [ "Protocol compatibility is mistaken for trust", "A server expands capability after approval without recertification", "Tool output injects new instructions into the agent" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "mcp-architecture", "mcp-enterprise-auth", "mcp-2026-release-candidate", "owasp-agentic-top10" ], "videoSourceIds": [], "relatedEntryIds": [ "tools-and-protocols", "tool-calling", "runtime-policy-enforcement", "instruction-data-trust-boundary" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Model Context Protocol | Agentic Engineering Knowledge Atlas", "seoDescription": "An open protocol for connecting AI applications to servers that expose context, tools, prompts, and related capabilities." }, { "id": "multi-agent-system", "index": "", "title": "Multi-agent system", "shortTitle": "Multi-agent system", "aliases": [ "multi-agent framework", "agent team" ], "declaredRoute": "/agentic-engineering/multi-agent-system", "entryType": "technical-term", "domain": "Multi-agent & protocols", "maturity": "emerging", "maturityNote": "Orchestration frameworks are proliferating; dependable coordination, assurance, and governance patterns remain immature.", "question": "", "oneLine": "A system in which multiple agents exchange work, state, or decisions under an explicit coordination and authority model.", "definition": "A multi-agent system assigns different roles or tasks to multiple model-driven agents and coordinates their communication, shared state, tools, and dispositions. More agents can create specialization or independent challenge, but they also add correlated error, identity, concurrency, security, and accountability risks.", "whyItMatters": [ "Multiplicity is an architecture choice, not an automatic capability or quality gain.", "Independence requires separation of model lineage or deterministic method, context, ownership, and decision authority—not merely different agent names." ], "anatomy": [ { "label": "Roles", "description": "Bounded responsibilities and permitted actions for each agent." }, { "label": "Coordination", "description": "Routing, delegation, handoffs, conflict resolution, and termination." }, { "label": "Shared state", "description": "Concurrency-safe facts, artifacts, and task status." }, { "label": "Authority model", "description": "Which agents can propose, execute, block, or only advise." } ], "mechanism": [], "distinctions": [ { "label": "Parallel model calls", "description": "Independent calls are not a multi-agent system unless state or decisions are coordinated." }, { "label": "Independent verification", "description": "A second agent is independent only when its method, lineage or tooling, ownership, scope, and block authority are separated." } ], "practices": [ "Use the fewest roles that create measurable value", "Give every agent a distinct identity and least privilege", "Define ownership of shared state and disagreement", "Keep human release authority separate and named" ], "failureModes": [ "Agents endlessly delegate to one another", "Several agents reproduce the same model blind spot", "Shared memory becomes a race condition or prompt-injection channel" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "deeplearning-agentic-ai-course", "a2a-v1", "anthropic-harness-design", "nist-agent-identity" ], "videoSourceIds": [], "relatedEntryIds": [ "orchestrator-supervisor", "agent-handoff", "multi-agent-verification", "agent-identity" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Multi-agent system | Agentic Engineering Knowledge Atlas", "seoDescription": "A system in which multiple agents exchange work, state, or decisions under an explicit coordination and authority model." }, { "id": "orchestrator-supervisor", "index": "", "title": "Orchestrator or supervisor agent", "shortTitle": "Orchestrator or supervisor agent", "aliases": [ "supervisor agent", "manager agent", "orchestrator agent" ], "declaredRoute": "/agentic-engineering/orchestrator-supervisor", "entryType": "technical-term", "domain": "Multi-agent & protocols", "maturity": "emerging", "maturityNote": "Supervisor patterns are common in frameworks, but reliability and governance vary widely.", "question": "", "oneLine": "A coordinating component that decomposes work, routes tasks, monitors progress, and resolves or escalates outcomes across agents or tools.", "definition": "An orchestrator can be deterministic software, a model-driven supervisor, or a hybrid. It assigns bounded work, carries shared state, applies budgets, gathers results, and decides whether to continue, retry, combine, block, or escalate. Coordination does not make the orchestrator an independent verifier or governance authority.", "whyItMatters": [ "A deterministic orchestrator is preferable when routing rules are known.", "A model-driven supervisor helps when decomposition is uncertain but must operate inside explicit authority and termination bounds." ], "anatomy": [ { "label": "Decomposition", "description": "Turning a goal into bounded tasks." }, { "label": "Routing", "description": "Selecting the appropriate agent, tool, or human." }, { "label": "State", "description": "Tracking progress, dependencies, budgets, and evidence." }, { "label": "Resolution", "description": "Combining results and handling disagreement or blockage." } ], "mechanism": [], "distinctions": [ { "label": "Governance", "description": "An orchestrator coordinates execution; governance establishes rules, standing, and accountable decision rights." }, { "label": "Verifier", "description": "A supervisor that commissioned work is not automatically independent from the work it evaluates." } ], "practices": [ "Keep orchestration policy explicit and inspectable", "Prevent recursive delegation beyond budgets", "Route unresolved disagreement to a named human" ], "failureModes": [ "Supervisor becomes a single unbounded authority", "Task results are merged without evidence or conflict checks" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-building-effective-agents", "openai-symphony", "deeplearning-agentic-ai-course" ], "videoSourceIds": [], "relatedEntryIds": [ "multi-agent-system", "agent-handoff", "agent-loop", "human-accountability" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Orchestrator or supervisor agent | Agentic Engineering Knowledge Atlas", "seoDescription": "A coordinating component that decomposes work, routes tasks, monitors progress, and resolves or escalates outcomes across agents or tools." }, { "id": "agent-handoff", "index": "", "title": "Agent handoff", "shortTitle": "Agent handoff", "aliases": [ "agent delegation", "agent transfer" ], "declaredRoute": "/agentic-engineering/agent-handoff", "entryType": "technical-term", "domain": "Multi-agent & protocols", "maturity": "emerging", "maturityNote": "Handoffs are supported by many frameworks; interoperable semantics and enterprise controls are still developing.", "question": "", "oneLine": "A bounded transfer of task responsibility, state, evidence, and permitted actions from one agent or human role to another.", "definition": "An agent handoff moves work between actors while preserving the goal, current state, source evidence, unresolved risks, authorization limits, expected output, and return or escalation path. A handoff transfers work—not accountability or standing beyond what governance has separately conferred.", "whyItMatters": [ "Durable handoffs prevent the next actor from reconstructing critical state from prose alone.", "The receiving agent must be independently authorized for the requested tools, data, and effects." ], "anatomy": [ { "label": "Task contract", "description": "Goal, scope, acceptance criteria, and deadline." }, { "label": "State packet", "description": "Completed work, open issues, decisions, and evidence." }, { "label": "Authority check", "description": "Validation that the recipient may accept and perform the work." }, { "label": "Return path", "description": "Completion, rejection, correction, or escalation behavior." } ], "mechanism": [], "distinctions": [ { "label": "Prompt forwarding", "description": "A handoff carries structured state, evidence, and authority boundaries—not just another message." }, { "label": "Ownership transfer", "description": "Business or lifecycle ownership requires explicit human authorization and recertification." } ], "practices": [ "Use typed handoff contracts", "Re-evaluate access for the receiving identity", "Record who transferred what and why" ], "failureModes": [ "Context loss changes the task meaning", "Delegation silently expands tool or data access" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "a2a-v1", "openai-symphony", "anthropic-long-running-harness" ], "videoSourceIds": [], "relatedEntryIds": [ "multi-agent-system", "orchestrator-supervisor", "durable-execution", "agent-identity" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agent handoff | Agentic Engineering Knowledge Atlas", "seoDescription": "A bounded transfer of task responsibility, state, evidence, and permitted actions from one agent or human role to another." }, { "id": "durable-execution", "index": "", "title": "Durable execution", "shortTitle": "Durable execution", "aliases": [ "durable agent run", "resumable execution" ], "declaredRoute": "/agentic-engineering/durable-execution", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "maturing", "maturityNote": "Workflow durability is established; model-driven, stateful agent runtimes are still evolving.", "question": "", "oneLine": "Execution that persists state and can resume safely across process, model, context, worker, or environment interruptions.", "definition": "Durable execution externalizes an agent’s state transitions, checkpoints, side-effect status, budgets, and evidence so work can resume without replaying unsafe actions or depending on one model context. It applies distributed-systems principles such as idempotency, leases, retries, and compensation to agent runs.", "whyItMatters": [ "Long-running agency is state-machine engineering as much as model prompting.", "Resumption must distinguish work that was proposed, started, committed, verified, or compensated." ], "anatomy": [ { "label": "Checkpoint", "description": "A durable snapshot of task and control state." }, { "label": "Idempotency", "description": "Protection against duplicate effects during retry or recovery." }, { "label": "Lease", "description": "Time-bounded ownership of work by one executor." }, { "label": "Compensation", "description": "A defined way to reverse or remediate partial effects." } ], "mechanism": [], "distinctions": [ { "label": "Long context window", "description": "More tokens do not provide transactional durability, concurrency control, or safe replay." }, { "label": "Conversation persistence", "description": "Saving messages does not capture exact side-effect and verifier state." } ], "practices": [ "Persist state outside model context", "Make external effects idempotent or compensatable", "Checkpoint verifier and approval dispositions" ], "failureModes": [ "Recovery repeats a payment, deployment, or message", "Stale workers continue after lease expiry" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-managed-agents", "anthropic-long-running-harness", "openai-symphony" ], "videoSourceIds": [], "relatedEntryIds": [ "working-state", "agent-loop", "harness-engineering", "execution-substrate" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Durable execution | Agentic Engineering Knowledge Atlas", "seoDescription": "Execution that persists state and can resume safely across process, model, context, worker, or environment interruptions." }, { "id": "model-routing", "index": "", "title": "Model routing", "shortTitle": "Model routing", "aliases": [ "LLM routing", "model gateway routing" ], "declaredRoute": "/agentic-engineering/model-routing", "entryType": "technical-term", "domain": "Models & inference", "maturity": "maturing", "maturityNote": "Gateway and routing patterns are established, while dynamic quality and safety routing remain workload-specific.", "question": "", "oneLine": "The policy-based selection of a model and configuration for a request, task stage, risk level, or fallback condition.", "definition": "Model routing chooses among models based on evaluated capability, latency, cost, data handling, region, availability, risk, and task requirements. The route is part of the deployed system and evidence chain; a public benchmark can inform it but cannot determine enterprise fitness by itself.", "whyItMatters": [ "Different stages may justify different models or deterministic tools.", "Routing must preserve version identity, policy constraints, evaluation coverage, and fallback semantics." ], "anatomy": [ { "label": "Eligibility", "description": "Models permitted for the data class, region, and risk tier." }, { "label": "Quality evidence", "description": "Use-case evaluations and calibrated confidence." }, { "label": "Operational factors", "description": "Latency, cost, capacity, and availability." }, { "label": "Fallback", "description": "Explicit behavior when the preferred route is unavailable." } ], "mechanism": [], "distinctions": [ { "label": "Leaderboard selection", "description": "A composite score is one external signal; routing requires local workload, control, and operational evidence." }, { "label": "Mixture of experts", "description": "Routing among deployed models is a system policy; MoE routing happens inside one neural model." } ], "practices": [ "Evaluate every eligible route on the same acceptance set", "Record the exact model and reason for each consequential decision", "Fail closed when fallback violates policy or evidence requirements" ], "failureModes": [ "Silent fallback to an unevaluated model", "Cost optimization routes high-risk work below required capability" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "artificial-analysis-methodology", "nist-benchmark-evals", "anthropic-evals" ], "videoSourceIds": [], "relatedEntryIds": [ "large-language-model", "mixture-of-experts", "eval-driven-development", "risk-tiered-autonomy" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Model routing | Agentic Engineering Knowledge Atlas", "seoDescription": "The policy-based selection of a model and configuration for a request, task stage, risk level, or fallback condition." }, { "id": "mixture-of-experts", "index": "", "title": "Mixture of experts", "shortTitle": "Mixture of experts", "aliases": [ "MoE", "sparsely gated mixture of experts" ], "declaredRoute": "/agentic-engineering/mixture-of-experts", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Sparse mixture architectures are established in research and production models; implementation details and tradeoffs vary.", "question": "", "oneLine": "A neural architecture that routes each input token or example through a selected subset of learned expert subnetworks.", "definition": "A mixture-of-experts model contains multiple learned subnetworks and a router that activates only some of them for a given input, enabling large parameter capacity with sparse computation. The “experts” are mathematical components inside a model—not agents, people, independently verified specialists, or separately governed services.", "whyItMatters": [ "The router and experts are trained together as model components.", "MoE architecture does not imply multiple perspectives, independent judgment, or a multi-agent workflow." ], "anatomy": [ { "label": "Experts", "description": "Learned neural subnetworks with no independent agency." }, { "label": "Router", "description": "A learned gate selecting which experts process an input." }, { "label": "Sparsity", "description": "Only a subset of total parameters is active for each input." } ], "mechanism": [], "distinctions": [ { "label": "Multi-agent system", "description": "Agents have software roles, state, tools, identities, and coordination; MoE experts are internal neural layers." }, { "label": "Model routing", "description": "External routing selects among deployed models; an MoE router selects internal subnetworks." } ], "practices": [ "Treat architecture labels as model metadata, not governance claims", "Evaluate the complete endpoint on the intended workload" ], "failureModes": [ "Marketing describes internal experts as collaborating agents", "Parameter count is used as a proxy for application quality" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "moe-paper", "artificial-analysis-methodology" ], "videoSourceIds": [], "relatedEntryIds": [ "large-language-model", "model-routing", "multi-agent-system" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Mixture of experts | Agentic Engineering Knowledge Atlas", "seoDescription": "A neural architecture that routes each input token or example through a selected subset of learned expert subnetworks." }, { "id": "software-factory", "index": "", "title": "Agentic software factory", "shortTitle": "Agentic software factory", "aliases": [ "AI software factory", "software factory" ], "declaredRoute": "/agentic-engineering/software-factory", "entryType": "technical-term", "domain": "Operating model", "maturity": "practitioner", "maturityNote": "The term is used across vendor and practitioner communities without one settled architecture or performance standard.", "question": "", "oneLine": "An operating model that assembles reusable agents, workflows, environments, specifications, checks, and delivery controls into a repeatable software-production system.", "definition": "An agentic software factory treats software delivery as an engineered production system: work enters as durable intent, runs through isolated agent and human roles, is challenged by repeatable checks, integrates through controlled queues, and exits with attributable evidence. The term is aspirational unless the organization can demonstrate repeatability, quality, control, and delivered outcomes.", "whyItMatters": [ "The value is not a swarm aesthetic; it is repeatable flow with bounded variation and measurable outcomes.", "Factory thinking can expose capacity constraints in review, verification, integration, and product decision-making." ], "anatomy": [ { "label": "Durable intent", "description": "Specifications and decisions agents can execute and humans can audit." }, { "label": "Reusable production assets", "description": "Agents, tools, harnesses, environments, policies, and evaluations." }, { "label": "Flow control", "description": "WIP limits, isolated work, merge queues, and release gates." }, { "label": "Evidence", "description": "Traceability from request to verified production outcome." } ], "mechanism": [], "distinctions": [ { "label": "Autonomous code generation", "description": "A factory includes integration, verification, governance, operations, and human decisions—not generation alone." }, { "label": "Team metaphor", "description": "Calling agents a team does not create a controlled production system." } ], "practices": [ "Measure throughput and stability together", "Standardize evidence and interfaces before multiplying agents", "Scale verifier and integration capacity with generation capacity" ], "failureModes": [ "PR output grows while review queues and defects grow faster", "A demo workflow is presented as an operating capability", "Ownership becomes unclear because agents appear autonomous" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "video-indydevdan-software-factory", "openai-harness-engineering", "openai-symphony", "google-dora-ai-development" ], "videoSourceIds": [ "video-indydevdan-software-factory" ], "relatedEntryIds": [ "agentic-engineering", "harness-engineering", "organizational-absorption-capacity", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agentic software factory | Agentic Engineering Knowledge Atlas", "seoDescription": "An operating model that assembles reusable agents, workflows, environments, specifications, checks, and delivery controls into a repeatable software-production system." }, { "id": "loop-engineering", "index": "", "title": "Loop engineering", "shortTitle": "Loop engineering", "aliases": [ "agent loop engineering" ], "declaredRoute": "/agentic-engineering/loop-engineering", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "practitioner", "maturityNote": "The underlying runtime practices are established; “loop engineering” remains an emerging practitioner label.", "question": "", "oneLine": "The practice of improving the complete perceive–decide–act–observe cycle around a model rather than optimizing prompts in isolation.", "definition": "Loop engineering designs context construction, tool contracts, state, environment feedback, validations, retries, memory updates, budgets, and terminal dispositions as one measurable runtime system. It is a useful practitioner label for a subset of harness engineering centered on the repeated decision cycle.", "whyItMatters": [ "A stronger model increases leverage on the loop it inhabits; it does not repair a weak environment, ambiguous state, or missing feedback by itself.", "Changes should be evaluated at the outcome and trajectory level." ], "anatomy": [ { "label": "Context cycle", "description": "Select the right evidence for each step." }, { "label": "Action cycle", "description": "Propose, validate, execute, and observe tools." }, { "label": "Learning cycle", "description": "Turn failures and corrections into evals or governed memory." }, { "label": "Termination cycle", "description": "Finish, correct, hold, escalate, or stop." } ], "mechanism": [], "distinctions": [ { "label": "Prompt engineering", "description": "Prompt engineering shapes one model interaction; loop engineering shapes repeated interactions and their environment." }, { "label": "Harness engineering", "description": "Loop engineering focuses on the runtime cycle; harness engineering also covers repository, workspace, delivery, and organizational feedback surfaces." } ], "practices": [ "Improve the bottleneck exposed by traces and evals", "Require state change or new evidence before retries", "Keep terminal decisions finite and inspectable" ], "failureModes": [ "The loop produces more tokens without better outcomes", "Self-critique is mistaken for independent acceptance" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "video-linear-production-agents", "video-openai-harness-engineering", "openai-harness-engineering", "anthropic-harness-design" ], "videoSourceIds": [ "video-linear-production-agents", "video-openai-harness-engineering" ], "relatedEntryIds": [ "agent-loop", "harness-engineering", "eval-driven-development", "reflection" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Loop engineering | Agentic Engineering Knowledge Atlas", "seoDescription": "The practice of improving the complete perceive–decide–act–observe cycle around a model rather than optimizing prompts in isolation." }, { "id": "vibe-coding", "index": "", "title": "Vibe coding", "shortTitle": "Vibe coding", "aliases": [ "vibe-coded development" ], "declaredRoute": "/agentic-engineering/vibe-coding", "entryType": "technical-term", "domain": "Operating model", "maturity": "practitioner", "maturityNote": "The phrase is culturally influential but informal, inconsistently defined, and not an engineering standard.", "question": "", "oneLine": "A practitioner label for software creation driven primarily by natural-language iteration and observed behavior, often with limited attention to the generated code.", "definition": "Vibe coding describes a highly exploratory mode in which a person asks a model to create or change software, runs it, and iterates from visible results. It can accelerate prototypes and learning, but consequential software still requires explicit intent, architecture, tests, provenance, security, ownership, and release evidence.", "whyItMatters": [ "The mode is valuable when reversibility is high and the objective is discovery.", "Agentic engineering begins where organizations make the surrounding intent, context, execution, verification, and accountability system explicit." ], "anatomy": [ { "label": "Natural-language steering", "description": "The person directs changes through conversation." }, { "label": "Rapid feedback", "description": "Visible execution drives the next request." }, { "label": "Low code inspection", "description": "The person may rely more on behavior than detailed implementation review." } ], "mechanism": [], "distinctions": [ { "label": "Agentic engineering", "description": "Agentic engineering treats the full delivery and control system as the engineering artifact." }, { "label": "Prototyping", "description": "Prototyping is a lifecycle intent; vibe coding is one informal interaction style." } ], "practices": [ "Keep use proportional to reversibility and impact", "Convert discoveries into explicit requirements and tests before production", "Do not hide generated-code provenance" ], "failureModes": [ "Prototype assumptions reach production unexamined", "The operator cannot explain, maintain, or verify the resulting system" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "karpathy-software-3", "github-spec-driven", "openai-harness-engineering" ], "videoSourceIds": [ "karpathy-software-3" ], "relatedEntryIds": [ "agentic-engineering", "software-factory", "intent-engineering", "evidence-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Vibe coding | Agentic Engineering Knowledge Atlas", "seoDescription": "A practitioner label for software creation driven primarily by natural-language iteration and observed behavior, often with limited attention to the generated code." }, { "id": "velocity-sickness", "index": "", "title": "Velocity sickness", "shortTitle": "Velocity sickness", "aliases": [ "AI velocity sickness" ], "declaredRoute": "/agentic-engineering/velocity-sickness", "entryType": "technical-term", "domain": "Operating model", "maturity": "practitioner", "maturityNote": "The underlying queue and coordination dynamics are established; this exact label is a new practitioner coinage and should remain attributed.", "question": "", "oneLine": "Matt Dailey’s practitioner term for the coordination strain that appears when local AI-assisted production accelerates faster than a team can decide, review, integrate, verify, and absorb it.", "definition": "Velocity sickness is an attributed thought-leadership framing—not a clinical or validated organizational diagnosis. It names a real systems question: what happens when generation throughput rises but product decisions, review, test environments, verifier ownership, merge capacity, release authority, and operational learning do not rise with it?", "whyItMatters": [ "AI can make implementation locally faster while making the delivery system globally slower.", "Rejecting speed is not the answer, and unlimited concurrency is not absorption. The response is to redesign the full value stream around evidence, constraints, and real bottlenecks." ], "anatomy": [ { "label": "Generation rate", "description": "How quickly code, PRs, analyses, and alternatives are produced." }, { "label": "Decision capacity", "description": "How quickly humans can resolve product, risk, and architecture choices." }, { "label": "Verification capacity", "description": "How much work independently owned checks can credibly challenge." }, { "label": "Integration capacity", "description": "How safely the system can merge, test, release, and learn from changes." } ], "mechanism": [], "distinctions": [ { "label": "Developer productivity", "description": "More generated artifacts or activity does not by itself mean more delivered value." }, { "label": "A universal 10x claim", "description": "Measured outcomes vary by task, developer, tool, system quality, and time period; “10x” is a provocative scenario, not an established constant." } ], "practices": [ "Track queue time, rework, stability, outcomes, and cognitive load alongside generation", "Limit work in process to integration and verifier capacity", "Use small batches and isolated workspaces", "Preserve named human product and release decisions" ], "failureModes": [ "PR count becomes the success metric", "Review is automated by a correlated model and called independent", "Teams suppress new tooling without fixing the actual constraint" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "ai-engineer-velocity-sickness", "google-dora-ai-development", "space-developer-productivity", "github-agent-pr-review", "metr-developer-productivity-rct" ], "videoSourceIds": [ "ai-engineer-velocity-sickness" ], "relatedEntryIds": [ "organizational-absorption-capacity", "software-factory", "human-accountability", "multi-agent-verification" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Velocity sickness | Agentic Engineering Knowledge Atlas", "seoDescription": "Matt Dailey’s practitioner term for the coordination strain that appears when local AI-assisted production accelerates faster than a team can decide, review, integrate, verify, and absorb it." }, { "id": "organizational-absorption-capacity", "index": "", "title": "Organizational absorption capacity", "shortTitle": "Organizational absorption capacity", "aliases": [ "AI delivery absorption capacity", "delivery absorption capacity" ], "declaredRoute": "/agentic-engineering/organizational-absorption-capacity", "entryType": "technical-term", "domain": "Operating model", "maturity": "emerging", "maturityNote": "Queue, flow, and socio-technical productivity principles are established; this AISDLC synthesis is an emerging application to agentic delivery.", "question": "", "oneLine": "AISDLC’s systems response to AI speed: the rate at which an organization can turn generated work into understood, verified, integrated, authorized, and operated value.", "definition": "Organizational absorption capacity is an AISDLC operating construct for balancing local generation speed with product decision-making, context transfer, independent verification, review, integration, deployment, and learning. When arrival rate exceeds this capacity, queues, rework, context fragmentation, instability, and accountability gaps grow even if individual implementation becomes faster.", "whyItMatters": [ "The objective is not to slow agents down. It is to increase safe system throughput by elevating the real constraint and reducing avoidable coordination load.", "Capacity is multidimensional: product choices, architecture, verification, human attention, environments, merge mechanics, release authority, and operations all matter." ], "anatomy": [ { "label": "Demand shaping", "description": "Clear priorities, durable intent, and bounded work entering the system." }, { "label": "Flow control", "description": "Small batches, visible queues, WIP limits, and merge discipline." }, { "label": "Verifier capacity", "description": "Independent algorithmic and agentic challenge scaled with production." }, { "label": "Human authority", "description": "Protected attention for consequential product, risk, and release decisions." }, { "label": "Learning capacity", "description": "Turning incidents, corrections, and outcomes into system improvement." } ], "mechanism": [], "distinctions": [ { "label": "Headcount", "description": "Capacity depends on system design and bottlenecks, not simply the number of developers or reviewers." }, { "label": "Generation velocity", "description": "Generation measures local artifact production; absorption measures verified, integrated, operated value." }, { "label": "Resistance to change", "description": "A queue can reveal legitimate safety or decision constraints as well as cultural resistance; diagnose before prescribing." } ], "practices": [ "Map arrival rate and queue time across the whole value stream", "Protect decision packets from transcript and context sprawl", "Scale independent verifier ownership before scaling release volume", "Measure stability, outcomes, satisfaction, and learning—not activity alone" ], "failureModes": [ "Faster generation saturates review and test systems", "Automation optimizes one stage while increasing downstream rework", "Teams celebrate merged output without verifying user or business outcomes" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "google-dora-ai-development", "dora-wip-limits", "dora-small-batches", "space-developer-productivity", "github-agent-pr-review", "metr-developer-productivity-rct" ], "videoSourceIds": [], "relatedEntryIds": [ "velocity-sickness", "software-factory", "eval-driven-development", "human-accountability" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Organizational absorption capacity | Agentic Engineering Knowledge Atlas", "seoDescription": "AISDLC’s systems response to AI speed: the rate at which an organization can turn generated work into understood, verified, integrated, authorized, and operated value." }, { "id": "shared-design-concept", "index": "", "title": "Shared design concept", "shortTitle": "Shared design concept", "aliases": [ "shared design model", "shared implementation concept" ], "declaredRoute": "/agentic-engineering/shared-design-concept", "entryType": "technical-term", "domain": "Foundations", "maturity": "practitioner", "maturityNote": "Shared mental models and domain language are established software practices; this explicit agent-facing framing remains practitioner-led and implementation-specific.", "question": "", "oneLine": "A durable, explicit understanding of the problem, domain language, boundaries, constraints, and acceptance conditions shared by humans and coding agents before implementation expands.", "definition": "A shared design concept is the common model that lets people and coding agents reason about the same system: why it exists, what outcome matters, which domain terms mean what, where responsibilities belong, which constraints bind, and how success will be tested. It is an alignment artifact that can evolve with evidence—not a promise that ambiguity disappears or a license for unattended execution.", "whyItMatters": [ "Coding agents amplify whatever conceptual structure they receive. A shared concept gives subsequent specifications, tasks, interfaces, and tests a coherent vocabulary.", "The concept should be inspectable and revisable. Interviews, examples, diagrams, and existing system evidence can expose disagreements before they become parallel implementations." ], "anatomy": [ { "label": "Purpose", "description": "The user or business outcome and the reason it matters." }, { "label": "Domain language", "description": "Stable terms for entities, rules, states, and exceptions." }, { "label": "Boundaries", "description": "Responsibilities, interfaces, exclusions, and ownership." }, { "label": "Acceptance", "description": "Observable conditions that would show the concept works." } ], "mechanism": [], "distinctions": [ { "label": "A single prompt", "description": "A prompt is one instruction event; a shared concept is durable, reviewable project knowledge used across many decisions." }, { "label": "Detailed implementation", "description": "The concept aligns meaning and boundaries without prescribing every code-level choice." } ], "practices": [ "Interview accountable stakeholders before decomposing ambiguous work", "Record contested terms, decisions, and open questions", "Test the concept with examples and a thin implementation slice" ], "failureModes": [ "Humans and agents use the same word for different ideas", "A polished specification hides unresolved product or domain decisions" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "pocock-video-software-fundamentals", "pocock-skills-repo", "github-spec-kit-docs", "anthropic-agentic-coding-expertise" ], "videoSourceIds": [ "pocock-video-software-fundamentals" ], "relatedEntryIds": [ "intent-engineering", "spec-to-code", "context-engineering", "tracer-bullet-development" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Shared design concept | Agentic Engineering Knowledge Atlas", "seoDescription": "A durable, explicit understanding of the problem, domain language, boundaries, constraints, and acceptance conditions shared by humans and coding agents before implementation expands." }, { "id": "spec-to-code", "index": "", "title": "Spec-to-code", "shortTitle": "Spec-to-code", "aliases": [ "spec-driven development", "specification-to-code" ], "declaredRoute": "/agentic-engineering/spec-to-code", "entryType": "technical-term", "domain": "Operating model", "maturity": "maturing", "maturityNote": "Specification-driven tools are rapidly maturing, while artifact schemas, change control, and evidence of outcome improvement remain uneven across implementations.", "question": "", "oneLine": "A controlled transformation from durable intent and acceptance criteria through a technical plan and bounded tasks into implemented, tested, and reviewable software.", "definition": "Spec-to-code is a family of engineering workflows that treats a specification as persistent input to planning, decomposition, implementation, and review. The useful pattern is not one-shot code generation: each artifact makes decisions visible, carries constraints forward, and can be checked against both upstream intent and downstream behavior. Teams may begin from a new specification or reconcile a specification with an existing codebase.", "whyItMatters": [ "A durable chain—concept, specification, plan, tasks, implementation, tests, and review—reduces the need to reconstruct intent from chat history.", "Specifications are hypotheses about the desired system. They require accountable decisions, versioning, feasibility feedback, and revision when implementation or user evidence changes." ], "anatomy": [ { "label": "Specification", "description": "Desired behavior, boundaries, constraints, and acceptance criteria." }, { "label": "Plan", "description": "Architecture and sequencing choices that make implementation feasible." }, { "label": "Tasks", "description": "Bounded units with dependencies, evidence, and completion conditions." }, { "label": "Conformance review", "description": "A check that implementation and tests satisfy current intent." } ], "mechanism": [], "distinctions": [ { "label": "One-shot generation", "description": "Spec-to-code maintains traceable intermediate decisions instead of asking a model to leap from request to final code." }, { "label": "Documentation after coding", "description": "The specification actively shapes and is reconciled with delivery rather than merely describing the result afterward." } ], "practices": [ "Version specifications with the code they govern", "Carry acceptance criteria into executable tests where appropriate", "Review both implementation drift and specification error" ], "failureModes": [ "A large specification becomes unreviewable context", "Tasks preserve syntax but lose the user outcome", "Generated code passes tests that do not represent the specification" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "github-spec-kit-docs", "github-spec-driven", "github-spec-persistence", "pocock-video-skills-workflow" ], "videoSourceIds": [ "pocock-video-skills-workflow" ], "relatedEntryIds": [ "shared-design-concept", "intent-engineering", "tracer-bullet-development", "eval-driven-development" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Spec-to-code | Agentic Engineering Knowledge Atlas", "seoDescription": "A controlled transformation from durable intent and acceptance criteria through a technical plan and bounded tasks into implemented, tested, and reviewable software." }, { "id": "tracer-bullet-development", "index": "", "title": "Tracer-bullet development", "shortTitle": "Tracer-bullet development", "aliases": [ "tracer bullet", "architectural tracer bullet", "walking skeleton" ], "declaredRoute": "/agentic-engineering/tracer-bullet-development", "entryType": "technical-term", "domain": "Operating model", "maturity": "foundational", "maturityNote": "Thin vertical slices are an established software technique; their explicit use to control coding-agent planning and context is a newer application.", "question": "", "oneLine": "A deliberately thin, end-to-end implementation slice used to expose architecture, integration, feedback, and deployment assumptions before scaling the full build.", "definition": "Tracer-bullet development connects a narrow but real path through the relevant system layers so a team can observe whether its architecture, interfaces, data flow, tooling, and delivery path work together. The slice is meant to produce learning and may remain as production structure; it is not a throwaway visual mockup, a broad minimum viable product, or proof that the remaining workload is low risk.", "whyItMatters": [ "The software-development technique is canonical in David Thomas and Andrew Hunt’s The Pragmatic Programmer; applying it to coding-agent planning is a later practitioner adaptation. Agents can elaborate an incorrect architecture very quickly, so a thin slice creates concrete feedback before the organization commits to parallel implementation.", "The slice should cross the riskiest boundary that can be tested economically, such as a real integration, data contract, deployment path, or permission check." ], "anatomy": [ { "label": "Thin scope", "description": "The smallest meaningful behavior that exercises the hypothesis." }, { "label": "End-to-end path", "description": "A real connection across the layers or integrations at risk." }, { "label": "Observable feedback", "description": "Tests, behavior, or operational evidence that confirms or challenges assumptions." }, { "label": "Decision point", "description": "A named choice to continue, revise, or abandon the architecture." } ], "mechanism": [], "distinctions": [ { "label": "Prototype", "description": "A prototype may explore one surface and be discarded; a tracer bullet exercises a real end-to-end route to learn about system fit." }, { "label": "Minimum viable product", "description": "An MVP tests product value; a tracer bullet primarily tests technical and delivery assumptions." } ], "practices": [ "Choose the uncertainty with the highest downstream cost", "Keep the slice real enough to reveal integration behavior", "Record what the slice did and did not validate" ], "failureModes": [ "A fake backend conceals the highest-risk boundary", "The slice expands into the full feature before the architecture decision", "A successful path is generalized to untested failure and security cases" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "pragmatic-programmer-tracer-bullets", "pocock-ai-hero-course", "pocock-skills-repo", "pocock-video-software-fundamentals" ], "videoSourceIds": [ "pocock-video-software-fundamentals" ], "relatedEntryIds": [ "shared-design-concept", "spec-to-code", "sandbox", "durable-execution" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Tracer-bullet development | Agentic Engineering Knowledge Atlas", "seoDescription": "A deliberately thin, end-to-end implementation slice used to expose architecture, integration, feedback, and deployment assumptions before scaling the full build." }, { "id": "deep-module", "index": "", "title": "Deep module", "shortTitle": "Deep module", "aliases": [ "deep modules", "deep abstraction" ], "declaredRoute": "/agentic-engineering/deep-module", "entryType": "technical-term", "domain": "Foundations", "maturity": "foundational", "maturityNote": "Module depth is established software-design guidance; applying it specifically to agent-readable repositories is a current practitioner synthesis.", "question": "", "oneLine": "A software module whose relatively simple, stable interface hides substantial implementation complexity and keeps that complexity from spreading through the codebase.", "definition": "A deep module provides significant capability behind a small conceptual surface. Its depth is relative: the benefit delivered and complexity hidden are large compared with the interface a caller must understand. Deep modules can make a codebase easier for humans and agents to navigate, but excessive generalization, hidden side effects, or poorly chosen boundaries can make an apparently simple interface misleading.", "whyItMatters": [ "Every public concept consumes attention and model context. A well-chosen boundary lets callers reason locally without loading internal machinery.", "Depth comes from information hiding and coherent responsibility, not from placing a large amount of unrelated code behind a short function name." ], "anatomy": [ { "label": "Small interface", "description": "Few concepts and operations for callers to learn." }, { "label": "Hidden complexity", "description": "Implementation decisions remain inside the responsible boundary." }, { "label": "Coherent responsibility", "description": "The module owns a meaningful capability rather than unrelated convenience methods." }, { "label": "Stable contract", "description": "Internal changes do not routinely force caller changes." } ], "mechanism": [], "distinctions": [ { "label": "Large module", "description": "Size alone is not depth; a large module with a large interface can still expose most of its complexity." }, { "label": "Opaque code", "description": "Information hiding preserves a clear contract and evidence, rather than concealing behavior that callers must understand." } ], "practices": [ "Compare interface complexity with the capability it exposes", "Name modules in the domain language", "Test behavior at stable boundaries while retaining focused internal tests" ], "failureModes": [ "A shallow wrapper adds another concept without hiding complexity", "A general-purpose module becomes a dumping ground", "Hidden side effects violate the apparent contract" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "ousterhout-software-design", "pocock-video-software-fundamentals", "pocock-ai-hero-course" ], "videoSourceIds": [ "pocock-video-software-fundamentals" ], "relatedEntryIds": [ "agent-readable-codebase", "shared-design-concept", "context-hygiene", "harness-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Deep module | Agentic Engineering Knowledge Atlas", "seoDescription": "A software module whose relatively simple, stable interface hides substantial implementation complexity and keeps that complexity from spreading through the codebase." }, { "id": "agent-readable-codebase", "index": "", "title": "Agent-readable codebase", "shortTitle": "Agent-readable codebase", "aliases": [ "AI-friendly codebase", "agent-friendly codebase" ], "declaredRoute": "/agentic-engineering/agent-readable-codebase", "entryType": "technical-term", "domain": "Harness & runtime", "maturity": "emerging", "maturityNote": "Many component practices are established, but repository design explicitly optimized for coding-agent navigation and recovery remains an emerging discipline.", "question": "", "oneLine": "A repository engineered so coding agents can discover its purpose, boundaries, commands, constraints, and feedback paths without reconstructing the system from an entire history.", "definition": "An agent-readable codebase makes the information needed for safe contribution easy to find and hard to misinterpret: domain structure, stable module boundaries, scoped instructions, deterministic setup and test commands, representative examples, current specifications, and clear failure output. Readability is a system property shared with human maintainability; adding one large instruction file does not create it.", "whyItMatters": [ "Coding agents operate through finite context and feedback. Repository structure determines how much irrelevant material must be loaded before a correct local change is possible.", "The codebase should teach through its shape and executable checks. Instructions can route an agent, while interfaces and tests reveal whether it understood correctly." ], "anatomy": [ { "label": "Discoverability", "description": "A clear map from task to responsible module, source of truth, and command." }, { "label": "Scoped guidance", "description": "Instructions close to the code and decisions they govern." }, { "label": "Deterministic feedback", "description": "Fast tests, types, linters, and reproducible environments." }, { "label": "Recoverable state", "description": "Durable specifications, tasks, and checkpoints for context refresh or handoff." } ], "mechanism": [], "distinctions": [ { "label": "Machine-readable syntax", "description": "Parsable code is not enough; the agent also needs conceptual boundaries, operating instructions, and useful feedback." }, { "label": "A giant AGENTS.md file", "description": "Central guidance should route progressively to local knowledge rather than duplicate the whole repository into context." } ], "practices": [ "Provide one reliable setup and verification path", "Use deep modules and domain names to reduce context required per change", "Keep instructions scoped, versioned, and testable", "Remove stale generated maps and duplicate guidance" ], "failureModes": [ "The agent searches the full repository for every decision", "Multiple instruction files conflict without an explicit scope rule", "Slow or flaky feedback causes speculative fixes" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-harness-engineering", "anthropic-context", "pocock-video-software-fundamentals", "pocock-ai-hero-course" ], "videoSourceIds": [ "pocock-video-software-fundamentals" ], "relatedEntryIds": [ "harness-engineering", "deep-module", "context-hygiene", "spec-to-code" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Agent-readable codebase | Agentic Engineering Knowledge Atlas", "seoDescription": "A repository engineered so coding agents can discover its purpose, boundaries, commands, constraints, and feedback paths without reconstructing the system from an entire history." }, { "id": "context-hygiene", "index": "", "title": "Context hygiene", "shortTitle": "Context hygiene", "aliases": [ "context discipline", "context maintenance" ], "declaredRoute": "/agentic-engineering/context-hygiene", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "maturing", "maturityNote": "Context selection and compaction are established constraints, while reusable measures and operating standards for hygiene are still developing.", "question": "", "oneLine": "The active practice of selecting, labeling, refreshing, compacting, and removing model-visible information so the working context stays relevant, attributable, and within budget.", "definition": "Context hygiene manages the quality of an agent’s finite working set over time. It chooses the smallest sufficient instructions, state, evidence, retrieved material, and tool output; tracks provenance and freshness; summarizes with a path back to primary sources; and starts a clean context when accumulated history creates more noise than value. It does not mean deleting evidence or assuming a larger context window removes the need for selection.", "whyItMatters": [ "Every token competes for model attention and can carry stale assumptions, untrusted instructions, or irrelevant detail into the next decision.", "Durable state and evidence should live outside transient context. A refreshed agent can load the current task packet without losing the authoritative history." ], "anatomy": [ { "label": "Selection", "description": "Load only information relevant to the present decision." }, { "label": "Provenance", "description": "Retain source, trust, and recency labels for context items." }, { "label": "Compaction", "description": "Summarize history while preserving links to primary evidence and unresolved decisions." }, { "label": "Refresh", "description": "Restart with clean context and explicit state when accumulation degrades performance." } ], "mechanism": [], "distinctions": [ { "label": "Large context window", "description": "Capacity says how much can fit; hygiene determines what deserves to be present and trusted." }, { "label": "Deleting history", "description": "Transient context can be refreshed while durable evidence and decision records remain available." } ], "practices": [ "Separate authoritative state from conversational history", "Load detail progressively from a compact task packet", "Mark summaries as summaries and retain primary-source pointers", "Test performance under realistic context noise" ], "failureModes": [ "Old instructions silently override the current task", "Compaction converts an uncertain claim into an apparent fact", "Tool output floods the context with low-value detail" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "anthropic-long-running-harness", "pocock-ai-hero-course", "pocock-video-skills-workflow" ], "videoSourceIds": [ "pocock-video-skills-workflow" ], "relatedEntryIds": [ "context-engineering", "context-window", "working-state", "agent-readable-codebase" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Context hygiene | Agentic Engineering Knowledge Atlas", "seoDescription": "The active practice of selecting, labeling, refreshing, compacting, and removing model-visible information so the working context stays relevant, attributable, and within budget." }, { "id": "private-ai", "index": "", "title": "Private AI", "shortTitle": "Private AI", "aliases": [ "private artificial intelligence", "privacy-preserving AI deployment" ], "declaredRoute": "/agentic-engineering/private-ai", "entryType": "technical-term", "domain": "Security & governance", "maturity": "contested", "maturityNote": "The underlying privacy and infrastructure controls are established, while “private AI” remains a broad market term with inconsistent boundaries and evidence.", "question": "", "oneLine": "An operating posture in which an organization defines and enforces where AI data, models, inference, tools, logs, identities, and administrative access may exist and flow.", "definition": "Private AI is a deployment and data-governance posture, not a model type. It combines an explicit threat model with controlled infrastructure, data boundaries, model and tool access, logging, retention, administrative controls, and evidence. Local or self-hosted inference can support that posture, but neither proves privacy when prompts, telemetry, dependencies, operators, or tool calls cross the intended boundary.", "whyItMatters": [ "A useful claim names the protected data, permitted processors, geographic and network boundaries, operators, retention, and exceptions.", "Privacy must cover the full execution path: retrieval, prompts, model runtime, caches, tools, traces, backups, support access, and model updates." ], "anatomy": [ { "label": "Threat model", "description": "The actors, data, actions, and failure paths the posture addresses." }, { "label": "Processing boundary", "description": "Where data and model execution are permitted to occur." }, { "label": "Access control", "description": "Who or what may administer, invoke, inspect, export, or update the system." }, { "label": "Evidence", "description": "Configuration and operating records supporting the stated privacy claim." } ], "mechanism": [], "distinctions": [ { "label": "Local inference", "description": "Locality describes where one runtime executes; privacy covers the complete data and control path." }, { "label": "Open-weight model", "description": "Downloadable weights can enable deployment choice but do not determine privacy, licensing, or security." }, { "label": "Air-gapped deployment", "description": "Network isolation is one possible control, not the definition of private AI." } ], "practices": [ "Write a data-flow and operator-access threat model", "Disable or constrain cloud features when the intended boundary requires it", "Verify logs, caches, backups, tool traffic, and support paths", "State precisely which privacy properties are implemented" ], "failureModes": [ "A local model sends tool requests or telemetry outside the boundary", "Prompts remain in ungoverned logs or backups", "The label “private” substitutes for testable controls" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "ollama-local-only", "llama-cpp-local-inference", "nist-zero-trust" ], "videoSourceIds": [], "relatedEntryIds": [ "local-inference", "self-hosted-inference", "open-weight-model", "instruction-data-trust-boundary" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Private AI | Agentic Engineering Knowledge Atlas", "seoDescription": "An operating posture in which an organization defines and enforces where AI data, models, inference, tools, logs, identities, and administrative access may exist and flow." }, { "id": "open-weight-model", "index": "", "title": "Open-weight model", "shortTitle": "Open-weight model", "aliases": [ "open weights", "downloadable model weights" ], "declaredRoute": "/agentic-engineering/open-weight-model", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Weight distribution is established; terminology, licenses, training transparency, and obligations vary substantially across model families.", "question": "", "oneLine": "A model whose trained parameter weights are available for download and use under stated license terms, enabling inspection, adaptation, or deployment outside a hosted API.", "definition": "An open-weight model makes trained parameters available under a specific license and usage policy. That can enable local inference, self-hosting, quantization, adaptation, and independent evaluation, but “open weight” does not by itself mean open source, unrestricted use, reproducible training, disclosed data, or safe deployment. The exact artifact, license, model card, and runtime dependencies determine what is actually possible.", "whyItMatters": [ "Weights are only one layer of the system. Tokenizers, inference code, adapters, safety components, data provenance, and acceptable-use terms can carry separate conditions.", "Availability changes who can operate and modify a model, which increases deployment choice and also transfers more evaluation, security, update, and incident responsibility to the operator." ], "anatomy": [ { "label": "Weight artifact", "description": "The trained parameters and supported numerical formats." }, { "label": "License and policy", "description": "Permissions, restrictions, attribution, and downstream obligations." }, { "label": "Model documentation", "description": "Architecture, evaluations, intended uses, and known limitations." }, { "label": "Runtime compatibility", "description": "Software and hardware required to execute the artifact." } ], "mechanism": [], "distinctions": [ { "label": "Open-source AI system", "description": "Open weights may omit training code, data, or reproducibility information and should not be labeled open source without meeting the relevant definition." }, { "label": "Free hosted model", "description": "Free access to an endpoint does not provide the model weights or deployment rights." } ], "practices": [ "Review the exact artifact license and usage policy", "Record model, tokenizer, quantization, adapter, and runtime versions", "Run workload-specific quality and safety evaluation before deployment" ], "failureModes": [ "A team assumes open weights permit every commercial or regulated use", "A repackaged checkpoint loses provenance and model-card context", "Downloadability is mistaken for privacy or safety" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "openai-gpt-oss", "openai-gpt-oss-model-card" ], "videoSourceIds": [], "relatedEntryIds": [ "local-inference", "self-hosted-inference", "model-adaptation", "quantization" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Open-weight model | Agentic Engineering Knowledge Atlas", "seoDescription": "A model whose trained parameter weights are available for download and use under stated license terms, enabling inspection, adaptation, or deployment outside a hosted API." }, { "id": "local-inference", "index": "", "title": "Local inference", "shortTitle": "Local inference", "aliases": [ "on-device inference", "local model inference" ], "declaredRoute": "/agentic-engineering/local-inference", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Local model runtimes are established and improving quickly; practical capability remains constrained by model size, quantization, hardware, workload, and surrounding services.", "question": "", "oneLine": "Model inference executed on the user’s or organization’s local hardware and runtime rather than delegated to a separately operated remote model endpoint.", "definition": "Local inference loads and executes a model on hardware controlled at the point of use, such as a workstation, server, edge appliance, or private development environment. It can reduce network dependency and keep model inputs inside that runtime boundary when configured accordingly, but local execution is not automatically offline, private, secure, performant, or legally authorized.", "whyItMatters": [ "The deployment unit includes more than weights: runtime, tokenizer, model configuration, caches, storage, APIs, tools, update path, and operating-system controls all affect behavior.", "Locality is a topology fact. Privacy and assurance claims require separate evidence about every data path and operator with access." ], "anatomy": [ { "label": "Local runtime", "description": "Software that loads weights and executes inference on controlled hardware." }, { "label": "Model artifact", "description": "Compatible weights, tokenizer, configuration, and optional adapters." }, { "label": "Hardware envelope", "description": "Memory, compute, accelerators, storage, power, and latency limits." }, { "label": "Network posture", "description": "Whether cloud features, model downloads, telemetry, and tools can communicate externally." } ], "mechanism": [], "distinctions": [ { "label": "Private AI", "description": "Local execution can support a private posture, but privacy depends on the entire data, tool, logging, and administration path." }, { "label": "Self-hosted inference", "description": "Local inference emphasizes execution near the user or controlled device; self-hosting can operate a remote internal service for many clients." } ], "practices": [ "Benchmark the exact model and quantization on target hardware", "Verify offline and telemetry settings rather than assuming them", "Protect model files, caches, prompts, logs, and local API ports" ], "failureModes": [ "The runtime silently uses a cloud feature", "A local API listens beyond the intended interface", "A model fits in memory but misses workload quality or latency requirements" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "ollama-local-only", "llama-cpp-local-inference", "openai-gpt-oss" ], "videoSourceIds": [], "relatedEntryIds": [ "private-ai", "open-weight-model", "quantization", "inference-serving" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Local inference | Agentic Engineering Knowledge Atlas", "seoDescription": "Model inference executed on the user’s or organization’s local hardware and runtime rather than delegated to a separately operated remote model endpoint." }, { "id": "self-hosted-inference", "index": "", "title": "Self-hosted inference", "shortTitle": "Self-hosted inference", "aliases": [ "self-managed inference", "private inference endpoint" ], "declaredRoute": "/agentic-engineering/self-hosted-inference", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Model-serving software is established, while efficient and secure operation of rapidly changing models remains a specialized infrastructure discipline.", "question": "", "oneLine": "An inference service whose runtime, capacity, configuration, model artifacts, and operational controls are managed by the organization using it or by a directly governed operator.", "definition": "Self-hosted inference places responsibility for deploying and operating the model-serving stack with the organization rather than consuming only a vendor-managed API. It may run on premises, in a private cloud, or in controlled hosted infrastructure. Self-hosting provides configuration and data-path options, but also transfers responsibility for scaling, patching, authentication, isolation, observability, evaluation, and incident response.", "whyItMatters": [ "A self-hosted endpoint can serve many applications and therefore may be remote from each caller even though the organization controls the service.", "The serving runtime is one layer. Gateways, identity, policy, quotas, secrets, data retention, model governance, and application-level verification remain separate responsibilities." ], "anatomy": [ { "label": "Serving runtime", "description": "Model loading, scheduling, batching, generation, and response handling." }, { "label": "Controlled infrastructure", "description": "Compute, network, storage, and administrative boundary operated under defined responsibility." }, { "label": "Service controls", "description": "Authentication, quotas, isolation, configuration, patching, and availability." }, { "label": "Model operations", "description": "Artifact approval, evaluation, rollout, rollback, and retirement." } ], "mechanism": [], "distinctions": [ { "label": "Local inference", "description": "A self-hosted service may run remotely inside organizational infrastructure and serve many clients." }, { "label": "Managed private endpoint", "description": "A vendor-operated dedicated endpoint can offer isolation without transferring full operational control to the customer." } ], "practices": [ "Define service ownership and patch responsibilities", "Authenticate clients and isolate tenants before exposing the endpoint", "Version and canary model, runtime, and configuration changes", "Capacity-test realistic concurrent workloads" ], "failureModes": [ "An unauthenticated compatible API is exposed on the network", "A model update changes behavior without acceptance evaluation", "Operators underestimate GPU capacity, queueing, or rollback needs" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "vllm-serving", "llama-cpp-local-inference", "ollama-local-only" ], "videoSourceIds": [], "relatedEntryIds": [ "inference-serving", "private-ai", "local-inference", "model-routing" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Self-hosted inference | Agentic Engineering Knowledge Atlas", "seoDescription": "An inference service whose runtime, capacity, configuration, model artifacts, and operational controls are managed by the organization using it or by a directly governed operator." }, { "id": "model-adaptation", "index": "", "title": "Model adaptation", "shortTitle": "Model adaptation", "aliases": [ "model customization", "adapting a model" ], "declaredRoute": "/agentic-engineering/model-adaptation", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Adaptation techniques are established, while method selection, data governance, regression testing, and lifecycle controls remain workload-specific.", "question": "", "oneLine": "The deliberate modification of a model or its task-facing behavior for a target domain, task, language, policy, or operating environment using measured evidence.", "definition": "Model adaptation is an umbrella term for changing how a pretrained model performs a target workload. Options range from instructions, examples, retrieval, tools, and structured decoding to parameter-efficient fine-tuning, full fine-tuning, continued pretraining, or combinations. The least invasive option that meets measured requirements is often easier to operate, but the correct intervention depends on the failure being addressed rather than a universal ladder.", "whyItMatters": [ "Adaptation should begin with a defined gap and evaluation set. Changing weights cannot repair every context, tool, process, or authorization problem.", "Parameter changes create a new model artifact with provenance, evaluation, security, deployment, monitoring, and rollback obligations." ], "anatomy": [ { "label": "Target gap", "description": "A measured behavior the intervention is intended to improve." }, { "label": "Adaptation method", "description": "Contextual, tool-based, parameter-efficient, full-weight, or continued-training technique." }, { "label": "Data and provenance", "description": "Authorized training examples, labels, transformations, and lineage." }, { "label": "Evaluation and release", "description": "Comparative quality, safety, regression, and operational acceptance evidence." } ], "mechanism": [], "distinctions": [ { "label": "Prompt engineering", "description": "Prompting changes inference-time instructions; weight-based methods create a modified model artifact." }, { "label": "Retrieval-augmented generation", "description": "Retrieval changes available context without necessarily changing model parameters." } ], "practices": [ "Diagnose whether the gap is in knowledge, behavior, tooling, or workflow", "Keep a fixed holdout set and evaluate regressions", "Record base model, data, method, hyperparameters, and resulting artifact", "Plan rollback before serving an adapted model" ], "failureModes": [ "Fine-tuning is used to compensate for missing product requirements", "Training data leaks evaluation examples or restricted content", "A gain on one slice conceals regressions elsewhere" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "hf-fine-tuning", "hf-peft-methods", "anthropic-evals" ], "videoSourceIds": [], "relatedEntryIds": [ "parameter-efficient-fine-tuning", "retrieval-augmented-generation", "open-weight-model", "eval-driven-development" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Model adaptation | Agentic Engineering Knowledge Atlas", "seoDescription": "The deliberate modification of a model or its task-facing behavior for a target domain, task, language, policy, or operating environment using measured evidence." }, { "id": "parameter-efficient-fine-tuning", "index": "", "title": "Parameter-efficient fine-tuning", "shortTitle": "Parameter-efficient fine-tuning", "aliases": [ "PEFT", "LoRA", "low-rank adaptation" ], "declaredRoute": "/agentic-engineering/parameter-efficient-fine-tuning", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "PEFT and LoRA are established techniques with broad tooling support; results and operational tradeoffs vary by architecture, method, data, and task.", "question": "", "oneLine": "A family of adaptation methods that trains a relatively small subset of parameters or added components while leaving most or all pretrained model weights fixed.", "definition": "Parameter-efficient fine-tuning, or PEFT, adapts a pretrained model without updating every base parameter. Methods include trainable prompts, selective layer tuning, and adapters such as Low-Rank Adaptation, which adds trainable low-rank matrices while freezing base weights. PEFT can reduce training memory and artifact size, but it does not guarantee full-fine-tuning quality, eliminate data risk, or remove the need for evaluation.", "whyItMatters": [ "Keeping the base model fixed makes it possible to maintain smaller task-specific adapters and sometimes combine or switch them at serving time.", "The deployed behavior depends on the exact base model, adapter, tokenizer, runtime, and composition order, so all of them belong in artifact lineage." ], "anatomy": [ { "label": "Frozen base", "description": "Most pretrained model parameters remain unchanged during adaptation." }, { "label": "Trainable component", "description": "A smaller parameter subset, prompt, layer selection, or adapter learns the target change." }, { "label": "Adapter artifact", "description": "The compact learned state tied to a compatible base model and configuration." }, { "label": "Composition", "description": "Rules for loading, merging, switching, or combining adapters during deployment." } ], "mechanism": [], "distinctions": [ { "label": "Full fine-tuning", "description": "Full fine-tuning updates all or most base parameters; PEFT intentionally limits the trainable portion." }, { "label": "Quantization", "description": "PEFT changes learned behavior; quantization changes numerical representation primarily for storage or execution efficiency." } ], "practices": [ "Benchmark PEFT against prompting, retrieval, and full fine-tuning baselines", "Version the adapter with its exact base model and tokenizer", "Evaluate merged and unmerged deployment forms separately" ], "failureModes": [ "An adapter is loaded onto an incompatible base revision", "Lower training cost is mistaken for lower assurance burden", "Multiple adapters interact in untested ways" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "hf-peft-methods", "lora-paper", "hf-fine-tuning" ], "videoSourceIds": [], "relatedEntryIds": [ "model-adaptation", "quantization", "open-weight-model", "inference-serving" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Parameter-efficient fine-tuning | Agentic Engineering Knowledge Atlas", "seoDescription": "A family of adaptation methods that trains a relatively small subset of parameters or added components while leaving most or all pretrained model weights fixed." }, { "id": "quantization", "index": "", "title": "Quantization", "shortTitle": "Quantization", "aliases": [ "model quantization", "low-bit inference" ], "declaredRoute": "/agentic-engineering/quantization", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Quantization is established, with rapidly evolving formats, kernels, hardware support, and quality-efficiency frontiers.", "question": "", "oneLine": "The representation or computation of model values at lower numerical precision to reduce memory, storage, bandwidth, or inference cost, with workload-dependent tradeoffs.", "definition": "Quantization converts some model weights, activations, or computation from higher-precision formats to lower-precision or integer representations. It can make models fit on smaller hardware and may improve throughput or latency, but effects depend on the model, method, kernels, device, context length, and workload. Reduced precision can alter quality, calibration, stability, or supported operations and must be evaluated rather than assumed.", "whyItMatters": [ "Post-training quantization modifies a trained artifact after training; quantization-aware approaches account for lower precision during adaptation or training.", "A smaller file is not the whole result. Runtime memory, key-value cache, batching, prompt length, and hardware kernels also shape capacity and performance." ], "anatomy": [ { "label": "Precision format", "description": "The bit width and numerical representation used for weights, activations, or computation." }, { "label": "Quantization method", "description": "Calibration, grouping, scaling, and whether conversion occurs during or after training." }, { "label": "Runtime support", "description": "Kernels and hardware capable of executing the chosen format correctly and efficiently." }, { "label": "Quality evaluation", "description": "Task, safety, and calibration checks against the unquantized baseline." } ], "mechanism": [], "distinctions": [ { "label": "Parameter-efficient fine-tuning", "description": "Quantization primarily changes representation and execution; PEFT learns a behavioral adaptation with a restricted set of trainable parameters." }, { "label": "Model pruning", "description": "Pruning removes parameters or structure, while quantization represents values with fewer bits." } ], "practices": [ "Measure quality and safety on the actual workload after conversion", "Benchmark end-to-end latency, throughput, memory, and power on target hardware", "Record format, calibration data, runtime, and conversion settings" ], "failureModes": [ "Aggregate benchmarks conceal a critical task regression", "A format is portable as a file but unsupported by the target kernel", "Memory estimates ignore runtime cache growth" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "hf-quantization", "llama-cpp-local-inference" ], "videoSourceIds": [], "relatedEntryIds": [ "local-inference", "open-weight-model", "parameter-efficient-fine-tuning", "inference-serving" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Quantization | Agentic Engineering Knowledge Atlas", "seoDescription": "The representation or computation of model values at lower numerical precision to reduce memory, storage, bandwidth, or inference cost, with workload-dependent tradeoffs." }, { "id": "inference-serving", "index": "", "title": "Inference serving", "shortTitle": "Inference serving", "aliases": [ "model serving", "inference server" ], "declaredRoute": "/agentic-engineering/inference-serving", "entryType": "technical-term", "domain": "Models & inference", "maturity": "foundational", "maturityNote": "Serving systems are established infrastructure, while model sizes, accelerator architectures, scheduling techniques, and compatible APIs continue to change quickly.", "question": "", "oneLine": "The runtime and operational layer that loads model artifacts, accepts requests, schedules computation, executes generation, and returns outputs under defined service constraints.", "definition": "Inference serving turns a model artifact into an operational service. The layer manages model loading, tokenization, request validation, scheduling, batching, caches, parallel execution, streaming, resource limits, and response contracts. It can expose a familiar compatible API, but protocol compatibility does not imply identical model behavior, security, configuration, or control semantics.", "whyItMatters": [ "Serving performance is a queueing and resource problem as well as a model problem: arrival patterns, prompt lengths, output lengths, batching, and memory all interact.", "Application authorization and agent governance normally sit outside the raw inference runtime. A serving endpoint should not be mistaken for a complete execution harness or control plane." ], "anatomy": [ { "label": "Artifact loading", "description": "Weights, tokenizer, adapters, quantization, and configuration loaded as one reproducible deployment." }, { "label": "Request scheduling", "description": "Queueing, batching, prioritization, cancellation, and concurrency decisions." }, { "label": "Execution", "description": "Device placement, parallelism, cache management, generation, and streaming." }, { "label": "Service contract", "description": "Authenticated endpoint behavior, limits, error semantics, health, and version identity." } ], "mechanism": [], "distinctions": [ { "label": "Model", "description": "The model is the learned artifact; serving is the software and infrastructure that operates it." }, { "label": "Agent harness", "description": "An inference server returns model outputs; a harness manages goals, tools, state, checkpoints, and execution across calls." }, { "label": "Control plane", "description": "Serving applies runtime configuration, but enterprise governance and binding action policy require distinct authority and enforcement layers." } ], "practices": [ "Pin model, tokenizer, runtime, adapter, and configuration versions", "Load-test realistic prompt and output distributions", "Authenticate and rate-limit endpoints", "Canary changes and retain a tested rollback path" ], "failureModes": [ "A compatible API masks incompatible parameters or behavior", "Batching improves throughput while violating latency objectives", "Unbounded prompts exhaust cache or starve other requests" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "vllm-serving", "llama-cpp-local-inference" ], "videoSourceIds": [], "relatedEntryIds": [ "self-hosted-inference", "local-inference", "model-routing", "harness-engineering" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Inference serving | Agentic Engineering Knowledge Atlas", "seoDescription": "The runtime and operational layer that loads model artifacts, accepts requests, schedules computation, executes generation, and returns outputs under defined service constraints." }, { "id": "second-brain", "index": "", "title": "Second brain", "shortTitle": "Second brain", "aliases": [ "AI second brain", "external brain" ], "declaredRoute": "/agentic-engineering/second-brain", "entryType": "technical-term", "domain": "Context & knowledge", "maturity": "metaphor", "maturityNote": "The metaphor is popular, while implementations range from personal notes to governed enterprise retrieval and memory systems.", "question": "", "oneLine": "A metaphor for an external knowledge and memory system that helps a person or agent retrieve prior context, decisions, and artifacts.", "definition": "In agentic engineering, “second brain” is a metaphor—not a settled technical architecture. A credible implementation is a governed knowledge system with explicit sources, access control, provenance, retrieval, recency, correction, retention, and trust boundaries; it is not an uncurated transcript dump or an extension of human cognition.", "whyItMatters": [ "The useful question is what knowledge should persist, who may access it, how it is retrieved, and how errors are corrected.", "Persistent memory increases utility and attack surface at the same time." ], "anatomy": [ { "label": "Capture", "description": "Deliberate ingestion of attributable information." }, { "label": "Organization", "description": "Versioning, metadata, permissions, and retention." }, { "label": "Retrieval", "description": "Task-relevant selection rather than indiscriminate context loading." }, { "label": "Correction", "description": "A governed path to supersede or remove inaccurate memory." } ], "mechanism": [], "distinctions": [ { "label": "Context window", "description": "The second-brain metaphor describes an external store; only selected items enter current model context." }, { "label": "Ground truth", "description": "Persisted content remains evidence with provenance and may be wrong, stale, or contested." }, { "label": "Durable project memory", "description": "Durable project memory is the more precise engineering concept with explicit state and governance requirements." } ], "practices": [ "Use durable project memory as the implementation vocabulary", "Carry source and trust metadata into retrieval", "Separate personal, project, and enterprise retention boundaries" ], "failureModes": [ "Every chat becomes permanent memory", "Poisoned or obsolete content silently shapes future decisions", "Sensitive information crosses users or purposes" ], "enterpriseQuestions": [], "sections": [], "sourceIds": [ "anthropic-context", "owasp-memory", "rag-paper" ], "videoSourceIds": [], "relatedEntryIds": [ "durable-memory", "retrieval-augmented-generation", "context-engineering", "instruction-data-trust-boundary" ], "links": [], "reviewedAt": "2026-08-09", "atlasConceptId": "", "lifecyclePhases": [], "controlIds": [], "seoTitle": "Second brain | Agentic Engineering Knowledge Atlas", "seoDescription": "A metaphor for an external knowledge and memory system that helps a person or agent retrieve prior context, decisions, and artifacts." } ], "sources": [ { "id": "openai-harness-engineering", "title": "Harness engineering: leveraging Codex in an agent-first world", "publisher": "OpenAI", "href": "https://openai.com/index/harness-engineering/", "publishedAt": "2026-02-11", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A production case study in designing repositories, tools, feedback loops, and environments for agent-first delivery.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "OpenAI" ] }, { "id": "openai-symphony", "title": "An open-source spec for Codex orchestration: Symphony", "publisher": "OpenAI", "href": "https://openai.com/index/open-source-codex-orchestration-symphony/", "publishedAt": "2026-04-27", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "An orchestration specification that connects project work, isolated agent execution, and reviewable delivery state.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "OpenAI" ] }, { "id": "openai-monitoring", "title": "How we monitor internal coding agents for misalignment", "publisher": "OpenAI", "href": "https://openai.com/index/how-we-monitor-internal-coding-agents-misalignment/", "publishedAt": "2026-03-19", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A current account of monitoring powerful coding agents that can act inside consequential development environments.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "OpenAI" ] }, { "id": "openai-self-improving", "title": "Building self-improving tax agents with Codex", "publisher": "OpenAI", "href": "https://openai.com/index/building-self-improving-tax-agents-with-codex/", "publishedAt": "2026-05-27", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A feedback-loop pattern that turns practitioner corrections and production traces into evaluations and scoped engineering work.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "OpenAI" ] }, { "id": "anthropic-context", "title": "Effective context engineering for AI agents", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents", "publishedAt": "2025-09-29", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A working model for treating model-visible context as a finite resource that must be selected and maintained.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "Anthropic" ] }, { "id": "anthropic-long-running-harness", "title": "Effective harnesses for long-running agents", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents", "publishedAt": "2025-11-26", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "Patterns for incremental progress and durable handoffs across context windows and extended execution.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "Anthropic" ] }, { "id": "anthropic-harness-design", "title": "Harness design for long-running application development", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/harness-design-long-running-apps", "publishedAt": "2026-03-24", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A planner, generator, and evaluator architecture for multi-hour autonomous application development.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "Anthropic" ] }, { "id": "anthropic-managed-agents", "title": "Scaling Managed Agents: Decoupling the brain from the hands", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/managed-agents", "publishedAt": "2026-04-08", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "An architecture separating durable sessions and environment state from changing models and harnesses.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "Anthropic" ] }, { "id": "anthropic-evals", "title": "Demystifying evals for AI agents", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents", "publishedAt": "2026-01-09", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "Official guidance", "note": "A practical treatment of evaluating trajectories, outcomes, graders, tasks, and agent-environment interaction.", "limitations": "This is first-party engineering guidance drawn from Anthropic deployments. Evaluation designs remain task- and environment-specific, and the article does not establish independent verifier ownership by itself.", "authors": [ "Anthropic" ] }, { "id": "anthropic-infrastructure-noise", "title": "Quantifying infrastructure noise in agentic coding evals", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/infrastructure-noise", "publishedAt": "2026-02-05", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Empirical evidence", "note": "An empirical demonstration that resource configuration can materially alter agent benchmark results and must be treated as part of the evaluation system.", "limitations": "Interpret the result within the published sample, task, model, environment, and measurement design; it does not establish a universal outcome.", "authors": [ "Anthropic" ] }, { "id": "github-spec-driven", "title": "Spec-driven development with AI", "publisher": "GitHub", "href": "https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/", "publishedAt": "2025-09-02", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A structured specification-to-plan-to-task workflow for making intent durable and actionable by coding agents.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "GitHub" ] }, { "id": "github-spec-persistence", "title": "Spec persistence models", "publisher": "GitHub Spec Kit", "href": "https://github.github.com/spec-kit/concepts/spec-persistence.html", "publishedAt": "2026-07", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "Distinguishes spec-first, spec-anchored, and spec-as-source approaches without asserting one universal model.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "GitHub Spec Kit" ] }, { "id": "nist-agent-identity", "title": "Identity and Authority for Software Agents concept paper", "publisher": "NIST NCCoE", "href": "https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf", "publishedAt": "2026-02-05", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A concept paper exploring how established identity and authorization practices can apply to software and AI agents.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "NIST NCCoE" ] }, { "id": "nist-agent-standards", "title": "AI Agent Standards Initiative", "publisher": "NIST", "href": "https://www.nist.gov/artificial-intelligence/ai-agent-standards-initiative", "publishedAt": "2026-02-17", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A standards initiative addressing secure, interoperable adoption of AI agents.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "NIST" ] }, { "id": "microsoft-agent-identities", "title": "What are agent identities?", "publisher": "Microsoft Entra", "href": "https://learn.microsoft.com/en-us/entra/agent-id/what-are-agent-identities", "publishedAt": "2026-06-15", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A current enterprise identity model distinguishing agents from people and conventional applications, including ownership, sponsorship, delegated rights, and auditability.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Entra" ] }, { "id": "nist-benchmark-evals", "title": "Towards best practices for automated benchmark evaluations", "publisher": "NIST", "href": "https://www.nist.gov/news-events/news/2026/01/towards-best-practices-automated-benchmark-evaluations", "publishedAt": "2026-01-30", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Guidance on the integrity and limitations of automated benchmark evaluation practices.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "NIST" ] }, { "id": "nist-deployed-monitoring", "title": "Challenges in monitoring deployed AI systems", "publisher": "NIST CAISI", "href": "https://www.nist.gov/publications/challenges-monitoring-deployed-ai-systems-center-ai-standards-and-innovation", "publishedAt": "2026-03-06", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A current view of monitoring needs and limitations for deployed AI systems.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "NIST CAISI" ] }, { "id": "owasp-agentic-top10", "title": "OWASP Top 10 for Agentic Applications 2026", "publisher": "OWASP GenAI Security Project", "href": "https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/", "publishedAt": "2025-12", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A threat-oriented reference for goal hijacking, tool misuse, identity abuse, memory poisoning, and cascading agent failures.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "OWASP GenAI Security Project" ] }, { "id": "owasp-memory", "title": "Memory Is a Feature. It Is Also an Attack Surface", "publisher": "OWASP GenAI Security Project", "href": "https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface/", "publishedAt": "2026-05-13", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A focused account of why persistent agent memory requires integrity, provenance, and poisoning defenses.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "OWASP GenAI Security Project" ] }, { "id": "mcp-enterprise-auth", "title": "Enterprise-Managed Authorization for MCP", "publisher": "Model Context Protocol", "href": "https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/", "publishedAt": "2026-06-18", "reviewedAt": "2026-08-09", "kind": "protocol", "format": "protocol", "claimRole": "Standard or protocol", "note": "An emerging authorization pattern for enterprise-managed agent access to MCP servers.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "Model Context Protocol" ] }, { "id": "mcp-2026-release-candidate", "title": "Model Context Protocol 2026-07-28 release candidate", "publisher": "Model Context Protocol", "href": "https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/", "publishedAt": "2026-07-28", "reviewedAt": "2026-08-09", "kind": "protocol", "format": "protocol", "claimRole": "Standard or protocol", "note": "A current protocol release candidate illustrating that agent-tool interoperability, authorization, and extension surfaces continue to evolve and require explicit version governance.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "Model Context Protocol" ] }, { "id": "a2a-v1", "title": "Agent2Agent Protocol v1.0", "publisher": "A2A Project", "href": "https://a2a-protocol.org/latest/announcing-1.0/", "publishedAt": "2026-03", "reviewedAt": "2026-08-09", "kind": "protocol", "format": "protocol", "claimRole": "Standard or protocol", "note": "A protocol milestone for interoperable communication and collaboration between agents.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "A2A Project" ] }, { "id": "google-agent-substrate", "title": "Agent Sandbox on GKE and Agent Substrate", "publisher": "Google Cloud", "href": "https://cloud.google.com/blog/products/containers-kubernetes/bringing-you-agent-sandbox-on-gke-and-agent-substrate", "publishedAt": "2026-05-20", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "An agent-specific execution architecture emphasizing isolation, state, scheduling, and environment control.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "Google Cloud" ] }, { "id": "opentelemetry-genai", "title": "GenAI observability", "publisher": "OpenTelemetry", "href": "https://opentelemetry.io/blog/2026/genai-observability/", "publishedAt": "2026-05-14", "reviewedAt": "2026-08-09", "kind": "standard", "format": "standard", "claimRole": "Standard or protocol", "note": "Developing semantic conventions for model and agent telemetry across traces, metrics, and events.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "OpenTelemetry" ] }, { "id": "slsa-provenance", "title": "SLSA provenance specification v1.2", "publisher": "SLSA", "href": "https://slsa.dev/spec/v1.2/provenance", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "standard", "format": "standard", "claimRole": "Standard or protocol", "note": "An established software-supply-chain foundation for attributable build provenance.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "SLSA" ] }, { "id": "karpathy-software-3", "title": "Software Is Changing (Again)", "publisher": "Andrej Karpathy", "href": "https://www.youtube.com/watch?v=LCEmiRjPEtQ", "publishedAt": "2025-06-17", "reviewedAt": "2026-08-09", "kind": "talk", "format": "video", "claimRole": "Practitioner perspective", "note": "A thought-leadership lens on natural language, neural networks, and changing software interfaces—not a formal standard.", "limitations": "This is an attributed thought-leadership or practitioner source, not a consensus standard or independently validated general law.", "authors": [ "Andrej Karpathy" ], "video": { "youtubeId": "LCEmiRjPEtQ", "channel": "Y Combinator", "speakers": [ "Andrej Karpathy" ] } }, { "id": "google-dora-ai-development", "title": "DORA 2025 State of AI-assisted Software Development Report", "publisher": "Google Research / DORA", "href": "https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/", "publishedAt": "2025", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Empirical evidence", "note": "Large-sample research framing AI as an amplifier of the capabilities and dysfunctions already present in an engineering organization.", "limitations": "The report identifies population-level relationships and system conditions; it does not promise that AI adoption will improve any individual team or metric.", "authors": [ "DORA research team" ] }, { "id": "microsoft-agent-accountability", "title": "Define roles, responsibilities, and decision rights", "publisher": "Microsoft Agentic Center of Excellence", "href": "https://learn.microsoft.com/en-us/agents/center-of-excellence/roles-responsibilities", "publishedAt": "2026-07-14", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "An operating model that assigns one accountable role per decision and distinguishes domain, platform, risk, and runtime responsibilities.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Agentic Center of Excellence" ] }, { "id": "microsoft-agent-risk-governance", "title": "Govern agents by risk", "publisher": "Microsoft Agentic Center of Excellence", "href": "https://learn.microsoft.com/en-us/agents/center-of-excellence/govern-agents-risk", "publishedAt": "2026-07-14", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Current enterprise guidance for matching review depth, autonomy limits, release gates, logging, and incident planning to agent risk.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Agentic Center of Excellence" ] }, { "id": "microsoft-agent-lifecycle", "title": "Manage the agent lifecycle", "publisher": "Microsoft Agentic Center of Excellence", "href": "https://learn.microsoft.com/en-us/agents/center-of-excellence/agent-lifecycle", "publishedAt": "2026-07-14", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A product-lifecycle model spanning intake, deployment, monitoring, improvement, ownership, evaluation, and deliberate retirement.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Agentic Center of Excellence" ] }, { "id": "microsoft-agent-id-governance", "title": "Governing Agent Identities", "publisher": "Microsoft Entra ID Governance", "href": "https://learn.microsoft.com/en-us/entra/id-governance/agent-id-governance-overview", "publishedAt": "2026-06-16", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "An identity-governance model for agent sponsors, access packages, ownership continuity, lifecycle workflows, and enable or disable decisions.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Entra ID Governance" ] }, { "id": "microsoft-agent-owners-sponsors", "title": "Administrative relationships in Microsoft Entra Agent ID", "publisher": "Microsoft Entra Agent ID", "href": "https://learn.microsoft.com/en-us/entra/agent-id/agent-owners-sponsors-managers", "publishedAt": "2026-04-08", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Separates technical ownership from business sponsorship and assigns sponsors lifecycle, access-review, and incident-response decisions.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "Microsoft Entra Agent ID" ] }, { "id": "owasp-agentic-security-state", "title": "State of Agentic AI Security and Governance 2.01", "publisher": "OWASP GenAI Security Project", "href": "https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/", "publishedAt": "2026-06-01", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "A current threat and governance synthesis covering instruction-data confusion, containment gaps, autonomous action, and agentic incident readiness.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "OWASP GenAI Security Project" ] }, { "id": "opa-policy-enforcement", "title": "OPA Management APIs and Architecture", "publisher": "Open Policy Agent", "href": "https://www.openpolicyagent.org/docs/management-introduction", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "standard", "format": "standard", "claimRole": "Standard or protocol", "note": "An established policy-engine architecture for distributed enforcement, centrally managed policy bundles, decision logs, and enforcement telemetry.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "Open Policy Agent" ] }, { "id": "nist-ai-rmf", "title": "Artificial Intelligence Risk Management Framework 1.0", "publisher": "NIST", "href": "https://www.nist.gov/itl/ai-risk-management-framework", "publishedAt": "2023-01-26", "reviewedAt": "2026-08-09", "kind": "standard", "format": "standard", "claimRole": "Standard or protocol", "note": "A consensus-based foundation for governing, mapping, measuring, and managing AI risk according to context, impact, and organizational priorities.", "limitations": "A specification defines an interface or control pattern; conformance alone does not establish authorization, security, or fitness for a use case.", "authors": [ "NIST" ] }, { "id": "anthropic-building-effective-agents", "title": "Building effective agents", "publisher": "Anthropic", "href": "https://www.anthropic.com/engineering/building-effective-agents", "publishedAt": "2024-12-19", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "Primary definition", "note": "A foundational distinction between fixed, code-orchestrated workflows and systems in which a model dynamically directs its process and tool use.", "limitations": "The workflow-versus-agent distinction is a useful architecture boundary, not a universal taxonomy or proof that autonomous execution is preferable.", "authors": [ "Anthropic" ] }, { "id": "artificial-analysis-methodology", "title": "Artificial Analysis Intelligence Benchmarking Methodology", "publisher": "Artificial Analysis", "href": "https://artificialanalysis.ai/methodology/intelligence-benchmarking", "publishedAt": "2026-06", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Independent benchmark", "note": "A transparent methodology for comparing model quality, price, latency, throughput, and cost per task. Its composite indices are useful evidence, not a substitute for use-case-specific evaluation.", "limitations": "Composite benchmark results change over time and do not establish enterprise fit, safety, controllability, or acceptance for a specific workload. No leaderboard values are reproduced here.", "authors": [ "Artificial Analysis" ] }, { "id": "ai-engineer-velocity-sickness", "title": "Velocity Sickness: What Happens When Your Whole Team Gets 10x Faster", "publisher": "Matt Dailey · AI Engineer World's Fair", "href": "https://www.youtube.com/watch?v=Kz4QJmNrVXU", "publishedAt": "2026-08-09", "reviewedAt": "2026-08-09", "kind": "talk", "format": "video", "claimRole": "Practitioner perspective", "note": "A practitioner framing for the coordination pain that appears when individual generation accelerates faster than shared decisions, review, and integration. It is an attributed field term, not a clinical or validated organizational diagnosis.", "limitations": "“Velocity sickness” is an attributed practitioner coinage, not a clinical term, validated diagnosis, or measured universal effect.", "authors": [ "Matt Dailey" ], "video": { "youtubeId": "Kz4QJmNrVXU", "channel": "AI Engineer", "speakers": [ "Matt Dailey" ] } }, { "id": "dora-wip-limits", "title": "Work in process limits", "publisher": "DORA", "href": "https://dora.dev/capabilities/wip-limits/", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Research-backed guidance for making work visible, limiting concurrent work to real capacity, and improving the most consequential constraint in the delivery system.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "DORA" ] }, { "id": "dora-small-batches", "title": "Working in small batches", "publisher": "DORA", "href": "https://dora.dev/capabilities/working-in-small-batches/", "publishedAt": "2025", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Guidance that connects smaller changes with faster feedback, easier review, and safer integration, including in AI-assisted delivery.", "limitations": "Guidance describes recommended practice; citation does not prove that a control is implemented or effective in a particular environment.", "authors": [ "DORA" ] }, { "id": "space-developer-productivity", "title": "The SPACE of Developer Productivity: There's more to it than you think", "publisher": "Microsoft Research / ACM Queue", "href": "https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/", "publishedAt": "2021-02", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Empirical evidence", "note": "A multidimensional productivity framework spanning satisfaction, performance, activity, communication, and efficiency rather than reducing engineering value to one activity metric.", "limitations": "Interpret the result within the published sample, task, model, environment, and measurement design; it does not establish a universal outcome.", "authors": [ "Nicole Forsgren", "Margaret-Anne Storey", "Chandra Maddila", "Thomas Zimmermann", "Brian Houck", "Jenna Butler" ] }, { "id": "github-agent-pr-review", "title": "Agent pull requests are everywhere. Here's how to review them", "publisher": "GitHub", "href": "https://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/", "publishedAt": "2026-05-07", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "A current practitioner account of agent-generated pull requests saturating review bandwidth and the continued need for contextual human judgment.", "limitations": "This first-party account documents one organization, product, or implementation context and should not be generalized without local evidence.", "authors": [ "GitHub" ] }, { "id": "metr-developer-productivity-rct", "title": "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity", "publisher": "METR", "href": "https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/", "publishedAt": "2025-07-10", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Empirical evidence", "note": "A randomized study in one narrow setting that found experienced contributors took longer with early-2025 tools. The authors explicitly caution against generalizing the result to all developers, tools, repositories, or later model generations.", "limitations": "The randomized study covered 16 experienced contributors, 246 tasks, mature open-source repositories, and early-2025 tools; it does not establish that AI always slows developers or predict later tools.", "authors": [ "METR research team" ] }, { "id": "anthropic-trustworthy-agents", "title": "Trustworthy agents in practice", "publisher": "Anthropic", "href": "https://www.anthropic.com/research/trustworthy-agents", "publishedAt": "2026-04-09", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Primary definition", "note": "Describes a self-directed plan–act–observe–adjust loop and the engineering layers needed to make longer-horizon agents more trustworthy.", "limitations": "This first-party synthesis describes design directions and failure surfaces; it is not a certification scheme or evidence that every described control is sufficient.", "authors": [ "Anthropic" ] }, { "id": "openai-practical-agent-guide", "title": "A practical guide to building agents", "publisher": "OpenAI", "href": "https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/", "publishedAt": "2025", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Primary definition", "note": "Defines a practical agent around a model, tools, instructions, and a run loop that continues until an exit condition is reached.", "limitations": "The guide is first-party product guidance and a simplified starting architecture, not a complete regulated-enterprise control model.", "authors": [ "OpenAI" ] }, { "id": "video-linear-production-agents", "title": "5 Rules for Building AI Agents That Work in Production | Nan Yu & Jacob Shumway", "publisher": "Peter Yang", "href": "https://www.youtube.com/watch?v=4mKtJzfGj0U", "publishedAt": "2026-08-09", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "A Linear engineering discussion of production agents, tool design, context loading, feedback, evaluation, and simple model-in-a-loop explanations.", "limitations": "The five rules and “LLM in a loop plus tools” shorthand reflect one product team’s experience; they are not a standard or a complete enterprise-agent definition.", "authors": [ "Peter Yang", "Nan Yu", "Jacob Shumway" ], "video": { "youtubeId": "4mKtJzfGj0U", "channel": "Peter Yang", "speakers": [ "Nan Yu", "Jacob Shumway" ] } }, { "id": "video-deeplearning-agentic-ai", "title": "Learn to build effective Agentic AI systems", "publisher": "DeepLearning.AI", "href": "https://www.youtube.com/shorts/NS47q32aWZw", "publishedAt": "2025-10-07", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "A short introduction to an Andrew Ng course covering reflection, tool use, planning, multi-agent patterns, and evaluation.", "limitations": "This 59-second course promotion contains very little technical evidence; use the associated course materials for substantive instruction.", "authors": [ "DeepLearning.AI" ], "video": { "youtubeId": "NS47q32aWZw", "channel": "DeepLearningAI", "speakers": [ "DeepLearning.AI" ] } }, { "id": "deeplearning-agentic-ai-course", "title": "Agentic AI", "publisher": "DeepLearning.AI", "href": "https://www.deeplearning.ai/courses/agentic-ai/", "publishedAt": "2025", "reviewedAt": "2026-08-09", "kind": "course", "format": "course", "claimRole": "Official guidance", "note": "A practitioner course organizing agentic systems around reflection, tool use, planning, multi-agent workflows, evaluation, and optimization.", "limitations": "Course taxonomy is instructional rather than normative; it does not itself define enterprise authorization or assurance requirements.", "authors": [ "Andrew Ng" ] }, { "id": "video-indydevdan-software-factory", "title": "My Super Simple Software Factory (For Agentic Engineers)", "publisher": "IndyDevDan", "href": "https://www.youtube.com/watch?v=haUfb1ievTE", "publishedAt": "2026-08-03", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "A practitioner demonstration of an agentic software-factory workflow built from reusable agents, commands, hooks, and feedback loops.", "limitations": "This is a personal implementation and editorial thesis, not comparative evidence, a safety case, or a production reference architecture.", "authors": [ "IndyDevDan" ], "video": { "youtubeId": "haUfb1ievTE", "channel": "IndyDevDan", "speakers": [ "IndyDevDan" ] } }, { "id": "video-openai-harness-engineering", "title": "Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI", "publisher": "AI Engineer", "href": "https://www.youtube.com/watch?v=am_oeAoUhew", "publishedAt": "2026-04-16", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "A conference presentation about engineering repositories, feedback loops, tools, and constraints around coding agents.", "limitations": "The talk reports a first-party approach and should be paired with the cited OpenAI engineering article; it is not a universal method or independent assurance evidence.", "authors": [ "Ryan Lopopolo" ], "video": { "youtubeId": "am_oeAoUhew", "channel": "AI Engineer", "speakers": [ "Ryan Lopopolo" ] } }, { "id": "rag-paper", "title": "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", "publisher": "arXiv / NeurIPS", "href": "https://arxiv.org/abs/2005.11401", "publishedAt": "2020-05-22", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Primary definition", "note": "Introduces retrieval-augmented generation as a combination of learned generation and explicit retrieved non-parametric memory.", "limitations": "The paper establishes an influential architecture, not a guarantee that retrieved content is current, correct, authorized, or safe to use.", "authors": [ "Patrick Lewis", "Ethan Perez", "Aleksandra Piktus", "Fabio Petroni", "Vladimir Karpukhin", "Naman Goyal", "Heinrich Küttler", "Mike Lewis", "Wen-tau Yih", "Tim Rocktäschel", "Sebastian Riedel", "Douwe Kiela" ] }, { "id": "react-paper", "title": "ReAct: Synergizing Reasoning and Acting in Language Models", "publisher": "arXiv / ICLR", "href": "https://arxiv.org/abs/2210.03629", "publishedAt": "2022-10-06", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Primary definition", "note": "Studies interleaved reasoning traces and environment actions, a foundational pattern for model-driven agent loops.", "limitations": "Reported benchmark gains do not establish reliability for open-ended production environments or permission for consequential action.", "authors": [ "Shunyu Yao", "Jeffrey Zhao", "Dian Yu", "Nan Du", "Izhak Shafran", "Karthik Narasimhan", "Yuan Cao" ] }, { "id": "reflexion-paper", "title": "Reflexion: Language Agents with Verbal Reinforcement Learning", "publisher": "arXiv / NeurIPS", "href": "https://arxiv.org/abs/2303.11366", "publishedAt": "2023-03-20", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Primary definition", "note": "Introduces a feedback pattern in which an agent converts signals into verbal reflections retained for later attempts.", "limitations": "Self-reflection can improve subsequent attempts in some tasks but is not independent verification and can preserve or amplify a model’s blind spots.", "authors": [ "Noah Shinn", "Federico Cassano", "Edward Berman", "Ashwin Gopinath", "Karthik Narasimhan", "Shunyu Yao" ] }, { "id": "llm-judge-position-bias", "title": "Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge", "publisher": "arXiv", "href": "https://arxiv.org/abs/2406.07791", "publishedAt": "2024-06-12", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Empirical evidence", "note": "Documents position-related bias in model-based comparative judgment and motivates calibration and bias controls.", "limitations": "The study addresses selected judge models, prompts, and tasks; other grader failure modes and later systems require separate evaluation.", "authors": [ "Lin Shi", "Chiyu Ma", "Wenhua Liang", "Xingjian Diao", "Weicheng Ma", "Soroush Vosoughi" ] }, { "id": "moe-paper", "title": "Outrageously Large Neural Networks: The Sparsely-Gated Mixture-of-Experts Layer", "publisher": "Google Research / ICLR", "href": "https://research.google/pubs/outrageously-large-neural-networks-the-sparsely-gated-mixture-of-experts-layer/", "publishedAt": "2017", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Primary definition", "note": "Introduces a sparsely gated neural layer that routes each example to a subset of learned expert subnetworks.", "limitations": "“Experts” are learned subnetworks, not autonomous agents, accountable specialists, or independently governed services.", "authors": [ "Noam Shazeer", "Azalia Mirhoseini", "Krzysztof Maziarz", "Andy Davis", "Quoc Le", "Geoffrey Hinton", "Jeff Dean" ] }, { "id": "mcp-architecture", "title": "Model Context Protocol architecture overview", "publisher": "Model Context Protocol", "href": "https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture", "publishedAt": "2026-07-28", "reviewedAt": "2026-08-09", "kind": "protocol", "format": "protocol", "claimRole": "Standard or protocol", "note": "Documents the host, client, server, capability-negotiation, and message layers used to connect AI applications with context and tools.", "limitations": "Protocol connectivity and capability discovery do not confer business authority, validate tool output, or make a server trustworthy.", "authors": [ "Model Context Protocol maintainers" ] }, { "id": "nist-zero-trust", "title": "Zero Trust Architecture (NIST SP 800-207)", "publisher": "NIST", "href": "https://csrc.nist.gov/pubs/sp/800/207/final", "publishedAt": "2020-08-11", "reviewedAt": "2026-08-09", "kind": "standard", "format": "standard", "claimRole": "Standard or protocol", "note": "Defines zero trust around explicit, continuously evaluated access decisions rather than implicit trust from network location.", "limitations": "The publication is an enterprise security architecture, not an agent-specific verification standard; agent applications require additional threat and assurance analysis.", "authors": [ "Scott Rose", "Oliver Borchert", "Stu Mitchell", "Sean Connelly" ] }, { "id": "pragmatic-programmer-tracer-bullets", "title": "The Pragmatic Programmer, 20th Anniversary Edition", "publisher": "Addison-Wesley, by special arrangement with Pragmatic Bookshelf", "href": "https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/", "publishedAt": "2019-09", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Primary definition", "note": "The official title record for Thomas and Hunt’s revised edition identifies the authors, publication date, and canonical Tracer Bullets topic, which uses real feedback from a thin implementation path to guide development toward an evolving target.", "limitations": "This copyrighted book is the provenance source for the established software-development concept. AISDLC paraphrases the high-level idea and links to the official title record; it does not reproduce the protected chapter. Applying the technique to coding-agent delivery is a later practitioner synthesis that still requires local evidence.", "authors": [ "David Thomas", "Andrew Hunt" ] }, { "id": "pocock-video-software-fundamentals", "title": "\"Software Fundamentals Matter More Than Ever\" — Matt Pocock", "publisher": "AI Engineer", "href": "https://www.youtube.com/watch?v=v4F1gFy-hqg", "publishedAt": "2026-04-23", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "A conference talk arguing that shared language, deliberate software design, deep modules, and fast test feedback become more important as coding agents increase implementation throughput.", "limitations": "This is an attributed practitioner argument illustrated with examples, not a controlled study showing that the proposed practices produce universal outcomes.", "authors": [ "Matt Pocock" ], "video": { "youtubeId": "v4F1gFy-hqg", "channel": "AI Engineer", "speakers": [ "Matt Pocock" ] } }, { "id": "pocock-video-skills-workflow", "title": "mattpocock/skills: A complete AI Coding workflow, end-to-end", "publisher": "Matt Pocock", "href": "https://www.youtube.com/watch?v=M6mYodf0dJM", "publishedAt": "2026-07-16", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "Demonstrates a skills-based coding workflow that develops shared domain context, writes a specification, decomposes work into tickets, implements it, and reviews against the specification and standards.", "limitations": "This is a first-party workflow demonstration rather than comparative evidence. A fresh-context model review is useful challenge but is not automatically an independently owned verifier.", "authors": [ "Matt Pocock" ], "video": { "youtubeId": "M6mYodf0dJM", "channel": "Matt Pocock", "speakers": [ "Matt Pocock" ] } }, { "id": "pocock-video-wayfinder", "title": "/wayfinder: Nothing is too big to plan anymore", "publisher": "Matt Pocock", "href": "https://www.youtube.com/watch?v=F3lL98Pj90o", "publishedAt": "2026-07-30", "reviewedAt": "2026-08-09", "kind": "video", "format": "video", "claimRole": "Practitioner perspective", "note": "Demonstrates planning a large body of work through an explicit destination, known dependencies, uncertainty, a current frontier, and decision tickets that can be resolved over time.", "limitations": "This is a first-party tool demonstration. Its planning vocabulary and context thresholds are setup-specific and do not constitute validation evidence for every project.", "authors": [ "Matt Pocock" ], "video": { "youtubeId": "F3lL98Pj90o", "channel": "Matt Pocock", "speakers": [ "Matt Pocock" ] } }, { "id": "pocock-ai-hero-course", "title": "Claude Code for Real Engineers", "publisher": "AI Hero", "href": "https://www.aihero.dev/cohorts/claude-code-for-real-engineers-2026-04", "publishedAt": "2026-03-30", "reviewedAt": "2026-08-09", "kind": "course", "format": "course", "claimRole": "Practitioner perspective", "note": "The official course page frames AI-assisted engineering around planning, decomposition, steering, feedback loops, tracer bullets, sandboxing, and maintaining navigable production codebases.", "limitations": "This is a commercial course description and first-party outcomes narrative, not independent evidence of learner or production results; examples focus on Claude Code.", "authors": [ "Matt Pocock" ] }, { "id": "pocock-skills-repo", "title": "Skills for Real Engineers", "publisher": "Matt Pocock", "href": "https://github.com/mattpocock/skills", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Practitioner perspective", "note": "An open repository of composable, user-invoked agent skills covering discovery, specifications, tickets, implementation, review, testing, debugging, teaching, and codebase design.", "limitations": "The repository documents one evolving workflow. Its MIT license covers repository materials, not separate videos, course branding, or an assurance claim for downstream use.", "authors": [ "Matt Pocock" ] }, { "id": "pocock-teach-skill", "title": "The /teach Skill", "publisher": "AI Hero", "href": "https://www.aihero.dev/skills-teach", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Practitioner perspective", "note": "Documents a stateful, source-led learning workflow organized around a learner mission, a persistent learning record, primary-source research, short lessons, retrieval practice, references, and a glossary.", "limitations": "The page describes an authored teaching workflow, not a validated curriculum standard; it also identifies gaps such as initial assessment, scheduled review, and explicit exit criteria.", "authors": [ "Matt Pocock" ] }, { "id": "github-spec-kit-docs", "title": "GitHub Spec Kit", "publisher": "GitHub", "href": "https://github.github.com/spec-kit/", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Documents an intent-driven workflow that turns a specification into a plan, tasks, and implementation artifacts while supporting multiple coding agents and replaceable process extensions.", "limitations": "This is official project documentation, not causal evidence that spec-driven development improves every project; its artifact flow is one configurable process model.", "authors": [ "GitHub" ] }, { "id": "anthropic-agentic-coding-expertise", "title": "Agentic coding and persistent returns to expertise", "publisher": "Anthropic", "href": "https://www.anthropic.com/research/claude-code-expertise", "publishedAt": "2026-06-16", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "Empirical evidence", "note": "Reports a privacy-preserving observational analysis of roughly 400,000 Claude Code sessions, including task composition, planning-versus-execution decisions, domain expertise, and operationalized success.", "limitations": "The analysis is observational and vendor-specific, so it does not establish causality or generalize automatically to other tools, teams, tasks, or definitions of success.", "authors": [ "Anthropic Economic Research" ] }, { "id": "ollama-local-only", "title": "Ollama FAQ", "publisher": "Ollama", "href": "https://docs.ollama.com/faq", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Documents local prompt handling, local-only mode, networking, storage, and runtime configuration for operating models through Ollama on user-controlled hardware.", "limitations": "Vendor documentation describes runtime behavior and configuration. Local execution alone does not secure the host, logs, network, tools, model license, or governance process.", "authors": [ "Ollama" ] }, { "id": "llama-cpp-local-inference", "title": "llama.cpp", "publisher": "ggml.org", "href": "https://github.com/ggml-org/llama.cpp", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "Documents a C and C++ runtime for large-model inference across a wide range of local and cloud hardware, including GGUF models, quantization support, and an API server.", "limitations": "This is implementation documentation for an inference runtime, not a complete agent, security boundary, governance system, or guarantee of model quality and performance.", "authors": [ "llama.cpp maintainers" ] }, { "id": "vllm-serving", "title": "OpenAI-Compatible Server", "publisher": "vLLM", "href": "https://docs.vllm.ai/en/latest/serving/online_serving/openai_compatible_server/", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Documents serving supported models through an HTTP API, including runtime arguments, model configuration, parallelism, request options, and deployment-oriented server behavior.", "limitations": "An inference server is not an identity, authorization, control, evaluation, or evidence layer. Defaults and compatibility vary by model, runtime version, and deployment.", "authors": [ "vLLM maintainers" ] }, { "id": "hf-fine-tuning", "title": "Fine-tuning", "publisher": "Hugging Face", "href": "https://huggingface.co/docs/transformers/en/training", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Defines fine-tuning as continued training of a pretrained model on a smaller task- or domain-specific dataset and provides an implementation path through Transformers.", "limitations": "The tutorial does not settle data rights, evaluation design, safety, governance, or deployment fitness; adaptation can introduce regressions and requires use-case testing.", "authors": [ "Hugging Face Transformers maintainers" ] }, { "id": "hf-peft-methods", "title": "Parameter efficient fine-tuning methods", "publisher": "Hugging Face", "href": "https://huggingface.co/docs/peft/main/methods/overview", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Catalogs parameter-efficient adaptation methods, including soft prompting, selective layer tuning, adapters, and Low-Rank Adaptation variants supported by the PEFT library.", "limitations": "Library documentation describes available methods, not equal quality across tasks or parity with full fine-tuning; the main-version page may also change ahead of stable releases.", "authors": [ "Hugging Face PEFT maintainers" ] }, { "id": "hf-quantization", "title": "Quantization overview", "publisher": "Hugging Face", "href": "https://huggingface.co/docs/transformers/quantization/overview", "publishedAt": "2026", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Official guidance", "note": "Surveys lower-precision model representations and the quantization methods integrated with Transformers for reducing model memory and supporting constrained inference environments.", "limitations": "Quality, memory, throughput, latency, kernel support, and hardware tradeoffs differ by model and method; target-workload evaluation remains necessary.", "authors": [ "Hugging Face Transformers maintainers" ] }, { "id": "openai-gpt-oss", "title": "Introducing gpt-oss", "publisher": "OpenAI", "href": "https://openai.com/index/introducing-gpt-oss/", "publishedAt": "2025-08-05", "reviewedAt": "2026-08-09", "kind": "engineering", "format": "engineering", "claimRole": "First-party case study", "note": "Introduces two Apache 2.0 open-weight reasoning models intended for customizable deployment, including consumer-hardware and local-inference scenarios.", "limitations": "This is a first-party launch description. Benchmark claims do not establish local workload fitness, privacy, safety, governance, or operational readiness for a specific deployment.", "authors": [ "OpenAI" ] }, { "id": "openai-gpt-oss-model-card", "title": "gpt-oss-120b & gpt-oss-20b Model Card", "publisher": "OpenAI", "href": "https://openai.com/index/gpt-oss-model-card/", "publishedAt": "2025-08-05", "reviewedAt": "2026-08-09", "kind": "research", "format": "research", "claimRole": "First-party case study", "note": "Documents the gpt-oss model family, release conditions, evaluations, safety analysis, capabilities, and limitations alongside downloadable model weights.", "limitations": "The model card is specific to two models and their release-time evaluations; it is not an enterprise acceptance decision or evidence for unrelated open-weight models.", "authors": [ "OpenAI" ] }, { "id": "ousterhout-software-design", "title": "A Philosophy of Software Design, Second Edition", "publisher": "Stanford University", "href": "https://web.stanford.edu/~ouster/cgi-bin/book.php", "publishedAt": "2021-07", "reviewedAt": "2026-08-09", "kind": "guidance", "format": "guidance", "claimRole": "Primary definition", "note": "The author’s official book page identifies deep, general-purpose modules and separation of important from unimportant information as central software-design concerns.", "limitations": "This is the author’s book page rather than empirical evidence that module depth improves every codebase; application remains contextual and requires engineering judgment.", "authors": [ "John Ousterhout" ] }, { "id": "lora-paper", "title": "LoRA: Low-Rank Adaptation of Large Language Models", "publisher": "arXiv / ICLR", "href": "https://arxiv.org/abs/2106.09685", "publishedAt": "2021-06-17", "reviewedAt": "2026-08-09", "kind": "paper", "format": "paper", "claimRole": "Primary definition", "note": "Introduces Low-Rank Adaptation, which freezes pretrained weights and injects trainable low-rank matrices to reduce the number of parameters updated for downstream adaptation.", "limitations": "The paper reports selected models, tasks, and hardware conditions; it does not establish that LoRA matches full fine-tuning or preserves safety for every workload.", "authors": [ "Edward Hu", "Yelong Shen", "Phillip Wallis", "Zeyuan Allen-Zhu", "Yuanzhi Li", "Shean Wang", "Lu Wang", "Weizhu Chen" ] } ] }