Lately a lot of people I talk to are impressed by something specific about how I work. They watch me handle a workday and notice I rarely open the apps I’m supposedly using.
I almost never look at Gmail. I haven’t logged into WordPress admin to write a post in months. I post to LinkedIn without opening LinkedIn. I check analytics without going to Google Analytics. I manage fifteen Cloudflare zones, half a dozen WordPress hosts, and three domain registrars without ever clicking through their dashboards.
The whole day runs through a terminal and a small set of dashboards I built myself.
The question I get most often is: “Why don’t you just install OpenClaw?” Or Hermes. Or Goose. The three big bundled AI agents of 2026. Between them, more than half a million GitHub stars, NVIDIA partnerships, Linux Foundation stewardship, OpenAI-bound founders. Some of the most carefully built open-source projects in the world right now.
I’m a fan of all three. They’re going to get a lot of people into AI-assisted work who wouldn’t otherwise get there, and that’s a real contribution. For a meaningful share of users, one of them is the right call.
I’m just not one of those users. And I think that’s true for more people than realize it.
What the bundled agents are great at
The category is easy to summarize. OpenClaw with 347,000 stars, Hermes with 140,000, Goose with 38,000. They all sell roughly the same thing.
Install one package. Connect your messaging apps (Telegram, Slack, WhatsApp, Discord, iMessage) and your tools and your credentials. Then chat with the agent like you’d chat with a colleague, while it handles email, code, browser, files, calendars, and APIs in the background. The big promise is that you stop being the glue between systems.
For a lot of people, this is the perfect entry point. The activation energy of “install one thing, connect a few accounts” is dramatically lower than “learn what an MCP server is, decide which scopes you actually need, write your own thin layer.” The bundled agents are doing real work to make AI agents accessible to people who wouldn’t otherwise touch them.
But the design choices they make to be that accessible come with three trade-offs. None of them are flaws. They’re just costs that get higher the more idiosyncratic your work becomes.
The three trade-offs
First, you stop seeing the moving pieces. When the agent does the work, you watch. You don’t see why your email got triaged. You don’t see how it knows to talk to your hosting provider. It’s the same trade-off that came with no-code tools at scale: when something breaks, and at some point it always breaks, you don’t have the leverage to fix it.
For a lot of people, that’s a fair trade. They want the outcome, not the leverage. For others, including me, the leverage is the whole point.
Second, the permission surface is broad, by necessity. Bundled agents need bundled access. To do real work they need OAuth tokens for half your life: Gmail, GitHub, hosting, calendar, possibly your bank. OpenClaw’s marketplace of thirteen thousand community-submitted skills is genuinely impressive in coverage. It’s also the structural reason it ships CVEs at a fast clip. That’s not a maintainer failure, it’s the cost of an open marketplace. Worth it for many people. Not worth it for me.
I just don’t want one package to be able to delete my WordPress site, send an email as me, and push a force-push, all in the same minute. Not because I think anyone is targeting me, but because I prefer the OS-level isolation that Bash and Keychain give me by default.
Third, and this is the one that matters most for power users: they’re built to fit everyone, which means they don’t fit anyone perfectly. Goose’s LinkedIn integration is built to fit the average LinkedIn workflow. Mine is specific: same scopes, cron-scheduled, no scrolling, posts straight from a text file. OpenClaw’s WordPress integration is built to fit the average WordPress workflow. Mine spans Kinsta, WP Engine, and Servebolt with different auth on each. The bundled agents necessarily smooth over the parts where you have judgment, because those are the parts that don’t generalize.
If you don’t have strong opinions about how your tools fit your work, having a framework smooth those decisions away is a feature. If you do have those opinions, it’s a loss.
What I built instead
There’s no clever framework name for what I have. It’s a terminal, Claude Code, a handful of MCP servers I wrote myself, my API tokens in macOS Keychain, and a dozen or so small scripts. The install footprint is trivial. The permissions are surgical. Every piece of it maps to something I actually do.
Five examples.
1. LinkedIn
I haven’t opened LinkedIn to post in months. I created a developer app on LinkedIn’s own API, scoped only to w_member_social (post on my behalf, nothing else), and a fifty-line Python script that posts a text file. For scheduled posts, the same script runs on one of my WordPress hosts via cron, independent of my Mac. The whole thing is the equivalent of one HTTP POST.
OpenClaw would handle this with a community skill that asks for OAuth on my whole account. That works. It just gives more away than I need to give.
2. Email
I read, reply, archive, and triage email without opening Gmail. Behind the scenes is my own Mailbox MCP server — Python, open source, exposing only the operations I care about: read, reply, archive, search, label, draft. When I want to reply to a vendor in Spanish, Claude drafts it in my voice, I review it, and I say “send it.” My standing preference (always show me the draft, never send without approval) is one line of plain English saved once. It sticks across every session.
A messaging-gateway agent that watches my inbox and acts on it before I read it is a different design choice. For a lot of people that’s the dream. For me, that’s the specific failure mode I want to avoid.
3. Telegram
Same pattern, different surface. I run a Telegram MCP server that I wrote myself, so Claude can read, send, search, and react inside any of my Telegram chats — group threads with friends and family, private DMs, channels. When I’m researching a question that came up in a group of fifty people last week, “search Telegram for the last conversation about Spanish autónomo deregistration” is one prompt, not twenty minutes of scrolling.
The bundled agents will all happily integrate with Telegram. The way they do it is via a single shared bot account or a session token they manage centrally. Mine is a session I control, on a server I control, with code I read before running. The functionality is the same. The trust boundary is completely different.
4. WordPress
I run nine WordPress sites across three different hosts. I haven’t logged into wp-admin to write a post in well over a year. Every site has SSH access, and WP-CLI handles content, plugins, users, exports, and search-replaces from the command line. Writing a post is a one-line command. Publishing a draft is one more. When I need to migrate a site or update a thousand posts, that’s a script, not forty-seven clicks.
The bundled agents would handle this through WordPress plugins. Plugins are a tricky place to put privileged automation, but credit where it’s due, they’re the only realistic option for anyone without shell access to their host.
And it’s about to get easier for everyone. WordPress now ships the Abilities API: a core mechanism for exposing WordPress operations as standardized REST endpoints at /wp-json/wp-abilities/v1/*, registered in PHP with wp_register_ability(), consumable from any HTTP client. That’s where the work belongs, at the platform layer, as an open standard. The bundled agents will be among the first to benefit, and so will custom setups like mine. Convergence, not competition.
5. Hosting, DNS, and Cloudflare
Fifteen Cloudflare zones across one account. A registrar API. Several SSH hosts. All of it runs through Bash with API tokens stored in macOS Keychain, encrypted at the OS level, never written to a config file, scoped to exactly what I need. Purging cache, swapping nameservers, checking SSL, deploying a Worker: none of these involve a dashboard.
A bundled agent could absolutely do this. It would install three or four skills, each with their own permission ask. Or I write fifteen lines of Bash and never give anything more access than it needs. Same outcome, very different shape.
The principle
What ties this together is something I think the AI agent industry is converging on, not missing. The right place for a generalist agent is at the top of the stack, not in the middle.
Claude, or any frontier model, is the generalist. The thing it’s interfacing with, your work, should be specific. The connective tissue between them works best when it’s thin, transparent, and yours.
The bundled agents take a different bet. They put the framework in the middle and let everyone share it. That bet is right for a lot of users, especially anyone whose work is close to the median of what these tools are built to do. The work you’d see in a tutorial is exactly what they fit.
The further your work is from that median, different stack, different rhythm, different security posture, more idiosyncrasy, the more you benefit from owning the middle layer yourself. You don’t need a hundred skills. You need three or four that map to your tools. You don’t need a Rust binary or a heartbeat daemon. You need a few shell scripts and an MCP server. You don’t need a framework. You just need to know how your own work flows.
What you actually get out of doing it this way
What surprised me most was how this approach builds on itself. Every time I wire up a new integration, I understand it. Three months in, I can recombine pieces I built two months ago to solve problems I didn’t know I had. I can tell you exactly which API call is being made when I “send a post to LinkedIn,” because I wrote it myself.
That’s not strictly better than using a bundled agent. It’s a different kind of better. The bundled agents give you outcomes. Building it yourself gives you outcomes plus understanding. For a year of work, that compounds.
What to try
If you’re staring at OpenClaw or Hermes wondering whether to install one, here’s a small experiment to run first.
Pick the one work task you do most often. Email, posts, content, deploys, whatever it is. Open Claude Code, or your terminal of choice. Spend a weekend building the smallest possible thing that lets you do that task without opening the consumer app. One MCP server. One script. One Keychain entry.
Then live with it for a week. See what breaks. See what you wish it did. Add that.
If that weekend was fun and you finished with something you actually use, do it five or six more times and you’ll have a layer that fits you exactly. If it felt like a chore, install OpenClaw or Hermes. You’ll be in good company and you’ll get great work done. Both paths are real.
The mistake is treating “install the framework” as the default without trying the other one. The bundled agents are good, and they’re going to keep getting better. But for anyone whose work has its own shape, a layer they built themselves will fit better than any framework ever could.
Related
Leave a Reply