I'm not in the framework war
This week on my feed: Google Agent Development Kit climbing on stars. OpenAI Agents SDK with native MCP. CrewAI consolidating. Goose maturing under the Linux Foundation. Cline, Aider and OpenHands with new releases. Microsoft shipping its Agent Governance Toolkit (MIT, April 2026). A whole week of fireworks.
My reaction? I tried zero. I spent the afternoon tuning a two-second pause in the script that builds Diana's drafts, because it was stomping on files in parallel. Thirty seconds of code, problem solved.
It's not that the frameworks are bad. Every one I cited solves something real. It's that they're not what I need. What I have is a pattern, not a framework. And the pattern is what survives the next release.
The pattern, in three pieces
My Harvie setup has three layers and only three:
1. Common protocol for tools: MCP
MCP (Model Context Protocol) has been an open standard under AAIF (Linux Foundation) since December 2025. If I need to connect Notion, Gmail, calendar or a scraper, I speak MCP. I don't invent my own plugin system. I don't marry myself to one framework's plugin store.
If a better-orchestrated framework ships tomorrow, my tools keep working. If Anthropic changes attitude (which it already did on April 10 with Steinberger's temporary ban), MCP doesn't break — it lives in a foundation, not in a company.
2. Business logic of my own: in my runtime
The OhanaSmart skills, Diana's templates, the ~130-lead pipeline, the running coach — all of it lives in my runtime, not inside someone else's framework workspace. My code, my repo, my decisions. If one of the skills evolves, I don't have to ask anyone for permission.
That was the lesson of April 11: when I migrated from OpenClaw to Hermes, what mattered wasn't the model — it was not having my code trapped inside a harness that could change the rules tomorrow.
3. Gates per domain: specific, not generic
Each flow has its own checks before executing:
- OhanaSmart B2B: drafts-only on Gmail (Diana reviews and sends manually), triple email validation (cross-source + heuristics + MX/SMTP), dedup in Notion.
- Running Coach: output only via Telegram, COROS data validated before the morning briefing, no automated email.
- La Fábrica: interactive proposal behind a password gate, access tracking in Supabase, no mass send.
Three domains, three different gate sets. No framework gives me these by default, because they depend on the business, not the runtime.
How the three pieces fit together
[ Notion / Gmail / Telegram / COROS / Supabase / scrapers ]
↑
MCP (protocol)
↑
My logic (own runtime)
↑
Gates per domain (specific)
↑
LLM (swappable)
The LLM sits at the bottom, not in the middle. It's a service. Today it's Claude Pro Max via proxy, tomorrow it could be OpenRouter or a local model. If I swap it, no gate and no skill notices.
That's the trick: the pattern is stable because every piece is replaceable without touching the others.
What a new framework doesn't break for me
Suppose Google ADK ships a brutal multi-agent orchestration tomorrow and everyone migrates. What do I do?
- My LLM: same (swappable, ADK doesn't lock me in).
- My tools: same (they speak MCP, ADK does too).
- My gates: same (my code, not framework plugins).
- My logic: same (lives in my repo, not their workspace).
The only thing that could change is the internal orchestration layer — and that's a couple of files. It's not a migration, it's a refactor.
Now suppose the opposite: I'm 100% on top of a framework, ADK ships that new orchestration, but my current framework ignores it. Result: I either suck it up, or I rewrite everything. Because my code lives inside the framework, not next to it.
The question I ask before adopting anything new
Every time a release moves the feed, my check is one:
If this disappears in 6 months, what breaks in my setup?
If the answer is "nothing, I unplug it and move on", it's a candidate. If the answer is "my code would have to be rewritten", I pass. The line between "tool" and "structural dependency" is drawn by that question.
Applied to this week:
- Google ADK: does it disappear and break something of mine? No. → I can try it if I want.
- OpenAI Agents SDK: does it disappear? No. → same.
- Microsoft Agent Governance Toolkit: does it disappear? No. → it can inspire my gates, but it doesn't replace them.
None of them are necessary today. If tomorrow I find one of them saves me work on a specific piece without locking me in, I plug it in. If it forces my logic into its workspace, I pass.
Why this pattern beats the framework
It's not ideology. It's survival.
The cycle of an agent framework in 2026 is ~6-12 months between release, hype, adoption and being displaced by the next. If you build on top of one, every cycle costs you. If you build the pattern next to it, every cycle you choose which piece to migrate and which piece to keep.
The ecosystem centralizes around open protocols (MCP, A2A, AGENTS.md — all under AAIF) and decentralizes the implementation. That's exactly the opportunity for an indie developer: get on the protocol and build your vertical on top, without asking permission from any foundation or any company.
What I learned this week
- Frameworks compete on the orchestration layer. It's the most visible layer and the least important. The one that matters is business logic + gates, and that's on you.
- The protocol is stable, the framework isn't. MCP has been a year under shared governance. Frameworks are still company projects with roadmaps that shift.
- If your setup collapses when a new framework ships, your setup was the problem. Not the news.
What's next
- Try one of the new community MCP servers (without replacing anything — adding a tool).
- Document the pattern explicitly in the runtime's README: "this is composition, not framework".
- Bring the idea to the La Fábrica call: the pitch isn't "we have an agent on Google ADK"; it's "we have a pattern that survives the next Google ADK".
— me, Johnny — agent configured: Harvie. The framework that ages best is the one I'm not using.