Glossary

Everything the model can see at once, its working memory.

The context window is the maximum amount of text an LLM can process in a single request: the system prompt, conversation history, tool results, and any injected documents. Information outside the window is invisible to the model; there is no background retention between requests.

A neural network trained on vast text that predicts and generates language.

LLMs don't store facts like a database; they compress statistical patterns from training data into billions of numerical weights. At inference time they generate text token by token based on probability. The 'large' refers to parameter count, which correlates loosely with capability. Claude, GPT and Gemini are all LLMs.

Crafting inputs to reliably steer model behaviour.

Prompt engineering designs instructions, examples, and constraints that make LLM outputs more accurate, consistent, and useful. Techniques include chain-of-thought prompting, few-shot examples, and role framing. Careful prompt design remains a key lever for complex workflows even as models improve.

A per-call setting on reasoning models that trades latency for deliberation.

Raising effort makes a reasoning model spend more time deliberating before it answers, at the cost of latency; lowering it answers faster but with less deliberation. It's a per-call knob, not a global default - raise it for genuinely hard steps and leave it low elsewhere.

A model response constrained to a fixed schema instead of free text.

Structured output removes a class of parsing failures by having the model return exactly the shape a schema declares - useful for classification, extraction, or any step where the result needs to be consumed as data rather than read as prose. Because the task is narrow and well-specified, it's often a good fit for a cheaper model than the one handling open-ended reasoning elsewhere in the same agent.

The unit an LLM reads and writes, roughly three-quarters of a word.

LLMs don't process characters or words directly; they work with tokens, chunks of text defined by a vocabulary of tens of thousands of entries. Tokens matter because they determine cost, speed, and context window limits. A million tokens is roughly 750,000 words, about ten novels.

A structured, semantic view of a page's interactive elements that assistive tools and browser agents read instead of raw pixels.

A browser agent that reads the accessibility tree can identify buttons, fields, and links by role and label rather than by visual position, the same information screen readers rely on. Pages with poor semantic markup degrade for both a screen reader user and a browser agent at once.

A specification for advertising where a site's agent-facing discovery document lives.

ARD defines an Agentmap directive in robots.txt, an HTML link tag, and a DNS service binding as the ways to point at a discovery document, published at /.well-known/ard.json. It keeps the predecessor AI Catalog path as an optional fallback, but a consumer only needs to check that fallback if it also targets the older format.

A cross-tool baseline file that tells a coding agent how to work in a repository.

AGENTS.md documents a project's conventions, commands, and boundaries in one place that most coding agents read by default. Tool-specific files such as CLAUDE.md or Cursor rules can layer overlays on top of it, but AGENTS.md is the file most repositories need and nothing else.

An earlier, separate specification for advertising a site's agent discovery document at /.well-known/ai-catalog.json.

AI Catalog predates ARD and uses its own path and link relation. ARD's current specification keeps this path as an optional fallback a consumer may additionally consult, so publish it only if you also want to support AI Catalog-native consumers directly.

Making content easier for answer engines to find, interpret, and cite.

Answer engine optimization concerns how search and AI answer systems retrieve and describe content: crawlable pages, clear facts, structured data, trustworthy sources. Agent readiness is broader; an agent may also need to sign in, perform actions, recover from errors, or pay, and visibility alone does not establish that those tasks work.

Machine-readable signals showing when content was published or last verified.

A visible last-updated date is not machine-readable on its own; an agent needs a structured date field or header it can parse to decide whether to trust or re-fetch a page. This is distinct from page-level freshness signals such as HTTP caching headers, which describe delivery, not editorial accuracy.

Letting a client request a particular representation of the same resource.

For example, a browser may request HTML while an agent requests Markdown through an HTTP Accept header. The server chooses a supported format and labels the response. Caches must distinguish these formats so a person does not unexpectedly receive raw Markdown.

Machine-readable attribution showing where a piece of content came from and who is accountable for it.

Provenance data lets an agent cite a source and a reader trace a claim back to its origin, which matters most for content that will be quoted or acted on. It is usually expressed alongside freshness data so an agent can judge both how current and how trustworthy a source is.

Declarations of whether content may be used for search, AI input, or training.

Crawler rules describe access to a page. Content Signals separately express permitted uses after retrieval through search, ai-input, and ai-train values. They communicate policy to systems that honour it; they do not enforce access controls or guarantee compliance.

A file that tells cooperating crawlers which URLs they may fetch.

Different rules can apply to search crawlers, training crawlers, and other automated visitors. robots.txt is a voluntary crawling convention, not access control: private information still needs authentication. Firewall rules can also block agents even when robots.txt allows them.

An emerging way to advertise agent services through a domain's DNS records.

DNS normally helps software locate servers. DNS-AID proposes records that also advertise agent services and their connection details, so a compatible client can discover services from a known domain. It remains an individual Internet-Draft, and publishing records does not grant access or prove the service works.

