Valved

From intent to a reviewable pull request

Valved takes a goal in plain English — “make stg_orders incremental”, “ingest the Stripe charges API into a Snowflake table” — turns it into a reviewable plan, and, when you approve, materializes the working code and opens a pull request in your repo: dbt models, Python dlt sources, SQL, tests, schema docs.

Agents are built to verify by executing, not by guessing. The DLT engineer holds gated bash and is directed not to call its work done until the pipeline runs green. The dbt engineer holds a dbt_verify tool that runs real dbt build / dbt test against the models it just wrote and reads the per-model result.

The authored diff then goes to adversarial reviewers before the build is recorded, and only after that does the control plane schedule, run, and monitor the pipeline on a durable job queue.

dbt execution depends on a provisioned engine

dbt_verify is only handed to the dbt engineer when the project’s [components.dbt] block pins a dbt engine and that engine is installed on disk — in practice, after you have run valved connect. Otherwise the tool is quietly not offered at all, and the dbt engineer authors without executing. Even when it is offered, the materializing subcommands (build, run, seed, snapshot) are refused below build mode, so a valved plan run designs and verifies nothing.

valved plan "ingest the Stripe charges API into raw_stripe, then a staging model stg_charges"
valved build <plan_id>          # writes the dlt source and the dbt model into your tree
valved run <pipeline> --watch   # execute on demand; data lands in your warehouse
valved deploy <pipeline>        # open a reviewable PR with the built code

AI harness for data work

A Claude-Code-style agentic engine — a main orchestrator that delegates to domain subagents (a DLT engineer, a dbt engineer, a pipeline engineer, a SQL specialist, an explorer, plus a separate recovery agent for failed runs), armed with terminal-grade tools and running behind a permission gate that clamps each one to the narrower of the caller’s mode and its own declared ceiling.

A narrow control plane

Scheduled execution of dlt, dbt, sql and python steps as a DAG over a Postgres job queue: multi-worker claiming, crash recovery, retries, structured logs, and webhooks — including straight into Slack. A run can finish with warnings that stay in view rather than pass for clean. Deliberately not a general-purpose orchestrator.

Adversarial review gate

When agents author a diff, the orchestrator routes it through read-only reviewers before the build is recorded — dlt-qa and dlt-security for dlt work, dbt-qa for dbt. Each sees only {diff, goal}, never the engineer’s transcript. A blocker or major finding stops the build: no Build row, and the findings come back to you. Which builds this covers →

A console for operators

A dashboard that answers did anything break?, each pipeline drawn as a graph you can edit, run pages with estimated finish times, a dbt step’s models drawn live as they build, a calendar of runs and scheduled firings, and trends per pipeline and per step. The web console →

Runs inside your Snowflake account

valved serve — the API, scheduler and worker pool — runs as a long-lived Snowpark Container Services service, so scheduled pipelines fire inside your account with no machine of yours left running. The image carries the dbt engine and the console. Deploying on SPCS →

Headless first

The valved CLI covers the whole project. A FastAPI REST API carries the core loop and the control plane, and an MCP server is generated from that API’s OpenAPI schema — so MCP tracks REST by construction. The console sits on the same API. These are not equal surfaces; see below.

Bring your own, or build with AI

Build-with-Valved (agents author components into your repos) or orchestration-only (bring existing dlt/dbt/sql/python; Valved just composes, schedules, and monitors). Both are first-class.

What each surface actually covers

Valved is headless in the sense that it is driven by machines as well as people — but the five surfaces are not interchangeable, and it’s worth knowing where the edges are before you build against one.

Surface	Covers
CLI	The whole project: setup (init, connect, auth, target, component), the core loop (plan, build, deploy, run), schedules, memory, and the inspection commands. It does not manage webhooks, which are REST-only.
REST	The core loop and the control plane: create a plan, run a build, deploy, enqueue and stream runs, register and edit pipeline definitions and components, pause, resume and reschedule schedules, mint tokens, manage and test webhooks, read metrics, step trends, dbt graphs and memory.
MCP	Generated from REST’s OpenAPI document, one tool per operation, minus the log-streaming endpoint. It can never be wider than REST, and it talks to a running valved serve.
Web console	An interactive UI over REST: watch, trigger, cancel and retry runs; draw, edit and create pipelines; manage schedules, components and webhooks; start plans, builds and asks. Ships in the container image, not the Python package.
Static UI	Read-only viewing — runs, per-run logs, pipelines, agents, skills. Ships in the package. No authoring, no actions.

Three gaps are worth calling out, because they’ll bite if you assume parity:

• Project setup is CLI-only. valved init, valved connect, valved auth, creating or renaming targets, graduating a component to its own repo, editing memory files, registering an external MCP server, and running EL artifacts directly all exist only as CLI commands. REST reads targets, agents, skills, and registered MCP servers but cannot change them. Components and pipeline definitions are the exception: both register, patch, and deregister over REST, because in a container deployment the API is the only way to change them.
• POST /plans takes only {goal, pipeline_name}. The CLI’s valved plan --refine <plan_id> (which records a new plan with parent_plan_id set) and its --table / --database / --schema pre-seeds have no REST equivalent at all, and therefore no MCP tool. A client driving Valved over REST or MCP can create a plan and build it, but cannot iterate on one.
• pip install valved has no console. The console is built into the container image. From PyPI you get the API it runs on, and the static UI.

Start here

IntroductionWhat Valved is and who it's for.

InstallationInstall the CLI and stand up the Postgres state store.

Quickstartinit → plan → build → run → deploy in a few minutes.

The core loopIntent → Plan → Build → Run → Deploy → Schedule → Observe.

Web consoleThe dashboard, pipeline and dbt graphs, the calendar, and trends.

Deploying on SPCSRun Valved as a service inside your Snowflake account.

---

Open source & governance. Valved is Apache 2.0. There is no license check, entitlement flag, or paid tier anywhere in the codebase — the CLI, the REST API, the MCP server, the built-in agents, the console, and the static UI all ship in the repository, and no endpoint or MCP tool is withheld from it. The project’s OSS_COMMITMENT.md is the governance promise about where that line stays.