dltHub Blueprints: launch FAQ

Why are we shipping dltHub Blueprints?

We at dltHub are at the epicenter of something new.

In a year, agent-built dlt pipelines went from 5% to 91% of what we see - 2,400 to 81,000 a month, 10X more than humans build. Agents are creating new categories of pipeline and use cases. Someone has to make them usable.

dltHub is a composable data platform. Composability is the whole point: every layer is assembled from the layer beneath it, out of a small set of shared parts. It's loosely similar to the modular kits the car industry runs on, like VW's MQB - one kit underpins dozens of models, from a Golf to an Audi.

Since launching mid-May we've watched customers build their own version of dltHub, and we've watched customers and partners ask us to build it with them. A Blueprint is where that composability stops being an architecture you have to understand and becomes a benefit you can feel.

It's the difference between a parts catalog and an Audi S3 with the Winter Package - someone already made the choices, and you drive off with exactly the car you wanted. LLM-native composable platforms like dltHub open a new age of customisable data engineering software. We think there will be 10,000 variations of dltHub - Blueprints - within a year.

Why are we shipping dltHub Blueprints for agent spend?

From 2025 to 2026, agents sprawled across the company. A startup runs hundreds; a large enterprise runs tens of thousands. The AI bill climbed right alongside them. That turned agents into a question the whole company has to answer, not just engineering.

Finance wants to know which team, customer, or result drives the spend. Engineering wants to know which agents ship work that survives. Product wants to know when an agent fails and hands off to a human. Sales wants to know which accounts are ramping or churning on agentic features. Leadership wants to know whether any of it is a durable advantage.

One question - what are our agents doing? - with five owners. Call it agent governance: every department asking, and expecting, different answers about the agents it now depends on. The first answer all of them want is cost.

Why is this hard? Why hasn't it been solved already?

Agent traces are the step-by-step record of what an agent did. They have yet to be standardized. Format and content differ widely depending on where in the stack they come from:

1. LLM provider (Vercel AI Gateway, OpenAI): where the LLM produces an answer for the agent request.
2. Agent CLI or framework (Claude Code, LangChain, Vercel AI SDK): where the agent's interactions between the LLM and your system are defined.
3. Instrumentation (Pydantic Logfire, Langfuse): where the agent's actions are organized as telemetry events.
4. Observability platform (generalist: Grafana Loki, Dash0; Arize): where telemetry is further processed and stored in a platform-specific format.

The records are deeply nested. Fields appear on some spans and not others. Types drift. The shape changes with every release. We are tracking more than thirty popular formats in the wild right now. Build a pipeline to read one, and the next release breaks it.

Then customers want to join the traces with the rest of their data:

• Cost APIs, e.g. Claude or Codex.
• Internal / SaaS APIs, e.g. app databases or sessions.
• Wider agentic ecosystem, e.g. GitHub or HubSpot.

So customers write custom pipelines, by hand, against moving targets.

Why dltHub, and not Fivetran plus dbt?

The incumbent stack can't do this. Fivetran's connectors are fixed at build time and break when a column changes. dbt models snap the moment a schema shifts. The GenAI semantic convention is still moving, and every provider (OpenAI, Anthropic, Bedrock, Azure, MCP) ships its own variant. SaaS-gated tooling can't run inside a customer's VPC, which is where the traces often have to stay.

dlt and dltHub are built for the opposite case. The first ever dlt pipeline in production, back in '21, was an agent trace pipeline. Schema inference and evolution are the first principle, not an add-on. Pipelines read a new or changed trace shape and adapt instead of breaking. Transformations are Python and Ibis that compile to versioned SQL and run anywhere: a notebook, a cron job, or a Databricks workspace. Agentic traces break the Fivetran-plus-dbt model. dlt and dltHub were built for it.

How does it actually work?

Every Blueprint is built from three parts, all part of dltHub:

1. Verified sources. Ingest any trace, handle drift, tag PII, normalize to OTel GenAI conventions.
2. Transformations. Turn normalized traces into outcomes, joined with your own data.
3. Dashboards and API endpoints. Put each outcome in front of the team that asked.

A Blueprint bundles the three for one outcome. Ingestion to transformation to dashboard. All Python. All in the customer's own warehouse. In hours rather than weeks.

We showed an early outline of this at the PyAI conference in March, for a single instrumentation framework (Pydantic Logfire). The full version is broader. dltHub delivers not only the building blocks for builders (eg ingestion, normalization, and data modelling, plus the skills, agents, and ontologies that let a team shape those blocks to the exact answer they need), but also Blueprints.

How do I get involved?

The agent-trace problem won't be solved by one team in isolation, and it won't be solved by a standards committee - the formats move too fast for design-by-consensus. dltHub takes a third path: we ship dltHub Blueprints. A Blueprint is an opinionated, partner-built version of dltHub that solves a use case end to end, from the sources you already use to a production-ready dashboard or API. Browse them like templates and start from one in days. Every new source a partner adds, and every outcome a customer asks for, becomes a Blueprint everyone gets after.

There are two ways in.

• Customers bring a business problem or a question. We build a Blueprint around it, or extend an existing one to your setup. distil labs came to us needing the agent traces teams already collect turned into a training-ready dataset; we customised dltHub for the Agent distillation Blueprint - ingesting from Pydantic Logfire, Arize, Langfuse, and LangChain, standardized to the OpenAI messages format, ready for them to fine-tune a cheaper drop-in model. As a customer you can also ask us to customize any standard Blueprint such as Agent Cost & Usage further. Reach us via our contact form.
• Ecosystem partners build with us. If you're a framework, model provider, or observability backend - a Rasa or a dash0 - you can join the dltHub ecosystem at whichever level fits: contribute a building block, a pre-integrated pipeline or transformation others draw on, or build a complete Blueprint with us. Either way your platform takes its verified place in the agentic ecosystem, and your users get a clean, maintained path instead of glue code. Reach us via our contact form.

Blueprints already draw on these pre-integrated dltHub agent pipelines, so you go live in days, not months: Arize, Claude, Codex, Cursor, Databricks MLflow, Databricks Zerobus, Grafana Loki, Langchain, Langfuse, Langsmith, Rasa.

"dltHub is the way to make Rasa traces understandable." - Alan Nichol, CTO & Co-Founder, Rasa

What's next?

This is the first step in two broader efforts dltHub intends to lead:

• building a standardized, evolving ingestion and transformation layer for agent pipelines, with the customers and partners who feel the problem most, and adding sources, transformations, and outcomes over time. Cost is the first outcome. It won't be the last.
• building Blueprints.

Read the Blueprints launch announcement for the full story, or browse all dltHub Blueprints to find one to start from.