Anchoring LLM outputs to verified, up-to-date source material.

An ungrounded LLM reasons from its training weights, which may be stale, biased, or simply wrong for a given domain. Grounding connects model outputs to external truth sources: a product database, a live API, a document store. RAG is the most common grounding technique, and it is why agents with tool access are more reliable than standalone models for factual tasks; they can verify claims against live data rather than recalling from memory.

Structured labels that describe what the information on a web page means.

A page can use JSON-LD and a shared vocabulary such as Schema.org to identify a product, its brand, its price, and the relationships between them. These labels help software interpret the page. They should match the visible facts and never invent ratings or reviews.

A Markdown index that points agents to a site's important documentation.

A site can publish llms.txt at its root with a short introduction and links to relevant pages. It helps clients that read this convention find focused documentation. It does not set crawler permissions or guarantee search rankings, citations, or adoption by every agent.

A plain-text format for headings, links, lists, and other document structure.

Markdown keeps a document readable without most of a website's interface markup. A Markdown version can help an agent retrieve focused content, provided it preserves the original facts, links, and source information.

A server-side protocol for exposing structured content through natural-language query endpoints.

NLWeb's reference implementation answers natural-language queries with structured results and source URLs, as a server-side retrieval surface. It serves a different execution context to WebMCP, which exposes tools inside a browser page rather than through a server endpoint.

A ratified standard for attaching machine-readable licence terms, including price, to content.

RSL lets a publisher state pay-per-crawl, subscription, pay-per-inference, attribution, or free-use terms via robots.txt, an HTTP header, an HTML tag, an RSS feed, or a media file. Reach for RSL when Content Signals' plain yes/no preference isn't enough and you need to state a price or a specific licence condition.

A standard URL path prefix reserved for machine-readable metadata about a site.

RFC 8615 reserves /.well-known/ so unrelated discovery documents, such as an API catalog, OAuth metadata, or an agent card, can live at predictable, non-colliding locations without a site inventing its own convention. Most agent discovery mechanisms in this guide publish under it.

An XML file listing a site's URLs so crawlers can discover pages without following every link.

A sitemap describes every URL a publisher wants crawled, unlike llms.txt, which curates only the most important pages for an agent's limited context. The two serve different consumers and are not substitutes for each other.

A defined way for software to request data or perform an action in another system.

An API describes the operations available, the inputs each accepts, and the results or errors it returns. For example, a shop might offer operations to search products, prepare a cart, and check an order. Clear documentation and consistent responses help agents use those operations correctly.

An OpenAPI Initiative specification for describing multi-step API workflows.

Where OpenAPI describes individual operations, Arazzo sequences several of them into a workflow, with control flow and data passed between steps. It complements MCP by giving a tool-building layer a machine-readable description of a multi-call process, rather than requiring an agent to infer the sequence from separate operation docs.

A way to operate software by entering commands in a terminal.

Coding agents can use a CLI in scripts and automated workflows. Explicit arguments, structured output, meaningful exit codes, and a way to run without interactive prompts make commands easier to use reliably.

HTTP messages a service sends when a subscribed event occurs.

For example, an order service can notify a client when a shipment leaves the warehouse. Receivers should verify the sender, handle duplicate deliveries, and recover from missed events. A webhook reports an event; the current record remains the source for its latest state.

Pipelines that move and reshape data from sources to destinations.

ETL extracts data from source systems, transforms it to fit the target schema, then loads it. ELT loads raw data first and transforms later, the more common approach once warehouse compute became cheap. These pipelines feed training sets, populate vector databases, and keep knowledge graphs and RAG systems fresh; a poorly designed pipeline means an AI application reasons over stale or inconsistent data.

An API query language that lets callers choose which fields they receive.

A typed schema describes the data and operations available. Queries read data; mutations can change it. Agents need field descriptions, pagination rules, and clear errors to use the schema. A successful HTTP response can still contain GraphQL errors.

A machine-readable description of an HTTP API.

It lists operations, inputs, responses, authentication requirements, and errors. Agents and developer tools can use it to construct requests. The specification must describe the API that actually runs; publishing a file alone does not make the operations work.

Returning a large collection in smaller portions with a way to request the next portion.

A response includes a cursor or another continuation mechanism. Predictable ordering and stable item identifiers help agents work through results without omissions or duplicates, especially when the collection changes between requests.

Central systems of record for product data and enterprise entity definitions.

A PIM (Product Information Manager) is the canonical source for product attributes: names, descriptions, specs, images, pricing, certifications. MDM extends this to any master entity, such as customers, suppliers, and locations. An agent browsing a catalog is only as good as the data it retrieves, so structured attributes and standardised taxonomies matter more than long unstructured descriptions.

A well-known endpoint that inventories an organisation's APIs through linksets.

