Glossary

Communication protocol that enables AI agents to discover, coordinate with, and delegate tasks to other agents in a distributed system.

The A2A protocol allows agents to work together by sharing capabilities, coordinating workflows, and distributing complex tasks across multiple specialized agents. It provides standardized messaging, capability discovery, and task delegation mechanisms for multi-agent systems.

A unified governance layer that mediates the access, information, and oversight agents need to do work across an organization.

A system built around a large language model (LLM) that interprets user intent, selects the right tools, and chains multiple steps into a workflow.

AI agents can understand natural language instructions, reason about tasks, invoke tools through MCP servers, and coordinate multiple operations to accomplish complex workflows.

The governed entry point for an agent’s LLM calls and MCP tool calls in Agentic Data Plane. AI Gateway holds the upstream credentials, authenticates each caller, and records usage. It also applies guardrails and budgets to LLM calls.

The maximum amount of text (measured in tokens) that an LLM can process in a single request.

The context window determines how much information an agent can consider at once, including the system prompt, conversation history, tool outputs, and retrieved documents. Larger context windows enable more sophisticated reasoning but may increase latency and cost. Common sizes range from 8K to 200K+ tokens.

Another name for a managed agent. Agentic Data Plane hosts and runs it for you, and you configure its LLM, system prompt, and attached tools instead of writing agent code.

The most advanced and capable AI models available, representing the current state-of-the-art in language understanding and reasoning.

Frontier models are cutting-edge large language models with exceptional reasoning, planning, and problem-solving capabilities. Examples include the largest current models from Anthropic, OpenAI, and Google. These models are commonly used to power sophisticated AI agents that require advanced decision-making and tool orchestration.

An AI model trained on vast amounts of text data that can understand and generate human-like text, reason about tasks, and follow instructions.

Large language models power AI agents by providing natural language understanding, reasoning capabilities, and the ability to plan and execute complex tasks. LLMs interpret user requests, decide which tools to invoke, and synthesize responses based on retrieved data.

An AI agent that Agentic Data Plane hosts and runs for you. You configure its LLM, system prompt, MCP tools, and optional subagents and triggers instead of writing agent code. By contrast, you build and run a self-managed agent in your own runtime.

An AI application or agent that connects to MCP servers to discover and invoke tools.

MCP clients use the Model Context Protocol to communicate with MCP servers, discovering available tools, understanding their capabilities, and invoking them with appropriate parameters. The client handles authentication, request formatting, and response processing.

A service that exposes tools and resources using the Model Context Protocol, allowing AI agents to discover and invoke them.

MCP servers act as bridges between AI agents and external systems, providing standardized interfaces for tool discovery, invocation, and resource access.

An open standard that lets AI applications and agents connect to external tools and data sources through a common interface.

MCP servers expose tools. MCP clients, such as AI agents, discover and call those tools. In Agentic Data Plane, agents reach tools through AI Gateway and MCP servers.

An Agentic Data Plane resource that governs inbound authentication: an external app (Claude Desktop, ChatGPT, Copilot Studio) authenticating to AI Gateway so the app’s users can invoke MCP tools. Separate from an OAuth provider, which governs outbound authentication.

A stored authorization that links a user to a third-party provider, created when the user completes the OAuth consent flow. OAuth connections hold access and refresh tokens in the token vault for agents to use on the user’s behalf.

An Agentic Data Plane resource that governs outbound authentication: AI Gateway authenticating to an upstream system (GitHub, Slack, Salesforce, and so on) on a user’s behalf so MCP servers can call it. Separate from an OAuth client, which governs inbound authentication.

The ability to understand a system’s internal state by examining its external outputs, such as traces, metrics, and logs.

In Redpanda’s agentic systems, observability enables debugging agent behavior, monitoring performance, analyzing execution flow, and identifying bottlenecks through transcripts captured in the redpanda.otel_traces topic.

Open-source observability framework that provides standardized APIs, libraries, and tools for capturing and exporting telemetry data.

