One of the first things I created as part of my agentic infrastructure was the ability to triage my email and Slack messages. My “agentic infrastructure,” for the record, is three skills that work together off about ten markdown files. Very fancy.

Then, the other day I noticed that I repeatedly get the same emails on my personal account: invitations for my personal training sessions and for my kids’ piano lessons. I wanted those to show up on my work calendar, since that’s my calendar of record. The obvious move would have been to set up an email filter, but I was already in Claude, so I just asked Claude to do it.

Later, I realized how over-engineered that was. When I asked Claude to “do it,” I don’t mean that I asked Claude to create an email filter, I mean I asked Claude to do the work itself.

It’s not just me, and it’s not just email

Now multiply that across a company. MCP, the standard that lets Claude plug into other software, means the AI can now reach into systems like Salesforce, Jira, Slack, and SharePoint. Every one of those products already has its own rules and automations that solve repeated work. But once people can just ask Claude, they aren’t necessarily using those, the same way I skipped the Gmail filter. And to be fair, MCP is also giving us access to systems whose interfaces we’ve never seen and whose menus for automation are alien to us. It’s no wonder we just ask Claude.

When I think about what’s flowing through enterprise AI systems now, the magnitude of this problem is striking. Routing a support ticket to the right team based on which product it mentions. Updating a field in the CRM when a deal closes. Moving a Jira ticket when the code merges. Putting an invite on the right calendar. Each of those is an “if this, then that.” Each one now spends tokens reasoning its way to an answer a rule would have given for free.

For me, this is a few cents and a calendar invite. In an enterprise, it’s a much bigger problem. It’s thousands of people, plus a growing number of agents they have enlisted and trained, running the same rule-shaped jobs thousands of times a day. Every one of those runs gets billed. And every one of them is a fresh chance for the answer to come out a little differently, in places where “a little differently” means a ticket goes to the wrong team or a deal shows up in the wrong forecast.

Look, it makes sense that we’d work this way. We’re spending our days teaching, conditioning, and building agentic workflows, so of course we want to talk to everything in that same format: through MCP, with a skill and a few markdown files for context. The problem is that this setup defaults to being non-deterministic. There’s nothing in the architecture that says it couldn’t be deterministic. It just isn’t, unless you write “NEVER do X” and “ALWAYS do Y” in capital letters, like you’re yelling at a toddler who’s about to touch the oven. That doesn’t feel like something the success of an enterprise workflow should hinge on.

Meanwhile, everyone is talking about cost

I hear plenty of leaders talking about how expensive it is to roll Claude out to everyone. The fixes I hear about tend to be big and complicated: data lakes, caching layers, a new platform to sit in the middle.

What I don’t hear is the simple question. How much of what we’re sending through an LLM doesn’t need to happen there?

Now, LLMs can produce an enormous amount of content that is genuinely valuable. So it makes sense that we started shifting work to them. But a lot of jobs don’t need any of that. Ask an LLM the same question twice and you can get two different, equally reasonable answers. For a first draft, that range is the whole point. For “put this on my calendar,” there’s exactly one right answer. Using something that can imagine a dozen possibilities just to land on the one obvious one is overkill.

Anthropic makes the point plainly in a post about Claude skills: “sorting a list via token generation is far more expensive than simply running a sorting algorithm.” Nobody would argue with that sentence. And yet.

Even the plumbing costs something. Anthropic’s own engineers wrote about how loading MCP tool definitions and passing results back and forth through the model can eat up a huge amount of context. In one example, they cut a task from about 150,000 tokens to 2,000 by having the agent write and run code instead of routing everything through the model.

Language in, not language out

What I keep coming back to is that some of the magic of an LLM is on the way in. I can ask a question or give direction in plain English, without knowing which menu the setting lives in, what the field is called, or whether the feature exists at all. That part is genuinely new, and valuable.

But the thing I need back often isn’t a response in generated language. When I asked Claude to address my inbox calendar invites, I didn’t need a prose response, I just needed the work done. The person routing support tickets doesn’t need a conversation; they need the ticket in the right queue.

To be fair, sometimes the thinking on the way in is worth every token. Just last night I had a complicated question about one of our product pipelines. Salesforce’s own AI assistant didn’t have the context to understand what I was asking, so I asked Claude to do it instead, and spent a bunch of tokens doing it. That was a one-time question, and I’d do it again. But notice what I needed back: just the results from a complex report. The language was all on my side.

That’s the pattern. For certain tasks, I want language on the way in, because that’s how I think and ask, and I need an old-fashioned automated action on the way out.

Think of it like asking someone what time it is. They might be wearing a Garmin that also knows the direction of the sun, their heart rate, and their blood sugar. But you don’t need any of that, because all you asked for was the time. For that question, the Garmin and a plain analog watch are equally good.

Where’s the conversation?

Here’s the part that surprises me. The conversation does exist. Engineers talk about “workflows versus agents,” about when to let the model decide and when to hard-code the path. Tools like n8n and Make are built around fixed steps with an AI step dropped in only where you want judgment.

But I don’t see that conversation on the business side. I don’t see it in the leadership discussions about AI budgets, and I don’t see huge amounts of capital going into companies whose pitch is “use less AI where you don’t need it.”

As a product marketer, I have a guess about why: predictability is hard to sell. “It does the same thing every time” doesn’t demo well next to “it wrote the whole campaign brief.” And there’s a bit of a game of chicken going on. Every AI vendor’s revenue grows with every token we spend. Who wants to be the first one to stand up and say, “spend less with me”?

Mind the gap

None of this means generation is the problem. Generative AI is useful on both ends: in how we ask, and, plenty of the time, in what comes back. A first draft, a summary, an answer to a hard question about a pipeline, a prototype for a web page. That’s real value, and it’s worth the tokens.

But I’d love an assistant that noticed the difference for me. “You’re asking me to do something I can ask your connected tool to do directly. Want me to do that?”

Meanwhile, my training invites (and the piano lessons) are still going through Claude every time. I’m not sure if that says more about the tools, or about me.