A data engineering team,
over your warehouse.
A manager plans, an engineer builds, a reviewer checks, a BI specialist ships. Working against your lakehouse, your dbt models, your conventions — with the same code-review discipline and testing bar a senior engineer would apply.
The PM asks for a new metric. The team ships it end to end.
A product manager opens the chat and says: “I need weekly active users by feature, plus a dashboard tile and a Slack alert if it drops week-over-week by more than 15%.” The manager agent decomposes the request into four pieces: (1) confirm the source event table has the right fields; (2) write a dbt model that aggregates by feature × week; (3) build the dashboard tile; (4) configure the alert. It delegates. The engineer inspects the source table via `inspect`, drafts the dbt model against the firm's conventions, runs the CI checks, and returns. The reviewer runs the required tests (null-check, uniqueness, referential integrity) and confirms row counts against a known baseline. The BI specialist builds the tile and configures the alert. The PM watches a narrative in chat and approves the final result. Every step is logged.
Who’s on it.
One published agent — the one your users talk to. The rest are internal team members with their own skills, retrieval scopes, and models.
The only agent PMs and stakeholders talk to. Decomposes ambiguous requests, plans the work, delegates to specialists, resolves conflicts, escalates to a human when required by policy.
Writes dbt models, Python transforms, Airflow-equivalent tasks against the firm's naming conventions and testing requirements. Uses `inspect` to verify source schemas before writing code.
Checks pipelines for the firm's required tests (null, uniqueness, referential integrity), verifies row counts against baselines, checks for schema drift. Flags anything that fails the bar.
Builds dashboard tiles and configures alerts on Looker / Power BI / Tableau / Superset. Follows the firm’s dashboard conventions (color palette, metric definitions, alert thresholds).
Plan → Delegate → Review → Return.
Plan.
Manager reads the request, writes a decomposition in-chat: verify source → build pipeline → review → dashboard + alert. PM can redirect.
Delegate to the engineer.
Engineer inspects the source event table via `inspect` (read-only DuckDB or native driver), confirms schema, drafts the dbt model against firm conventions, runs local tests.
Delegate to the reviewer.
Reviewer runs the checklist: required tests present, row counts match baseline within tolerance, no schema drift, model documented. Flags issues if any.
Delegate to the BI specialist.
Builds dashboard tile matching firm conventions (color palette, metric definitions). Configures Slack alert with the required threshold.
Return.
Manager synthesizes: pipeline PR link, dashboard preview URL, alert config summary. PM approves. Merge action fires; alert goes live.
The team gets sharper on your conventions with every request.
When the reviewer flagged a missing `is_deleted` filter on the last pipeline, the auto-checkpoint pipeline emitted a skill_refinement against the Data Engineering Skill: “always exclude soft-deleted rows in dbt models against the events table.” When a data lead added a Slack note that the alert threshold should be tighter on the pricing dashboard, refinements were emitted against both the Manager Skill and the BI Engineering Skill. Once a week, a data lead reviews the queue. Approved refinements bump the skill's version and become the team's institutional voice on the next request. Reject with a reason and the same suggestion doesn't keep returning.
Works over the tools you already run.
Data mapped from where it already lives. Nothing uploaded, nothing migrated. Common connections for this team:
Want to see this team on your workflow?
30-minute demo. Bring one specialist task your team keeps re-doing. We’ll show how the team topology fits.