A Subscription Is Not an Agent#
Most companies’ first move with AI is to rent a seat on someone else’s chatbot. It works, for a while. Then the questions arrive: Where does our data go? Can it touch our systems — and what stops it from doing the wrong thing? What happens to our workflows when the vendor changes the model, the price, or the terms? You don’t own any of the answers, because you don’t own the agent. You own a login.
For anything that runs inside an organization — reading KPIs, moving tickets, triggering operations — that’s the wrong trade. The valuable thing isn’t “a model that chats.” It’s an agent you control: it lives on your infrastructure, calls your tools against your data, and does it under rules you can audit. I’ve become convinced this is where serious operational AI is heading — so I stopped theorizing and started building.
So I Got My Hands Dirty#
For the last few weeks I’ve been building a real, working agent — not a slide, a running process. The foundation is PicoClaw: an ultra-light AI agent written in Go — a single ~10 MB binary, sub-second startup, MIT-licensed, ~29k stars, maintained daily. It handles the agent loop, the chat channels, and the provider plumbing (Claude, OpenAI, local models), and — crucially — it’s a genuine library: you extend it with your own tools without forking it. (A tip from the trenches: when a project advertises itself as “extensible,” verify it with a compile, not the README. Several don’t survive that test.)
On top of that I’ve been wiring an operational agent that does actual work against real data, over a chat channel a team already lives in. I’m keeping the specifics under wraps for now — it goes by the codename Falcó, after the kind of operative who works alone and quietly gets the job done. When it’s mature enough to show, I will. Today I want to make the case for the approach, and hear what you’d want from it.
Why Owning the Agent Wins#
Owning the agent — versus renting a chatbot seat — changes what’s possible on four axes that matter to any organization:
- Control. The model, the prompts, the tools, the data flow are yours to inspect, version, and change. No surprise model swaps mid-workflow.
- Data residency. Nothing has to leave your network. For regulated or simply sensitive operations, that’s not a nice-to-have.
- IP where it belongs. The agent core is commodity open-source. The durable value is the domain tools that encode how your business actually works — and those stay your code, on your terms.
- Security below the model. This is the one people underestimate. When you own the tool layer, you can put guardrails underneath the model, where prompt injection can’t reach them: least-privilege access to data (read and write as separate, narrow database roles), and human approval on irreversible actions — designed so the model never even sees the approval secret and therefore cannot talk its way past it. You can’t bolt that onto a black box; you have to own it.
Where MCP, RAG and LoRA Fit#
The question I get asked most: can a tiny, self-hosted agent really do the “serious” enterprise things? Here’s the precise, honest answer.
MCP — natively. PicoClaw ships native Model Context Protocol support: connect any MCP server and the agent gains those tools. This is the part I’m most bullish on. Your bespoke tools go in through the code; the entire MCP ecosystem — databases, internal systems, third-party services wrapped as MCP servers — plugs in without touching the agent. A private agent and an open tool standard at the same time.
RAG — not built in, and that’s the right default. A good agent framework shouldn’t ship a vector database, because retrieval belongs to your knowledge, on your infrastructure. You compose it in — as a tool, or cleanly as an MCP retrieval server pointed at your own embeddings store — so answers are grounded in your documents without a byte leaving your network. RAG is something you add deliberately, not a black box you inherit.
LoRA — one layer down, at the model, not the agent. This is the common confusion: LoRA is a fine-tuning technique, so it belongs to whoever serves the model, not to the agent calling it. The clean pattern: serve a LoRA-adapted model on vLLM (which does multi-LoRA serving) or Ollama, expose an OpenAI-compatible endpoint, and point the agent’s provider config at it. Now the whole stack is yours — your fine-tuned model + your agent + your tools — on your hardware.
Put together: MCP for tools, RAG for knowledge, LoRA for the model — three independent layers you own and can swap, instead of one vendor you can’t.
It Even Runs on the Edge#
Because the binary is ~10 MB and boots in under a second on a 0.6 GHz core, it runs where heavyweight stacks can’t: Raspberry Pi, ARM, RISC-V. For anyone working in industrial IoT — as we do at Amplía — that’s a door opening: an agent that can live on the gateway, next to the sensors, reasoning and acting locally instead of round-tripping everything to the cloud. Owning the agent and owning the edge are the same instinct.
The Take#
The model is becoming a commodity. The agent framework is becoming a commodity. The durable value is the layer you own — the tools that encode your operations, the security you can audit, the data that never leaves your walls. Rent the chatbot and you rent all of that from someone else. Own the agent and operational efficiency becomes something you compound, not something you subscribe to.
That’s the direction I’m building in. I’m curious: if you could own an agent end to end — model, tools, and all — what would you put it to work on first? More soon.