Knowledge base

The terms of agentic engineering, each in a few sentences.

Each term links to a page that covers it in depth.

A

Agent instructions (CLAUDE.md, AGENTS.md): Agent instructions are the files a coding agent reads at the start of every session in a repository, such as CLAUDE.md or AGENTS.md: build and test commands, conventions and the team's rules. AGENTS.md is an open format that many coding agents read, and Claude Code reads it when a project has no CLAUDE.md, so one file can serve a whole team. That file needs a single owner, because separate files per tool drift apart.
Agent loop: The agent loop is the cycle a coding agent runs: the model reasons, calls a tool, reads the result and repeats until a stop condition is met. The model keeps no state between calls, so the agent's reliability comes from that feedback and from keeping prompts, context and control flow in ordinary code.
Agent observability: Agent observability is the record of every agent run and every agent change: prompts, tool calls, tokens, durations, decisions and the identity behind each commit. Agent runs vary from one execution to the next, so without that record a team cannot debug a failure, audit what happened or learn from it.
Agentic continuous delivery: Agentic continuous delivery sends agent-written changes through the same delivery pipeline as human ones, to at least the same standard. A person owns the intent, the pipeline checks that the intent, the tests, the code and the architecture all agree, and no agent promotes its own change to production.
Agentic engineering: Agentic engineering is building software with coding agents while keeping to engineering rules. People define what done means, give the agent the context it needs and check the result with tests and gates, while the agent writes the code. It extends classical software engineering and replaces vibe coding wherever a team has to run and change what it builds.
Automation catalog: An automation catalog is the set of standing jobs that run around the coding agents in a software factory without anyone starting them, such as a pull-request reviewer, a post-merge verifier and an auditor that checks the other automations. Each job is defined in a file in the repository with its trigger, its work and what it may change, so a person can read what the factory does.

C

Context engineering: Context engineering is deciding what goes into an agent's context window, at what point, and into which window. Every token competes for the model's attention, so the main session stays small and research and other bulky work move into separate windows.
Context product: A context product is company knowledge or code packaged as a reusable asset for agents, with an owner, metadata and a stable interface. Documents are extracted, chunked, enriched and indexed, conversations become managed memory, and source code becomes a queryable knowledge graph built from its syntax tree.
Context window: The context window is everything a model sees in one session: system prompt, instruction files, tool definitions, files it has read and the conversation so far, counted in tokens up to a fixed limit. Quality drops well before that limit, and facts in the middle of a long context are recalled least reliably, so a smaller, well-ordered window usually beats a full one.
Cost to Serve Software (CTS-SW): Cost to Serve Software (CTS-SW) is Amazon's metric for the full cost of delivering one unit of software. Amazon reports that developer-experience work cut it by 15.9 percent year over year in 2024, alongside 18.3 percent more weekly production deployments per builder.
Creator-verifier: Creator-verifier splits agent work into two roles: one agent produces the change, and a second agent with its own context judges it. An agent grading its own work tends to approve it, so the verifier checks against criteria fixed before the code was written and looks at what the change actually does.

D

Dark factory: A dark factory is a software factory that runs without a person approving each step: agents write, test, deploy and maintain the code within rules and quality limits that people set up beforehand.
Disciplined compounding loop: The disciplined compounding loop puts every agent task through the same cycle: plan, build test-first, check, then a short retrospective whose lessons are written back into the repository. Each finished change leaves the next run better equipped, so changes get cheaper over time.
Dynamic-robust organization: A dynamic-robust organization handles known work through plans and rules, and meets unknown work with strategy within clear principles, temporary teams and local judgment. Its leaders switch between the two modes as the problem changes, instead of forcing every task through one process.

E

Enabling environment: The enabling environment is the runtime, platform and repository an agent works in. It limits a software factory more than the model does: an agent that cannot start the app, reach real services and run the full test suite produces code that looks right and was never verified.
Evals for non-deterministic systems: Evals for non-deterministic systems measure a system that can answer the same input differently each time, so a single passing or failing run proves nothing. The deterministic parts get ordinary unit tests; the rest runs many times, and its pass-rate distribution is compared with a recorded baseline. Each run is graded on the path the agent took, its steps and tool calls, as well as on its final answer.

F

