"Kai: Building an Open-Source Pipeline Platform for AI-Driven Development"

Full Story

A while ago, I found myself thinking about a gap in the AI coding tool landscape. Tools like opencode and Claude Code are fantastic at solving individual tasks, but when you need to chain multiple steps together -- lint, test, review, deploy -- there is no orchestration layer. You run one command, wait, run another, check the output manually. It feels like scripting before CI/CD existed.

So I built Kai: an open-source platform that brings CI/CD-style rigor to AI-assisted development.

Think of it as a pipeline engine where the steps are not shell commands or Jenkins jobs, but AI agent missions. Each step gets assigned to an agent worker, executes in a sandboxed environment, runs through validation gates, and either proceeds to the next step or blocks for human review.

Architecture

Kai is a polyglot system with three main layers:

• Orchestrator (Go) -- The central control plane. It parses pipeline YAML, builds a DAG from step dependencies, dispatches missions to agents, runs validation gates, manages git operations, and persists audit events.

• Agent Runtime (C# .NET) -- The actual AI coding agent. It implements a full tool-use loop against any OpenAI-compatible LLM. Read files, write code, run commands, search, glob -- the same primitives you expect from any coding assistant, but now operating inside a pipeline step.

• Frontends (React 19) -- Three separate UIs: the pipeline dashboard for monitoring runs, the plan builder for creating pipelines conversationally, and the observability viewer for logs.

Communication between the orchestrator and agents happens over gRPC with server-side streaming. This lets real-time logs and file changes flow back to the orchestrator as the agent works.

How a Pipeline Runs

The flow is straightforward:

1. Spec -- You describe what you want in plain English to the Plan Builder, which converts it into a structured spec and then into a pipeline.yaml via an LLM.

2. Submit -- The pipeline is submitted to the orchestrator via REST API, the web UI, or the kaictl CLI.

3. Scheduling -- The orchestrator parses the YAML, validates it, builds a DAG, and starts executing ready steps. Steps with depends_on run in parallel when their dependencies are satisfied.

4. Execution -- Each step is dispatched to an idle agent worker. The worker clones the repo into a sandboxed temp directory, removes the remote origin (so the AI cannot push on its own), spawns the runner plugin, and streams logs back in real time.

5. Validation -- When the AI finishes, the orchestrator runs validation gates. Built-in gates include exit_zero, lint, typecheck, tests, diff_review, and approval. If human approval is required, the step blocks and waits for manual sign-off.

6. Git -- After all steps pass, the agent commits and pushes (or creates a PR). The remote is briefly re-added for the controlled push, then removed again. If the branch has advanced, it rebases and retries.

7. Audit -- Every stage writes audit events. Fourteen event types, event-sourced, stored in PostgreSQL or in-memory for development.

Design Decisions Worth Mentioning

Pluggable everything. Runners, validation gates, git providers, secret backends, archive backends -- all are binary plugins discovered at runtime from a configurable directory. Each plugin is just a directory with a plugin.json manifest and an executable. This means you can swap out kai-code for opencode or Claude Code without changing the orchestrator.

Sandbox security. The agent workspace is a temp directory with the repo cloned inside. The remote origin is removed before the AI tool runs and re-added only for the controlled push. The sandbox also enforces allowed_dirs, allowed_tools, and allowed_commands per step. Even if the agent goes rogue, it cannot push to your repository.

Zero-dependency UIs. The three React frontends have no external dependencies -- no router, no UI library, no state management. Everything is vanilla React 19 with native fetch, native EventSource for SSE, and pure CSS custom properties. This keeps the maintenance surface small and the builds fast.

Observability without agent awareness. Agents do not know about the observability service. They send logs to the orchestrator via gRPC, and the orchestrator forwards them. This centralizes correlation IDs (run, step, mission) and avoids configuring every agent with yet another endpoint.

Practical Impact

• AI-driven tasks now run as reproducible, auditable pipelines instead of ad-hoc terminal sessions.
• Validation gates catch issues early, reducing the back-and-forth of manual review.
• Human approval checkpoints keep a human in the loop for critical decisions.
• The plugin system makes it extensible to any AI coding tool or validation strategy.
• Everything runs on your own infrastructure with any OpenAI-compatible LLM, including local Ollama instances.

What is Next

I have been experimenting with Small Language Models (SLMs) for specific pipeline tasks like secret scanning and code quality checks -- sub-10ms inference on CPU, trained for a single purpose. The architecture already supports this through the plugin system, so it is a natural extension.

Kai is open-source and available at github.com/traneo/kai. The repository includes the full platform, documentation, examples, and a Docker Compose setup to get started quickly.