OpenTelemetry provides standardized APIs for capturing traces, metrics, and logs from applications. Agentic Data Plane automatically emits OpenTelemetry traces from AI Gateway, managed agents, and managed MCP servers. Self-managed agents export their own spans through the environment’s OTLP endpoint.

Standard protocol for encoding and transmitting telemetry data defined by the OpenTelemetry project.

OTLP is the OpenTelemetry Protocol specification for encoding and transmitting telemetry data. Redpanda stores spans in the redpanda.otel_traces topic using a Protobuf schema that closely follows the OTLP specification.

Natural language instructions or context provided to an LLM to guide its behavior and responses.

Prompts are the primary way to communicate with LLMs and AI agents. They can include instructions, examples, context, and questions that guide the model’s reasoning and output. Effective prompt design is critical for agent performance and reliability.

Read-only data that an MCP server exposes and agents can fetch by URI. Resources provide file contents, database rows, or API responses without performing side effects.

An AI agent you build and run yourself, in your own runtime and framework, registered with Agentic Data Plane as an identity. AI Gateway becomes the agent’s LLM and MCP endpoint, so Agentic Data Plane attributes spend, tokens, latency, and traces back to the agent. Agentic Data Plane does not host or run the agent. By contrast, Agentic Data Plane hosts and runs a managed agent for you.

An MCP server you host and operate yourself, registered with Agentic Data Plane so the AI Gateway can proxy tool calls to it. By contrast, Agentic Data Plane hosts a managed MCP server in-process for you. In the UI, these servers carry a Remote badge.

A single unit of work within a trace representing one operation, such as a data processing operation or an external API call.

Spans are organized in the Redpanda UI as parent-child relationships that show how operations flow through the system. Each span captures details about a specific operation, including timing, status, and metadata.

A record produced by the AI Gateway for every LLM call. Each event captures input, output, and cached token counts, the total cost in microcents, request count, and the provider, model, user, and organization context that the call ran under.

A delegate inside a managed agent. It has its own name, system prompt, and MCP tools, and the parent agent hands it focused tasks.

A subagent runs inside its parent agent rather than as a separate agent. By default, a subagent uses the parent agent’s model and LLM provider.

Initial instructions that define an agent’s role, capabilities, and behavioral guidelines.

The system prompt is provided at the start of an agent session and establishes the agent’s identity, available tools, operating constraints, and response style. It remains active throughout the conversation and shapes all subsequent agent behavior and decision-making.

Encrypted per-user store for the OAuth access and refresh tokens used to access third-party providers. Redpanda injects a user’s token at call time and refreshes it automatically; connections persist until the user revokes them.

The process of an AI agent executing an MCP tool to perform a specific operation.

Tool invocation occurs when an agent determines that it needs to use a tool, formats the request with appropriate parameters, sends it to the MCP server, and processes the response. Each invocation is captured in transcripts as spans for observability and debugging.

A capability exposed by an MCP server that an AI agent can discover at runtime and invoke through structured JSON-RPC calls. Tools encapsulate operations such as querying a database, calling an API, or sending a message.

The complete lifecycle of a request captured as a collection of spans, showing how operations relate to each other.

A trace represents the complete lifecycle of a request (for example, a tool invocation from start to finish). A trace contains one or more spans organized hierarchically, showing how operations relate to each other.

Complete observability record of agent or MCP server operations captured as OpenTelemetry traces and stored in the redpanda.otel_traces topic.

Transcripts capture tool invocations, agent reasoning steps, data processing operations, external API calls, error conditions, and performance metrics. They provide a complete record of how agentic systems operate, enabling debugging, auditing, and performance analysis.

A metadata service that tracks Apache Iceberg tables and their schemas. Redpanda supports REST catalogs (such as AWS Glue, GCP BigLake, Snowflake Open Catalog, or Databricks Unity Catalog) and filesystem-based catalogs.

Redpanda SQL connects to a REST catalog with CREATE ICEBERG CATALOG to query the Iceberg-committed history of a topic.

The Redpanda topic property (redpanda.iceberg.mode) that controls whether and how the topic’s records are translated into an Apache Iceberg table.

