Nate B Jones argues that AI automation should start at the edges of workflows, not the core
A solo presentation by Nate B Jones on why most AI agent automation projects fail and how to fix them.
Summary
Nate B Jones of AI News & Strategy Daily presents a case for rethinking how teams approach AI agent automation. His central argument is that most teams fail because they try to automate the core of their workflows first — the parts humans already handle well — rather than the edges, where the real friction and leverage exist. He identifies specific edge categories — data preparation, QA, synthesis, packaging, and coordination — as ideal starting points for AI agents, particularly for teams new to building automation. He also argues that AI agent projects are not purely technical endeavors but are fundamentally trust-building and upskilling exercises, and that losing the trust of the humans involved in a workflow will cause the entire effort to collapse.
Key Takeaways
FULL TRANSCRIPT
Why Most AI Automation Projects Fail Before They Start
Nate B Jones: I want to let you in on a little secret around AI automation and agents: automate the edges first. I'll get into what I mean by that.
Most teams burn months trying to automate the core of their work — the thing the humans already do pretty well. The real leverage often comes from automating the edges: the data preparation, the QA, the synthesis, the handoffs. AI can quietly compress cycles here by 70, 80, 90%, but most people don't start there.
I want to note that this is different from the problem space you pick. If you're saying, "Nate, I thought you tell us to pick something important to work on" — 100%, I do. I think you need to pick things that matter for AI. What I'm saying is: once you do, think about the edges of the work, because there's tons of leverage around that valuable problem space in the edges of the work.
I get the "automate everything" vision, especially if you have a core workflow. But keep in mind that most core workflows, when you first face them, contain ambiguity. They contain exceptions. They contain tribal knowledge. Teams underestimate the hidden state and tend to overestimate model reliability, especially if you haven't built an AI agent automation before. What does this lead to? It leads to stalled agents. It leads to bloated scope. It leads to frustrated leadership, frustrated engineers, and endless QA.
If you are trying to automate the core first, it's kind of like trying to build a self-driving car before you've invented cruise control.
The Challenge: Map the Edges of Your Workflow
My challenge for you: when you pick a valuable workflow to automate — if this is your first AI agent job — figure out the edges of your workflow and just test. Just see if there is something here that gives you a lot of bang for your buck.
Look at data preparation. How do you collect context for this workflow today? How do you clean your data inputs? How do you normalize your formats today? Is that a manual process before you even get into the core workflow?
Look at QA. How are you checking for completeness, quality, consistency, obvious errors? Something that an LLM-as-judge can perhaps easily do — that doesn't require doing the whole workflow.
Synthesis is another great example. Let's say that all you're trying to do is not automate the full workflow, but you're picking a valuable part of it and saying, "I just need to summarize information to date." I want to summarize the discussion thread in the Jira ticket and update the description. I want to summarize and synthesize information that is relevant in the workflow and communicate it over here. That can also look like grouping information. It can also look like templating output — you have the information and you're just writing it to a template. Super valuable work, often takes a lot of human time, but not super hard for the LLM, and is a valuable edge to go after.
Another edge to go after: the packaging of the work. How do you convert the work into deliverables once it's done? How do you get it into a brief? How do you get it into a report? Especially now, with the advent of new frontier models and improved capabilities around PowerPoint and long-form document generation, you have options to get all the way to a finished deliverable that you did not have three months ago. That is another edge you can start to look at.
Coordination is another edge that often has a ton of value, especially in tribal knowledge situations. Coordination often resides in someone manually pulling information from one place, talking to someone, then putting it somewhere else. If you can pick up that piece — where you have the information and you just need to get it from point A to point B — that is often very, very valuable.
Why Edges Are Perfect for AI Agents
So why do I suggest edges of the work? They're high friction. Typically a workflow is least frictional at the core and most frictional at the edges — that's just a general observation anyone who has worked with workflows will tell you. It's the edges that are often the worst.
It's also often a low-judgment task, because all of the inputs are ready, which is perfect if you're just starting out on AI agents. And that means they are perfect for LLMs. Even when LLMs are imperfect — and you should not assume that your first AI agent is perfect, you should assume it's imperfect and that it needs to deliver value anyway — errors are often recoverable and cheap. The humans doing the core of the workflow were doing those edges before. If there's an exception that occurs, they can pick that up easily. You have the chance to look at the data, fix it, and come back and make your agent better.
This also means that you are not abandoning the core of the workflow. If your goal ultimately is to have an AI agent sit at the heart of the workflow, you get a clean path into that by attacking the edges. If you own QA, if you own handoff, if you own data inputs and data preparation, you are well positioned to have the knowledge you need to do the AI agent at the heart of the workflow — which may be your ultimate goal. You position yourself by being at the edges of a core, valuable workflow. You position yourself to attack the heart of that workflow next, and then to snowball those gains across the org.
AI Automation Is an Upskilling Project, Not Just a Technical One
Because really, what you're doing is twofold. You're not just going after this core workflow. You are teaching yourself and teaching the org how AI automation ought to work. And this is the part that almost nobody says out loud: you are not just doing a technical project. You are doing an upskilling project — not just for the engineers building the agents, but for the humans involved.
The humans involved tend to have a lot of tribal knowledge. They tend to be fingertippy on the work. If it's a valuable workflow, they need to be able to be confident that your AI automation task with the agent will not cost them that fingertippy feeling on the work. They are craftspeople. Make sure they know where their craft can be practiced.
If the part of the work that is highly valuable in this workflow is the high-level understanding of the customer history over multiple years, and how you nuance a particular response to the customer — that's a customer success example — you want to automate around that so that the customer service agent can apply that knowledge efficiently, with their full intuition, with their full human memory of the relationship, and not be distracted by other stuff.
When you start by attacking the edges, you are reminding the people doing the work that their fingertippy feeling for the work is valuable, that they are worth having in the work because of the craft they bring. That is critical, because if you lose that trust, they will not be inclined to share with you all of the secrets of the art that you need for the rest of the workflow. You need to look at AI agent building as an exercise in trust. There is no substitute.
The Real Leverage Hides Outside the Core
I'm going to argue that the real leverage hides outside the core. It hides in stuff like intake, data pull, QA checklists, synthesis, and packaging. When you do this, reliability can go up, you have less risk, you're attacking a core workflow, you're showing gains, and you're earning the trust of everyone involved to get where you want to go. This leads to teams winning fast.
So if you want to apply this tomorrow: pick a workflow that you touch every single week that's valuable. Map the edges. Where do you waste time prepping? Where do you check for errors? Where do you hand off repeatedly? Where do you summarize over and over? Pick the simplest edge, get into ChatGPT, Claude, or Gemini, and focus on thinking about how you build a simple solution. It's okay if it's semi-manual to start and you build automation from there. That's fine. The point is that you're approaching it correctly, and then you can build the automation edge inward.
Automation does not start with replacing the core — unless you have a very experienced engineering team. It starts with reclaiming the edges. If you automate three or four edges in a row and you're starting to feel good, you don't need the full grand vision. The workflow itself will reveal the answer: the correct place of automation and the correct place of human expertise. And that's how real AI transformation happens. I wish we talked about it more.
Tell me: where are you looking to automate?