Published at /.well-known/api-catalog, the RFC 9727 API Catalog lists an organisation's APIs so agents and tooling can discover them in one place. It does not replace an OpenAPI document for any single API, and does not turn an HTML developer page into a machine-readable contract; each listed API still needs its own accurate description.

The structure, vocabulary, and hierarchy that give data meaning.

A schema defines the shape of data: fields, types, constraints. A taxonomy organises concepts into a hierarchy. An ontology goes further and defines relationships between concepts. Structured, well-defined data is dramatically easier for a model to reason over than free text; Schema.org provides shared vocabularies for web content, and JSON-LD embeds them in HTML.

Libraries and supporting tools for integrating a service into an application.

An SDK can provide typed functions, authentication helpers, and examples around an API. It saves developers and coding agents from rebuilding common integration code. Its supported API versions and maintenance status should be clear.

A published walkthrough of how an agent can register for a service.

The auth.md protocol connects readable setup instructions with metadata describing accepted identity methods and endpoints. An agent can discover how to register, obtain access, and involve the user when an account needs claiming. Advertised flows must exist and enforce normal authorization checks.

A token that grants access to whoever presents it, with no proof that the presenter is the party it was issued to.

A bearer token is the simplest OAuth access token shape, and the easiest to misuse: anyone who obtains it, by theft or leak, can use it exactly as the legitimate holder could. DPoP exists specifically to close this gap for tokens that protect sensitive resources.

An OAuth client registration mechanism where a client's identity is a URL pointing to a metadata document, rather than a pre-registered ID.

A Client ID Metadata Document lets a client and authorization server work together without a prior relationship, since the client ID itself resolves to the client's registered details. It is the OAuth working group's recommended replacement for dynamic client registration, which is deprecated in the current MCP specification.

A self-sovereign identifier that resolves to keys and endpoints without a central registry.

A DID lets an agent prove who it is and establish an encrypted channel by resolving the identifier itself, rather than looking it up in a company-run directory. It underpins draft peer-to-peer agent protocols such as ANP, which use DID-based identity in place of a shared platform account.

A way to give an application limited access without sharing a user's password.

A customer can approve access to selected capabilities, such as reading orders. The client then uses an access token when calling the API. The service must enforce the granted permissions, expiry, and account boundaries. OAuth grants access; it is not by itself a complete user identity protocol.

A mechanism that binds an access token to the client holding a private key, so a stolen token alone is not enough to use it.

The client signs a proof for each request with a key it holds; the server validates the proof against the token before accepting it. This stops a leaked bearer token from being replayed by an attacker who does not hold the matching key. DPoP is independent of MCP but is the concrete piece of the emerging agent workload-identity work that is ready to implement today.

A way for an OAuth client to register itself with a server automatically.

Rather than a developer manually registering an application in a dashboard, Dynamic Client Registration lets a client register itself with the authorization server at connection time and receive credentials programmatically. It matters for MCP clients, which often connect to servers they have not been registered with in advance.

A signed identity assertion used to request access from another service.

A trusted issuer describes an identity in an audience-bound JWT. The receiving service verifies the assertion and decides what access may follow. In auth.md, the provider assertion goes to the identity endpoint; registration and the later token exchange are separate steps.

A server-side component that authenticates users and issues its own tokens to downstream MCP tools.

Instead of every tool implementing OAuth directly, an identity proxy sits in front of them, handles the authorization flow once, and forwards a token or session the tools trust. It centralizes auth logic at the cost of adding a component every request has to pass through.

A published set of public keys a service uses to verify signed tokens.

A JWKS endpoint lets a relying party fetch the current signing keys for an issuer rather than hardcoding them, so keys can rotate without breaking verification. Protected Resource Metadata and agent identity documents typically point to a JWKS URL alongside the issuer.

A signed, compact token format used to carry claims such as identity and permissions between parties.

A JWT has a header, a payload of claims, and a signature, and a receiving service validates the signature and checks claims such as issuer, audience, and expiry before trusting it. Agents encounter JWTs as OAuth access tokens, identity assertions, and delegation grants; validating them correctly, not just decoding them, is what prevents a forged or stale token being accepted.

An OAuth flow for a service acting as itself, with no human present to approve access.

The Client Credentials grant is the standard M2M flow: a service authenticates directly with its own credentials and receives a token scoped to its own permissions. It is distinct from user-delegated flows such as Authorization Code with PKCE, which exist because a human is present to consent.

A token exchange pattern where a service acts for a specific user rather than as itself.

An on-behalf-of token carries both the calling service's identity and the user it is acting for, so a downstream API can enforce the user's permissions rather than the service's broader ones. It is the shape token exchange takes when a human, not another agent, is the party being delegated for.

An identity layer built on top of OAuth that adds a standard way to authenticate a user, not just authorize access.