A Redpanda topic with Iceberg integration enabled, so its data is also stored as an Apache Iceberg table that downstream analytical systems can read directly. Also called an Iceberg-enabled topic.

The background process that converts records on an Iceberg topic into Apache Iceberg format and commits them to the configured Iceberg catalog.

Features in beta are available for testing and feedback. They are not supported by Redpanda and should not be used in production environments.

Redpanda software that is available under the Redpanda Business Source License (BSL). These core features are free and source-available.

Redpanda software that is available under the Redpanda Community License (RCL). It includes the free features licensed with the Redpanda Community Edition, as well enterprise features, such as Tiered Storage, Remote Read Replicas, and Continuous Data Balancing.

Features in limited availability (LA) are production-ready and are covered by Redpanda Support for early adopters.

Redpanda Self-Managed refers to the product offering that includes both the Enterprise Edition and the Community Edition of Redpanda.

Sometimes used interchangeably with self-hosted.

Bring Your Own Cloud (BYOC) is a fully-managed Redpanda Cloud deployment where clusters run in your private cloud, so all data is contained in your own environment. Redpanda handles provisioning, operations, and maintenance.

A Bring Your Own Virtual Network (BYOVNet) cluster allows you to deploy the Redpanda data plane into your existing Azure VNet to fully manage the networking lifecycle. Compared to standard BYOC, BYOVNet provides more security, but the configuration is more complex.

A Bring Your Own Virtual Private Cloud (BYOVPC) cluster allows you to deploy the Redpanda data plane into your existing VPC on AWS or GCP to fully manage the networking lifecycle. Compared to standard BYOC, BYOVPC provides more security, but the configuration is more complex.

This part of Redpanda Cloud enforces rules in the data plane, including cluster management, operations, and maintenance.

This part of Redpanda Cloud contains Redpanda clusters and other components, such as Redpanda Console, Redpanda Operator, and rpk. It is managed by an agent that receives cluster specifications from the control plane. Sometimes used interchangeably with clusters.

Containing all your data in your environment.

With BYOC, Redpanda handles provisioning, monitoring, and upgrades, but you manage your streaming data without Redpanda’s control plane ever seeing it. Additionally, with BYOVPC, the Redpanda Cloud agent doesn’t create any new resources or alter any settings in your account.

A fully-managed Redpanda Cloud deployment option where you host your data in Redpanda’s VPC, and Redpanda handles provisioning, operations, and maintenance. Dedicated clusters are single-tenant deployments that support private networking (for example, VPC peering to talk over private IPs) for better data isolation.

A fully-managed data streaming service. It includes automated upgrades and patching, backup and recovery, data and partition balancing, Redpanda Console, and Redpanda Connect pipelines. Redpanda Cloud is available in Bring Your Own Cloud (BYOC), Dedicated, and Serverless deployment options to suit different data sovereignty and infrastructure requirements.

A container for Redpanda Cloud resources, including clusters and networks. You can rename your default resource group, and you can create more resource groups. For example, you may want different resource groups for production and testing.

Serverless is the fastest and easiest way to start data streaming. You host your data in Redpanda’s VPC, and Redpanda handles automatic scaling, provisioning, operations, and maintenance.

A component that moves data between Redpanda and an external system, such as a database. In Redpanda Connect, the inputs and outputs of a pipeline are connectors. Kafka Connect runs connectors as plugins.

A function that an AI assistant can call to perform a specific task, such as fetching data from an API, querying a database, or processing streaming data. Each tool is defined using Redpanda Connect components and annotated with MCP metadata.

A single configuration file running in Redpanda Connect with an input, an output, and optional processors in between. A pipeline typically streams data into Redpanda from an operational source (like PostgreSQL) or streams data out of Redpanda into an analytical system (like Snowflake).

A Redpanda Connect component that transforms data, validates inputs, or calls external APIs within a processing pipeline.

Processors are stateless components in Redpanda Connect that operate on individual messages or batches.

A process that exposes Redpanda Connect components to MCP clients. You write each tool’s logic using Redpanda Connect configurations and annotate them with MCP metadata so clients can discover and invoke them.

