Skip to main content

Architecture — how the CI/CD engine fits together

Agentic Pipeline is a CI/CD engine built for fleets of AI coding agents. It owns the full chain from GitHub webhook intake through orchestration, executor runs, the required check, and ship-on-green deploys. Four Agentic Pipeline services run on isolated machines over a private network: the control plane, executor, MCP server, and dashboard.

Legend: green = Agentic Pipeline services (private network) · blue = external actors.

The four services​

Control plane. The control plane receives GitHub webhooks, verifies HMAC signatures, and fails closed on invalid payloads. It orchestrates runs, stores configuration in Postgres, and exposes the API that powers the dashboard and MCP server. When a run completes, the control plane posts the required GitHub check verdict back to your repo.

Executor. The executor runs on pre-warmed machines where your repo, dependencies, and Docker layers are already present. When the control plane dispatches a run, the executor executes each stage in your recipe as a named shell command. These machines sit on a private network and never receive traffic directly from GitHub or agents.

MCP server. The MCP server exposes 24 tools that coding agents use to operate CI/CD over Agentic Pipeline. Agents authenticate with OAuth or a bearer token and receive a scoped token for the control plane API. Status checks, log tails, diagnoses, re-runs, sandbox runs, recipe promotion, onboarding, and the ship-and-follow loop all flow through this surface. Sessions and long-running follow state persist in Postgres, so agents survive service restarts without losing their place.

Dashboard. The dashboard is the human-facing UI for runs, configuration, and deploy state. It proxies API requests to the control plane and serves this documentation site. You use it to inspect runs; agents typically use the MCP server instead.

What this means for your repo​

Your repo keeps GitHub PRs, reviews, and branch protection unchanged. Agentic Pipeline posts the RunsGreen required check when a run finishes, so merge gates behave the same as with any other CI provider. Opting in means shipping a recipe format in .slipstream.json; once configured, every push follows the push to green path on pre-warmed executors.