Tangison Agent
GitHubWhatsApp
Back to Blog

Architecture · Field note

Why we built a self-hosted AI agent platform

Cloud AI changes terms, deprecates models, and rents your intelligence back to you. We accepted the operational cost of self-hosting because the alternative is worse. This post walks through the three problems that pushed us off hosted AI, the line we draw between your infrastructure and the model provider, and the trade-offs we accepted to ship Tangison Agent as an open-source runtime.

By Tangi Iigonda6 min read

The call that started it

In March 2025, I got a call from a friend who runs a logistics company in Windhoek. The cloud AI service he used to triage customer emails had changed its terms overnight. The new contract gave the vendor a perpetual license to train on and improve from any input his team submitted. He had two weeks to accept or lose access. His account held two years of customer history, contract templates, route data, and pricing logic. None of it was exportable in a form another tool could read. He accepted. I hung up the call and started sketching the architecture that became Tangison Agent.

The shape of the problem

Three problems compound when AI runs in someone else's cloud. They do not appear on day one. They appear once you depend on the system, by which point the cost of leaving has multiplied. We group them under data residency, model deprecation, and vendor lock-in. Each one deserves its own paragraph because each one breaks a different promise the vendor made at signup.

The first problem is data residency. When you send a prompt to a hosted API, your input lives in their region, their database, their backups, and their training pipeline. You sign their data processing agreement, but you cannot prove where the bytes went after the request returned. For a logistics company, that means customer names, delivery addresses, and shipment patterns leave the country. For a law firm, it means privileged communications leave the building. For a hospital, it means protected health information leaves the jurisdiction. The vendor's promise is not the same as your control, and an auditor will draw a hard line between the two.

The second problem is model deprecation. A model is not a product. It is a snapshot of weights that the vendor can retire on a six-month timeline. The prompts you wrote against generation N break against generation N+1 in ways the vendor does not document. The agent you tuned for tone, for length, for tool selection, behaves differently after a silent update. You build on sand. The vendor's release notes are marketing copy, and their migration guide arrives three months after the breaking change already shipped to your users.

The third problem is vendor lock-in. Cloud AI services bundle storage, model access, fine-tuning, and orchestration into one proprietary shape. Once you commit, your workflows, your prompts, your evals, and your guardrails all speak the vendor's dialect. Migrating means rewriting everything in a new dialect, re-tuning against a new model, and re-training your team on a new surface. The cost of leaving grows every month you stay, and the vendor knows it. That asymmetry shows up in your invoice, your rate limits, and your renewal negotiation.

What self-hosting actually means

Self-hosting in Tangison Agent means four things live on hardware you control. The agent process runs as a binary you started. The workspace, where files are written and read, sits on a disk you can unmount and walk away with. The audit log, every prompt and every tool call, sits in a database you back up. The network egress, the policy that decides whether the agent can call out to the internet at all, is a file you edited. None of these four things touch a Tangison server.

Models are the one thing that does not run on your box. We chose OpenRouter as the default model router because it gives you a single key that routes to Claude, GPT, Mistral, Llama, Qwen, and dozens of others. The prompts leave your server, reach the model provider through OpenRouter, and the response comes back. Tangison never sees the prompt. Tangison never sees the response. Tangison never sees the bill. The key lives in your .env file and never touches our infrastructure.

This is the line we draw. Your infrastructure holds the agent. Your key pays for the model. The model provider holds the weights. Three parties, three clear roles, no hidden fourth party in the middle reselling access or metering usage. If you want to run the model on your own GPU instead, you swap the OpenRouter endpoint for a local one and nothing else changes. The skills, the channels, the audit log, the workspace, all stay identical.

The trade-offs we accepted

Self-hosting is more work. You patch the OS. You rotate the OpenRouter key. You monitor the queue. You back up the audit log. You decide when to upgrade the agent. You decide whether to enable a new skill. You are the operator. The vendor will not wake up at 03:00 to restart a stuck worker because there is no vendor. You will.

We made that trade because the alternative is renting your intelligence. When the vendor owns the runtime, the model, and the audit trail, you are a tenant in your own business. The vendor can raise the rent, change the rules, or evict you. You have no leverage because you have no assets. Self-hosting returns the leverage. The agent, the workspace, the logs, the skills, the channels, all travel with you. If you decide to leave Tangison tomorrow, you fork the repo, you keep the binary, and you keep the workspace. Nothing breaks.

The cost is real and we will not hide it. You need a machine. You need an hour to install. You need an evening to read the docs. You need someone on call when the queue backs up. For a solo founder, that someone is you. For a small team, that someone is the most technical person on staff. For an enterprise, that someone is a platform team that already exists. We did not invent the work, we just moved it back onto your side of the contract.

What we built

Tangison Agent is what came out of that calculus. Seven skills ship in the box: web search, file I/O, code execution, HTTP fetch, messaging, deploys, and MCP connectors. Three channels ship in the box: Telegram, WhatsApp, and a web dashboard. One config file defines the agent, its skills, its channels, and its egress policy. The whole thing is MIT licensed and lives on GitHub. You can read the source, fork it, run it on a Raspberry Pi in your office or a Kubernetes cluster in your data center.

You can wire it to OpenRouter or any other model router that speaks the OpenAI shape. You can extend it with a skill in TypeScript in an afternoon. The docs walk through every step, from the first install to the first custom skill, with copy-paste commands and working examples. We built the agent we wanted to use, and then we shipped it with the license we wanted to see.

Closing

If you run a business where data residency, model deprecation, or vendor lock-in keep you up at night, the waitlist is open. Message Tangi on WhatsApp. Tell him what infrastructure you run, what you want to automate, and which model you want to use. He replies within one business day, Monday to Friday, 09:00 to 17:00 CAT. There is no funnel and no CRM. Just a conversation about whether self-hosted AI is the right fit for your team.

Tangison Agent is built by Tangison, an independent software brand founded by Tangi Iigonda. The parent brand ships product work, consulting, and writing from tangison.com. The agent platform is the brand's open-source contribution to the sovereignty-first AI stack, and we intend to maintain it for the next decade.

Run your agent on your terms

The waitlist opens directly to Tangi on WhatsApp. Tell him what you want to automate, what infrastructure you run, and which model you want to use. He replies within one business day. No funnel, no CRM, no third form to fill.

Built by Tangison · More from the brand at tangison.com