The Need for Sovereignty
... a first MCP agent ...
The AI Subscription Model
In the recent past, I relied heavily on commercial infrastructure to handle complex tasks within my ecosystems.
I created a suite of agents following a "Single Intake Pattern".
The combination with (what I realised later) a "Ralph Wiggum - Loop" resulted in a highly efficient, flexible and self improving system. But the current backbone is not affordable anymore.
💸💸💸 is a strong incentive to do something. But it is not the only one. It boils down to the core tension: Convenience vs. Control.
Sovereignty doesn't come for free; and there are limitations. But a lot is possible without the need to tightly couple (and therefore depend) on commercial ecosystem(s). With a clean abstraction we only use the big guns if they are really needed. This is what inspired S.H.O.D.A.N. - a massive, ongoing commitment to building a vendor agnostic framework, hosted entirely within my own domain.
Yep - others are doing the same thing; why not just using something existing that is already out there. The answer is simple: The fun in the process to learn something new and to get the most out of my tools and available resources. I do not know if I, or when I will finish S.H.O.D.A.N. - but for sure it is not ready for the problems at hand.
Pragmatism: MCP
I'll start to encapsulate functions I need - one after the other - keeping the vision in mind. A regular task I face is creating new sorting rules for my self hosted document management system. Using OCR to give the scanned documents a meaningful name, tag and categorise them into different inboxes (e.g. invoices have unfortunately higher priority ...).
A simple exchange of Claude Sonnet with a local model like gemma4:e4b did break the agent orchestration and feedback loops completely
Time to start; time for my first MCP agent. I started with a fork - but as I try to limit the number of tools and libraries and to ensure alignment with my vision I ended up with a re-implementation (the repository history looks terrible now 🤔).
On the plus side: the local models perform surprizingly well and finally I was able to convince Visual Studio Code to use the agent in the workflow.
It is also an interesting - but to be honest, also takes a a lot of frustration tolerance. Unfortunetely the necesary interoperanbility standards are not established yet. It turns out, that MCP is the least of my worries. After experimenting with multiple agent harnesses none of them are major enough to consider for my indented use cases. Vendor lock-in was unavoidable without be able to fully leverage the possibilities.
There are several projects out there. Most of them are partly open source, but for the more advanced features you'll need a subscription. After experimenting with a few it would be a shift from one vendor to the other - as the compatibility with external system is in most cases only achieved after lengthy configuration. If you have models with different abilities or even API's that's an issue. In some cases you'll be limited by the API.
In our case the user is the harness that provides access from the virtual world to the real machines. The tool calls are hell 😈... The protocol seems to be negotiated on the fly - and only if the llm supports this.
For UI's there is an interestig project ongoing:
A2UI is Apache 2.0 licensed, created by Google with contributions from CopilotKit and the open source community, and is in active development on GitHub.
Instead of text-only responses or risky code execution, A2UI lets agents send declarative component descriptions that clients render using their own native widgets. It's like having agents speak a universal UI language.
This repository contains:
- A2UI specifications (v0.9.1 current, v1.0 candidate).
- Implementations for renderers (Angular, Flutter, Lit, Markdown, etc.) on the client side.
- Transports like A2A which communicate A2UI messages between agents and clients
[https://a2ui.org]
Links