Run

Run is the part of the surface concerned with execution. Where AI applications and agents actually run, what they can reach from there, the databases and object stores and indexes they accumulate, the secrets they hold while working, how all of it gets provisioned, and whether any of it can move.

It is the letter that vendors most often push back onto you. A product that covers a corner of Build and then says “deploy it on your infrastructure” has handed you Run, and Run is where the operational cost lives.

The claim

Long-running agents are not web requests. They are stateful, they hold credentials for the length of a session, they execute generated code, and they read untrusted content while doing it. A platform designed around stateless services has nowhere correct to put one, so it ends up on a machine somebody set up by hand.

The second claim is about placement. In any organization large enough to be regulated, the data is not all in one place and will not be. The runtime therefore has to go where the data is, which means one system with multiple placements rather than a migration plan.

The tests that matter

1. Name the machine. Where does a long-running agent execute today, and what can it reach from there: which network, which cloud role, which databases?
2. Name the stores. List everything your AI applications write to. If the list does not include the vector index and the prompt log, the list is incomplete.
3. Name the second placement. Could this run somewhere else, and what would break?

The tension

Run pulls against Build: every isolation boundary is friction for the person trying to ship. It pulls against Secure in the opposite direction, because the fastest runtime is the one with no boundaries at all. The Replit incident is what the second tension looks like when nobody resolves it: an agent with production credentials, no separation to enforce, and a code freeze that was a request rather than a control.