A framework for building data streaming applications using declarative YAML configurations. Redpanda Connect provides components such as inputs, processors, outputs, and caches to define data flows and transformations.

Exports data from a Redpanda cluster into a target system. In Redpanda Connect, this is an output.

Imports data from a source system into a Redpanda cluster. In Redpanda Connect, this is an input.

The SQL engine technology that powers Redpanda SQL. "Oxla" may appear in version strings, error messages, and some API field names.

A catalog in Redpanda SQL that maps Redpanda topics to SQL tables. The default Redpanda catalog (default_redpanda_catalog) is provisioned automatically when Redpanda SQL is enabled.

A PostgreSQL-compatible SQL engine built into Redpanda Data Platform for querying streaming data in Redpanda topics.

Redpanda SQL provides analytical SQL queries over Redpanda topic data without requiring ETL pipelines or a separate analytics system. It can also query the Iceberg-translated history of Iceberg-enabled topics alongside live records.

The address a Redpanda broker broadcasts to producers, consumers, and other brokers. It specifies the hostname and port for connections to different listeners. Clients and other brokers use advertised listeners to connect to services such as the Admin API, Kafka API, and HTTP Proxy API. The advertised address might differ from the listener address in scenarios where brokers are behind a NAT, in a Docker container, or in Kubernetes. Advertised addresses ensure clients can reach the Redpanda brokers even in complex network setups.

One or more data centers served by high-bandwidth links with low latency, typically within a close distance of one another.

An instance of Redpanda that stores and manages event streams. Multiple brokers join together to form a Redpanda cluster.

Sometimes used interchangeably with node, but a node is typically a physical or virtual server.

See also: node

A producer application that writes events to Redpanda, or a consumer application that reads events from Redpanda.

This could also be a client library, like librdkafka or franz-go.

One or more brokers that work together to manage real-time data streaming, processing, and storage.

A set of consumers that cooperate to read data for better scalability. As group members arrive and leave, partitions are re-assigned so each member receives a proportional share.

The position of a consumer in a specific topic partition, to track which records they have read. A consumer offset of 3 means it has read messages 0-2 and will next read message 3.

A client application that subscribes to Redpanda topics to asynchronously read events.

A broker that manages operational metadata for a Redpanda cluster and ensures replicas are distributed among brokers. At any given time, one active controller exists in a cluster. If the controller fails, another broker is automatically elected as the controller.

Snapshot of the current cluster metadata state saved to disk, so broker startup is fast.

A continuous flow of events in real time that are produced and consumed by client applications. Redpanda is a data streaming platform. Also known as event stream.

A record of something changing state at a specific time. Events can be generated by various sources, including sensors, applications, and devices. Producers write events to Redpanda, and consumers read events from Redpanda.

A broker that is a follower in a Raft group but is not part of quorum.

In a Raft group, a broker can be in learner status. Learners are followers that cannot vote and so do not count towards quorum (the majority). They cannot be elected to leader nor can they trigger leader elections. Brokers can be promoted or demoted between learner and voter. New Raft group members start as learners.

Configuration on a broker that defines how it should accept client or inter-broker connections. Each listener is associated with a specific protocol, hostname, and port combination. The listener defines where the broker should listen for incoming connections.

An ordered, append-only, immutable sequence of records.

The log is Redpanda’s core storage abstraction for event streams. At the conceptual level, topics represent replayable logs. Physically, each partition is implemented as a log file on disk, divided into segments. Redpanda uses the Raft consensus algorithm to coordinate writing data to log files and replicate them across brokers for fault tolerance.

See also: topic, partition, segment

One or more records representing individual events being transmitted. Redpanda transfers messages between producers and consumers.

Sometimes used interchangeably with record.

A machine, which could be a server, a virtual machine (instance), or a Docker container. Every node has its own disk. Partitions are stored locally on nodes. In Kubernetes, a Node is the machine that Redpanda runs on. Outside the context of Kubernetes, this term may be used interchangeably with broker, such as node_id.

