Agentic data engineering platform — dbt · airflow · your warehouse
The senior data team
you can’t hire.
The process you never
had time to write.
You own a data platform you can’t fully see, can’t fully staff, and can’t confidently change. NerveStax is a team of agents that share one memory of how your data actually works — and one opinionated way of shipping changes safely.
A coding assistant makes a fast junior faster. This brings the discipline a mature data org would have. See how we compare ›
>
- read manifest.json — 412 models, 1,208 columns
- trace lineage — mart.orders_daily ← 14 downstream assets
- source landed 6h late on 2 of the last 7 runs
- edit models/staging/src_orders.yml
- run dbt build --select stg_orders+
What just happened, in plain English: a daily revenue table had been late twice this week. It found the cause upstream, wrote the fix, tested it against real data, and stopped to ask a person before changing anything.
- Works on
- Your warehouse, your transformations, your pipelines
- Delivers
- A tested change, reviewed by your team
- Remembers
- Every table, column and run — permanently
- Never
- Touches production without an approval
The condition
You own a platform
you didn’t fully build.
Whether you started last month or three years ago, it comes down to the same three sentences — and none of them are fixed by the team trying harder.
“I don’t know what we actually have”
Hundreds of models, no ownership, documentation from two jobs ago. The people who know how it fits together are already booked — and everything routes through them.
“I can’t tell what a change will break”
One renamed column can quietly take out a board report nobody remembers depends on it. So changes get batched, deferred and over-reviewed. The slowness is the risk control — just an expensive one.
“My team spends its week keeping yesterday working”
Industry surveys put pipeline maintenance at roughly half of all data engineering time. That is capacity you are already paying for, spent keeping yesterday working instead of building what was promised this quarter.
What it does
Data engineering isn’t one job.
So it isn’t one assistant.
It’s a fleet of specialised agents sharing one memory of your platform and one rulebook — across the whole lifecycle. Here’s the arc, in the order a new data leader lives it.
-
01Live
Understand
“What did I actually inherit?”
One map of every table, column, test and run — what feeds what, which numbers to trust, what broke and why.
-
02Live
Stabilise
“Why does this break every night?”
It reads the runs, the logs and the retries — and tells you the real cause, not a guess from the DAG name.
-
03Live
Ship
“How do we build without breaking it?”
Real builds and tests in a sandbox, then a reviewable change behind an approval gate. Nothing merges untested.
-
04Next
Operate
“How do I stop being paged at 3am?”
An AI Ops agent that triages every alert, fixes what it can prove it can fix, and pages a human only when it can’t.
Day one:
the whole map.
The knowledge that usually lives in two people’s heads — what feeds what, which numbers are trustworthy, what broke last month and why — written down, kept current, and available to everyone. It doesn’t leave when someone does.
For the engineers: one graph fusing design-time truth (models, columns, tests, lineage) with runtime reality (run status, duration, row counts, freshness, schema drift), indexed once and refreshed on merge rather than re-parsed per session.
Why did
it fail?
The question every data team starts the morning with. It answers the way your best engineer would — by reading the runs, the logs and the retries — and tells you whether it’s transient or real before anyone wastes an hour re-running it.
For the engineers: list_dag_runs, get_task_log,
get_task_tries, debug_failed_task — correlated against recent merges,
not guessed from the DAG name.
> revenue_daily failed again — what is wrong? 02:14:41 ERROR snowflake ProgrammingError 002003 (42S02): Object RAW.ORDERS_STG_V2 does not exist 02:14:41 INFO UP_FOR_RETRY — try 1 of 3 03:02:19 ERROR ... identical error on try 3 of 3 03:02:20 INFO Marking task as FAILED
It ships the fix —
and stops for you.
You get a change that has already been run against real data — not a suggestion to go and try something. Then it stops at an approval gate before it writes anything: every change has an author, an approver and a record, so “an AI changed our numbers” is never a sentence anyone has to say.
For the engineers: real dbt build and dbt test against a dev
target in an isolated sandbox, a branch and PR in your own repo, gates that resume with working
state intact, and credentials that stay encrypted references — never in the prompt, code or logs.
$ dbt build --select stg_orders+ --target dev 14:02:04 Found 412 models, 1,208 tests, 39 sources 14:02:08 1 of 15 OK stg_orders ............. [OK 0.94s] 14:02:09 2 of 15 OK not_null_order_id ...... [PASS] 14:02:13 15 of 15 OK mart.orders_daily ...... [OK 3.1s] 14:02:13 Done. PASS=15 WARN=0 ERROR=0 SKIP=0
Stop getting paged
for the obvious.
The stage we’re building now. An AI Ops agent that receives every alert, triages it, attempts a fix it can prove is safe — and pages a human the moment it can’t. The point isn’t autonomy; it’s that it escalates early instead of thrashing at 3am.
Once alerts route through it, the numbers get concrete: pages avoided, time-to-resolution, nights not ruined. We’d rather show you this working than list it — so it’s marked next, not now.
03:11 alert revenue_daily SLA missed 03:11 triage read logs · check upstream · compare runs 03:12 fix upstream late — cleared + re-ran downstream 03:14 resolved no page raised — had it been ambiguous, it pages on-call instead
Who it’s for
Two people have to say yes.
This is the answer for both.
If you run the data team
- Requests answered in days instead of sprints — without hiring ahead of the roadmap.
- Fewer wrong numbers reaching the business, because nothing ships untested.
- Every change has an owner, an approver and a record you can hand to an auditor.
- AI spend as one forecastable line, not a surprise at the end of the month.
- Knowledge that stays with the company when people move on.
If you’re on the data team
- Stop re-explaining the warehouse to a tool that forgot it yesterday.
- Real runs against a real target — not plausible SQL you have to babysit.
- Pull requests you can actually review: a diff, passing tests and the reasoning.
- Keep your stack, your repo and your review rules exactly as they are.
- Less of your week spent inside somebody else’s model.
Getting started
Connect once. Ask in plain English.
Approve the change.
Connect your stack
Point NerveStax at the repo, the warehouse and the orchestrator you already run — dbt, Airflow, Snowflake and friends. Credentials go into a secret store as references, never into a prompt.
Ask in plain English
“Why was revenue late yesterday?” “Add a check so this can’t happen again.” “Model this new source.” You describe the outcome you want — it already knows the tables, the history and what depends on what.
Review and approve
The change arrives with its test results and the reasoning behind it, in whatever review process you already use. Approve it, or send it back with a comment. Nothing reaches production without a person saying yes.
Security
Built for a team that
answers to an audit.
- Execution
- Each conversation runs in its own isolated sandbox with scoped credentials. One agent’s run cannot reach another’s.
- Credentials
- Warehouse and git secrets live encrypted in a secret store and resolve at execution time — never inline in prompts, code or logs.
- Source of truth
- Work lands as branches and pull requests in your own git remote. Sandboxes are caches and get thrown away.
- Production
- Agents work against a development target. Merging is yours, behind your existing CI and review rules.
- Model access
- Bring your own provider keys and pick the model per agent. Spend is itemised per workspace and conversation.
- Deployment
- Hosted by us, or self-hosted in your own cloud account — the whole stack ships as containers.
Questions
Everything people
ask us first.
Q01What exactly is NerveStax?−
An AI data engineer for your platform. You connect the systems you already run; NerveStax builds and maintains a working model of how your data fits together, then uses it to do real work — building and testing new tables, investigating why last night’s numbers were late, tracing what a change would break. Everything it does arrives as a change your team reviews and approves.
Q02Do I need to know dbt or SQL to get value from this?+
To ask, no — you describe the outcome in plain English. To approve, someone on your team should read the change, the same as they would for any other engineer’s work. The tools named on this page are how the work gets done underneath; nobody needs to learn them to make a request.
Q03Do you replace my stack, or bring a whole new way of working?+
Neither, quite. We keep your tools — your repo, warehouse, orchestrator and the review rules you already have — and we add a process: changes ship through a pull request, nothing merges untested, an agent stops before it writes. If your team already works this way, it enforces it consistently. If it doesn’t, this is the discipline you never had time to set up. You can turn the opinions down, but they’re the point — a fast junior with no process is exactly the problem we’re solving.
Q04How do we know whether it’s working?+
The measures your team already argues about: how long a request takes from ask to merged, how much of the week goes to maintenance rather than new work, and how often something wrong reaches the business. Every run is recorded, so those become countable rather than anecdotal.
Q05Which warehouses and tools do you support?+
dbt is first-class, with Snowflake, Trino, DuckDB/MotherDuck and Postgres targets working today, and Airflow alongside it. The adapter layer is deliberately pluggable — if you run something else, say so in the form below and we’ll tell you where it sits on the roadmap.
Q06Does it write to production?+
No. Agents work in an isolated sandbox against a development target, and anything that changes your codebase arrives as a pull request. Merging — and therefore production — stays entirely in your hands, behind your existing CI and review rules.
Q07Does my code or data leave my infrastructure?+
Your repository is cloned into an isolated sandbox to run dbt, and model prompts include metadata such as schemas, column names and run results. We don’t ship warehouse rows to the model provider as a matter of course. If your policy requires everything to stay inside your own network, the self-hosted deployment is exactly that.
Q08Do I have to restructure my dbt project?+
No. NerveStax reads your existing project — manifest, run results and catalog — as it already is. If it builds on your machine, it builds here.
Q09Can I use my own LLM API keys?+
Yes. Add your provider keys in settings and choose which model each agent uses. Token spend is itemised per workspace, agent and conversation so you can see exactly where it goes.
Q10Is there a self-hosted option?+
Yes — the whole stack runs in containers and can be deployed inside your own cloud account. Pick “Question” in the form below and mention self-hosting; we’ll send the deployment notes.
Q11What does it cost?+
Pricing lands with general availability. The private beta is free, and beta teams get founding-customer pricing at launch.
Q12What’s coming next?+
Deeper Airflow authoring, ingestion pipelines, and a richer catalog surface on top of the context layer. Beta customers materially shape that order — that’s most of the point of the beta.