Your new MCP workflow is avoidance with a nice UI
Last week, I read a blog post where someone had built an elaborate AI pipeline to manage their email. MCP servers reading every incoming message, scoring them by urgency, routing them into categories, surfacing the results on a custom dashboard.
My first thought was: you have way too many subscriptions.
My second was: don’t you already clear out your inbox each day?
Because if you are—if the emails are being read and triaged—then the problem isn’t prioritisation, it’s volume, and no amount of infrastructure changes that. It’s like building an elegant queuing system for the uninvited guests streaming through your front door, when what you actually need to do is close the front door.
I keep seeing this pattern, and not just with email. Someone’s overwhelmed by Slack, so they build a notification triage system. Someone’s buried in meetings, so they create an AI summariser that writes up the ones they couldn’t attend. Someone’s struggling to keep up with PRs, so they set up automated review tooling that adds more commentary to already-noisy threads.
Each solution is technically impressive, and it’s also entirely downstream of the actual problem. The upstream fix is almost always simpler and more uncomfortable: unsubscribe. Leave the channel. Narrow your engagements.
I recognise this instinct because I’ve lived it. At Almanac, when things were chaotic and I was burning out, my reflex was always to build something—a new process, a new dashboard, a new way of tracking what was going wrong. It felt productive. It was also a way of avoiding the harder, messier work of saying “this is too much” or making yet another brutal tradeoff. In fact, my determination to dashboard all of the things was usually a clear sign I was already struggling.
Engineers are particularly susceptible to this. We’re trained to see problems as things that can be decomposed and solved with better tooling. And sometimes they can: I believe some of these new workflows will help people. But when the problem is fundamentally about too much—too many inputs, too many commitments, too many things competing for your attention—adding another layer of tooling just raises the waterline.
This is especially relevant right now, because AI makes it trivially easy to add complexity. The cost of building an elaborate workflow has plummeted and you can have a working MCP pipeline in an afternoon. Which means the constraint is no longer “can I build this?” but “should I?”
And that matters, because complexity is already our biggest cost—in cognitive load, in maintenance burden, in the slow erosion of clarity that comes from managing too many moving parts. Every new system you introduce has a carrying cost, and most of us are already overdrawn. Taking on more of it willingly, when a little discipline could serve you better, isn’t leverage. It’s avoidance with a nice UI.
“Should I build this?” is a question that requires discernment, not engineering. It asks you to sit with the discomfort of the problem before reaching for a solution. To notice whether you’re solving the real issue or just making the symptoms more manageable. To ask whether the intervention point is really at the output or at the input.
The next time you find yourself sketching out an automated workflow to manage something that’s overwhelming you, pause. Ask whether the problem is really about processing—or about permission. Permission to have fewer inputs and stronger boundaries.
It’s a less satisfying answer than a dashboard. But it might be the one that actually works, now and in the long-term.