AI coding agent terms product managers need to know

Four terms carry the decisions, and the rest are recognition

Most agent glossaries are flat lists that treat a context window and a vector store as equally worth your evening. They are not. Four concepts map directly onto choices a product manager already owns: how much the system can see at once, what it is permitted to touch, what stops it before it does damage, and how anyone finds out it was wrong. Everything else on this page is vocabulary you should recognise in a conversation with an engineer and should not spend a weekend on.

That is the sorting rule. What follows is organised by which layer of the machinery each term belongs to, with a link out to the full definition rather than a restatement of it.

Layer one: what the agent can see

This layer decides how much of your system the agent is reasoning about, and it is where most confusing behaviour originates. An agent that gives a strange answer is usually working from a partial view rather than reasoning badly.

Term	One line	Why it matters to you
Context window	The total amount of text a model can hold in one session	Sets the practical size of a task before quality degrades
Context architecture	How you deliberately structure what goes into that window	The difference between a reusable setup and starting from scratch daily
System prompt	Standing instructions applied before your request	Where a team's rules live, if anyone has written them down
Agent memory	What persists across sessions rather than resetting	Decides whether the agent relearns your project every morning

Claude Code's own documentation makes this layer concrete. A CLAUDE.md file in a project root is read at the start of every session and holds coding standards, architecture decisions and review checklists, and the tool also builds automatic memory as it works, carrying learnings between sessions without anyone writing them down. For a PM, that file is the closest thing to a place where a policy can be stated once and applied every time.

Layer two: what the agent can actually do

An agent is separated from a chat window by this layer, and it is the layer that turns a suggestion into an action with consequences.

Term	One line	Why it matters to you
Tool use	The model calling an external function instead of just answering	The moment output becomes action, and needs a permission model
Agentic workflow	A goal broken into steps the agent plans and executes	What you are scoping when you delegate a task rather than a question
Agent skill	A packaged, repeatable workflow the team can share	Turns one person's good setup into a team standard
Multi-agent orchestration	Several agents working parts of one task in parallel	Adds speed and a merge step, which is where coordination bugs live
Parallel worktrees	Separate working copies so agents do not collide	The mechanism that makes parallel work safe rather than chaotic
Prompt chaining	Feeding one step's output into the next as a pipeline	The simplest structure that beats one giant prompt

The connector layer sitting under all of this is the Model Context Protocol, an open standard for wiring an agent to outside systems so it can reach a document store, an issue tracker or a chat workspace without a bespoke integration for each one. Building an AI assistant with MCP covers what that means in practice. You do not need to build one; you need to know that the reach of any agent workflow you scope is bounded by what has been connected.

Layer three: what stops it

This is the layer PMs under-invest in, and it is where the Builders Camp curriculum spends the most time. AI Agents teaches safety as its own module: approvals, constraints and monitoring on high-stakes actions, with autonomy treated as a dial rather than a switch. The vocabulary is small and the decisions behind it are not.

Term	One line	Why it matters to you
AI guardrails	Rules constraining what a system may produce or do	The cheapest place to encode a policy you cannot afford to break
Human in the loop	A required human approval before an action proceeds	The control that converts an unbounded failure into a caught one
Automation hooks	Commands that run automatically before or after an agent action	Enforcement that does not depend on anyone remembering
Quality gate	A check output has to pass before moving on	Where an acceptance criterion becomes mechanical instead of hopeful

Building with Claude Code teaches this as a build target rather than a concept: hooks, CI/CD-style automation and quality gates configured so the pipeline itself refuses bad output. It runs 1 week, 6 hours total, 4 of them taught across 2 live sessions of 120 minutes, and sits inside the AI Agentic Builders Expert Track.

Layer four: how you know it worked

Three terms, and the first one is the term most worth learning properly.

• Evaluation, usually shortened to evals, is a repeatable test of whether output meets a standard. Builders Camp's AI Product Management material treats evals as the replacement for acceptance criteria and the launch gate, which is a stronger claim than most teams act on. How to write evals for AI products covers the mechanics.
• Hallucination is confidently stated output with no basis in the source material, and the reason agent review cannot be done by skim.
• Structured output is constraining a model to a fixed shape, such as JSON, which is what makes output checkable by a program rather than by a person.

Which terms are engineering trivia for a product manager?

Vector stores, embeddings, chunking strategies and retrieval tuning. These describe how a system finds relevant text before answering, and they are real engineering decisions that will not change a single call you make. If you are shipping a retrieval feature, RAG for product managers is the level of detail you need and no more.

The honest caveat is that this boundary moves. Two years ago, context window size was an implementation detail and is now a scoping constraint you feel weekly. Treat the sorting above as current rather than permanent, and revisit it when a term you filed under trivia starts appearing in arguments about scope.

Who this is for, and who it is not for

This fits a product manager working with engineers who have already adopted agents, and who wants to follow the conversation and push back in it rather than nod along. It assumes you know what a repository and a pull request are, and it does not assume you write code.

It is not a substitute for the individual definitions. Each term above links to a full entry, and this page exists to tell you which of them to read first, not to replace any of them.

Learn the layer that decides the outcome

The vocabulary is easy. The build is the part that transfers, and it sits in layers one and three: structuring context so the agent starts from the right picture, then wiring the checks that stop it when it does not. Building with Claude Code covers exactly those, from context files and reusable skills through MCP integrations to multi-agent orchestration and quality gates, taught by Guilherme Salgueiro across 9 self-paced microlessons alongside the live sessions.

See the Building with Claude Code bootcamp

For the design decisions behind an agent rather than the words for them, see how to design an AI agent. For the practice all of this vocabulary supports, see what vibe coding means, and for the spec format that replaces a PRD in an agent workflow, see the product requirement prompt.