Private stops at the provider you chose

"Your data stays on your computer" is true in one sense and easy to overread in every other sense. T-FORCE is a Windows desktop app. The project is not a document you uploaded into a workspace we host. That sentence does not mean a model provider never received the words you asked it to work on. Collapsing the two is how a privacy claim becomes a slogan, and how a slogan fails a security review.

The useful version is a map. Some things stay. Some things leave, on purpose, to a place you picked. The product's job is to make the map hard to misunderstand, not to pretend the leaving does not happen.

What actually stays

Projects, chats, and agent memory are stored in a local database on the PC where you installed the app. API keys and integration tokens are written to the operating system keychain. The window does not read those secrets back to show them to you. Installing T-FORCE does not create an account. There is no shared cloud folder of your documents sitting behind the marketing site.

Update checks look at the public GitHub releases for a signed installer. That is a network call about the app, not about your project. It is still a network call, and it is worth listing so "the app is local" does not get exaggerated into "the app never speaks."

The local database is the claim to defend. If someone asks where the transcript and the memories live when the app is closed, the answer is that disk, not our disk. If the machine is lost, the project is lost with it, unless you have your own backup. That is the ordinary bargain of local software. It is a better bargain than a workspace you cannot export, and it is a worse bargain than a vendor who will restore last Tuesday for you. We do not restore last Tuesday. We do not have last Tuesday.

What leaves when you call a model

A model call goes to the provider you configured.

• OpenAI, Anthropic, DeepSeek, and Moonshot are cloud providers. The request leaves the machine. Their terms, not ours, describe what they do with prompts.
• The built-in T-FORCE provider is also a service you are calling. Skipping the step where you paste a key does not turn that call into local inference. It means we operate the provider relationship so you do not have to bring an account.
• Ollama is the local case. If the model is running on the machine, the inference can stay there. That is a choice you make in the picker, not a property of the app's wordmark.

"Files and memory stay on your computer" describes storage. The request still contains whatever the agent puts in it. A paragraph from a local file can be inside a prompt. A standing fact from memory can be inside a prompt. The file was not uploaded as a file into a shared drive. The words were still sent, because that is what a remote model call is.

If your requirement is that a given document never be transmitted, a remote provider cannot satisfy it, no matter how local the database is. Use a local model, or do not put that document in front of an agent. The approval card will not save you here. Reading a PDF in the project is an immediate action. The gate is about side effects, not about whether a later model call might quote the PDF. You have to decide that earlier, when you choose the provider and when you decide what the project contains.

What leaves when you connect an app

GitHub, Gmail, Drive, and Slack are other people's systems. Connecting them means T-FORCE can talk to them from this machine, with a token kept in the keychain. Reading, once you have asked, runs. Sending, posting, creating an issue, and the other writes wait for the card.

That split does not make the connected account local. A read of your inbox is a read of your inbox. The message was already at the provider. The new fact is that an agent on this PC asked for it, and the token that allowed the ask is stored here rather than in a hosted automation product. For some teams that is the improvement they wanted: the automation runs on a machine they control, against accounts they already have. For a team whose rule is "no third-party client on mail," connecting Gmail fails the rule. The app will not talk you out of a rule like that. It will also not connect the account by itself.

Generic MCP tools follow the same placement. They are stored on this machine. They extend what an agent can call. They are not reviewed, hosted, or vouched for as part of T-FORCE. Adding one is closer to installing a plugin than to enabling a feature we operate.

What a serious review should ask

A procurement questionnaire that only asks "is it cloud or on-prem?" will get a messy answer, because the honest answer is both, depending on the row.

Ask these instead:

1. Where do projects, chats, and memories sit when the app is closed? On the PC. A local database.
2. Where do API keys sit, and can the interface display them? In the OS keychain. The interface does not show them back.
3. Which model receives prompts, and under whose terms? Whichever provider is selected, including the T-FORCE provider, or a local Ollama model.
4. Which connected products can be read or written, and which writes wait for a person? GitHub, Gmail, Drive, Slack, plus any MCP server you add. Writes wait in the chat.
5. Is there an account, a hosted workspace, or a restore path operated by Tony Tech Insights? No account for the app. No hosted workspace for your documents. No restore path.

Those answers are narrower than "private AI." Narrow is the point. A wide claim would be easier to put on the hero and worse to defend in a review. The desktop team is private in the placement of the work: one machine, a local record, keys the window will not echo, and a person at the approval card before the machine changes or a message goes out.

The model is private only if you made it private. We would rather say that in an essay than imply it in an adjective.