Why bulk.run exists

AI is good at reasoning.
Computers are good at structure.

What's missing is a reliable way to apply one to the other.

Today, AI mostly runs:

• one prompt at a time
• inside chats
• behind opaque workflows

But real work doesn't happen in prompts.
It happens in datasets.

Spreadsheets. Tables. Lists. Logs.
At scale, everything becomes rows.

The gap

When people try to apply AI to real datasets today, they end up with:

• copy-paste loops
• brittle workflow graphs
• hidden logic
• outputs that can't be reproduced

These systems are impressive to demo and painful to maintain.

They optimize for interaction, not execution.

The missing primitive

What's missing is a simple execution layer:

• take a dataset
• define a transformation or enrichment
• run it deterministically per row
• return structured results

No workflows.
No hidden state.
No ceremony.

Just jobs that run and finish.

What bulk.run is

It treats datasets as the unit of work.

You give it:

• structured input
• an explicit operation
• optional external data (web search, context)

It gives you:

• predictable outputs
• repeatable runs
• data you can reuse and share

CSV is the first interface. Not the point.

The three non-negotiables

A true execution layer has three requirements:

Build those three, and you stop being "a tool." You become infrastructure.

How we think about this long-term

We're not building an app.
We're building infrastructure.

That means:

• behavior over magic
• consistency over cleverness
• formats that can be shared
• execution you can trust

Some parts will be hosted.
Some parts will be open.

What matters is that the primitive exists.