“Can’t I just build this as a skill in Claude?” It’s a fair question, and it comes up more now that every vendor ships some version of one: Claude has Agent Skills, OpenAI has Workspace Agents, Google has Gems, Microsoft has Copilot agents.
The obvious objection to running operations in a chat session used to be that a session isn’t running at 2am. That objection is gone. Claude Code Routines run on Anthropic’s cloud with schedule, webhook, and GitHub triggers. Cowork Scheduled Tasks run server-side with no device online. Workspace Agents keep going after you close the browser.
If triggering were the whole difference, this post would be obsolete. It isn’t, because triggering was never the hard part. What matters is run number four hundred, and who is watching it.
What a skill is, and isn’t
A skill makes one model better at a task. You give it context and a goal, it works the problem, you get an answer. When the task calls for judgment, that’s exactly the right tool.
What it still isn’t is a place for your operations to run, and the vendors say so themselves. Anthropic’s routines documentation warns that a green run status “means the session started and exited without an infrastructure error. It does not mean the task in your prompt succeeded.” Its own list of failure modes includes webhook triggers “over-firing from webhook retries.” Scheduled runs have a one-hour minimum and can start late by design. Missed Cowork tasks are skipped, not caught up.
That’s not a knock on the products. It’s an honest description of what a session-based automation is: a capable assistant, started on a timer, with no delivery guarantee attached. Operations need guaranteed retry when an API times out, deduplication so a customer never gets two emails, dead-letter handling so failures surface instead of vanishing, and a record tying each run to a business result. Those are properties of infrastructure. Starting a session on a schedule doesn’t create them.
Three things happen on every run
- It reads its own instructions. Even loaded on demand, the skill’s guidance enters the model’s context and you pay input tokens for it, every time.
- It pays for each step. Real work is a loop: think, call a tool, read the result back, think again. Every turn is billed.
- It can produce a different result than last time. Setting temperature to zero doesn’t fix this. Temperature only makes token selection deterministic; your request still gets batched with a varying number of other people’s requests, and that changes the arithmetic enough to change the output. It’s fixable with batch-invariant kernels at roughly a third of your throughput, which no production API is paying. Identical input does not guarantee identical output.
For an interactive task done a handful of times, that’s a bargain. The trouble starts when you point it at operations.
At volume, the math turns
An operation doesn’t run once. A backorder notification, an order tag, a reconciliation check: each runs hundreds or thousands of times a month, forever, and a skill pays for its instructions and its steps on every one.
The vendors know it, which is why these features ship with caps. Claude routines draw down subscription usage like interactive sessions, plus a daily limit on runs started; past that they’re rejected unless you enable metered overage. Webhook events have hourly caps, and events beyond the limit are dropped. Sensible limits for the job these tools are built for, and a clear signal the job isn’t “handle every order that comes through the store.”
“Usually correct” also isn’t a standard you can hold customer-facing work to. A notification that sometimes goes to the wrong person isn’t a quirk. It’s a liability.
What Clarissi does instead
An automation fires on an event or a schedule, runs a deterministic chain of steps, and calls a model only where an expert decided one earns its place. Most executions make zero model calls: no tokens, identical behavior every time. The rare step that genuinely needs judgment gets a model.
On top of that sits the infrastructure a session lacks: retry, deduplication, and dead-letter handling (why that’s hard), plus measurement tying every run to your baseline (how that differs from a workflow builder). And because we model your operation once, that model powers the automations, a live dashboard, and the weekly analysis, not three separate builds.
The part nobody budgets for
Here’s what the build-it-yourself version leaves out. Say you write the skill and it works. You now own it.
Shopify changes a webhook payload. Your support desk deprecates an endpoint. Volume triples in Q4 and you hit a rate cap. A prompt that worked in March drifts in August. Someone has to notice the run that quietly did nothing at 3am, and someone has to know whether the numbers it produced are trustworthy. That’s not a one-time build. It’s a standing job, and it’s the job that gets skipped, because the person best equipped to do it is usually the person with the least time.
You have three real options, and the middle one is new.
Writing it yourself is a genuine option, not a strawman. You know your operation better than any vendor does, and the platform is built for it: describe the outcome you want, and the system authors, validates, and simulates the automation before it ever touches a customer. An embedded engineer is the same platform with someone else on the hook, reporting what it produced against your baseline every month.
The case for the middle column isn’t that you couldn’t do it. It’s that your time compounds somewhere else. Nobody grew a business by tuning prompts. The work that only you can do, the product decisions, the customer relationships, the calls about where to go next, is worth more per hour than AI plumbing, and it’s the first thing to get crowded out when you take on a maintenance job you didn’t budget for.
Which to use
Use a skill when the task calls for judgment and an odd result is cheap: research, drafting, a weekly summary someone reads before acting on it. Now that these run on a schedule, that’s a lot of useful ground.
Use Clarissi when the work touches a customer or a system of record, has to behave the same way every time, and has to be provable afterward. The test: what happens on the run that goes wrong at 3am? Does something retry it, does something stop it firing twice, and can you show a record of what it did? If the honest answer is “someone would notice eventually,” that work doesn’t belong in a session.
A skill makes the assistant smarter. Clarissi runs the operation when no one’s in the chat, calls a model only where it earns its place, and proves it did the job. Whether you drive it yourself or hand the keys to an embedded engineer is a question about where your hours are worth the most.