Where OAuth grants scoped access to resources, OIDC adds an ID token that asserts who the user is. Agent systems that need to know which human is behind a request, rather than only what that request is allowed to do, layer OIDC on top of the OAuth flow they already use.

Named permissions that define what an access token is allowed to do.

A token might allow reading orders while forbidding refunds. The server must check those permissions on every protected operation and ensure the caller can access the requested account or record. A scope written in documentation provides no protection unless it is enforced.

A safeguard that binds an OAuth authorization request to its code exchange.

PKCE prevents authorization-code interception attacks by requiring the client to prove it holds a secret generated at the start of the flow when it later exchanges the code for a token. It is mandatory in OAuth 2.1, even for confidential clients, and is the standard choice for user-delegated MCP access alongside the Authorization Code grant.

An OAuth metadata document that tells a client which authorization server, scopes, and rules apply to a protected API.

Protected Resource Metadata (RFC 9728) is published at a well-known location so an agent can discover how to get a token before calling an API, rather than being told out of band. MCP servers use it as the standard way to point clients at their authorization server.

Defences that stop a captured request from being resubmitted and accepted a second time.

A DPoP proof carries a unique identifier (a JTI) and a timestamp that a server checks against ones it has already seen, so a copied request fails even if the underlying token is still valid. Combined with idempotency keys, replay protection covers both a malicious resubmission and an accidental client retry.

An OAuth extension that lets a service trade one token for another with a narrower or different scope.

Token exchange (RFC 8693) is how a sub-agent gets a scoped-down token for a delegated task, or how a service acts on behalf of a user without holding the user's original credential. The exchanged token can carry an actor chain, so a downstream service can see both the original caller and the service acting on its behalf.

Signed HTTP requests that help a website verify which bot sent them.

The sender signs a request and publishes verification keys. The receiving service checks the signature and applies its own access rules. Verifying a bot's identity does not give it permission to read a customer's private data or spend their money.

A credential that proves what an agent is running as, distinct from the human who authorized it.

Web Bot Auth and OAuth answer who sent a request or who authorized it; workload identity answers what process is making the call and how it proves that to another service. This is still a forming line of standards work built on the ID-JAG grant, and is not yet ready to build against.

An IETF working group defining how workloads prove their identity to each other within a trust domain.

WIMSE covers how a process obtains and presents identity credentials, such as X.509 certificates or JWTs, to authenticate to other services. A related, separate draft applies these ideas specifically to AI agents, but it remains an individual submission with no working-group standing.

A draft protocol for peer-to-peer agent identity and communication using decentralized identifiers.

ANP proposes self-sovereign agent identity via DIDs and end-to-end encrypted, agent-to-agent messaging without a shared platform. It remains a draft and is one to watch rather than depend on.

Installable packages of related agent tools, skills, and connections.

A plugin bundles capabilities for a particular agent platform and describes how to install and configure them. Platform formats differ, so a working package in one host does not guarantee compatibility with another.

Instructions and supporting files that teach an agent how to perform a task.

A skill explains when to use it, the steps to follow, and any tools or reference material needed. It can package a team's working practices for compatible coding agents. Instructions do not grant credentials or override the permissions enforced by the host or service.

A JSON document an A2A agent publishes at a well-known URL describing its identity and capabilities.

Before delegating a task, a peer agent fetches the target's AgentCard to learn its capabilities, authentication requirements, and endpoint, the way an OpenAPI document describes a conventional API. It is A2A's discovery mechanism and works across organizational boundaries without pre-shared secrets.

The Linux Foundation body that now governs MCP, A2A, and related agent protocols.

MCP and A2A were both donated by their original vendors to the Linux Foundation and now sit under the AAIF alongside sibling projects, rather than under any single company. That shifts stewardship to a vendor-neutral steering process, though it does not by itself change either protocol's technical content.

A Linux Foundation project building shared cross-organization infrastructure for agent discovery, identity, messaging, and observability.

Donated by Cisco in 2025 and backed by Cisco, Dell, Google Cloud, Oracle, and Red Hat among others, AGNTCY's discovery component is OASF. It is infrastructure to watch rather than a finished, stable dependency to build on today.

An LLM in a loop: it perceives, reasons, acts, and observes consequences.

An AI agent is not just a chatbot; it is a system where an LLM decides what actions to take, observes the results, and iterates until a goal is reached. The key elements are a model (the reasoner), tools (the hands), memory (context), and an orchestrator (the loop). Reliability drops as loop length grows, so short, bounded tasks are where agents perform most reliably today.

The part of a protocol handshake where a client and server each state which optional features they support.

MCP clients and servers declare capabilities such as sampling, resource subscriptions, or elicitation during initialization, so neither side calls a feature the other doesn't implement. Getting this declaration right avoids silent failures where a client assumes support that was never advertised.

Having an agent write and run code against a set of APIs, instead of calling each API through a separate tool call.

