dltHub: dlt made agents good at building pipelines. Now they're safe enough to run for your whole team.

TL;DR: dlt made agents good at building pipelines. dltHub makes their work safe to run. It's the agentic data and managed-infra layer for your whole team. Two of its six building blocks changed the most since May: the AI Harness, which now ships agentic alerts, a rebuilt UI for how humans and agents work together, and skills built for real production messes, and Managed Infrastructure, which now also lets people and their agents build together as a team, and scale without anyone carrying a pager.

Try dltHub for two weeks with one prompt: Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub or book a demo.

Coding agents got good enough over the last year to write entire data pipelines - not by hand-rolling everything, but because dlt already gives them the building blocks: authentication, pagination, schema evolution, incremental loading. The agent writes a thin declarative layer; dlt does the rest, and the community ships tens of thousands of custom sources a month this way.

But, as we wrote when we launched an early version of the dltHub AI Harness in March, writing the code was never the hard part. Everything around it is: does the data match what you expected, who changed this pipeline and why, what happens when the API breaks at 3am on a Saturday. dltHub closes that gap - your agents build and maintain pipelines, dltHub keeps everything validated, versioned, and auditable, and your team stays the owner.

We build dltHub for data teams in scale-ups and enterprises, 2 to 10 engineers serving 10+ analysts, in industries where data must be governed and audited from lifescience to finance.

From solo pros to whole teams

When we launched dltHub in May, it initially was aimed to work well enough for solo practitioners: individual power dlt users - people who wanted managed infrastructure and the best agentic support for data engineering tasks.

From the moment we launched instead of single agentic pros, whole agentic teams showed up. Data leads with two, five, ten engineers, serving dozens of analysts, started asking a different set of questions, all versions of the same one: how do we become a team where agents work the data stack alongside humans? Concretely - how do we work together on this? How does it scale without a platform team? How do we keep staging and production separate when a pipeline takes minutes to write? How do we hear about failures before our stakeholders do?

It was also not only data engineers building. Analytics engineers and data analysts started shipping their own pipelines, because with an agent and the right harness, the long tail of sources no longer needs a data engineer's calendar. A recent favorite: a drug safety expert with ten years in pharmacovigilance built his first pipeline on openFDA adverse event data. Domain knowledge plus an agent, no ticket queue.

There's no single release behind that answer. It's what dltHub has become since - and this is the first time we're saying it plainly, in one place.

dltHub is six building blocks across two layers: an agentic layer - the AI Harness and Context Catalog - that's your agent's interface, sitting on top of a managed infrastructure layer - ingestion, transformation, orchestration, and the infrastructure itself. Two of them changed the most since May: the AI Harness, which makes your agent's work safe to run, and Managed Infrastructure, which now also lets people and their agents build together as a team, and scale without anyone carrying a pager. That's the shape we'll use to talk about dltHub from here - here's where those two stand today.

Martin Seifert runs his stack this way, 25 sources through the Harness with his coding agent. Watch his walkthrough and explore his setup, published as a blueprint.

1. The AI Harness: your agent's interface to dltHub

The outcome: a production pipeline in one agent session, and Day 2 handled as a review instead of a morning.

The dltHub AI Harness is your agent's interface to dltHub. It gives your coding agent the skills, platform tools, and run context to operate pipelines in production: run, fix, maintain, and, when needed, build new ones to your team's conventions. It works with Claude, Codex, Cursor, or any agent you already use.

The skills are open on GitHub: toolkits for REST API, SQL, and filesystem pipelines, data quality, data exploration, transformations, deployment, and performance. A workspace MCP server hands the agent pipeline state, schemas, tables, and row counts, so it inspects production instead of guessing. Source discovery runs against 10,100+ sources. Your agent never sees your credentials. We ship new stuff to the dltHub AI Harness all the time. That's the point of it being ours to maintain: your team runs on skills we keep current, instead of one developer quietly becoming the person who maintains a pile of internal agent scripts on the side, which was never supposed to be their job.

The skills carry real judgment, not just boilerplate:

"Hey team, I just wanted to reiterate how damned cool dltHub continues to be, along with the agentic workflows. We have an absolute mountain of Klaviyo data and due to API rate limits it's very slow and was prone to failure on extraction. The agent devised a tiered chunking strategy which does 7 days, then if it times out drops to 1 day, then 1 hour, and has managed to get through some highly problematic data patterns without missing a beat. Super impressive, you guys are amazing!" (Jim, Pinter, running his company's data with what he calls a team of agents)

Try the dltHub developer experience with your coding agent:

Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub

With the dltHub AI Harness, your coding agent scaffolds a workspace, builds a pipeline, deploys it, and hands you a notebook to explore the data - all from that one prompt. Since the May launch the same thing keeps coming back from users: Day 2 is where an AI harness actually earns its value.

For your agent to earn that value, it needs to hear about trouble on your managed infrastructure the moment it happens - so dltHub has agentic alerts. The debug and validate workflows isolate the failure, the workspace tools pull run history and traces, the data quality checks confirm the fix holds. You get a diagnosis and, usually, the fix as a reviewable diff. A broken pipeline stops being your morning and becomes a review.

Below a real example: a schema violation broke zendesk_tickets in production. The agent traced it to a new column, evolved the contract instead of freezing on it, confirmed data quality on staging, and opened the fix as a reviewable PR - no 3am page, just a diff waiting for you.

Martin Seifert runs on exactly this pitch. He's the data lead at the Swiss NGO Pro Juventute, and inside OpenCode he splits the work across four subagents: a Data Engineer for ingestion, a Data Modeler for the semantic layer, a Dashboard Developer for data apps, and a Platform Admin that handles infra, ops, and the build-run-fix fallback - "it tries to fix it, presents the fix to me before deploying anything." Twenty-five production pipelines into Snowflake, 155 million rows moved in a week, one engineer, no platform team.

The two things he calls out as the real value map straight onto the agentic layer above: the skills - "one of the more hidden benefits is the skills; the agent skills maintained by dltHub work very well, particularly for deploying a pipeline, building one from scratch" - and the observability that comes with them - "everywhere else I've run dlt, I had to build observability myself just to see if pipelines ran." Underneath, he calls dltHub "a managed service on top of a couple of VMs": his Platform Admin agent runs dltHub, Snowflake containers, and an on-prem VM on one framework, because dlt runs wherever Python runs.

Watch the full walkthrough, read how he set it up, and explore his setup, published as a blueprint.

We also continue to rebuild the dltHub UI for the humans who answer for what agents do. Pipeline health is now visible at a glance - runs, rows loaded, last-run status, one click to logs and traces - so knowing where things stand doesn't require pinging someone.

"Totally different process, but way nicer than the old world." (Jim, Pinter, running his company's data with what he calls a team of agents)

2. Teams: workspaces on Managed Infrastructure

The outcome: ten people and their agents on one codebase, every pipeline with an owner. Merged means deployed.

dltHub now has organizations and workspaces. Invite colleagues by email, split work across staging and production or by domain, and see at the organization level what runs where and what it consumes.

Deployment is a CLI command, so it drops into the GitHub or GitLab Actions you already run. Ana opens a PR adding a Stripe pipeline; checks pass, a teammate approves, and the merge deploys it to staging automatically. Production only moves when that same code merges to main. Workspace-scoped API keys keep the promotion path safe: each key opens only its own workspace, and your CI swaps one secret to target staging or production.

Every data team knows the anti-pattern we built against: the pipeline called v4, created by someone who left, no context, no history.

On dltHub the code lives in Git, PyTest and CI/CD work as they do for the rest of your data stack, and every pipeline has an owner, a PR, and a dltHub workspace. That's what a workspace looks like day to day: stripe_pipeline and salesforce_crm deployed and green, ga4_events shipped last week - and zendesk_tickets sitting in review, the exact fix from the alert above, waiting on a human before it merges.

Next on our roadmap are workspaces for your open pull requests, so short-lived workspaces to preview and test new changes as a team before bringing them to staging or production.

Secrets and environment variables follow the same logic. Credentials live per workspace and profile, managed on the platform, not in a TOML file passed around Slack. Retry counts and log levels sit in plain text; a variable like a Datadog DSN shows as set, never as its value. Your agent gets that same redacted view, never raw values.

Pricing: teams, not seats. We do not charge per seat. Invite the whole team - analysts included - at no extra cost; the bill tracks what your pipelines run, not how many people log in. Bring on your tenth analyst without a purchase order.

Many teams arrive mid-migration: connector bills growing with row counts, a tool sunsetting, scripts nobody owns.

Migrations off Fivetran and Airbyte are an agentic workload we support end to end, delivered as the Agentic Migrations blueprint (how Blueprints work), directly or through partners. Your agent ports pipelines source by source; dltHub validates the arriving data. Talk to us about migration support.

A platform for teams only works if the whole team can use it, so we train the full bench on agentic data engineering: the 10 to 15 people who touch data, engineers, analytics engineers, and analysts. The dltHub Academy has free courses with certification. Commercial customers get personalised hands-on workshops on their own sources and workspaces. In one customer's onboarding, a six-person team (tech lead, two data engineers, an analytics engineer, two analysts) had everyone shipping a pipeline to their own workspace by lesson four; the CI/CD and Day 2 lessons are where the training continues.

"Thanks to the dltHub team for providing such a well-structured and insightful learning experience." (Denis Krivenko, on completing the dlt Advanced certification, LinkedIn)

This is where dltHub stands for teams today. We keep shipping every week - the changelog is where to watch what's next.

3. Managed infrastructure: scaling and performance, without a platform team

The outcome: your first pipeline and your seventieth job on the same infrastructure, and nobody carries a pager for the orchestrator.

dltHub deploys, schedules, and monitors your pipelines on managed infrastructure. No Airflow to maintain, no Kubernetes to size.

When a workload gets heavy, scaling is a Harness skill. The performance skill we developed covers both sides: dlt optimizations like parallelism, batching, and incremental settings, and the dltHub instance size the job runs on.

Instance requirements live in your Python code, next to the pipeline, and the platform provisions them. Infrastructure as a function argument, not a second codebase.

@run.pipeline(
    my_pipeline,
    require={"instance": {"size": "medium"}},
)

One customer's nightly events_backfill job loads 48.2M rows in 18 minutes on a single large instance; the performance skill's read on it was simple - extraction is the bottleneck, raise parallelism to 8 workers, keep the instance size - and the estimate dropped to about 9 minutes.

Underneath sits dlt, proven across millions of production runs. dltHub does not store your data: it processes it and moves it into your warehouse, keeping the context, not the data. That is why the platform works in regulated environments.

"My dltHub workspace has grown to roughly 70 jobs." (Martin Seifert, on LinkedIn)

The six building blocks dltHub is made of

It's one stack, top to bottom: your coding agent - Claude, Cursor, Codex, whatever you use - operates through the AI Harness and Context Catalog, which run on the ingestion, transformation, and orchestration blocks, into any warehouse you already have.

So to summarise - dltHub consists of six building blocks:

AI Harness. Your agent's interface: run, fix, maintain, and build pipelines to your conventions.

Context Catalog. The memory of your data stack: schemas, lineage, run traces, and data quality results, recorded with every run, governed with a human in the loop.

Ingestion. Open source dlt: any source to any destination, schema evolution, contracts, incremental state, every row stamped with its load ID. Existing dlt pipelines run unchanged.

Transformation. Raw data into a canonical model of the business, Python or SQL, executed where the data lives, lineage carried from source to model.

Orchestration. Triggers, schedules and jobs, all defined in code and deployed with the workspace: intervals and cron, jobs that chain off each other on success or failure, freshness checks, and refresh cascades.

Managed Infrastructure. One-command deploys, isolated profiles with their own secrets, role-based access, region choice, patching on us, and metering per pipeline and per run.

dltHub is an AI-native data engineering platform for teams of humans and agents. As the agentic data and managed-infra layer on top of any warehouse, your team and their agents generate and manage high-quality data at scale. This is the shape we'll keep coming back to - what's live, what's next, one block at a time.

What's shipped and what's in public preview

General availability means fully supported. Public preview means live and built for real use, but not yet fully hardened.

What's next. Short-lived workspaces for open pull requests, so a team and their agents can test a change in isolation before staging, and a browsable Context Catalog with lineage across pipelines. We ship weekly.

For whom we are building dltHub

dltHub is built for data teams in scale-ups and enterprises: 2 to 10 engineers, 10+ analysts, one backlog that never shrinks. It is for organizations where management is ready to put agents to work but cannot afford to lose governance in the process. Every pipeline, transformation, and agent action is validated and auditable by default, which is why dltHub lands hardest in regulated industries like pharma and financial services.

If that sounds like your team, we built this for you. Try dltHub for two weeks with one prompt:

Run uvx dlthub-start@latest to build my first pipeline and run it on dltHub or book a demo.