How to Automate Your Business Workflow Using Claude Code
A step-by-step method for auditing your work, building evals, and turning repeatable tasks into automated Claude Code skills.
What does it mean to automate a business with Claude Code?
Automating a business with Claude Code means using Anthropic’s coding agent not just to write software, but to observe how you actually work, turn those observations into repeatable “skills,” test those skills until they’re reliable, and then schedule the reliable ones to run without you. The process has four stages: audit your work, convert tasks into tested systems, score them with evals, and schedule or institutionalize whatever clears the bar. One operator used this process on a real agency doing roughly a million dollars a year in revenue and ended up automating most of the non-customer-facing work in the business.
TL;DR
- The audit comes first. Before automating anything, you need a clear record of what you actually do all day, not a guess from memory.
- Screenshots beat self-reporting. Periodic screen captures plus a handful of daily questions give the AI model real context instead of a vague verbal summary.
- Evals are the quality gate. Running each candidate task multiple times and scoring the outputs is what separates a task that looks automatable from one that actually is.
- Not everything should be scheduled. Tasks that need human judgment or client-facing nuance stay human-in-the-loop even after they’re “automated.”
- Skills are the unit of reuse. Once a task scores well, it gets institutionalized as a skill that less technical team members can run through simpler interfaces, not just the coding agent.
- Batching tests saves real time. Running several eval iterations in parallel rather than one at a time can cut the improvement cycle from roughly a week to roughly a day.
- The goal is a short human list. The end state isn’t “everything is automated,” it’s a small set of tasks (calls, judgment calls, client relationships) that a person still owns, with everything else running on its own.
Plans first. Then code.
Remy writes the spec, manages the build, and ships the app.
How do you audit your own work before automating it?
The first step is figuring out, with evidence rather than intuition, what you spend your time on. In the case described, this took about a week and involved building a simple tracking tool using Claude (Opus, on a high-thinking setting) that captured a screenshot of the screen roughly every five seconds, about a dozen times a minute. Each screenshot gets compressed to a minimal, legible size and then summarized: what’s on screen, what task it likely represents. All of this gets logged to a database.
On top of the passive screenshots, the AI also asked the operator a running set of questions throughout the day, somewhere around 10 to 15 per day. These weren’t complicated: what are you working on, why are you working on it, why did you make that choice, what would need to be true for this to run without you. The logic here matters: people are bad at fully articulating their own workflows from memory. You can tell an AI model what you do, but you usually leave out context you don’t realize is relevant. Showing it, through screen activity, surfaces details that telling it would miss.
The output of this audit stage is a full list of every deliverable and process you touch. For an agency, that list might include scraping lead lists, verifying and enriching emails, writing cold email sequences, buying and warming up sending domains, replying to inbound responses, booking calls, and prepping for sales calls and proposals. The point isn’t the specific list, it’s that almost every knowledge-work job breaks down into dozens of discrete, nameable tasks once you actually track it for a week instead of guessing.
How do you turn a task list into automated systems?
Once you have the full list, the next move is feeding it into a fresh Claude Code session with a direct instruction: here’s everything I do, my goal is automating as much of the non-client-facing work as possible, help me build a system for each one, and ask me questions wherever you lack context. The model will come back with clarifying questions, which you can answer efficiently using voice transcription instead of typing, often clearing an hour’s worth of context-dumping in a single sitting.
This is also the stage where you supply reference material. Generic instructions aren’t enough. If you want good cold email copy, the model needs examples of copy that actually performed well. If you want qualified lead lists, it needs examples of what “qualified” looks like in your business. If you want strong proposals, feed it real proposals that closed deals. The automation only works as well as the examples and templates you’re willing to hand over.
Why do you need evals before trusting any automated task?
Remy doesn't build the plumbing. It inherits it.
Other agents wire up auth, databases, models, and integrations from scratch every time you ask them to build something.
Remy ships with all of it from MindStudio — so every cycle goes into the app you actually want.
An eval, in this context, is a repeated test of how well a model performs a specific task under a specific prompt, scored across multiple runs rather than judged on a single output. This matters because AI models are inconsistent: a prompt that produces an excellent result once can produce a mediocre one the next time on the same job. Judging a system by one good output is a trap.
The practical method: run each candidate task about 10 times, score each output yourself, and look at the average. An 8 out of 10 (or roughly 80%) was used as the general bar for “good enough to trust,” though some tasks got a pass at a slightly lower threshold depending on how much the mistakes actually mattered. Anything below that threshold goes back to Claude with specific feedback: this output looks like X, I want it to look like Y, how do we close that gap. That loop repeats until the score clears the bar.
The biggest efficiency tip here is to avoid fixing one small thing and rerunning a full 10-sample eval before moving to the next fix. Batching three or four candidate changes and testing them in parallel, rather than sequentially, compresses what could be a week of iteration into something closer to a single day. Given how many tasks a real business generates, this parallelization is what makes the whole process tractable instead of a part-time job on its own.
When should a task be scheduled versus kept human-in-the-loop?
Not every task that passes its eval should run unattended. The filtering question is whether the task still benefits from a human check before it goes out. A daily client status update, summarizing what you worked on yesterday and what’s blocking you today, is close to fully automatable: a quick skim and a send is low-risk. Something like building a client deliverable from scratch, or writing a brand-new cold email campaign, still warrants a human reviewing before it ships, because the downside of a bad output reaching a client is higher and harder to reverse.
The practical split in a real deployment comes out lopsided: dozens of tasks get scheduled to run on their own, while a much smaller number, maybe five or six per day, stay as things a person actively does. That’s the actual target of this process: not “zero human involvement,” but a short, deliberate list of what still needs you.
Is automating your workflow with Claude Code worth it?
It depends on how much of your work is repeatable and how much tolerance you have for the upfront time cost. The audit alone can take roughly a week of passive tracking plus active review, and the eval-and-fix loop is described as the most time-intensive part of the whole process, requiring real judgment calls on what “good” looks like for your business. It also requires a paid plan with enough usage headroom, since high-thinking models running repeated evals burn through usage quickly. If you hit a usage cap, the fix is simply waiting for the session to reset rather than switching to a weaker model, since this kind of upstream planning work benefits disproportionately from the most capable model available.
Remy is new. The platform isn't.
Remy is the latest expression of years of platform work. Not a hastily wrapped LLM.
For businesses with a lot of repeatable, document-and-communication-heavy work (agencies, consultancies, services businesses), the payoff is a meaningful reduction in operational overhead and more time spent on the parts of the job that actually require a human, like sales conversations and judgment calls. For businesses that are mostly novel, physical, or highly relationship-dependent in every interaction, the return will be smaller because there’s simply less to standardize into a skill.
Frequently Asked Questions
What is a Claude Code “skill” in this context?
A skill is a task or process that has been tested through repeated evals, scored reliably high, and then packaged so it can be reused, either by running it again in Claude Code or by sharing it with other people on a team plan who can run it through simpler chat-based tools without needing to touch the coding agent directly.
How many times should you test a task before trusting it?
The process described uses about 10 repeated runs per task, scored individually and averaged, with roughly 8 out of 10 (around 80%) as the general bar for considering a task reliable enough to institutionalize as a skill.
Do you need screenshots specifically, or can you just describe your work to the AI?
Describing your work works, but it’s less complete. People tend to leave out context they don’t realize matters. Passive screen tracking plus a small number of daily check-in questions gives the model a fuller, more accurate picture than self-report alone.
Which tasks should not be automated end-to-end?
Tasks where a bad output has real downside and no easy recovery, like a brand-new cold email campaign or a client deliverable, are better kept human-in-the-loop even after the underlying system is built. Low-stakes, repetitive communications (like a daily internal status update) are better candidates for full automation.
What model setup does this process assume?
The process was run using Claude’s most capable model setting with extended (“max”) thinking enabled, on the logic that this is upstream planning work: errors or weak outputs at this stage affect everything built downstream of it, so it’s worth using the strongest available model even if that means waiting out usage limits.
