Why your AI assistant should run on a model you choose
A workspace assistant is only useful if it can read your work, which is exactly why the model it talks to should be your decision, not the vendor's.
There's a paradox at the centre of "AI for work". An assistant is only useful if it can read your work: the tickets, the specs, the conversations. But the more it can read, the more it matters where those tokens go. Most tools resolve the paradox by not letting you choose. We think the choice is the whole point.
Useful means "has read everything"
A chatbot that knows nothing about your company can write a decent email. It cannot tell you which tickets have been idle since Thursday, summarise what the mobile team decided in #launch-week, or draft the three tickets that fall out of a conversation you just had. For that it needs to be inside the workspace, reading with your permissions.
That's what Tenon's Brain does: it sees the projects, tickets and pages you're allowed to see (and nothing else, because Row Level Security applies to it too), and it can propose actions you accept with a click.
Which means the model choice is a data-governance choice
Every question you ask Brain sends context (ticket titles, page excerpts, message snippets) to a language model. If the vendor hard-codes which model, they've made a decision about your data on your behalf: which company processes it, in which country, under which retention policy, and whether it's used for training.
For a marketing team that's probably fine. For a law firm, a hospital, a defence contractor or a company with an EU data-residency obligation, it's a non-starter, and the usual fix, "just don't use the AI features", throws away the most useful part of the product.
What "bring your own provider" looks like
In Tenon, no AI key exists in the codebase. A superadmin opens Admin Settings and chooses:
- Google Gemini: paste an API key, pick a model.
- Any OpenAI-compatible endpoint: a base URL, a model name and an optional key. This covers OpenAI itself, Azure OpenAI in your tenant, and every self-hosted inference server that speaks the same API: Ollama, vLLM, LM Studio, LocalAI, and most enterprise gateways.
Every AI feature (the floating assistant, the morning briefing, the executive summary on the insights dashboard, the standup digest that a cron job writes overnight) routes through one shared module. Change the provider once and everything follows. Point it at a model in your own rack and no prompt ever leaves your network.
Three configurations we see
| Team | Provider | Why |
|---|---|---|
| Startup, fast-moving | Gemini | Cheapest path to strong results; data-processing terms acceptable |
| Enterprise with an Azure agreement | Azure OpenAI (OpenAI-compatible) | Stays inside the existing cloud contract, region and DPA |
| Regulated / air-gapped | Ollama or vLLM on-prem | Zero egress; the security questionnaire gets a one-word answer |
The other half: honest empty states
A less obvious consequence of letting you choose: sometimes nothing is chosen yet. Many products paper over that with a canned paragraph that looks like an insight. We think that's worse than nothing. If AI isn't configured, Tenon's executive summary says so, the standup cron skips its digest, and the assistant explains what a superadmin needs to do. You'll never mistake placeholder text for analysis.
What we'd tell any buyer
Ask three questions of any tool with an AI assistant:
- Which model does it use, and can I change it?
- Can I point it at a model I host?
- What does it show when AI is unavailable?
If the answers are "ours", "no" and "something that looks like it worked", the assistant is a feature for the vendor, not for you. Here's how Brain answers them.