I've been exploring how non-technical people can use AI to do work for them. People like my mom and dad.

I wanted to my share some beliefs I've converged on so far:

• Most work you want done by an agent is a workflow: a structured, multi-step, repeatable task
• AI workflows face major ergonomics, cost, and reliability challenges
• There's open questions around the best ways to solve them

I'll also share my work on the rise (and probably fall) of WorkflowSkill.

Mom and Dad

Like so many people, I've been playing around to see how I can use AI to automate my work, both personal and professional. You may have seen my article on how I used n8n to process vast amounts of job postings and deliver a highly tailored report to my email every morning.

Now, n8n is pretty cool, but there's even more exciting players that have entered the AI-sphere. OpenClaw has spawned this collective "aha!" moment where everyone is realizing you can chain inference models together to build always-on personal assistants. We've all seen the stories about OpenClaw agents doing things from calling restaurants and tricking the host into thinking a real person was calling, to starting their own religions.

The vision is clear: soon, everyone will have their own thinking, persistent worker bees. And right now there's a dichotomy between structured, repeatable workflows (n8n style) and ephemeral, improvised inference (OpenClaw style).

All of this has been extremely inspiring and exciting, and has me (and many others) seeing how much stuff in our lives can be automated.

Though, It's got me thinking about my parents a lot.

Sure, a full stack dev can spin up OpenClaw and get it to work. But how could a paint store owner and a nurse with no technical background use these tools to better their lives?

I call this the "mom and dad" problem. How can mom and dad use it?

Right now, they can't. The reality is the vast majority of the population is yet to experience any benefit from AI.

Workflows

When I think about what my parents would actually automate, it's all the same shape. Find and book cheap flights to Arizona. Check Craigslist every morning for a used Honda Civic under $8,000. Find a nice restaurant with a table for two at 8pm and book it. Pull together a grocery list from this week's meal plan and order it.

These tasks share traits:

• Structured: the work is predictable and can be defined ahead of time.
• Multi-step: useful automation chains together multiple tasks.
• Repetitive: they need to happen on a schedule or in response to a trigger, not just once.
• Action-oriented: the value comes from doing something (fetching a page, comparing prices, sending an email), not from open-ended reasoning.

I'd call these workflows. They represent the vast majority of what regular people want from AI. Not philosophical conversations. Not creative writing. Just: do this thing for me, reliably, over and over.

The data backs this up. A 2025 Stanford HAI study surveyed 1,500 U.S. workers across 104 occupations and found that people overwhelmingly want AI to automate repetitive, low-value tasks like scheduling, file maintenance, routine processing. 69% of positive automation responses cited freeing up time for higher-value work as the primary motivation.

The supply side tells the same story. ClawHub, OpenClaw's skill registry, hosts over 3,200 curated skills. The most popular categories aren't creative writing or open-ended reasoning. They're productivity integrations, browser automation, workflow orchestration, and data extraction.

The important thing about workflows is that they don't inherently require intelligence. Fetching a web page, parsing HTML, filtering results, sending a notification. These are deterministic operations. You might want an LLM somewhere in the pipeline to evaluate whether a car looks good from its photos. But the orchestration itself? That's just code.

The problem is that while workflows excel at structured, repeatable tasks, they have poor ergonomics. That's what I tried to solve with WorkflowSkill.

The Rise (and Probably Fall) of WorkflowSkill

I tested OpenClaw on what should be an ideal use case: browsing Craigslist for a used car on my behalf, scheduled hourly. It went horribly. Different filters every time. Sometimes forgot to apply them. Got lost navigating pages. Reports formatted differently each run. Occasionally it worked great. In a few hours, I'd burned through $30 in Anthropic credits.

This is exactly the kind of task that would add real value to my parents' lives, which is why I was testing it.

We could solve it with an n8n flow. I've done that before. All orchestration (page fetching, HTML parsing, filtering) handled deterministically. Zero inference. Cheap and reliable.

But building an n8n flow is technical and time-consuming. My parents can't build one.

My hypothesis: there's a better paradigm. Visual workflow builders are powerful for technical users but will never be accessible to non-technical people for complex tasks. What if you could author sophisticated workflows using natural language instead?

I built WorkflowSkill to test this. It's a YAML-based workflow language with a TypeScript runtime. You define steps (tool calls, LLM prompts, data transforms, conditionals) and the runtime handles execution and observability. It ships with a skill.md file that teaches an agent how to author WorkflowSkills. Say "I want to check Craigslist daily for a Honda Civic" and the agent composes a workflow executed by a runtime (free) rather than an LLM (expensive).

I also built an OpenClaw plugin to try it within the most hyped agent ecosystem of the moment.

