Two Copilots, One Platform: How Zerq Serves Both Operators and API Consumers

When teams start thinking about adding an AI copilot to their API platform, the first question is usually "who is it for?" The ops team that manages the platform? The partner developers who consume it? Both audiences have genuine needs, but they have almost nothing else in common — different levels of access, different scopes of action, different goals for each conversation.

Most AI assistant implementations pick one audience and design for them. Zerq Copilot is built for both — through two genuinely distinct experiences that share a common foundation.

The two experiences

Copilot for Management: the operator's assistant

Copilot for Management lives in the Zerq console, alongside the day-to-day work of platform engineers and operations teams. It talks to the platform through Management MCP — the same programmatic API surface that the console itself uses.

The scope is the full platform:

Query what exists: collections, proxies, policies, clients, credentials, workflows
Make changes: create resources, update configurations, rotate credentials, assign policies
Understand state: pull traffic metrics, audit logs, error summaries
Orchestrate sequences: ship a new API product end-to-end in a single thread

The key property: every action runs under your OIDC session with your role. An operator with editor permissions can change configuration. A viewer can only read. The same RBAC that governs console access governs Copilot access — there is no side door.

Every action Copilot takes on your behalf appears in the platform audit log with your identity. When someone asks "who changed this policy?" the audit record says "Alice, via Copilot, at 14:32" — not "AI assistant."

Copilot for Gateway: the developer's assistant

Copilot for Gateway lives inside the Developer Portal, available to partners and API consumers who have been onboarded to specific products. It talks to the platform through Gateway MCP — the protocol surface that published APIs use for discovery and invocation.

The scope is strictly consumer-side:

Discover what APIs are available to this consumer (not all APIs on the platform)
Inspect endpoint contracts, schemas, and authentication requirements
Execute test calls using the active access profile's credentials — the same headers as the interactive try-it console
Ask questions about error responses, rate limit behaviour, and integration patterns

The key property: Copilot for Gateway is bounded by what the consumer is allowed to do. It cannot query platform configuration, see other consumers' products, or make calls beyond the scope of the consumer's assigned policy. The gateway enforces all of this identically to any other client.

Why this distinction matters

The distinction is not cosmetic. Management Copilot and Gateway Copilot operate with fundamentally different trust models and enforcement surfaces.

Scope boundary. Management Copilot has platform-wide scope — it can see and change anything your operator session allows. Gateway Copilot has consumer scope — it is bounded by the products your access profile entitles you to. If a developer portal user asks Gateway Copilot about an API they are not subscribed to, the response is the same as any other unauthorised request: denied.

Enforcement layer. Management Copilot's actions are enforced by the Management MCP server and Zerq's RBAC system. Gateway Copilot's actions are enforced by the gateway itself — subject to rate limits, token validation, and the same access controls as external API clients. Neither one has a privileged path that bypasses enforcement.

Audit surface. Management Copilot actions appear in the platform audit log alongside console actions. Gateway Copilot actions appear in the API traffic log alongside normal client calls. Both produce structured records; they are separate because they represent separate concern domains.

Conversation patterns. An operator building a product needs to sequence multiple management actions in one thread. A developer integrating against an API needs to understand contracts, test endpoints, and debug error shapes. These are different conversations with different tools available. Blending them into one experience would either restrict operators or expose operators' configuration surface to consumers.

What they share

The division in scope is clean. The infrastructure underneath is shared:

Model configuration. Both Copilot experiences use the same server-side LLM configuration (AI_MODELS). You configure your preferred model provider once per environment — OpenAI, Anthropic, Google Gemini, Groq, Azure OpenAI, Amazon Bedrock, Ollama, OpenRouter, or a custom endpoint. That configuration applies to both Management Copilot and Gateway Copilot. LLM credentials stay server-side; they do not ship to the browser regardless of which experience is in use.

Conversational patterns. Both experiences use the same interaction model: plain language input, structured tool calls to the underlying MCP surface, narrated results. The difference is in which MCP surface is available and what scope the session carries, not in how the conversation itself works.

Audit discipline. Both experiences produce audit records. The records go to different destinations (platform audit log vs. API traffic log) because they represent different concern domains — but neither experience is invisible to your audit and compliance infrastructure.

The practical implication for platform teams

For platform teams, the dual-experience design means one decision instead of two: choose your model provider and configure it once. Both the internal operations experience and the outward-facing consumer experience are covered.

For developer portal consumers, the implication is that AI-assisted API discovery is available without any additional credential management, integration work, or security review on the consumer side. It uses the same profile credentials and gateway enforcement as everything else they do in the portal. There is nothing new to audit.

For security and compliance teams, the implication is that neither experience is a shadow path. Management Copilot is governed by the same RBAC as the console. Gateway Copilot is governed by the same policies as API clients. There is no exception surface to review — the existing control model extends to both.

See Zerq Copilot for the full product overview including how each experience is configured and deployed, or request a demo to see both experiences running in a live environment.