Senior Data Engineer, Agentic Systems

Fountain sells agentic software. We intend to run on it too.

Our data platform is healthy and owned. dbt and Dagster on Kubernetes, ClickHouse Cloud as the primary analytical store, CDC off Postgres and MongoDB source systems, a long tail of third-party sources, and Snowflake, Redshift, BigQuery, and object-store lakes around the edges. Engineers on the team own those models and pipelines today, and they’ll keep owning them.

This role is different. You own the agentic buildout itself, in two halves.

First, how our own team works. We want the data team building agentically by default: agents that author and test models, extend pipelines, catch breakage and repair it, keep documentation and contracts honest. Someone has to design that system. The harnesses, the context and tooling agents work through, the review and CI workflows that make agent-written code safe to merge, the evaluations that tell us whether the output can be trusted. Other engineers own the models. You own the machinery that changes how they get built, and that machinery reaches upstream into the product, where most data problems actually start.

Second, how the rest of the company works. The same capability, pointed outward. A CSM, a finance analyst, a PM, or a support lead should be able to ask a real question and get a trustworthy answer without waiting in a queue. That means semantic context, skills and MCP surfaces, access boundaries, evaluation, and a clear-eyed view of what the agent should refuse to answer. It also means working closely with the people who’ll use it, because tooling nobody adopts is worth nothing.

At its core this is still a data and analytics engineering job. You need enough depth in modeling, dbt, and orchestration to build credibly for engineers who do it all day, and to know when agent-generated output is subtly wrong. The difference is what you’re accountable for: the leverage, not the DAG.

Be aware that this is as much a change problem as an engineering problem. Building the capability is half of it. Getting a team, and then a company, to genuinely work differently is the other half, and it’s the half that decides whether this role succeeds.

We’re moving quickly. This role is a bet that we can change how we work in weeks rather than quarters, and we’re staffing it accordingly.

What you’ll do:

• Design and build the agentic development workflow for the data team. Agent-authored models and pipeline changes, the context and tooling those agents operate through, PR and review patterns, CI that catches what agents get wrong, the guardrails that make it safe to run against production, and the standards that make any of it repeatable across a team.
• Push that reach upstream into the product. Build the context and tooling that shape how features get conceived and built in the first place, and verify data architecture while changes are in development. Most data problems are cheapest to fix at the root, before a dev PR lands, which means working inside Engineering and Product rather than downstream of them.
• Build the evaluation layer. Regression suites, correctness checks, lineage awareness, and observability on the agents themselves. Nobody adopts an agentic workflow they can’t verify, so this is foundational rather than a follow-up.
• Build agentic analytics capability for the company. Semantic context, skills, MCP surfaces, access controls, and query and cost guardrails that let non-technical teams get answers they can act on, along with the honest scoping of what the system won’t answer.
• Drive adoption. Work alongside the engineers on the data team and stakeholders across GTM, Finance, Product, and Support, teaching the patterns, watching where people get stuck, and closing the gap between what you built and how people actually work.
• Stay hands-on in the platform. You won’t own the models and pipelines, but you’ll work in that codebase constantly, and you should be able to fix what you find.

What you should bring:

• 5+ years in data engineering, analytics engineering, or a closely related role, or equivalent depth arrived at another way. What you’ve built and operated matters more to us than the number.
• Real depth in analytical data modeling and SQL. You can read a normalized transactional schema, design something that answers business questions without falling over, and spot when a generated model is subtly wrong.
• Hands-on production experience with dbt and an orchestrator. Dagster is what we run; Airflow, Prefect, or Temporal transfers fine. You should know the operational reality of a large DAG, not just the syntax.
• Strong Python and the software engineering habits that go with it: version control, testing, code review, CI/CD.
• You have shipped agentic or LLM-powered systems to production. Tool and function calling, context and retrieval design, orchestrating multi-step workflows, and evaluating all of it. You should be able to walk through something you built, how you measured whether it worked, and where it failed. This is the requirement we care most about.
• Sound judgment about data governance and PII in a multi-tenant environment. We handle applicant and worker data across 75+ countries, and exposing it through an LLM surface raises the stakes on getting access boundaries right.
• You can bring people with you. This role changes how the data team, product engineers, and other departments do their work. That requires listening well, teaching patiently, and being persuasive without a title that makes anyone do anything.

Nice to have:

• Depth in a columnar or MPP warehouse, especially ClickHouse Cloud and ClickPipes; Snowflake, BigQuery, or Redshift also translates
• Building with Claude: the API, Claude Code, the Agent SDK, MCP servers, or subagent patterns
• AWS, Kubernetes, and infrastructure as code, enough to debug your own deployment
• Semantic layer and BI tooling (Omni, Looker, dbt Semantic Layer, Cube)
• LLM observability and evaluation tooling (Langfuse, Braintrust, or equivalent)
• Streaming and CDC internals (Debezium, Kafka, Kinesis)
• Having led a technical practice change on a team that was skeptical at the start
• HR tech, high-volume hiring, workforce management, or another domain with heavy operational data

What success looks like:

These are weeks, not quarters. That’s the point, and it’s possible because you won’t be carrying the platform while you do it. The models and pipelines have owners, so your time goes into building rather than inheriting.

Week 1 — you’ve shipped. A small agent-assisted change, merged to production. You learn our stack by building in it.

Week 2 — the first agentic workflow is running against production. Agent-authored changes moving through a review path you designed, with the CI and guardrails that make merging them safe.

Week 4 — engineers other than you are using it daily, the evaluation layer is catching regressions before a human does, and the first agentic analytics capability is in front of real users outside the data team, rough edges and all.

Week 8 — agent-initiated is the default path for at least one entire class of data work, the patterns are documented well enough that adoption no longer depends on you being in the room, internal agentic analytics is live for at least one department with measurement behind it, and the rate at which we add trustworthy data capability is no longer bounded by the size of the data team.