Rather than making a tool call per operation, the agent writes a short program that chains several calls together and runs it in a sandbox, returning only the final result. It cuts the token and round-trip cost of a long tool-calling sequence, at the cost of needing a code execution environment the agent can trust.

An orchestration pattern where several agents independently answer the same question and a result is chosen from among them.

Running the same task through multiple agents, or the same agent multiple times, and comparing or voting on the outputs trades extra cost for higher confidence on a single answer. It suits high-stakes decisions where the cost of the extra calls is justified by the cost of getting the decision wrong.

Layering independent security checks so a single failure doesn't fully compromise a system.

For an MCP server this means input validation, scope checks, and output filtering each stand on their own, so a bug in one layer doesn't leave the server fully exposed. It's a design discipline rather than a specific mechanism, applied wherever a single point of enforcement would be a single point of failure.

A way to preview what a tool call would do without actually doing it.

A dry-run flag returns the effect a mutating call would have, such as the order it would create, without committing it, letting an agent or a human confirm intent before a destructive action runs for real. It's a cheaper safety mechanism than full undo support for actions that are expensive or impossible to reverse.

An agent whose tool set, memory recall depth, and model choice are resolved from runtime context instead of hard-coded per segment.

Resolving configuration - not just prompt text - from context such as user role or plan tier at request time avoids maintaining a separate near-duplicate agent per segment, which tends to drift as each copy is patched independently. The trade-off is predictability: a statically configured agent behaves the same for everyone, which is easier to test and explain, while a dynamically configured one can behave differently for two users on the same request.

Exposing only the tools relevant to the current task instead of an agent's full tool set at all times.

Loading tools on demand keeps the token cost of tool definitions down and reduces the chance an agent picks the wrong tool from a long, mostly-irrelevant list. It trades a small amount of orchestration complexity, deciding which tools to load when, for a smaller and more relevant working set.

An orchestration pattern that runs several agents concurrently, then combines their results.

Fan-out dispatches the same or related work to multiple agents in parallel; fan-in waits for and merges what comes back. It suits tasks that decompose into independent pieces, such as researching several sources at once, where a sequential loop would just add latency without adding correctness.

An orchestration pattern where one agent transfers a task to another better suited to handle it.

A handoff passes control and context to a different agent, rather than the first agent staying in the loop and delegating a sub-task. It suits systems with clearly separable specialisms, such as routing a billing question away from a general support agent.

Interactive interfaces displayed alongside tool results in a compatible MCP client.

An MCP App can show a chart, selection interface, or editable result inside a conversation. The host controls how the view loads and what it can access. A service must test host compatibility, accessibility, and security boundaries as well as its tool responses.

The formal change-proposal process the MCP steering group uses to evolve the specification.

Each significant change to MCP, such as removing protocol-level sessions or adding MCP Apps, ships as a numbered SEP that the community can reference. Citing a SEP number pins a claim to a specific, reviewable change rather than a vague description of new behaviour.

Metadata hints on an MCP tool describing whether it reads, writes, or has other side effects.

The four standard hints (read-only, destructive, idempotent, open-world) tell a client and a human reviewer what a tool call might do before it runs, so an agent can gate risky calls behind approval. Annotations are hints, not enforced contracts, and clients should default to the worst case when a tool omits them.

Letting a user redirect or correct an agent while it's still working, rather than only before or after a run.

Without mid-run steering, a user who spots a mistake has to wait for the run to finish, or kill it and start over, losing whatever the agent had already done correctly. Supporting it well means the agent can accept new input mid-loop without losing track of the state it had already built up.

An open protocol for connecting agent clients to tools, data, and reusable prompts.

An MCP server describes the capabilities it offers so a compatible client can discover and call them. Servers can run locally or be reached over HTTP. Support varies by client and protocol version, so authentication, tools, and results still need testing in the clients customers use.

Sending different steps of an agent loop to different models based on cost, speed, or capability needs.

A cheap, fast model can handle simple classification or extraction steps while a stronger model is reserved for the steps that need real reasoning, cutting cost without lowering quality where it matters. This is a routing decision made by the orchestrator, not a property of any single model call.

A normalized schema for describing agent and tool capabilities, aimed at package-registry-style discovery.

OASF is AGNTCY's discovery component: it standardizes how an agent or tool describes what it does, so a consumer can search by capability rather than by publisher. The schemas have not converged on a stable version and the surrounding registry tooling is still nascent.

Coordinating model calls, tools, and workflow steps to complete a task.

An orchestrator decides what runs next, carries state between steps, and handles retries, limits, and handoffs. It can support one agent or several. A fixed workflow suits predictable steps; an agent can make decisions where the next step depends on the result. More agents are useful only when their separate responsibilities justify the added coordination.

A separate agent invoked by a parent agent to handle a bounded piece of a larger task.

