The Independence part closes by laying AI on top of everything stood up so far. Foundation, gate, documents, code, mail, meetings — an AI grounded in the data piled there, on your own side. The pgvector enabled back in 2-02 finally pays off here.
Why your own AI
- Keep data in — don't hand confidential internal documents to another company's API
- Always-on is cheap — run classification, summarization, and extraction continuously at zero marginal cost
- Grounded in your data — answer in light of internal documents, code, and history
Stand up the model — North Mini Code on Ollama
To start easily, Ollama. Stand up an open-weight model in one line and use it as an API.
The first one to load is North Mini Code (Cohere) — an open-weight (Apache 2.0) agentic coding model. It is exactly the tool this sub-series centers on: "the builder has AI write the code." A 30B MoE with only 3B active, it is light enough to run with low latency even on local hardware.
docker run -d -p 11434:11434 ollama/ollama
docker exec -it ollama ollama pull north-mini-code # open-weight, runs on your own side
You can hit it free on OpenRouter to try, but in production run it yourself — neither code nor data leaves your side. Cohere is one corner of sovereign AI, alongside Europe's Aleph Alpha (→ blog 027).
For RAG and chat, separately load a general model (Qwen and the like) and an embedding model on the same Ollama. As volume grows, move to the higher-throughput vLLM, and for always-on processing that needs higher quality you can choose the privately deployable Command A (Cohere, mentioned in 2-02). Stand one up first, swap as needed.
RAG — put pgvector to work
This is the payoff from 2-02. Turn internal documents, code, and mail into embeddings (vectors), put them in pgvector, pull the fragments closest to a question, and have the model answer — this is RAG (retrieval-augmented generation).
# 1) embed a document and put it in the 2-02 pgvector
emb = embed(text) # a local embedding model
pg.execute("INSERT INTO docs(body, embedding) VALUES (%s, %s)", [text, emb])
# 2) pull the closest fragments and have the model answer
hits = pg.execute(
"SELECT body FROM docs ORDER BY embedding <=> %s LIMIT 5", [embed(q)])
answer = llm(f"Answer based on the following sources:\n{hits}\n\nQuestion: {q}")
The table for which 2-02 "only had the vessel ready" now gets its contents. An AI that answers from your own real data, with citations, stands up on your side.
The AI does not bypass the gate
One thing must be decided as design, up front. RAG searches only within the documents the asker can open — write this into the spec from day one. Feed the whole company's documents to an AI, and an employee without clearance can extract, as an answer, the contents of documents they could never open. The gate (2-03) and the xattr permissions (2-05) must not be bypassed here.
Two tiers suffice. By default, put into RAG only the shared knowledge everyone can read, prepared in 2-10 — deciding the scope at preparation time is the most reliable control. If permissioned documents must be searchable, carry each document's permission on its pgvector rows and filter the search by the asker's token. The sources then come only from documents that person can open.
Search, too, happens inside the key. The AI does not bypass the gate.
The chat UI — Open WebUI
The window people use is Open WebUI — a screen resembling ChatGPT or Copilot, connected to the model and RAG you stood up. Place it behind the 2-03 gate, beyond the reverse proxy.
ai.example.com { reverse_proxy open-webui:8080 }
How much to keep in-house — honestly
Open models have reached practical sufficiency. But for the hardest judgment and large-scale code generation, frontier models like Claude are still stronger. This is the same shape as the mail relay (2-06) and Cloudflare (2-08).
- Keep in-house — processing of confidential data, always-on classification, summarization, RAG (the real body of control)
- Borrow — hard judgment and heavy generation go to a frontier model's API
Control on your side, capability borrowed as needed. Keeping everything in-house is not the goal — hold the data and the daily processing in your own hands, and send only the hardest parts out.
And the range you can hold yourself widens as hardware advances. AMD's Ryzen AI Max PRO 400 series (Q3 2026, from ASUS, HP, and Lenovo) carries up to 192GB of unified memory (up to 160GB allocatable as VRAM) and is the first x86 client capable of running 300B-class models locally. Once a PC with this is on your desk, you can run Command A+ (Cohere, privately deployable, RAG with citations) entirely in-house, mainly for company document management. The heavy document RAG you can only borrow today comes home — the line of what you borrow recedes year by year.
The value of your own AI is not maximizing cleverness. It is embedding AI into the everyday without letting go of your data.
Summary — closing the Independence part
Your own AI, on top of everything.
- Ollama / vLLM — start with North Mini Code (Cohere, an open-weight coding model), add a general model alongside for RAG; Command A where quality is needed
- RAG (pgvector) — fill the 2-02 vessel with internal data, answer with citations
- Open WebUI — a ChatGPT-like window, behind the gate
- In-house vs. borrowed — data and always-on in-house, the hard parts to a frontier model
From 2-02 through 2-11, we replaced Microsoft 365 and the vendor packages under the core systems, one at a time, with OSS. Foundation, gate, documents, code, mail, meetings, booking, web, information preparation, AI — none of it was written; it was stood up.
As written at the start of 2-02 — the effect of OSS is greater than the effect of AI. The generic is already shared with the world.
That closes how you build it (the Independence part). From the next chapter the viewpoint shifts — why this changes the industry's structure (the Shift part). In an era when you can stand it up yourself, why does the SIer-commissioned model become structurally uneconomic?