See also: broker

An acknowledgement that the event has been read.

A unique integer assigned to each record to show its location in the partition.

Every Redpanda partition forms a Raft group with a single elected leader. This leader handles all writes, and it replicates data to followers to ensure that a majority of brokers store the data.

A subset of events in a topic, like a log file. It is an ordered, immutable sequence of records. Partitions allow you to distribute a stream, which lets producers write messages in parallel and consumers read messages in parallel. Partitions are made up of segment files on disk.

A client application that writes events to Redpanda. Redpanda stores these events in sequence and organizes them into topics.

A failure zone that has one or more Redpanda brokers assigned to it.

The consensus algorithm Redpanda uses to coordinate writing data to log files and replicating that data across brokers.

For more details, see https://raft.github.io/

A self-contained data entity with a defined structure, representing a single event.

Sometimes used interchangeably with message.

Copies of partitions that are distributed across different brokers, so if one broker goes down, there is a copy of the data.

The mechanism for determining how long Redpanda stores data on local disk or in object storage before purging it.

The number of copies of each partition in a cluster. The default is 3 in Redpanda Cloud and in Kubernetes clusters with at least three brokers, and 1 (no replication) otherwise. With a replication factor of 3, each partition has a copy of its data on two other brokers. One replica acts as the leader, and the other replicas are followers.

An open-source thread-per-core C++ framework, which binds all work to physical cores. Redpanda is built on Seastar.

For more details, see https://seastar.io/

The initial set of brokers that a Redpanda broker contacts to join the cluster. Seed servers play a crucial role in cluster formation and recovery, acting as a point of reference for new or restarting brokers to understand the current topology of the cluster.

Discrete part of a partition, used to break down a continuous stream into manageable chunks. You can set the maximum duration (segment.ms) or size (segment.bytes) for a segment to be open for writes.

A CPU core.

Programming model that allows Redpanda to pin each of its application threads to a CPU core to avoid context switching and blocking.

A topic may be partitioned through multiple brokers. A "topic partition" represents this logical separation in Redpanda, which is managed natively by Raft.

A logical stream of related events that are written to the same log. It can be divided into multiple partitions. A topic can have various clients writing events to it and reading events from it.

A Redpanda topic type that uses object storage (such as S3, ADLS, GCS, or MinIO) as the primary data store, rather than replicating data across brokers. Unlike standard Redpanda topics, Cloud Topics allow users with flexible latency requirements to lower or eliminate costs associated with cross-AZ networking.

Feature that retains the latest value for each key within a partition while discarding older values.

Framework to manipulate or enrich data written to Redpanda topics. You can develop custom data functions, which run asynchronously using a WebAssembly (Wasm) engine inside a Redpanda broker.

Feature that places a topic’s partition leaders in a preferred location, such as a cloud availability zone, to reduce networking costs and latency for nearby clients.

A state where a Redpanda broker temporarily doesn’t take any partition leaderships. It continues to store data as a follower. This is usually done for system maintenance or a rolling upgrade.

Feature that lets you distribute replicas of the same partition across different racks to minimize data loss and improve fault tolerance in the event of a rack failure.

Process of moving partition replicas and transferring partition leadership for improved performance.

Redpanda provides various topic-aware tools to balance clusters for best performance.

The process of upgrading each broker in a Redpanda cluster, one at a time, to minimize disruption and ensure continuous availability.

A read-only topic that mirrors a topic on a different cluster, using data from Tiered Storage.

A read-only Redpanda cluster that continuously receives replicated data from a source cluster through a shadow link. During a disaster, you can fail over to the shadow cluster so it handles production traffic.

A persistent connection between two Redpanda clusters that continuously replicates topic data, metadata, consumer offsets, ACLs, and Schema Registry content from a source cluster to a shadow cluster for disaster recovery.

A period of running a new version under your normal production traffic before you commit to it, so that problems show up while you can still roll back.

In Redpanda Self-Managed, deferred finalization makes a soak test possible for a feature-release upgrade: after every broker runs the new version, the cluster waits for you to finalize the upgrade, and until then you can roll back to the previous release.

