Last night I spent two hours watching someone on YouTube explain how to automate their entire life with AI agents. By minute forty, they had a system that could draft emails, file expenses, and order groceries. It was impressive. It was also completely useless, because the person building it had no idea what they actually wanted the system to do. This is the problem with automation in 2026. Everyone is building machines. Nobody is thinking. I have spent thirty years watching people make this mistake. When I wrote about startups, I said the way to get ideas is not to try to think of ideas, but to look for problems. Automation is the same. The way to automate is not to try to automate everything. It is to look for the work you hate doing, the work you do badly, the work that eats your afternoon. Automation is a mirror, not a machine. It reflects back the quality of your thinking before it ever touches your workflow. Here is why that matters: if you automate a broken process, you get broken results faster. I found this out the hard way. In 1995, I built Viaweb to automate online stores. We spent six months building tools for art galleries before we realized nobody wanted them. We were automating the wrong thing. The galleries did not need a website. They needed customers. When we pivoted to building actual stores, the automation worked, because we finally understood the problem. The same thing happens to individuals. I see people spend three weeks building an n8n workflow to sort their email into forty categories. They could have spent ten minutes writing a filter that archives the newsletters they never read. The difference is not technical skill. It is taste. It is knowing what matters. Here is a specific number that should scare you. Industry data suggests that over seventy percent of automation projects fail to deliver their expected value. Not because the technology is bad. Because the people building them skipped the thinking step. They went straight from "this is annoying" to "let me build a system" without ever asking what success looks like. I have been writing about this for two decades. The essay Writing Briefly taught me that constraints clarify thinking. The same applies to automation. If you cannot explain what you are automating in one sentence, you do not understand it well enough to automate it. So here is my guide. Not a tutorial about tools. A tutorial about thinking. If you do this right, the tools become obvious. Step one: Write down everything you did today in fifteen-minute blocks. Do this for three days. Do not judge. Do not categorize. Just write. Most people have no idea where their time goes. They think they spend four hours on deep work. In reality, they spend ninety minutes on email, two hours in meetings that could have been an email, and forty minutes hunting for files. Step two: Circle the tasks you dread. These are not necessarily the tasks you should automate. Some dread comes from difficulty, and difficulty is where you grow. The tasks you should automate are the ones that are easy, repetitive, and boring. The ones where your brain turns off. The ones you make mistakes on because you are not paying attention. Step three: For each circled task, ask a brutal question. If I never did this again, what would break? If the answer is "nothing," stop doing it. You do not need automation. You need deletion. This is the step everyone skips. They automate tasks that should not exist. I have seen companies automate their monthly reporting process, only to discover the reports were never read by anyone. Step four: Pick one task. Just one. The most common pitfall is scope creep. You start with "I want to automate my expense reports" and end up building a system that also manages your calendar, your email, and your grocery list. Then it breaks, and you have no idea why, because you built a Rube Goldberg machine instead of a tool. Pick the smallest task that causes the most pain. For me, it was invoicing. I hated invoicing. I would put it off for weeks. So I built a system that generated an invoice the moment I finished a project. It took me an afternoon. It saved me hours every month. That is the goal. Not to build a system. To solve a problem. Step five: Automate the boring part, not the thinking part. Here is the line I draw. If a task requires judgment, keep a human in the loop. If it requires consistency, automate it. Drafting an email to a client requires judgment. Sending a follow-up if they do not reply in three days is pure consistency. Automate the follow-up. Keep the drafting. This is the mistake I see in the AI agent hype. People want to automate the thinking. That is not automation. That is abdication. When you automate judgment, you outsource your taste, and taste is the only thing that cannot be replaced. Step six: Measure the before and after. You need a baseline. If you are spending two hours a week on a task, and after automation you are spending one hour a week fixing the automation, you have not saved time. You have created a new job. I am not saying this to discourage you. I am saying it because I have watched people fall in love with their systems. The system becomes the point. They spend more time maintaining it than they ever saved. That is not automation. That is a hobby. Step seven: Leave a manual override. Every automation needs an off switch. Every system needs a way to do the task by hand. This is not just practical. It is psychological. When you know you can do it manually, you are not afraid of the system breaking. Fear makes you build defensive systems. Defensive systems are complicated. Complicated systems break. The best automation I have ever built was a script that renamed my essay files. It saved me maybe five minutes a week. But it removed a tiny friction that annoyed me every single day. The best automation is not the biggest. It is the one that makes you forget the task exists. I think about this a lot as I watch the AI world develop. Everyone is racing to build the most sophisticated agents. They are solving the wrong problem. The problem is not building smarter machines. The problem is figuring out which work deserves to exist at all. Here is what I tell founders. Here is what I tell writers. Here is what I tell anyone who asks about automation. Start with the thinking. The tools will follow. The pencil case model of creativity applies here. You do not need a better pencil. You need to know what you are trying to draw. So before you build another workflow, before you connect another API, before you train another agent, sit down with a piece of paper. Write down what you actually do all day. Circle the parts that make you miserable. Ask yourself if they need to exist at all. Then automate the one thing that should exist but should not require you. That is the whole game. Everything else is just tools. FAQ Q1: What is the most common mistake people make when starting with automation? The most common mistake is skipping the thinking phase and going straight to building. People automate tasks that should be deleted entirely, or they automate broken processes and get broken results faster. The first step should always be writing down what you actually do and identifying which tasks should not exist at all. Q2: How do I know if a task is worth automating? A task is worth automating if it is easy, repetitive, and boring, and if it would break something important if you stopped doing it. If nothing would break, delete the task instead of automating it. The goal is to remove friction, not to build systems. A good benchmark is whether the automation saves you more time than it costs you to maintain. Q3: Is it true that over seventy percent of automation projects fail to deliver value? Industry data suggests that more than seventy percent of automation projects fail to deliver their expected value. The primary cause is not technical failure but poor planning. People automate tasks that should not exist, or they build overly complex systems without a clear baseline for measurement. Start small, measure before and after, and always keep a manual override.