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

Not usually. The model call typically still goes to a third-party AI provider's infrastructure, since running a large language model locally is impractical for most teams. 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 typically simpler for the vendor to operate and can ship features faster across all customers 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?

Ask directly, 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.

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 environment (their database, their instance) than routed through a shared vendor-side system, since data staying in-instance means it never has to transit the vendor's own compute to be processed.
In-instance agents keep the audit trail attached to the data it describes: every action an agent takes is logged in the same database the data lives in, so an investigation never has to correlate records across two separate systems.
Vendor-side agents are typically simpler to operate, since the vendor can update logic once and have it apply across every customer at once, rather than each customer's instance needing its own update.
"We don't store your data" and "your data passes through our servers" are both often true at the same time, and the distinction between the two matters more than either claim alone; ask specifically where processing happens, not only where storage happens.

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 infrastructure, your data transited the vendor's systems on its way to being processed, regardless of whether it was stored there afterward.

This distinction, transiting versus storing, matters for teams with real data-handling requirements, whether contractual, regulatory or just a matter of internal policy. An architecture where the agent's orchestration and data access happen entirely inside the customer's own instance keeps that data from ever needing to leave, model calls themselves usually still go to a third-party AI provider, but the surrounding data never passes through a separate vendor-operated system in between.

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 prioritizing fastest feature velocity over data locality

What to actually ask a vendor about this

Ask where the agent's logic runs, not only where data is stored at rest. Ask whether your data is processed on shared infrastructure alongside other customers' data, or within an environment dedicated to your account. And ask which AI model provider is actually used, since that is a separate hop in the pipeline regardless of which architecture the vendor chose for everything else.

Disclosure: SalesCrew is our product, and its architecture is single-tenant by design: one Supabase project per client instance, with the CRM's own data, orchestration and audit log all living inside that instance. 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 specifically where an agent's logic runs and whether your data transits shared vendor infrastructure to get there, not only whether it is retained afterward.

Questions

Does 'runs in your database' mean the AI model itself runs locally too?: Not usually. The model call typically still goes to a third-party AI provider's infrastructure, since running a large language model locally is impractical for most teams. 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 typically simpler for the vendor to operate and can ship features faster across all customers 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?: Ask directly, 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.