It totally works. You can converse naturally with an agent and get effective, robust workflows. But the hard reality: it still takes significant technical instruction and iteration to get complex tasks performing well. The agent generates syntactically valid YAML every turn, but knowing, for example, that you should rate-limit your API calls isn't obvious to an agent authoring the flow. Production-grade results still require someone technical enough to say, "you're calling the API 100 times in a row. Add a 500ms delay."

The Author/Consumer Split

This finding forces a reframing. I had imagined a single user who describes a task and gets a working workflow. But if production-quality authoring requires technical skill, you get two personas:

Authors build workflows. They understand the tools, the data flow, the failure modes. They iterate until it's robust. This is technical work.

Consumers use finished workflows. Push a button, get a daily report. Don't care how it works. Shouldn't have to. This part can be non-technical and conversational.

This split shows up everywhere. WordPress powers 40% of the web. Almost none of those site owners built their own theme. Shopify is the same. Someone designs the storefront template; the shop owner picks one and adds products. Creation and consumption are fundamentally different activities performed by different people.

It's exactly what I did with the n8n job search flow. I spent hours building and debugging it, then open-sourced it. Others adopted it with minimal effort. I was the author; they were the consumers.

The AI automation space is formalizing this pattern. ClawHub is a marketplace of community-built OpenClaw skills. n8n has similar. Even Apple Shortcuts does the same: power users build complex automations, everyone else downloads and taps "run."

The platforms are discovering what WordPress already knew: most people don't want to build. They want to use what someone else built.

Is the split inevitable?

There's a strong case it's inherent to the problem. Complex tasks have complex failure modes. Anticipating them requires experience with the systems involved. You often can't avoid watching the workflow fail and troubleshooting why.

If true, the right move is to embrace it: make authoring as powerful as possible for technical users, consumption as effortless as possible for everyone else, and build the bridge between them.

Or is it solvable?

But some things nag at me. I'm not sure I'm ready to give up.

WorkflowSkill is a custom YAML language that exists in zero training data. I made it up days ago. Of course the agent struggled with edge cases. When you consider it's writing runnable workflows in a language it just learned, it's actually impressive.

What if the agent wrote workflows in a well-established framework massively represented in its training data? Something with thousands of open-source examples, production implementations, and Stack Overflow answers? The competence gap between a custom DSL and an established framework could be the difference between "needs a human to debug" and "handles it alone."

Now layer on: what if the agent had access to a library of proven, production-tested workflows to reference before writing new ones? Not installing templates. Reading them. Learning patterns. If you want a flight price monitor and the agent can study three existing monitors that already handle rate limiting, retries, and notification formatting, it's not writing from scratch. It's adapting known-good patterns. That's how experienced developers actually work.

And what if the runtime had durability and error recovery built in, so the author could focus on the workflow logic rather than infrastructure concerns?

Strong priors from pre-training plus high-quality reference implementations plus native durability and error recovery, maybe the skill gap shrinks enough that a non-technical person can iterate their way to a production-quality workflow through conversation alone.

This is yet to even mention building iteration into the authoring process. If the agent can sandbox and pressure-test the workflow before running it live, it's more likely to reach production quality without intervention.

So there's still hope. Mom and dad may author workflows with natural language someday.

What I think I know

Most of what regular people want from AI is workflows. Structured, multi-step, repetitive tasks. Not chat. Automation.

Pure agent-based approaches are too expensive and unreliable for these tasks today. Letting an LLM improvise every step of a repeatable process is the wrong tool.

Pure workflow approaches are too technical for non-technical people. n8n works brilliantly, but requires a mental model of data flow that most people don't have and shouldn't need.

Natural language authoring is promising but not yet sufficient. An agent can generate valid workflows from conversation, but production-grade results still need technical judgment to refine.

The author/consumer split is a natural pattern. It shows up everywhere in technology, and fighting it entirely may be less productive than designing for it.

But the split may not need to be as wide as it is today. Better frameworks, richer reference libraries, built-in durability, and smarter iteration tooling could shrink the gap between "needs a developer" and "a conversation gets you there." I don't think the gap closes to zero. But it might close enough to matter.

The winning platform will nail the bridge between authors and consumers. Making workflows easy to share, discover, customize, and trust is at least as important as making them easy to build.

What I'd Love to Hear

I'm publishing this half-formed on purpose. If you're thinking about these problems too:

Has anyone found a framework/environment where agents can author/perform workflows in reliably? I tested a custom DSL and hit a ceiling. I suspect something with deep training data representation performs better, but I haven't proven it.

Is the author/consumer split permanent, or do you think it's an artifact of current ergonomics?

What's the right abstraction level for consumers? Should they see steps and tweak them, or should the whole workflow be a black box behind a single sentence of intent?

Are there platforms I'm missing? I've looked at n8n, OpenClaw, and a handful of others, but this space moves fast.

And if you're a non-technical person who's tried to automate something with AI, I especially want to hear from you. The "mom and dad" problem doesn't get solved by builders talking to other builders.