Using your company's AI server from your own desktop — without becoming shadow AI

In the previous piece we argued that shadow AI at companies with their own inference server is not a discipline problem — it is a doorway problem. The endpoint exists; nobody individually feels it. This post is the practical sequel: how a person on a normal Windows desktop connects Filer to that endpoint, what that connection does and does not send out, and which everyday tasks stop needing a public chat tab once it's done.

Why the public tab still wins today

Ask someone who pastes work into a public chat app why they don't use the internal server instead, and the answer is rarely "it's worse". It's that the internal server is an address, and an address is not a tool. To use it you would need something on your own machine that already knows where your files are, remembers the recurring task, and speaks the server's protocol — and then you would have to build the habit of opening that thing instead of the tab you already have open. Most people never get past the first step, so the sanctioned infrastructure idles while the same work runs somewhere it can't be seen.

The fix is not another portal. It is to put the connection where the work already is: in the folder.

What "point Filer at the endpoint" actually means

Filer is a file explorer. Every folder in it can carry its own AI agent, and every right-click action, chat panel and search inside Filer talks to one configured model source. That source is a single, app-wide setting — a local model, a cloud API key, or the address of an OpenAI-compatible endpoint. Company inference servers built on GPUStack, Ollama, vLLM or an internal gateway in front of them all expose exactly that shape, so Filer connects to them the same way it would connect to a cloud API: a base URL, optionally a key, and a model name.

So "pointing Filer at the endpoint" is done once, per person, on their own machine. After that, every folder they give an agent to inherits it. There is no per-folder server to configure and no central console for IT to run — the only thing a person needs from IT is the address (see the teams page for what a rollout actually involves, which is not much).

Setup in Filer: one screen

1. Open Settings → AI. The chat model section shows the available sources as tiles; pick OpenAI Compatible.
2. Endpoint — paste the gateway's OpenAI-compatible base URL, the one ending in /v1 that IT hands out. Nothing else about the server matters to Filer.
3. API Key — only if your gateway requires one. Many internal servers don't; leave it empty then.
4. Model — the model name the server serves. If you don't know it, whoever runs the gateway does; it is the same string any other client on the network uses.
5. If you also want AI Search (Filer's search across the documents you've memorized) to embed on the company server rather than locally, the embedding section directly below takes the same endpoint and key. Otherwise leave it on the local model — embeddings never need to leave your machine.

That is the whole setup. Open the chat panel on any folder and ask it something about a file in that folder; the reply comes from the company server, and the connection status in Settings shows the endpoint answering.

What stays inside the boundary

With the endpoint set to an internal address, every model call Filer makes — a right-click summary, a chat turn, a folder agent's scheduled run — goes to that address and nowhere else. Your files and their contents travel to the company server and back over the company network; they are not sent to Filer AI or to any third party. The boundary the agent works inside is the one you already see in File Explorer: an agent attached to a folder can read and act on that folder, and its trust level decides how much it may do there without asking you first.

Two honest footnotes, both already stated on the teams page. First, Filer itself sends limited diagnostic telemetry — crash and usage signals, never file names or content — to help stabilize the product at this stage; it is disclosed in the Terms of Service, and you can turn usage data off under Settings → General. Second, "inside the network" is only as true as the endpoint you paste: if you point Filer at a public cloud API with your own key, the same calls go to that provider instead. The setting is the boundary; Filer does not add a second one behind your back.

Three desk-level workflows that stop needing the tab

Each of these is something people currently do by copying text into a public chat app. With the endpoint set, each becomes a folder that does it on its own, on the company server.

• The weekly folder report. A folder of vendor updates, tickets or meeting notes gets an agent with a schedule: every Monday, read what arrived, write the summary into the folder. Nobody pastes anything anywhere. See the scheduled-report usecase for the exact instruction and output.
• Drafting from past work. Point the chat at the folder of last quarter's proposals and ask for a first draft of the next one. The past documents are the context; they never leave the network. This is the similar-draft usecase.
• Watching a document for changes. An agent on a shared folder that notices when a policy file changes and writes up what changed — the kind of "just tell me what's different" question that used to mean pasting both versions into a chat window. See the doc-diff-notify usecase.

What it needs

• A Windows PC with Filer installed — one person, one machine, no central deployment
• The base URL of an OpenAI-compatible endpoint your company already runs (GPUStack, Ollama, vLLM, or a gateway in front of them)
• Five minutes in Settings → AI, and a folder where the recurring work already lives

See what folder agents do in practice · More from the blog