Feature that lets you offload log segments to object storage in near real-time, providing long-term data retention and topic recovery.

A Kubernetes controller that simplifies the process of obtaining, renewing, and using certificates.

For more details, see https://cert-manager.io/docs/

Generates and applies all the manifest files you need for deploying Redpanda in Kubernetes.

Extends Kubernetes with custom resource definitions (CRDs), which allow Redpanda clusters to be treated as native Kubernetes resources.

A security feature used to define and enforce granular permissions to resources, ensuring only authorized users or applications can perform specific operations. ACLs act on principals.

The process of verifying the identity of a principal, user, or service account. Also known as AuthN.

The process of specifying access rights to resources. Access rights are enforced through roles or access control lists (ACLs). Also known as AuthZ.

An access token used for authentication and authorization in web applications and APIs. It holds user credentials, usually in the form of random strings of characters.

Group-based access control lets you manage Redpanda permissions at scale by assigning them to OIDC groups instead of individual users.

GBAC lets you manage Redpanda permissions at scale using the groups that already exist in your identity provider (IdP). You define access once for a group and your IdP controls who belongs to it. You can grant permissions to groups in two ways: create ACLs with Group:<name> principals, or assign groups as members of RBAC roles. Both approaches can be used independently or together.

A service that creates, maintains, and manages identity information while providing authentication services to applications.

Identity providers authenticate users and issue tokens that applications can use to verify identity and access permissions. Common IdPs include Okta, Auth0, Microsoft Entra ID, and Google Identity Platform.

Authentication layer built on OAuth 2.0 that allows clients to verify user identity and obtain basic profile information.

OpenID Connect provides a standardized way for applications to authenticate users through identity providers. In Redpanda’s agentic systems, OIDC enables secure authentication for AI agents and MCP servers accessing cloud resources.

An authenticated identity (user, service account, or group) that Redpanda evaluates when enforcing ACLs and role assignments.

Redpanda supports User:<name> and Group:<name> principal types. Permissions are granted to principals through ACLs or RBAC role assignments.

Role-based access control lets you assign users access to specific resources.

An identity independent of the user who created it that can be used to authenticate and perform operations. This is especially useful for authentication of machines.

An independent namespace for subjects within a Schema Registry. Contexts let multiple groups of schemas coexist in one registry without naming conflicts. The default context is named ".".

Redpanda Schema Registry (pandaproxy) is the interface for storing and managing event schemas. Producers and consumers register and retrieve schemas they use from the registry. It is built into the Redpanda binary and uses the default port 8081.

An external mechanism to describe the structure of data and its encoding. Schemas validate the structure and ensure that producers and consumers can connect with data in the same format.

The process of converting a record into a format that can be stored. Deserialization is the process of converting a record back to the original state. Redpanda Schema Registry supports Avro and Protobuf serialization formats.

A logical grouping or category for schemas. When data formats are updated, a new version of the schema can be registered under the same subject, allowing for backward and forward compatibility.

A serialization format used by Schema Registry that prefixes each record with a magic byte and 4-byte schema ID, so consumers can identify and apply the correct schema.

A REST API used to manage and monitor Redpanda Self-Managed clusters. It uses the default port 9644.

For more information about using this API with Redpanda Self-Managed, see the Admin API reference.

Note: The Redpanda Admin API is different from the Kafka Admin API.

Redpanda HTTP Proxy (pandaproxy) allows access to your data through a REST API. It is built into the Redpanda binary and uses the default port 8082.

Producers and consumers interact with Redpanda using the Kafka API. It uses the default port 9092.

Original name for the subsystem of Redpanda that allows access to your data through a REST API. This name still appears in the HTTP Proxy API and the Schema Registry API.

The web-based UI for managing and monitoring Redpanda clusters and streaming workloads, including topics, consumer groups, schemas, and security. Redpanda Cloud includes Redpanda Console, and you can also run it on its own with Redpanda Self-Managed.

Redpanda’s command-line interface tool for managing Redpanda clusters.