Agentic Data Plane

Register Your Own Agent (BYOA)

Register a self-managed agent with Redpanda ADP to bring it under the same observability and governance as managed agents. Your agent gains registry visibility, transcript capture, and cost attribution without moving off your own infrastructure. Registration creates a metadata record: ADP does not host, run, or proxy calls to your agent.

After completing this guide, you will be able to:

  • Choose between a self-managed (BYOA) and a Redpanda-managed agent for your use case

  • Register a self-managed agent so it appears in the agent registry

  • Identify the telemetry and service-account model that attributes a self-managed agent’s activity in ADP

When to use BYOA versus a managed agent

The two models differ in who runs the agent, who owns scaling, and how the agent is defined.

Question Choose BYOA when… Choose a managed agent when…

Where does your agent run?

You have an existing runtime (LangGraph, custom Go, and so on) you want to keep, and you run it yourself.

You want Redpanda to host and operate the agent runtime for you.

How is the agent defined?

It’s already coded; you don’t want to translate it into the declarative agent format.

You want a declarative agent you configure through the ADP wizard, with no runtime code to maintain.

Who scales and operates it?

Your team owns scaling, deploys, and the failure model.

Redpanda owns the runtime; you reason about the agent definition only.

What are you optimizing for?

Maximum control over runtime, libraries, networking, with governance and observability layered on.

Time-to-first-running-agent and built-in observability without integration work.

If you have a Redpanda-managed agent today and you’re considering BYOA, you don’t have to migrate; the two coexist in the same registry and the same dashboard.

What registration gives you

When a self-managed agent is registered:

  • It appears on the Agents page alongside managed agents, and in cost-attribution queries.

  • A service-account identity is created for the agent at registration. Mint credentials for it to authenticate the agent’s calls to AI Gateway and its telemetry ingestion. Credential issuance follows the same pattern as managed agents. See Service account authorization.

Registration does not make the Agentic Data Plane run your agent or route requests to it. The agent runs in your infrastructure, and any clients (including other agents) call it directly.

Prerequisites

Before you register a self-managed agent, make sure you have:

  • An agent running in your own infrastructure.

  • The agent instrumented with OpenTelemetry, emitting the minimum required spans contract with its registered name as the service.name. See BYOA telemetry.

  • The dataplane_adp_agent_create permission, granted by the Writer built-in role. See Agent management permissions.

  • A name for the agent that follows DNS-1123 conventions (1 to 63 characters, lowercase letters, numbers, and hyphens, starting with a letter). The name is immutable after registration.

Register the agent

You can register a self-managed agent from the Agents page in the console, with the rpk CLI, or through AgentRegistryService.CreateAgent. The registration carries the agent’s metadata, and you leave the agent-type configuration unset:

Field What it carries

name

DNS-1123 identifier. Immutable. Used in the registry, in cost-attribution queries, and as the agent’s resource identifier.

display_name

Human-readable label shown in the UI. Editable later.

description

Free-text description of what the agent does. Editable later.

tags

Optional key/value labels (up to 50 pairs). Useful for filtering agents in cost-attribution queries.

agent_type

Leave unset. Populating the managed arm creates a Redpanda-managed agent instead; leaving the whole field unset registers a self-managed (BYOA) metadata record.

Once registered, your agent appears on the Agents page. The first time it serves a request and emits telemetry, transcripts begin populating.

Make your agent callable by other agents (optional)

If you want other agents or clients to call your agent, expose a standard A2A protocol endpoint on your own infrastructure (an agent-card document at /.well-known/agent-card.json, plus the A2A message endpoints). Callers reach your agent directly at its own address. The Agentic Data Plane does not proxy A2A traffic to self-managed agents; its A2A reverse proxy serves Redpanda-managed agents only.

For the agent-card schema and the A2A message-endpoint shapes, see Agent-to-agent concepts.

Verify the registration

After registering, confirm the following end-to-end:

  1. Registry: The agent appears on the Agents page and in cost-attribution queries. At the API level, confirm AgentRegistryService.ListAgents returns it.

  2. Telemetry: Open the transcripts list, filter by your agent’s service.name, and confirm a recent execution shows up with non-zero token counts and a non-empty conversation ID. If it doesn’t, see BYOA telemetry troubleshooting.

Troubleshooting

Symptom What to check

Agent registered but doesn’t appear on the Agents page

Confirm AgentRegistryService.ListAgents returns the agent. If ListAgents is empty, the registration didn’t persist; retry.

Transcripts list shows the agent column blank for your agent’s runs

Your agent’s OpenTelemetry service.name resource attribute doesn’t match the registered name, or isn’t being emitted at all. See BYOA telemetry.

Limitations

This page does not cover:

  • Building the agent itself. Bring whatever runtime, framework, and language you want. The integration points (telemetry attributes plus the registry record) are what make it visible in ADP.

  • Tool use through MCP. If your agent calls MCP servers hosted in AI Gateway, see MCP Servers for the consumer-side flow. Tool calls appear in your agent’s transcript when MCP servers emit their own spans.

  • Gateway-proxied A2A routing. The Agentic Data Plane does not route A2A calls to self-managed agents; that is a managed-agent capability. Clients call your agent directly.

  • Migration from a managed declarative agent to BYOA. The two coexist; BYOA is for agents that already exist outside the managed runtime, not for re-platforming existing managed agents.

Next steps