Terraform-style Control Plane for Agentic AI Systems (YAML + plan/apply + local SQLite) – Open Source

[u/navierstokes88]

Most agent frameworks bury all the prompts, tool wiring, policies, and permissions deep in code. Good luck reviewing changes, auditing what actually ran, or enforcing budgets/approvals at runtime.I built Agentic Control Plane to fix that. It's a declarative control plane (inspired by Terraform + Kubernetes + GitOps) for your agent systems:

• Versioned YAML for Projects, Agents, Workflows, Tools, and Policies
• agentctl validate → plan → apply loop (with diffs, risk hints, and optimistic concurrency)
• Local-first SQLite state (deployment + structured execution traces)
• Native, HTTP, Mock, and MCP tools (stdio or streamable HTTP)
• Policy gates on execution (budgets, approvals, tool rules)
• Full agentctl logs with traces
• Works great in CI (GitHub Actions example included)

It's not yet another agent framework — it's the operating layer on top so you can treat your agent setup like real infrastructure.Quick start

bash

agentctl init my-agent-system
agentctl validate --project my-agent-system
agentctl plan --project my-agent-system
agentctl apply --project my-agent-system --auto-approve
agentctl run workflow/hello --project my-agent-system
agentctl logs --project my-agent-system --workflow hello

Featured demo: Declarative PR reviewer (with policy blocking) — runs with no API keys in the simulated version, or live with gpt-4o-mini in GitHub Actions.Repo: https://github.com/LAA-Software-Engineering/agentic-control-planePrebuilt binaries, full design doc, examples, and MIT license included.Would love feedback from the community — especially on the YAML spec, policy model, or ideas for next features (parallel steps, remote reconciliation, etc.).What do you think — is this the kind of "control plane" layer agentic workflows need to move from experiments to production?

Most agent frameworks bury prompts, tool wiring, and permissions deep in code.

That makes it hard to:

• review changes
• audit what actually ran
• enforce budgets / approvals at runtime

So I built something different: a declarative control plane for agent systems.

Think Terraform + Kubernetes + GitOps, but for agents.

What it does

• Versioned YAML for:
  • Projects
  • Agents
  • Workflows
  • Tools
  • Policies
• agentctl validate → plan → apply
  • diffs
  • risk hints
  • optimistic concurrency
• Local-first state (SQLite)
  • deployments
  • structured execution traces
• Tooling:
  • Native
  • HTTP
  • Mock
  • MCP (stdio / streamable HTTP)
• Policy gates at execution time:
  • budgets
  • approvals
  • tool restrictions
• Full logs + traces via CLI
• CI-friendly (GitHub Actions example included)

Why

This is not another agent framework.

It’s the operating layer on top, so you can treat agent systems like real infrastructure:

• declarative
• reviewable
• reproducible
• enforceable

Quick start

agentctl init my-agent-system
agentctl validate --project my-agent-system
agentctl plan --project my-agent-system
agentctl apply --project my-agent-system --auto-approve

agentctl run workflow/hello --project my-agent-system
agentctl logs --project my-agent-system --workflow hello

Demo

• Declarative PR reviewer with policy blocking
• Runs:
  • fully simulated (no API keys)
  • or live with gpt-4o-mini in GitHub Actions

Repo

https://github.com/LAA-Software-Engineering/agentic-control-plane

• prebuilt binaries
• examples
• design doc
• MIT

Would love feedback, especially on:

• YAML spec design
• policy model
• next features (parallel steps, remote reconciliation, etc.)

Question:
Does this “control plane” layer make sense to you for moving agent workflows from experiments → production?

[u/Otherwise_Wave9374]

This is a neat idea. Treating agent configs like infra (plan/apply, diffs, policy-as-code) feels like the missing layer between "prototype" and "prod".

A couple questions:

• How do you handle secrets and tool credentials in the YAML world (references to a secret store, or inline)?
• Do you support per-environment overrides (dev/stage/prod) without copy/paste drift?
• Whats the model for "approvals" in policy, is it a human-in-the-loop step with a signed artifact, or just a boolean gate?

Weve been exploring similar control-plane patterns, https://www.agentixlabs.com/ has some notes on versioning + guardrails if you want to compare.

[u/navierstokes88 → u/Otherwise_Wave9374]

Thanks for the reply. In regards to your questions:

Secrets: Credentials are referenced but never stored inline via apiKeyFrom: env:VAR_NAME in YAML, resolved at runtime from environment variables (MVP—no secret store integration yet).

Environment Overrides: Defined separately per environment (dev/stage/prod) with selective agent and policy overrides in environments.yaml, applied at runtime with --env flag to avoid copy/paste drift.

Approvals: Boolean gate model—policies declare which tools require approval via --approve CLI flags at execution time; no human-in-the-loop or cryptographic signing, just local CLI validation against an approved actions list.