Skip to main content

Why we built Zerq: one platform for APIs, AI agents, and everything in between

API management, gateway, MCP, workflow designer, access & security, platform automation, Copilot, developer portal, observability, compliance, performance, and deployment — all in one platform. Here's why we built it this way.

  • zerq
  • api-gateway
  • api-management
  • mcp
  • workflow-platform
  • developer-portal
  • platform-automation
  • copilot
  • founder-story
Zerq team

Ask any platform engineering team how many tools they use to run their API infrastructure and the answer is almost always the same: too many.

A gateway here. A developer portal bolted on as an afterthought. A separate workflow tool for request transformation. An observability stack that doesn't quite connect to the gateway's access model. A compliance audit trail assembled from three different log streams. And now, as AI agents start calling enterprise APIs, a whole new category of tooling that doesn't fit into any of the existing infrastructure.

We built Zerq because this problem is not a minor inconvenience. It is the thing that makes enterprise API programs slow, expensive, and genuinely risky — and the existing market had treated it as an acceptable tradeoff for too long.


What the market got wrong

The API management market was built around a reasonable idea: a gateway handles traffic, a portal handles developers, and you wire them together. For a while, that worked. APIs were called by apps. Apps were built by known developers. The integration surface was manageable.

That model started breaking under three pressures that hit at the same time.

The first was compliance. Regulated industries — banking, healthcare, government, fintech — needed more than a proxy in front of their APIs. They needed to know exactly who accessed what, when, with which credentials, and whether anything changed in the configuration since the last audit. A gateway that routes traffic and a portal that issues keys don't give you that. You get two partial pictures that have to be manually reconciled whenever a regulator asks a question.

The second was workflow complexity. Real enterprise API programs involve routing logic, request transformation, multi-backend aggregation, error handling, conditional branching, and partner-specific response shapes. Building all of that in code — custom middleware, bespoke plugins, hand-rolled Lambda functions — creates a maintenance burden that grows with every integration. Teams were spending more engineering time maintaining gateway logic than building the APIs that actually mattered.

The third was AI. In 2025 and into 2026, AI agents and copilots started calling enterprise APIs at scale. Not through the gateway — around it. Because the gateway wasn't built for an AI client. There was no standard way for an agent to discover available APIs. Auth flows designed for apps didn't map cleanly to agents. The access model had no concept of "this AI assistant should only see these three API products." So teams gave agents long-lived keys, pointed them at backend services directly, and created a second tier of API access that no compliance officer could see and no security team could govern.

Each of these pressures was being addressed by a different tool, from a different vendor, with a different data model, a different auth layer, and a different approach to logging. The result was sprawl that looked like infrastructure but functioned like technical debt.


The decision to build everything together

We could have built a better gateway. Or a better developer portal. Or a better workflow engine. Any one of those would have been a defensible product.

We chose not to, because the problem isn't any individual tool. The problem is that the tools don't work together — and in regulated enterprise environments, the seams between tools are where compliance gaps live.

When your gateway and your developer portal are from different vendors, your access model is maintained in two places. When your workflow logic lives in custom code outside the gateway, changes to routing rules don't appear in your audit trail. When your AI agents use a different auth path than your apps, you have two audit trails and the one that covers AI traffic is the one your compliance team probably can't see. When your platform automation uses separate credentials from your admin UI, every scripted change is invisible to your compliance record.

So we built Zerq as one platform. Twelve capabilities. One deployment. One access model. One audit trail. Everything in your environment.


The platform — all twelve capabilities

API management and full lifecycle — define, version, and publish APIs with drafts, publishing workflows, and organised API products. Import and export standard API specs. Manage who can access what. One place where the API catalog lives and teams stay in sync.

API gateway — a single Go binary, no vendor-specific runtime required. Authentication, authorisation, rate limiting, routing, caching, duplicate request protection, and streaming — all in one runtime. Deploy with Docker Compose for development and Kubernetes for production with multi-replica scaling and zero-downtime rolling updates.

Workflow designer — customise behaviour per API without shipping custom code. Build conditional routing, branches, multi-backend aggregation, request and response transformation, error handling, and retries through a visual interface. Reference data from previous steps. Add an optional code node when genuinely needed. Changes are versioned and audited. Your operations team owns the logic without engineering tickets.

Access and security — every request is verified. Role-based access control with four roles — view, edit, admin, and audit — with separation of duties built in. Single sign-on and enterprise authentication via OIDC and SAML. Token and certificate validation. IP allowlists, credential encryption at rest, key rotation on schedule or post-compromise. Secrets referenced from your environment — HashiCorp Vault or equivalent — so sensitive values never sit in configuration files.

MCP gateway for AI agents — AI tools connect via the Model Context Protocol and use the same gateway, credentials, access controls, rate limits, and audit trail as traditional apps. No separate deployment. No separate credential path. An AI agent is just another client with a profile that limits what it can discover and call. Nothing bypasses the control plane.

Platform automation via Management MCP — platform engineers, scripts, CI/CD pipelines, and AI assistants manage the API catalog through Management MCP using the same OIDC session and role-based access as the admin UI. Create collections, update proxies, modify workflow definitions, rotate credentials — all appearing in the same audit log as changes made through the console. One auth model for humans and automation. No separate API keys for scripts. No shadow admin plane.

