Give an agent a job, not a codebase.
Describe the work in a sentence, pick the systems it may touch, and decide what it is allowed to see. Redpanda handles the credentials, the policy, the cost and the audit trail. No developer needed.
Free to start · Runs in your VPC · ~2 minutes to first agent
Pick a model, pick the tools, write the prompt.
Assembled from parts other people already connected. No framework to choose, no config file, no deploy step. A job too big for one agent splits into sub-agents, each scoped to its own tools.
Plain language. No template, no config file.
Choose the systems from connectors other people already set up.
Attach a data policy. Fields are masked before the model sees them.
Pick a trigger. The gateway, tracing and audit trail were already there.
The person who understands the work is the person who builds it.
Every agent below was assembled the same way: a sentence, a few systems, one policy. No sprint, no ticket, no waiting on engineering.
Support Ticket Classifier
Triages every new incident, looks up the customer's plan, and posts a recommendation in #support.
Fraud Detection Bot
Scores card-not-present transactions and flags the ones that need a human before settlement.
Code Review Bot
Reads open pull requests, finds the race conditions, and files the issue with a reproduction.
Lead Scoring Agent
Enriches every inbound lead, scores it against closed-won history, and updates the CRM.
It does not wait for you to open a tab.
An agent takes ongoing responsibility for a process. You decide when it runs on its own and what it has to ask you about first.
Every run belongs to a person.
A scheduled run acts as whoever set it up; a Slack mention acts as whoever sent the message. Answers only ever contain what that person could already see, which is why an agent in a shared channel cannot leak one person's tickets to another.
Some actions wait for a yes.
Mark a tool as ask-first and the run pauses there: the request lands with a person who approves or rejects it, and the transcript records who said yes. Autonomy is set per tool, not all-or-nothing.
And a rule that stops it without you.
Containment is cut at the gateway, so it works even for agents running in your own infrastructure, and only a person can end it.
Read it like a conversation, because that is what it is.
Every run is recorded as a transcript: what someone asked, what the agent decided, which systems it touched, and what it refused to do. In sentences, not spans.
The same run is also available as OTel-compatible spans with raw attributes, exportable to whatever collector you already run. Nobody has to open that to find out what their agent did.
Or skip all of that and bring your own agent.
Register an agent you wrote and it inherits the same identity, policy, budget and tracing. There is no separate governed path, which is the only way "govern every agent" can be true.
- The same tool scoping and data policies as a managed agent
- The same budget ceilings and per-agent cost attribution
- The same audit log, streamed to your SIEM
- The same kill switch. Containment is cut at the gateway
What it does not get is a lifecycle status. A self-hosted agent runs outside our runtime, so we report Unknown rather than guessing.
$ rpk adp agent register ./agent.yaml registered revenue-analyst (self-hosted) gateway https://aigw.acme-prod…/llm/v1 traces otlp://collector.acme-prod… # One credential authorises both its model calls # and its tool calls. Nothing else to wire.
One path to every system
Every tool call brokered through one place: hosted connectors with auth handled, per-agent tool scoping, and field-level policy on the way back.
How it works →AI GatewayOne endpoint, every model
Your keys and your models behind one OpenAI-compatible endpoint, with routing, failover, per-agent cost attribution and budgets that refuse at the cap.
How it works →Put agents to work on the processes you already own.
Your first agent runs in minutes. The governance was there before you started.