Skip to main content

← All writing

The agentic spectrum: stop burning tokens on what a script can do

The agentic spectrum: stop burning tokens on what a script can do

AI workflows sit on a spectrum, and people often tend to go too far up it. At the low end, an LLM does one bounded task: translate this page, summarize this doc, rewrite this paragraph. At the high end, a long-running agent sets its own plan and grinds away unsupervised until the job is done. Both ends are useful. The mistake I keep seeing is reaching for the autonomous end when a small script would finish the job for a fraction of the cost. Tokens are cheaper than ever, but we tend to use LLMs in a more agentic way, driving up the bill.

The agentic spectrum

Think of a line. On the far left, the human drives every step and the AI fills one slot: you ask, it answers, you decide what happens next. In the middle, you script the actual actions and let an agent trigger or supervise them, so the work is deterministic and the AI is the operator, not the brain doing every keystroke. On the far right, an autonomous agent decides what to do and does it with no human in the loop.

Most content work lives in the bottom third of that line. That is also exactly where people stop building scripts and start handing the whole thing to an agent. The capability is impressive, so it feels like the right tool. That isn’t always the case, especially at scale.

A token bill that got out of hand

Someone asked me about a Contentstack MCP setup they were running for a big site redesign. Two stacks (content repositories). One MCP instance pointed at stack A for the initial planning. A second instance pointed at stack B, where they needed to update 351 entries based on that initial planning.

The agent worked. It also burned through their five-hour Claude usage limit almost three times before those 351 entries were done. Three windows of usage to perform what is, underneath, a loop.

What to do instead?

Talk to Claude about the task first. Tell it you have AI skills available, the ones in the contentstack/contentstack-agent-skills repo on GitHub. Tell it you have an MCP connected to the stack. Once Claude understands the shape of the problem and has the connections, ask it to write a mini CLI or a short script that runs all the content updates.

Then you run the script. The actions happen through deterministic tooling. Claude does the planning and the handholding, not the grinding.

The shift is small, but it changes the economics. It uses more automation and less LLM agentic loops, resulting in much lower costs.

Why a script wins here

351 entries is a loop, and a loop is the most solved problem in computing. An agent that re-reasons about each entry pays the reasoning tax 351 times. A script reasons once, when you write it, then executes 351 times for free.

You move the thinking to authoring time and let cheap, predictable code do the repetition. You also get determinism for free: the script does the same thing on entry 1 and entry 351, every run, no drift, no surprise tool call halfway through that eats an hour.

Building the script is cheap now. Claude can write a custom CLI in minutes, you run it once, and you throw it away. There is no maintenance story to worry about because there is nothing to maintain.

When more agency is needed

I do not pretend a script is always the answer. There is an agentic spectrum for a reason.

Some tasks belong at the autonomous end. When the work is genuinely novel each time and no script can capture it in advance, you want reasoning in the loop. If every entry needs a judgment you would struggle to write rules for, an agent earns its token cost because a script simply cannot do the job.

So the line to watch is this: is the task a loop with a known shape, or a series of unique decisions? Loops want scripts. Decisions want agents. The trap is that most content work at scale is a loop wearing a decision’s costume. Be honest about which one you actually have before you pay for the expensive option.

Platforms should cover the whole spectrum

Content platforms should offer an agentic experience across the full range, not at one fixed point. LLM-assisted tasks for the small bounded work. Deterministic automations and scriptable tooling for the loops. Autonomous agents for the genuinely open-ended problems that need reasoning at every step.

It is a wide range, and real use cases live at every point on it. Today most platforms either push you toward one end or leave you to wire the rest up yourself. The ones that map the whole spectrum, and make it easy to pick the right point for the job, will save their users a lot of tokens and a lot of grief.

I think content platforms should offer APIs, MCPs, Skills, and automation flows so end-users can chose how to manage their data in their context. Each capability needs to be autonomous and when you combine them you get magic.

An example of this is that in the next version of the Contentstack MCP, we allow users to create deterministic automations with steps, connectors, data mappers, credential management, and expose these as tools to the MCP. We will also have a wizard to choose only the tools you need. This allows LLMs to choose a deterministic or an agentic approach to cover what is needed for the user on the agentic spectrum.

Concluding

Go less agentic and more deterministic whenever you can. Not because agents are bad, but because most problems with a bit of scale are loops, and loops have had a good solution since long before any of us were writing prompts. We are handing those loops to agents that chew through context like it is free, when a quick custom CLI would be more stable, more predictable, and almost free to build.

Be clever about where you spend the expensive reasoning. Have Claude write the one-time CLI, let your agent run it, and save your token budget for the work that actually needs a brain.

On this page
Aug 24, 20267 min read

Claude Desktop MCP lifecycle is broken

Claude Desktop currently launches duplicate local MCP stdio servers for a single configuration, causing two independent OAuth flows, extra browser tabs, and unnecessary resource usage. The bug is masked once credentials are cached, so it silently persists in production while still spawning two processes every time. This is not an mcp-remote or external service issue but a host-level lifecycle problem, likely caused by overlapping legacy and new MCP managers and poor observability for one of the processes. Workarounds like pre-authenticating with mcp-remote mitigate UX pain but do not fix the duplication. The article argues that open-source tools should not shoulder complex coordination logic just to survive a major desktop app’s sloppy process management.

  • Composable architecture
  • AI engineering
  • Performance
Aug 5, 20268 min read

Ten AI security problems hiding in plain text

This article argues that AI security risks extend far beyond model jailbreaks and prompt engineering, into every piece of text an AI can read. Natural language now behaves like soft code, where logs, documentation, commit messages, wikis, support tickets, web pages, PDFs, and search results can all carry hidden instructions for agents. The author walks through ten concrete scenarios where ordinary text fields become attack surfaces, often with delayed or indirect activation through internal tools and multi agent pipelines. The core message is that information and instruction have blurred, and any text accessible to AI must be treated as part of the security model. Teams need to rethink access, editing rights, retrieval, and agent capabilities accordingly.

  • Composable architecture
  • AI engineering
  • Cloud & infra
Jun 20, 20266 min read

We are thinking too small

AI coding agents are not a threat to developer jobs, they are a fundamental shift in the economics of software creation. Just as the cloud removed the risk and capital cost of infrastructure, AI is removing the cost of writing and refactoring code. This kills the old moats that protected horizontal enterprise platforms and makes rebuilding wide, deeply integrated stacks viable. Instead of spending years stitching together narrow SaaS tools and APIs, teams can let agents generate bespoke services quickly and cheaply. The real risk is using AI only to speed up legacy glue work. Developers who win will treat the cost of reinventing the wheel as effectively zero and pursue much larger, previously impossible product ideas.

  • Composable architecture
  • AI engineering
  • Cloud & infra