SYSTEM Cited by 1 source

Redpanda agi CLI (Agentic Gateway Interface)¶

agi CLI — short for "agentic gateway interface" — is a dynamic, self-describing command-line tool that agents running inside a gateway-only-egress sandbox use to invoke the Agentic Data Plane's governance gateway. It is the sandbox-to-gateway mediator that lets agent reasoning compose with standard Unix tooling (shell pipelines, redirection, text-processing utilities) while keeping every external-world call governed.

First disclosed in the 2026-04-14 Redpanda Openclaw is not for enterprise scale post as a demonstration, not a shipping product. "Yes, the name is a play on that [AGI]."

Canonical statement¶

(Source: sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale)

"We at Redpanda have a demonstration of this using our 'agentic gateway interface' or agi CLI (yes, the name is a play on that AGI) to allow the agent to invoke our AI gateway from within the sandbox, this way."

"We use a dynamic, self-describing CLI to mediate access to external tools. This provides an interface for agents to discover and invoke services outside the sandbox, fitting cleanly into the composable Unix workflow while keeping all communication strictly governed by the gateway."

Architectural role¶

The agi CLI is what turns "the sandbox can only talk to the gateway" from a restrictive invariant into a productive workflow. Without something like the agi CLI, a gateway-only-egress sandbox either needs:

Direct HTTP calls to the gateway from every agent tool call — brittle, exposes internal gateway URL shape, no discovery.
Per-provider SDKs with gateway-aware transports — fan-out of SDK dependencies inside the sandbox.
A fixed set of pre-registered tool shortcuts — defeats the agent's need to discover new tools.

The agi CLI answers all three: one command, dynamically- discovered subcommands, composable with |, $(...), etc.

Three named properties¶

1. Dynamic¶

Subcommands and their arguments are not hard-coded into the CLI binary. The CLI resolves available tools / services / operations at invocation time — likely by asking the gateway "what can this agent session do right now?" This makes the CLI's effective surface:

Session-scoped: only tools the gateway authorises for this agent session appear.
Policy-aware: a tool the gateway has policy-blocked isn't listed.
Evolutionary: new tools appear without redeploying the sandbox.

2. Self-describing¶

Subcommands carry their own help text, argument schemas, and discovery metadata. The post's implication (not spelled out): the agent can run agi --help, agi salesforce --help, agi salesforce.opportunity.update --help to discover the current tool surface from inside the sandbox.

This mirrors the MCP tool-listing model — agi CLI is plausibly an MCP client or close analogue, with the gateway as the MCP server.

3. Mediator of access to external tools¶

Every agi <tool> invocation is a gateway call. The CLI is the only network-touching binary in the sandbox (or one of a small, audited set). Its job is to:

Attest the agent's identity (via the out-of-band metadata the sandbox launched with).
Serialise the tool call + arguments to the gateway's wire format.
Await the gateway's response (which may have transited the token vault + downstream service).
Render the response as text on stdout for the agent's next pipeline stage.

Unix-workflow composability¶

The post explicitly calls out "composable Unix workflow" as the design goal. Example mental-model invocations (not from the post, extrapolated):

# Pipe agi output into standard tools
$ agi github.issues.list --repo foo/bar --state open | jq '.[].title'

# Use agi in a script
$ for user in $(agi salesforce.account.list --industry tech | cut -f1); do
    agi salesforce.account.enrich --id $user
  done

# Redirect output to a sandbox-local file for later reasoning
$ agi snowflake.query --sql "SELECT ..." > /tmp/query-result.json

The design deliberately lets the agent think in shell, with the gateway providing policy enforcement transparently.

Relationship to other Redpanda systems¶

Substrate: Redpanda Connect with its MCP-server add-on is the likely gateway implementation behind the agi CLI. The ADP post canonicalised this via patterns/mcp-as-centralized-integration-proxy.
Protocol: likely MCP (systems/model-context-protocol) over HTTP / stdio — though the 2026-04-14 post does not name the protocol.
Sibling: Redpanda's existing rpk CLI (rpk connect mcp-server, rpk connect agent) is the operator-facing CLI; agi CLI is the agent-facing CLI. Two distinct tools at different altitudes.
Contrast: Fly.io's wrap-CLI-as-MCP-server pattern goes the other direction — take an existing CLI, wrap it as an MCP tool. The agi CLI is the gateway-side counterpart: take the gateway's tool surface, expose it as a CLI.

Capabilities implied but not disclosed¶

The 2026-04-14 post is demonstration-altitude. Not walked:

Authentication flow. How does the CLI attest the agent's identity to the gateway? Token on filesystem? Unix socket
SO_PEERCRED? mTLS? Kernel-level identity transport?
Tool discovery wire format. MCP tools/list? REST OpenAPI? Custom RPC?
Caching of tool schemas. Every invocation re-discovers, or session-scoped cache?
Streaming output. Long-running tool calls that produce incremental output — does the CLI stream to stdout as responses arrive, or buffer?
Error handling. Non-zero exit codes mapping to what gateway error classes? stderr for policy-deny reasons?
Self-update. Does the CLI update when the gateway's tool surface evolves? How?

All deferred to future Redpanda material.

Caveats¶

Demonstration, not product. The 2026-04-14 post frames the agi CLI as a "demonstration" — no repo URL, no release version, no Apache / Enterprise license statement, no public-availability disclosure.
"Play on AGI" naming is intentional and self-aware. The post explicitly notes "yes, the name is a play on that AGI" — Artificial General Intelligence. Signals the name is rhetorical; subsequent Redpanda material may rename.
Requires the full four-component stack. The agi CLI alone doesn't solve anything — it requires the governance gateway to call, the token vault behind the gateway, the audit log capturing calls, and the sandboxed compute it lives in. Component #4's "how" not its whole value.
Not a public MCP standard. The CLI is Redpanda-specific even if it uses MCP under the hood. Enterprise customers integrating non-Redpanda MCP gateways won't get agi CLI semantics unless Redpanda open-sources it.
Sandbox-binding not specified. The agi CLI needs to know which gateway session / agent identity to attest as. How this bootstraps inside a fresh sandbox — whether via kernel identity, env var, sidecar socket, or otherwise — isn't walked.

Seen in¶

sources/2026-04-14-redpanda-openclaw-is-not-for-enterprise-scale — canonical wiki introduction of the agi CLI as a demonstration system. Named as a dynamic, self-describing CLI inside the sandbox that mediates agent→gateway calls and preserves Unix-workflow composability while keeping all egress governed.