One coding agent holding all your company's information — private, and any model's API.

This is the request we hear from technical founders and ops leads, and it's always phrased almost exactly the same way: "we want one agent that knows all the company's information. Private. We own the data. And we want to use whatever model's API we want."

They're right to want it, and it's more achievable than the vendor marketing makes it sound. But the reason they're asking us instead of just signing up for an enterprise chatbot is that they've already felt the failure mode. This is what that failure looks like, and what the owned alternative actually involves for a US, UK, or EU team.

Why "just use the enterprise chatbot" breaks

The hosted assistants are convenient until they aren't. Three things happen in practice. First, your team starts working around them — pasting code into a web tab, then into a doc, hoping nobody notices what's leaving the building. Second, the vendor changes a policy or a plan and a workflow your team depends on disappears or gets repriced, with nothing you can do about it. Third, procurement or a client contract asks the question you can't answer: exactly where does our code go when your engineer asks the assistant a question?

If none of those apply to you, the enterprise plan is honestly the simpler path. But if any of them do — a client contract, a regulated workload, or just a technical founder who refuses to rent their own codebase back — you need the agent to live with you.

What "owns all the company's information" actually means

It means the agent answers from your material, not from a model's general memory of how companies usually work. Concretely, at install we connect it to the sources your team already has:

• Repos — so "where do we handle retry logic for the payment webhook?" returns your code, with the file and line.
• Docs and wiki — so "what's our refund policy for annual plans?" returns the actual page, not an average of the internet's refund policies.
• Tickets and runbooks — so the on-call person at 2am gets the runbook step, not a plausible-sounding guess.

All of that becomes one index, and the index is a set of files on your machine. You can back it up, move it, or delete it. It is, in the plainest sense, yours.

You own the data; you bring the model

Two commitments sit underneath the pitch, and they're worth being exact about.

You own the data. The index, the conversation history, the credentials — all of it lives on infrastructure you rent directly from a provider (a VPS in your choice of region, or on-prem). Nothing is used to train anyone else's model, and the only egress is the individual model call. For UK and EU teams this is the difference between a paragraph in a DPIA and a deal-breaker.

Any model's API. You bring your own key. Today that's one provider; next quarter it can be another, or a local model so inference never leaves the box at all. Switching providers doesn't move your data or rebuild the index — you change one setting and keep working. That freedom is the whole point: the model is a commodity, the index of your company is the asset.

Where this genuinely isn't the right answer

If you're a three-person startup with no compliance surface and no client asking hard questions, the hosted enterprise plan is simpler and you should take it. If nobody on the team will own the box after handover, it will rot. And if the real problem is that your docs are wrong, an agent will just retrieve wrong docs faster — that's a content problem to fix first.

But if you've read this far nodding at the parts about where the data goes, you're exactly the company this is for.