Federated context platform: A federated context platform gives enterprise agents governed context that the business domains own, without pulling every source into one central store. Domains publish their context as products, a shared gateway and catalog make those products easy to find and safe to use, and every kind of retrieval uses the store that suits it.

H

Harness engineering: Harness engineering is building the system a coding model runs in: its environment, rules, deterministic gates, feedback loops and validation. A harness covers exactly what the model cannot yet do reliably on its own, and it is what turns a fleet of agents into a software factory.
Hooks: Hooks are commands the agent harness runs automatically at fixed points in a session, such as before or after a tool call, when a prompt arrives or when the agent stops. Instruction files are advice the model can ignore; a hook always fires. It can block a dangerous command, run the type checker after every edit or log each tool call.
Human accountability: Human accountability means a named person, not the agent, decides what ships and answers for it. Agents can investigate, implement and test. Judging whether the evidence is enough, accepting the risk and owning the consequences stay with that person.

J

Just-in-time retrieval: Just-in-time retrieval means the agent keeps lightweight pointers, such as file paths and search queries, and loads the actual data through tools only when a step needs it. For coding agents it is the default that works, because precomputed embedding indexes go stale and miss queries that trace through a codebase.

M

MCP (Model Context Protocol): MCP (Model Context Protocol) is an open protocol that lets an agent reach tools, resources and prompts through one standard interface instead of a custom connector for every pairing. Its main cost is context: most clients load every tool schema up front, which fills the window and makes tool selection worse.

P

Prompt engineering: Prompt engineering is writing the instructions a model or agent works from. Agentic prompts work best when structured like a small program, with a purpose, inputs, numbered steps and a defined report, plus concrete examples and the reason behind each rule. It is one part of agentic engineering; context engineering covers everything else the model sees.

Q

Quality gates: Quality gates are automated checks a change must pass before it moves on: build, type check, linter, tests, security scan, coverage threshold. Each applies a fixed rule and returns pass or fail. Gates run on an event such as a commit or a push, not when the agent decides to run them.

R

Research, Plan, Implement (RPI): Research, Plan, Implement (RPI) splits a coding task into three separate steps, each in a fresh context window: research how the system works and condense the findings, write a concrete plan, then implement from the plan. People review early, on the short research and alignment notes, where a wrong assumption is cheapest to fix, and again on the finished code.

S

Skill: A skill is a folder of instructions, scripts and reference files that an agent loads only when a task calls for it. Until then only its name and description sit in the context window, so a skill adds a capability at almost no context cost.
Software Factory: A Software Factory is the delivery system that carries a team's intent all the way to released software the team can trust. It spans the specifications, the context agents work from, the environments they run in, the checks every change must pass, the rules on who may approve and act, and the feedback that improves the next run. People build and tune the system instead of writing the product. How much it releases is limited by the quality of its specifications, its verification capacity and its inference cost, not by how fast agents write code.
Spec-driven development: Spec-driven development makes a written specification the source of truth for agent work: a Markdown file in the repository, reviewed like code, that states the change, its constraints and its acceptance tests before any code exists. Every later step reads that file, and corrections go into the spec rather than into a patch in chat. The acceptance tests come from the spec, and the agent implementing the change neither writes nor edits them. Where code or tests drift from the spec, the spec's owner decides which side changes and records the decision.
Subagent: A subagent is a separate agent instance that a main agent hands a task to, with its own context window, instructions and tool permissions. It does the searching and reading in that window and returns a short summary, so the main session stays small. Subagents exist to split context, not to play roles such as frontend or QA.

T

Thin harness: A thin harness keeps the agent loop small and leaves planning and adaptation to the model. Claude Code is built this way: specialized capabilities live in plugins, MCP servers, SDKs and language servers, and with each model release the core drops scaffolding and absorbs the extensions that worked.

V

Verification literacy: Verification literacy is the skill of checking code a model inferred rather than compiled: knowing where models invent plausible details, testing what matters, and scaling review capacity with the volume of generated code so review never becomes a formality.
Versioned context: Versioned context treats skills, rules and instruction files as artifacts with a software lifecycle, which a team needs once it has many of them rather than a single prompt. They are generated, tested with evals, distributed through registries and revised like code.
Vibe coding: Vibe coding is prompting a model until something runs, with no plan, no definition of done and no automated checks. It works for prototypes, experiments and one-off scripts, and breaks down on software a team has to run, change and answer for, which is where agentic engineering replaces it.