Every data engineer knows the loop. You change a transformation, submit it to the cluster or the warehouse, wait for compute to start, wait for the job, read the result, find the mistake, and go again. Each round takes minutes, spends compute, and touches shared environments. It is a poor loop for a person, and a worse one for an agent that may need several attempts to get a template right.
Emolysis is designed around a different loop. We call it local-first, and the word needs a careful definition.
What local-first means
Development will happen on your machine. Emolysis will use DuckDB, an analytical database that will run inside the app with no server, as the engine for the development loop. DuckDB starts instantly, reads Parquet, CSV and JSON files directly, and can read Delta and Iceberg tables. That makes it a practical place to run a transformation hundreds of times a day.
The loop will look like this. You will connect your platform once. When you need real data to look at, Emolysis will pull a small sample of the tables you choose into a local lakehouse in your project. That sample read will be a query on your platform; everything after it will run locally. The agent will fill a template, platform lint rules will run on every edit, a dry run on DuckDB on every save, and the template's golden tests before anything can deploy. Testing a change will spend no warehouse compute.
Production will run on your platform. When the tests are green, Emolysis will translate the pipeline into your platform's dialect and deploy it as the platform's native unit, under your account. Your platform will run only what you deploy. The deploying docs describe the planned flow.
Why this matters for an agent
An agent learns from feedback. If each round of feedback takes minutes and costs money, you get fewer rounds, and you are tempted to skip them. If it takes seconds and spends no warehouse compute, the agent can try, fail, fix and try again until the tests pass, and you can watch each attempt. The fast loop is what makes it reasonable to insist on tests before every deploy.
It will also keep development off shared environments. Trying an idea will not leave half-written tables in a production catalog or wake a warehouse at night.
Where DuckDB is the judge, and where it is not
Golden tests use DuckDB as the judge: fixed input, expected output, exact comparison. That proves the logic of a pipeline on the cases its fixtures cover. It does not prove everything. Permissions, performance on full data, and platform-specific behavior only show up on the platform. That is why each template will also be run on the real platform before we call it ready there, and why the platform profile lists the known traps that lint rules will check for. Read more in tests before production and the golden tests docs.
What local-first does not mean
It does not mean that nothing leaves your machine. To write code, the agent will send prompts to the AI model provider you choose. A prompt can include table and column names, schemas and sample values. With your own model key, prompts will go to that provider under your key and its terms. With a paid plan's included usage or usage credits (on Enterprise, metered usage), prompts and responses will pass through Emolysis's metering service on the way to the model provider; that service is designed not to store or log their content. If you publish a dashboard, the data behind its charts will leave your machine at that moment. Your platform credentials will stay in your machine's credential store, and Emolysis's own services are designed never to connect to your data platform. We keep the complete list on our security page, and we will not shorten it to make a better headline.
It also does not mean offline-only or single-user. Teams will share projects through Git, review changes in pull requests, and run the same golden tests in CI. See what works offline.
The short version
Iterate on your machine, in seconds, with no warehouse compute. Prove the logic with golden tests. Deploy to your platform only what passes. That is the loop Emolysis is being built around, starting with Databricks.
Emolysis is in private development. Nothing described here is released yet.