Most agentic work will become workflows

Find the desire paths, then pave them

Last winter, during the height of OpenClaw fever, I enjoyed asking people what tasks they were giving their agents. Overwhelmingly, their favorite tasks were tasks that could easily be completed using only code.

One friend’s favorite task told him when to leave his house in the morning. Opus 4.5, piloting his Claw, checked his recent Strava rides and deduced his current cycling pace, checked his Google Calendar to get his first meeting, computed his cycling time from the ferry terminal to his office (at his current pace!), determined the latest ferry he could catch, timed how long it would take him to get to his starting terminal, then (finally!) told him when to leave.

All of this was done, every morning, with Opus 4.5. A powerful foundation model doing a routine job that, once defined, could largely be achieved with code. Every time I heard similar use cases, I imagined someone hiring a McKinsey consultant to mow their lawn.

Now, this task was genuinely useful to my friend. And the foundation model provided a real function: it scoped, designed, and implemented his multistep task. Further, the foundation model received his feedback as he discovered problems while using this task (unsurprisingly, he pedaled slower in work clothes). Together with Opus, he arrived at better requirements.

And there are so many tasks for us to extract, improve, and define from our agentic work. Many of the tasks we give agents repeat, with the nouns changed.

Finding emergent paths

I used to run data science at a location intelligence company, where I observed how our lives are defined by routines. We visit the same venues, take the same routes, and stick to an established territory. Sure, occasionally we take vacations or try a new restaurant, but our routine is the rule.

In the user experience field, there’s a concept called “desire paths.” Desire paths form as people repeatedly travel an unplanned route, choosing to trample over a lawn rather than take an indirect sidewalk. Desire paths reveal where infrastructure doesn’t serve a recurring need, and our repeated requests are wearing similar paths, where workflows would be valuable.

Tools like Wes McKinney’s AgentsView let you peruse your past conversations with coding agents, making any desire paths visible. Grab a coffee and start scanning, looking for repeated requests you do over and over again. Or, you could simply ask your agent.

Review our past conversations and work and try to identify tasks I do repeatedly, ideally ones that aren't guided by a skill. I want to understand what repeated workflows I can better formalize. Structure repeated tasks in a JSON file, with references to relevant traces.

Giving this to Claude Code worked surprisingly well! It identified five common workflows, including “Structured read-only recon dispatch,” a clunky moniker for something I do very often: task an agent with exploring and compiling information to inform a design, before writing code.

With a desire path identified, we can begin to formalize our task.

Cultivating the routes

With our task in hand, we can first capture it as a skill. Ask an agent to identify the common patterns of a discovered workflow, and draft a supporting skill. The plain Markdown allows us to read and review the work (if we choose), tweaking details and adding immediate feedback.

Our workflow definition seems simple (it’s just text), but creating an artifact gives us three big benefits:

1. Consistency: We don’t have to explain our workflow every time we want it performed. A few words or a slash-command stand in for the entire text.
2. Accumulation: As we use our workflow, we’re going to spot shortcomings. An artifact, like our skill, gives our feedback a place to live. If there’s an issue, ask the agent to update the skill.
3. Optimization: Once our procedure is firmed up, we can test its performance on smaller models and peel off bits (or the whole!) to execute with code.

The last benefit is often overlooked. Primed with sufficient context, today’s smaller models are surprisingly capable. While I might develop a skill with Fable or Astra, my own personal agent runs my workflows with the relatively diminutive GLM 5.3 Flash, coupled with a Python script or two. The requirements and corrections I’ve captured remain, even as the models change.

We shouldn’t employ Fable to sort our emails, just as we wouldn’t hire a McKinsey consultant to mow our lawn.

Building paved walkways everywhere

I am convinced, as our ecosystem evolves, more and more of the work we hand to agents will be crystallized into repeated workflows. These routines will be identified, defined, and tuned before being offloaded to minuscule models and code.

To reach this future, we require better, more diverse, and interoperable harnesses. Today, coding and chat harnesses dominate our agentic use cases. But we can only discover patterns in the work these harnesses can observe. As personal agents expand across terminal and desktop environments, we’ll have more terrain to trample down.

The threat, however, is that these harnesses aren’t interoperable. If we can’t export our data, combine histories from different agents, and analyze it with our own tools, our understanding of our routines will be limited. Without interoperability, changing providers or tools risks losing the refinements we’ve accumulated. We must be mindful of where we forge our paths.

This is our knowledge that we cultivate by doing. Our preferences and our intelligence. We should develop the tools and talent to capture that knowledge and keep improving it. Choose harnesses that let you keep your traces, support open tooling, and practice turning repeated work into artifacts you own.

Watch Drew’s talk on how contexts fail

In his AGNTCon + MCPCon North America talk, Drew Breunig explains how agents get distracted or confused as their context grows. He walks through fixes such as pruning old tool results and loading only the tools a task needs. In both the talk and this post, Drew asks which steps should run in code and which should be left to the model.