Does 'runs in your database' mean the AI model itself runs locally too?

Not usually. The model call most often still goes to an outside AI provider, since few teams can run a large language model on their own. What stays in-instance is the data storage, the orchestration logic, and the audit trail, not the model inference itself.

Is vendor-side always the wrong choice?

No, it depends on what you are optimizing for. Vendor-side agents are most often simpler for the vendor to run, and new features reach every customer at once. In-instance is harder to build but keeps data and audit together, which matters more for teams with strict data-handling requirements.

How do I tell which model a vendor actually uses?

Put the question to them, and check whether the answer is specific (a named provider and model family) or vague ('proprietary AI,' 'our own models'). A specific answer is easier to evaluate against your own data-handling requirements than a vague one.

Should agents run in your database or the vendor's?

Agents that act on customer data should run inside the customer's own environment, so the data never transits vendor compute and the audit trail lives with the data. Vendor-side agents are simpler to operate and harder to audit.

Want to see it first? Book a demo

app.salescrew.io/inbox

The unified reply inbox with classified threads

The short answer

An agent that acts on customer data is better run inside the customer's own setup (their database, their instance) than sent through a shared vendor system. Data that stays in the instance never has to pass through the vendor's own servers to be worked on.
In-instance agents keep the audit trail next to the data it describes. Every action an agent takes is logged in the same database as the data, so you never have to match records across two systems when you look into something.
Vendor-side agents are most often simpler to run. The vendor updates the logic once and every customer gets it, so no single instance needs its own update.
"We don't store your data" and "your data passes through our servers" are often both true at once, and the gap between them matters more than either claim. Ask where the work on your data happens, not only where it's stored.

Why 'we don't store it' does not settle the question

A vendor's claim that it does not store your data is often accurate and often incomplete, because storage is only one part of the pipeline. An agent has to read your data to act on it, which means that data has to reach wherever the agent's logic runs, even if nothing is retained afterward. If that logic runs on the vendor's shared servers, your data passed through the vendor's systems on the way, whether or not it was stored there after.

Passing through versus being stored: that gap matters if you have real rules on how data is handled, whether from a contract, a law or your own policy. When the agent's logic and data access sit wholly inside your own instance, the data never needs to leave. The model call itself most often still goes to an outside AI provider. But the data around it never passes through a separate system the vendor runs.

In-instance vs vendor-side, by dimension

Dimension	In-instance	Vendor-side
Where data is processed	Inside the customer's own database and compute	On the vendor's shared infrastructure
Audit trail location	Lives with the data, in the same database	Often separate from the customer's own records
Update model	Each instance updates on its own schedule	The vendor updates once, applies to every customer at once
Operational complexity	Higher for the vendor to build and maintain per-instance	Lower for the vendor; shared infrastructure serves everyone
Best fit	Teams with strict data-handling or audit requirements	Teams that want new features fastest, over keeping data in place

What to actually ask a vendor about this

Ask where the agent's logic runs, not only where data is stored at rest. Also find out whether your data is handled on shared servers next to other customers' data, or in a setup that's yours alone. And ask which AI model provider they use. That's a separate hop, whatever setup the vendor chose for everything else.

Disclosure: SalesCrew is our product, and it's single-tenant by design. Each client instance is its own Supabase project, and the CRM's data, agent logic and audit log all live inside it. Model calls go to Anthropic's API (or the client's own key under BYOK), which is the one hop that leaves the instance; everything else, the data, the agent logic, the audit trail, stays inside the client's own project.

'We don't store your data' and 'your data passes through our servers' can both be true

Storage and processing are different claims. Ask where an agent's logic runs and whether your data passes through shared vendor servers to get there, not only whether it's kept afterward.

Questions

Does 'runs in your database' mean the AI model itself runs locally too?: Not usually. The model call most often still goes to an outside AI provider, since few teams can run a large language model on their own. What stays in-instance is the data storage, the orchestration logic, and the audit trail, not the model inference itself.
Is vendor-side always the wrong choice?: No, it depends on what you are optimizing for. Vendor-side agents are most often simpler for the vendor to run, and new features reach every customer at once. In-instance is harder to build but keeps data and audit together, which matters more for teams with strict data-handling requirements.
How do I tell which model a vendor actually uses?: Put the question to them, and check whether the answer is specific (a named provider and model family) or vague ('proprietary AI,' 'our own models'). A specific answer is easier to evaluate against your own data-handling requirements than a vague one.