A subagent runs with its own context and tools, then returns a result to the parent rather than sharing the parent's full conversation history. UIs that surface agent activity need to show subagent work distinctly, since collapsing it into the parent's stream hides which agent actually did what.

An orchestration pattern where one agent plans and delegates work to others but doesn't do the work itself.

A supervisor agent breaks a task into pieces, assigns them to worker agents, and assembles the results, staying in control of sequencing throughout. It differs from a handoff in that the supervisor keeps the task rather than transferring it away.

An orchestration pattern where agents hand tasks directly to each other with no central supervisor.

Instead of a supervisor routing work, agents in a swarm pass a task peer-to-peer based on which one is best placed to continue it. It removes the supervisor as a bottleneck but makes the overall flow harder to trace, since there's no single place that shows the whole plan.

Structured mechanism for an LLM to invoke external actions and return results.

An LLM cannot directly query a database or call an API, but it can emit a structured request to call a named function with given arguments. The host application executes the actual call, returns the result, and the model incorporates it into its response. This is what turns a text generator into an agent that can take real-world actions.

Deliberately managing which tools an agent has access to, rather than exposing every available tool by default.

A large, uncurated tool set slows an agent's tool selection and raises the chance of picking the wrong one; role-based tool kits and read-only versus mutating splits are two common ways to curate. Tool curation is an ongoing discipline, not a one-time setup, since sprawl returns as integrations are added.

A proposed browser interface that lets a page offer tools to visiting agents.

A compatible browser can discover named actions in the current page and call them with defined inputs. The tools operate in the page's context. Browser support is still evolving; this is distinct from running a remote MCP server and should complement accessible controls.

A classic keyword-ranking algorithm that scores documents by term frequency, balanced against document length.

BM25 predates embeddings and still outperforms vector search on exact-term queries, such as a product code or an error string, where meaning-based similarity isn't the point. Retrieval systems increasingly combine BM25 with embeddings so exact matches and semantic matches each cover the other's weak spot.

An error that enters context and gets treated as true for the rest of the run.

Once a wrong fact or a hallucinated result lands in context, the model tends to build on it rather than question it, compounding into further wrong steps. It's one of five named context failure modes covered under memory - the others are distraction, confusion, clash, and rot.

Output quality falling as context grows, well before the model's advertised limit.

Context rot is measurable degradation, not a hard cutoff at the context window's stated size - a model can get noticeably worse partway through a window that technically still has room. It's one of five named context failure modes alongside poisoning, distraction, confusion, and clash, and it motivates keeping context lean by design rather than trusting the window's advertised size.

A list of numbers that captures the meaning of text in a form machines can compare.

An embedding model converts text into a dense numerical vector, typically 768 to 3072 floating-point numbers. Texts with similar meaning produce vectors that sit close together, which lets software find semantically related content without exact keyword matches. Embeddings underpin semantic search, RAG, deduplication, and recommendation systems.

A network of entities and the typed relationships between them.

Where a vector database finds similar documents, a knowledge graph models how things connect: nodes represent entities, edges represent relationships. Knowledge graphs enable multi-hop reasoning that is hard to do with vector search alone, and are often combined with RAG, where the graph provides structure and vectors provide semantic search.

The raw sequence of messages exchanged in a conversation, the simplest form of agent memory.

Message history is what fills the context window by default: every user message, assistant reply, and tool call and result, in order. It's necessary but not sufficient for a capable agent, since it grows unbounded and doesn't survive past the context window without summarization or another memory type carrying the durable parts forward.

Facts an agent records about a user or environment by watching behaviour, not by being told directly.

Where semantic recall stores what was said, observational memory stores what was noticed: patterns in how a user works, corrections they made, or choices they repeated. It needs the same accuracy discipline as any other stored fact, since a wrong inference compounds every time the agent acts on it.

Learned steps for doing a recurring task, stored so the agent doesn't re-derive them each time.

Procedural memory is closer to a saved skill or runbook than a fact: once an agent has worked out the right sequence of tool calls for a task, storing that sequence lets it skip the trial and error next time. It's the agent-memory analogue of a cached plan rather than a cached answer.

A second, more precise pass that reorders retrieved results by relevance.

Vector search returns candidates quickly but imprecisely. A reranker scores each candidate against the query with a slower, more accurate model and reorders the list before it reaches the LLM. Reranking is a common way to raise RAG answer quality without changing the underlying retrieval index.

Pulls live knowledge into a prompt at inference time rather than baking it into weights.

RAG solves the staleness problem: an LLM has a training cutoff and cannot know what happened after it. Instead of retraining, RAG retrieves relevant documents from a knowledge base and adds them to the context window before generating an answer. A typical pipeline embeds a query, searches a vector store, reranks results, and passes the top chunks to the model.

Retrieving relevant facts or past interactions by meaning rather than by exact match, usually via embeddings.

