Introduction

Valved is a control plane plus an AI harness, over independently-versioned dlt/dbt/sql components — not a project that contains them. The value proposition: build, schedule, and monitor pipelines — all with AI.

Valved schedules, orchestrates, and monitors dlt (extract & load) + dbt (transform) + sql pipelines. Its AI harness builds and deploys those components for you — or you bring your own, built outside Valved, and Valved just orchestrates them.

The two halves

The control plane is the thing you run (valved serve, backed by Postgres). It holds the orchestration entities — pipelines, steps, schedules, jobs, runs, deploys — plus versioned references to your code components. It does not contain the components’ code. Each component is independently versioned and follows its own repo / CI-CD / lifecycle. A pipeline references each component by name and composes them into a step DAG.

The AI harness is a Claude-Code-style agentic engine that authors those components. A main orchestration loop classifies your intent and delegates to domain subagents:

• a DLT engineer — writes dlt sources, resources, and pipelines
• a dbt engineer — writes dbt models, tests, and schema docs
• a pipeline engineer — composes components into a step DAG
• a SQL specialist — writes, explains, and modifies ad-hoc and sql-step SQL against a connection’s dialect
• an explorer — answers read-only questions about your project (valved ask)

Alongside these sit three read-only reviewers (dlt-qa, dlt-security, dbt-qa) that vet what the engineers author — see Every authored diff is reviewed — and a separate recovery agent that handles failed runs.

The harness supplies terminal-grade tools — edit, create_file, bash (allowlisted and gated per command), glob, grep, read_file — alongside domain tools like sql, dbt_manifest, dbt_conventions, dbt_verify, dlt_library, and rest_api_explore. Agents do not all get the same set: each declares its grant in its own definition, and the grants are narrow on purpose. The DLT engineer holds bash, because it has to run the pipeline it wrote; the dbt engineer does not, and reaches the warehouse through sql and dbt_verify instead.

Every agent then runs behind a permission gate with four modes in a total order: read_only < plan < build < deploy. An agent file declares only a ceiling (max_mode); the mode it actually runs at is min(caller's mode, that ceiling). Write tools are denied below build regardless of what an agent was granted, which is why a valved plan run can read, introspect, and design but cannot touch a file.

Web tools are not wired

web_fetch and web_search exist in the tool taxonomy, and web_fetch appears in some agents’ grants — but no fetcher or searcher backend is wired in the shipped runtime, so calling either returns … is not configured in this runtime. Agents work from your repository, your warehouse, the dbt manifest, and Valved’s curated dlt source corpus. Treat them as offline.

Verifying by execution

Agents are built to ground claims in real tool output rather than assert them. The DLT engineer holds gated bash and is directed not to consider its work done until the pipeline runs green. The dbt engineer holds dbt_verify, which runs real dbt build / dbt run / dbt test over a required selector and returns the per-model result.

How far that goes depends on your project:

• dbt_verify is only offered when the engine is on disk. The project needs exactly one [components.dbt] block, that block must pin dbt_engine and dbt_version, and the pinned engine must be present in Valved’s managed venv — which is what valved connect installs for a bundled component. If any of that is missing the tool is simply not handed to the agent (no error, no warning), and the dbt engineer authors without executing. A dbt component discovered by convention alone carries no pin, so it never gets the tool; neither does one configured with dbt_env = "external", since connect installs nothing into the managed venv for it.
• Materializing subcommands need build mode. build, run, seed, and snapshot write to the warehouse, so dbt_verify refuses them below build. During valved plan the agent can run dbt test, but nothing is materialized — by design, since a plan is reviewed before any code is written.

Every authored diff is reviewed

After the engineers author, the orchestrator — not the engineer, which never reviews its own work — routes the resulting diff through a sequence of adversarial reviewers before any build is recorded.

• The reviewers are read-only. They are delegated at read_only, and each declares max_mode: read_only, so the clamp holds twice. They report; they never edit or fix.
• They see only {diff, goal}. Never the engineer’s transcript, reasoning, or self-assessment. The diff is rendered from the engineers’ harness-tracked authored file set against a pre-build snapshot, per file, so a multi-engine build cannot hide one engineer’s work behind another’s.
• The sequence follows who authored. dlt work is reviewed by dlt-qa then dlt-security; dbt work by dbt-qa. A build that touched both runs all three, de-duplicated and order-stable.
• blocker and major findings stop the build. No Build row is written, the plan stays drafted, and the findings come back to you. minor and info findings surface as warnings and let the build through.

Which builds the gate covers

The gate runs on builds produced by multi-engine decomposition — the normal path for a plan that spans dlt and dbt. A single-engine plan falls through to the older single-loop build path, which records no review verdict. A build authored only by the pipeline engineer has no reviewer family assigned to it and ships ungated (Valved logs a warning when this happens). Read a build’s review manifest block if you need to know which case you got.

Simple mode is the default

A small team can keep the control-plane config and all components in one repo — the delightful greenfield default — without changing the architecture. The control plane still references its components; they just happen to be co-located. Components can later graduate to separate repos (pinned by ref) with one guided command and no pipeline rewrites.

Two adoption modes, both first-class

• Build-with-Valved — the AI authors components into your repos, and the control plane schedules them.
• Orchestration-only — you bring existing dlt/dbt/sql, Valved references them by version and only composes, schedules, and monitors. This is a central path, not a corner case — it’s exactly why the control plane references components rather than owning them.

Who Valved is for

• The staff data engineer at a mid-size company who owns the data platform, has dbt on Snowflake, maintains a few dozen pipelines, and wants to delegate the routine 60% of their work.
• The analytics engineer who lives in dbt and wants agent assistance for model authoring, refactoring, and test generation that respects their team’s conventions.
• The agent developer building their own data-stack agent who wants a programmable backend (REST / MCP) that can plan, build, deploy, and run pipelines — Valved is headless by default. Note the surfaces are not at parity: project setup is CLI-only, and POST /plans accepts only {goal, pipeline_name}, so the CLI’s plan --refine has no REST or MCP equivalent.

Valved targets the SMB-to-mid-market segment. It is not designed for the long tail of large-enterprise platform requirements (multi-cluster orchestration, fine-grained RBAC across thousands of resources, custom asset-graph orchestration) — those teams are better served by Airflow or Dagster.

Where to next

InstallationInstall the CLI and stand up Postgres.

QuickstartBuild your first pipeline end-to-end.

The core loopThe seven-step lifecycle every interaction flows through.

SurfacesCLI, REST, MCP, and the static UI.