Zerq Copilot with bring-your-own-model — two governed experiences in one. Copilot for Management lets operations teams configure collections, proxies, workflows, policies, clients, credentials, audit history, and metrics through natural language via Management MCP, under their existing OIDC session. Copilot for Gateway lets API consumers in the developer portal explore and test APIs through conversation via Gateway MCP, scoped strictly to what they are authorised to use. Connect OpenAI, Anthropic, Google, Azure OpenAI, Amazon Bedrock, Groq, Ollama, OpenRouter, or any OpenAI-compatible endpoint. LLM credentials stay server-side. The gateway stays authoritative.

Developer portal — passwordless sign-in via magic link. Per-partner scoped access — each partner sees only the API products they are authorised to use, not your full catalog. Self-service API discovery, try-it-in-browser with parameter and header configuration, OpenAPI spec download, copy-curl, and sandbox vs production profile switching. Partners go from invite to first API call without involving your engineering team.

Observability and metrics — Prometheus integration and structured JSON logging. Real-time dashboards, request logs, and response times. Filter by product, partner, and time range. Logs that plug directly into your SIEM. AI-assisted anomaly detection that surfaces unusual traffic patterns and suggests rate limit and policy adjustments before they become incidents.

Compliance and audit — full audit trail of every configuration change and every API request, stored in your own MongoDB instance. Every action — whether taken from the admin console, a script, Copilot, or an automation pipeline — appears with the same identity fields, timestamp, and change record. Configurable log retention. Dedicated audit role for compliance teams with read-only access and no ability to modify gateway configuration. Enterprise authentication ready for regulated industries.

Performance — real-time and streaming support. Optional response caching for read-heavy endpoints. Protection against duplicate requests to avoid redundant upstream calls and double charges. Health checks and readiness probes for Kubernetes orchestrators. Multi-replica scaling with zero-downtime rolling updates so you can patch and scale without dropping traffic.

Deployment flexibility — on-premises, hybrid, air-gapped, or your cloud. Docker Compose for development. Kubernetes for production. The same product, the same capabilities, and the same operating model in every deployment — air-gapped is not a stripped-down version. No outbound runtime dependency during normal operation. No traffic, config data, or audit logs in Zerq's systems. Everything stays in your environment.


What this changes in practice

The difference shows up most clearly when something goes wrong — or when a regulator asks a question.

In the old model, answering "which partners accessed the payments API in the last 30 days, and did any of them hit rate limits?" involves correlating logs from the gateway, the developer portal, and possibly a separate analytics service. If AI agents were involved, add a fourth system. If a script made a config change, add a fifth.

In Zerq, that query runs against one audit trail. Same data model for apps, partners, AI agents, and automation. Same filter interface. Results in seconds, not hours.

The workflow designer changes the relationship between the platform team and the engineering team. When routing logic and transformation rules live in visual workflows rather than custom code, operations teams can own and modify gateway behaviour without filing engineering tickets. A bank that wants to add a new transformation rule for a specific TPP doesn't need a deployment. They make the change in the workflow designer, it goes through the same audit trail as everything else, and it's live.

Platform automation changes how the platform itself scales. When a CI/CD pipeline can create a new collection, wire proxies, and publish a product using the same OIDC identity as the admin team, infrastructure-as-code for your API platform becomes real — and every change is audited whether it came from a human or a script.

Zerq Copilot changes how the platform is managed day to day. Ask "why are 502s spiking on /orders?" and Copilot correlates errors, latency data, and recent traffic changes in one thread. Ask it to onboard a new partner and it creates the client, binds the policy, configures the profile, and tells you exactly what it changed before making anything permanent. The model you use is your choice. The enforcement stays on the gateway.


Why we built it for regulated industries specifically

We could have built a developer-first gateway with a clean API and good documentation. There are already several of those. They are good products for teams building cloud-native SaaS applications.

Regulated industries have different requirements. Data cannot leave a defined perimeter. Audit trails must be complete, tamper-evident, and queryable by compliance teams who are not the same people as the engineering team. Access control must support separation of duties — the person who can change rate limits should not be the same person who can query audit logs. Air-gapped deployment is not a niche requirement; for government agencies and defence organisations it is a procurement condition.

These requirements aren't features you add on top of an existing gateway. They shape the architecture from the start. MongoDB runs in the customer's instance, not ours. The control plane runs in the customer's environment, not a hosted SaaS. The audit role is a first-class concept in the access model, not an admin filter. Platform automation uses the same identity as the admin UI, so scripted changes appear in the same compliance record as manual ones. Air-gapped deployment works without changes because there are no outbound runtime dependencies by design.


What we want to be

We want Zerq to be the infrastructure layer that makes enterprise API programs work properly — for apps today, for AI agents as they become a normal part of enterprise operations, and for the automation that platform teams need to scale without scaling headcount.

The sprawl of tools that most enterprise platform teams manage is not inevitable. It is the result of a market that built components and left the integration as the customer's problem. We built a platform instead.

One platform. Your infrastructure. Full control.


Zerq brings API management, API gateway, workflow designer, access and security, developer portal, AI agent access via Gateway MCP, platform automation via Management MCP, Zerq Copilot with bring-your-own-model, observability and metrics, compliance and audit, performance, and deployment flexibility together in one deployment — running entirely in your environment, built for regulated industries. See all capabilities or request a demo to walk through your specific requirements.