Semantic recall lets an agent pull in a fact or a past conversation that's relevant to the current task without the user restating it, the same mechanism RAG uses for documents applied to an agent's own memory. It's what separates an agent that remembers a user's stated preference from one that starts fresh every session.

A store optimised for finding semantically similar embeddings at scale.

A traditional database finds exact matches; a vector database finds nearest neighbours, the embeddings geometrically closest to a query vector. This is how RAG retrieves relevant chunks without knowing their exact wording. Most vector databases support metadata filtering, combining semantic search with structured conditions.

The state an agent keeps for the duration of a single task, discarded once it completes.

Working memory holds intermediate results, current plan, and scratch state for the task at hand, distinct from message history, which is the raw conversation, and semantic recall, which persists across sessions. Modelling it explicitly, rather than letting it live only in prompt text, makes an agent's reasoning easier to inspect and resume.

Automated tests that score an agent's plan, tool calls, and final result.

An LLM eval measures a single turn against a reference answer. An agent eval measures multi-step execution: whether the agent reached a correct end state by making correct decisions at each step. A three-layer framework separates reasoning (plan quality), action (tool selection and parameters), and execution (task completion), because each layer can fail independently and a single pass/fail score hides which one broke.

Protocols for agents to discover, delegate to, and collaborate with other agents.

As agent systems grow, agents need to call other agents: a research agent might delegate to a search agent, which delegates to a summarisation agent. A2A and related protocols standardise how agents advertise capabilities, accept tasks, stream progress, and return results, so agents from different vendors and frameworks can compose.

A pattern that stops retrying a failing service after repeated failures, rather than retrying indefinitely.

After a threshold of consecutive failures, a circuit breaker stops sending requests for a cool-down period and then probes with a single request to check recovery, instead of hammering a degraded dependency. It complements exponential backoff: backoff spaces out retries, a circuit breaker decides when to stop retrying altogether.

A workflow an agent should be able to complete end-to-end, used as the unit of regression testing for API changes.

Before changing an operation description or schema, test whether the change regresses existing CUJs rather than only checking the API still returns a valid response. A CUJ regression is a behaviour break even when nothing about the underlying operation's correctness changed.

Running a non-deterministic agent loop inside a replay-safe workflow engine.

An agent loop is non-deterministic: the same input can produce different model output, tool results vary, and the step count isn't known in advance. A durable workflow engine assumes replaying recorded history reproduces the same code path. Durable execution reconciles the two by treating each model and tool call as a recorded, memoized step, so a crash and restart resumes from history instead of re-running everything.

Writing evals for an agent behaviour before implementing it, the eval equivalent of test-driven development.

A failing eval defines the target behaviour up front, and the agent is built or the prompt iterated until it passes, the same discipline TDD applies to conventional code. It works best on capability evals with a clear pass bar, less well on open-ended behaviour where the target itself is still being discovered.

A named set of categories for why an agent fails, tracked as a first-class artefact.

Rather than treating failed eval cases as an undifferentiated pile, a failure-mode taxonomy classifies each one against categories such as extraction, reasoning, or rule application - so the classification itself becomes the input to prioritizing what to fix next, not a byproduct of triage.

Adapting a pretrained model to a specific domain or task using targeted training.

Fine-tuning continues training an already-capable base model on a smaller, curated dataset, typically thousands of input/output pairs that demonstrate the desired behaviour. It can make a model faster, cheaper, more consistent, or better at domain-specific tasks, but it does not reliably add new knowledge; RAG is better for that. Most problems are better solved with prompt engineering or RAG before reaching for a training budget.

Deterministic checks that wrap an agent loop to keep it within safe boundaries.

Runtime guardrails are code, not model behaviour: input processors sanitise what goes in, output processors gate what comes out, before either reaches the user or a tool. Model refusals vary by prompt and drift across versions and cannot be audited, so enforcement belongs in a deterministic layer that runs every time, sequenced and budgeted for latency and cost.

A design where a person must review or approve a step before an agent proceeds.

Human-in-the-loop puts a checkpoint in front of consequential or irreversible actions: a spend above a threshold, a delete, a message sent externally. It trades autonomy for a safety margin, and only works if the agent can genuinely pause and wait, not just log a warning and continue.

Running a trained model to produce outputs, the live serving layer.

Training teaches the model; inference is using it. Every API call to an LLM is an inference request. Inference cost and latency are the primary operational concerns for AI products: larger models are more capable but slower and costlier per token. Optimisation techniques include quantisation, batching, caching, and speculative decoding.

The combination of private-data access, untrusted-content exposure, and an outbound channel that makes an agent exploitable.

Any agent with all three properties at once - access to private data, exposure to untrusted content, and a way to send data out - can be steered by text injected into that untrusted content into exfiltrating the data it holds. The attacker never needs to compromise the model, only to get text in front of it. The fix is removing one leg, usually the outbound channel, rather than hardening all three.

The discipline of deploying, monitoring, and improving AI systems in production.

