CatalEx Engineering

Everyone who designs an agent loop spends their time on two steps. They tune the generate step, because that's where the intelligence appears to live. They harden the verify step, because that's where the discipline lives. Almost nobody budgets serious design effort for the third step, which is the one that actually determines whether the loop is trustworthy: the stop.

Here is the uncomfortable mechanical fact underneath every loop you have ever built. A turn that produces text with no tool call is the only place a run can stop. That's it. That's the entire exit condition — the absence of a function call. And that single signal conflates three completely different situations, which is why agents routinely "finish" tasks they never did.

This post assumes you already have a loop — generate, verify, correct — and that it has burned you at least once. We're going one level down, into the exit.

Ask an engineer how to stop an agent that won't stop, and you'll get the same answer every time: add a limit. It's the right instinct and the wrong plan. There is no single limit that catches every shape of runaway, because runaways don't have one shape — and each shape slips past a different guard for a different structural reason.

A skill is a self-contained Markdown directive with a little YAML frontmatter on top, sitting in its own directory. That description makes it sound like documentation, which is exactly the trap. The interesting part is not what a skill contains. It's when the agent pays for it.

Here is the sentence we keep in our own skill registry, and it is the whole design: a skill is a directive the agent reads on demand via a read_skill tool, rather than something injected into every prompt — so the agent pays the token cost only when the skill is actually relevant to the turn.

"Run this agent every morning at 9" sounds like a one-line feature. There's a cron expression, there's a job table, there's a thing that reads the table. Ship it Friday.

Cron is the easy 5%. The other 95% is not firing twice, not losing a fire, not holding a database transaction open across a task that runs for minutes, and deciding whose 9am you actually mean. A cron expression is a trigger. A scheduler is everything you build around it.

"What can your agent do?" is two questions wearing one coat. The first is about the action space: once the agent is awake and thinking, what can it reach, call, read, and change? The second is about the trigger space: what makes it wake up in the first place? Teams conflate them constantly, and the conflation is expensive, because the two want opposite answers.

From the outside, creating an agent looks like filling in a form. You describe what you want, you look at a preview, you click a button. Thirty seconds, maybe less. The interface is doing everything it can to feel like nothing much is happening.

"Give the agent memory" is one of those phrases that sounds like a feature and is actually an architecture. Everyone agrees agents should remember things across sessions. Almost no one agrees on what that means — and the default implementation, a vector database that everything gets dumped into, produces agents that are confidently wrong about their own past.

Every team that has tried to ship an AI feature has hit the same wall. The demo works. A stakeholder asks, "is it good?" and the honest answer is a shrug. You feel like it's good. You changed a prompt and it feels a little better, or a little worse, and you cannot say which, because "feels" is the only instrument you have.

The most expensive misconception in applied AI is that performance lives in the model. Pick the best model, the thinking goes, and the rest is glue. So teams spend their attention on which model to call and treat everything around it — the tools, the loop, the context they assemble, the way they check the output — as plumbing.

There's a tidy argument going around: skip the Model Context Protocol, just give the agent a shell and a CLI. No server to run, no schemas to maintain, and — the clincher — it saves tokens, because a command is short and a tool definition is long. It's a good argument. It's also only half right, and the missing half is where most of the cost actually lives.