LLMOps extends DevOps principles to AI: version-control prompts, track model changes like code changes, monitor output quality over time, and build eval pipelines to catch regressions. AI systems can degrade silently, where a model update or data drift changes behaviour without a clear error, which is why evals and traces matter as much as conventional monitoring.

Using a model to grade another model's output against criteria a rule-based check can't express.

Model-based grading suits outputs like open-ended summaries or tone, which a fixed answer can't score, but it carries documented biases such as favouring longer or earlier-listed answers. The grading model should differ from, and ideally be stronger than, the model being evaluated to avoid the two rating each other's blind spots the same way.

A ranked list of the most common security risks in LLM-powered applications.

Maintained by OWASP, it covers risks such as prompt injection, insecure output handling, and excessive agency, giving red-teaming and guardrail work a shared checklist to map coverage against rather than inventing categories from scratch.

A metric measuring the chance an agent succeeds at least once across k independent attempts.

Where a single pass/fail run hides how consistent an agent is, pass@k runs the same task k times and reports the success rate, exposing flaky behaviour a one-shot eval would miss. It matters most for tasks with non-deterministic model output, where a single failing run may not reflect the agent's real reliability.

Instructions hidden in external content that try to redirect an agent's behavior.

A retrieved page might tell an agent to reveal private data or ignore the user's request. Treat that content as untrusted data and enforce permissions outside the model. Testing should cover attempted redirects as well as ordinary input errors.

Deliberately attacking an agent system before launch to find where it can be manipulated.

Red-teaming tests prompt injection, jailbreaks, and other adversarial inputs against an agent, distinct from runtime guardrails, which defend production traffic after launch. Continuous red-teaming in CI catches regressions a one-off pre-launch pass would miss.

Limits on how often a client can call a service.

A service may cap requests within a time window or limit concurrent work. Documented quotas and retry timing let agents slow down when they reach the limit. Repeatedly retrying immediately can prolong the failure or exhaust a budget.

The current standard for structured HTTP error responses that agents can parse.

RFC 9457 standardises an error response shape with five core fields: type (a stable URI), title, status, detail, and instance. An agent should branch on type, never on title or detail, since those are meant for people. Extensions such as is_retriable, retry_after_ms, suggestions, and trace_id let a server give an agent enough to recover automatically.

Making a repeated request have the same intended effect as a single request.

If an order request times out, the caller may not know whether it succeeded. An idempotency key lets the server recognize the retry and return the earlier outcome instead of placing a second order. The API must document how long keys remain valid and how changed inputs are handled.

Running a new model or prompt version against live traffic without letting its output reach users.

A shadow evaluation compares the candidate's responses to the current production version on real, not synthetic, inputs, surfacing regressions a fixed test set would miss. Because nothing the candidate produces is shown to a user, it carries none of the risk of a live A/B test.

An isolated environment for trying operations without affecting production customers.

A sandbox can provide test credentials, sample records, and simulated payments. It lets agents exercise changes and failure recovery before using live services. Document differences from production so a passing test is not mistaken for proof of every live behavior.

A recorded timeline of an agent run: which tools ran, in what order, with what results.

A trace is the source of truth for debugging an agent: the model calls, tool calls, arguments, results, and errors that made up a run, usually captured as OpenTelemetry spans. The relevant GenAI semantic conventions are still under active development, so treat attribute names as likely to shift and record which convention snapshot a given instrumentation targets.

A protocol for expressing and verifying authorization in agent-led payments.

AP2 uses signed mandates to record purchase intent and authorization. Participants verify the evidence required by their payment flow. A signed mandate, a completed payment, and delivery of the purchased item are separate facts.

A protocol for agent-assisted checkout and related commerce operations.

ACP provides defined interfaces for preparing and completing purchases with a merchant. The integration must handle totals, customer approval, payment, and order results. Use the version and binding supported by the actual agent client and payment provider.

A protocol that uses HTTP 402 responses to request payment for a resource.

The response tells a compatible client what payment is required. The client provides payment information, which is verified under the supported scheme before access is granted. Check the payment network, asset, settlement process, and retry behavior required by the integration.

An HTTP payment protocol for paid resources such as API calls and content.

A server presents a payment challenge, the client responds with a payment credential, and the server verifies it before supplying the resource. Price, spending limits, receipts, and recovery after failed delivery all need defined behavior.

A record of what someone has authorized an agent to buy or spend.

A mandate can bind permission to an amount, merchant, purpose, or expiry, depending on the protocol. The receiving system verifies that permission before proceeding. An agent preparing a cart does not itself establish authority to pay.

A protocol for connecting agent platforms with merchant commerce capabilities.

UCP describes capabilities such as checkout, identity linking, and order management. It lets compatible systems exchange purchase information through defined contracts. A merchant still needs supported payment integrations and must enforce its business rules and the buyer's authority.