Last updated: August 27, 2026
Build your first agentic AI workflow by picking one boring, high-volume task, writing its rules down like onboarding notes, giving it two or three narrow tools, and making it stop for a human wherever mistakes are expensive. Start with a workflow, not an agent. The stopping rules are the part almost everyone skips.
Imagine you can instantly hire an intern. Unlimited patience, no lunch break, works at 2 a.m. You tell them exactly what to do and exactly when to do it. Naturally you would hand them your simplest job first and let them go for it.
That is the whole design brief. I have said a version of it on LinkedIn probably six times, and people nod, and then almost nobody builds the thing. The nodding is not the problem.
Here is what I would add now that I have watched a few of these go into production and a few of them go sideways. The intern analogy gets you to the starting line. It does not get you across it, because a real intern has three habits your agent does not have, and every first workflow I have seen fail, failed on one of those three.
Two commercial interests to weigh before you take any of this seriously, and I would rather put them up front than bury them. Business systems consulting is what I do for a living, so a reader who concludes their stack needs adult supervision is a reader who might call my office. This is also published by a staffing firm, and KORE1’s IT staffing services practice places the ERP, data, and integration people who end up owning these workflows six months in. Both of those should colour how you read the last section, which is the one about hiring.
The offset is that nearly everything below is a couple of afternoons of your own attention, and I flag the places where you should not call anybody. If you want the wider argument about where to point AI in an operations business at all, the practical AI for business operations piece is the parent of this one. This is the build.
What an Agentic Workflow Actually Is, Minus the Deck
An agentic AI workflow is a business process where an AI model reads the situation, decides which step to run next, calls software tools to do the work, checks what came back, and keeps going until the job is finished or it hits a rule that says stop and get a human.
The part that separates it from the automation you already have is the deciding. A Zapier zap or a scheduled script runs the same path every time. Somebody wrote that path. If the input is shaped even slightly wrong, the script either fails loudly or does something stupid quietly, and there is no third option.
An agentic workflow can take a different path. That is the entire pitch, and it is also the entire risk, and anyone selling you one without saying the second half is selling.
Anthropic’s engineering team drew the line better than most vendors do in their Building Effective Agents guide from December 2024. Workflows are systems where the model and its tools run through code paths a person laid out ahead of time. Agents are systems where the model directs its own process. Their advice, which I would tattoo on the inside of a few executives’ eyelids, is to find the simplest solution possible and only add complexity when the simple one stops working.
Your first one should be a workflow. Not an agent. You want the model making small decisions inside a lane you drew, not choosing the lane. Draw the lane yourself.
The Intern Analogy Is Right Until It Isn’t
Three habits. A real intern has them and an agent does not, and you have to build each one back in by hand.
An intern asks. An agent guesses.
Give a new hire a stack of open purchase orders to reconcile and they will get four in before they walk over to somebody’s desk holding one of them, because the vendor field is blank and they do not want to guess. That instinct is free. Nobody trained it into them and you did not have to pay for it.
An agent handed the same stack does not have it. Confronted with a blank vendor field, a decent model will find the closest name match in your vendor list and proceed, and it will write a short, confident, entirely reasonable note explaining why. The agent is not lying to you. It genuinely resolved the ambiguity the way its training says ambiguity gets resolved. It just resolved a question you would have wanted to answer yourself.
Nobody taught the intern to ask. Nobody has to.
So the asking has to be designed. You write down, in advance, the specific conditions under which the thing stops: a field is empty, a dollar amount clears a threshold, a match scores below whatever you decide is confident, two records look like the same record. Then you route those to a person with enough context attached that answering takes forty seconds instead of ten minutes.
Most teams get this backwards and make a human approve every single output. That collapses in about a week. Your reviewer starts skimming by Thursday, and a reviewer who skims is worse than no reviewer, because now you have a control on the org chart that is not a control in reality. Design the exceptions instead.
An intern’s mistakes arrive one at a time.
They also arrive slowly, and visibly, and somebody usually notices by lunch. An agent’s mistakes arrive all at once, at machine speed, and they look exactly like successful runs until somebody reconciles something.
Two guardrails, both boring. Cap the run. Whatever the volume is that a human would eyeball at the end of a day, that is your ceiling, and the workflow stops there and waits. Second, make every write idempotent, meaning if the same instruction lands twice it does not do the work twice. Retries happen. Timeouts happen. A tool call that ran fine but never got its acknowledgement back will get called again, and if that call posts a transaction, you now have two.
The failure that actually shows up is the retry storm. A tool call times out, the platform retries it three times because that is the sensible default, and on a queue of four hundred records that is twelve hundred calls inside about ninety seconds. Your SaaS vendor rate-limits you. The workflow starts returning errors that look exactly like a bug in your own logic, and you will spend a day chasing the wrong thing.
Count the calls before you build. On the wider question of what looping does to an API budget, I ran the arithmetic in the piece on AI-augmented development, and the short version is that the constraint usually lives in a licensing document rather than in your code.
An intern remembers Tuesday.
By week three a decent intern knows that the Ohio account codes things differently and that you never touch the Kessler file without asking. Nobody wrote that down. It accumulated.
Your agent starts from zero every single run. Every quirk, every exception, every “we do it this way because of a thing that happened in 2019” has to be handed to it explicitly, either in its instructions or through retrieval over documents you actually maintain. This is why “write the rules down like onboarding notes” is not a cute framing. It is the work. Teams that skip it end up with a prose prompt that says “reconcile the POs correctly” and then act surprised when the thing reconciles them incorrectly.
Our quality system has a line about this that applies well outside regulated work. Generation runs against an approved specification, not against a prose description. If you cannot write the spec, the task is not ready, and the honest read is that it was never as well defined as everyone assumed.
Pick the Task Before You Pick the Tool
Everybody does this in the wrong order. They pick a platform in January and spend until April looking for something to point it at. I watched it twice this year. Both times it stalled.
A candidate task has to clear all four of these. Not three.
- High volume. If it happens eleven times a month, automating it is a hobby. You will spend more attention building it than the thing has ever cost you.
- Checkable by someone who did not do it. Skipped more than the other three combined, and the most expensive omission of the four. If the only person who can tell whether the output is right is the person who produced it, you do not have review. You have a feeling.
- Cheap to get wrong. Wrong once, caught same day, fixed in ten minutes. Not wrong once and it is in a customer’s inbox or a filed return.
- Boring enough that nobody defends it. Half-serious, and only half. Automating work somebody is quietly proud of will generate friction that has nothing to do with the software and will not resolve in a status meeting.
Invoice coding. Vendor onboarding checks. Support ticket triage. Turning a pile of meeting recordings into notes with owners and dates attached. Matching a bank feed against open receivables and flagging only the ones that do not tie.
Not forecasting. Not pricing. Nothing that a customer reads before a colleague does. Those come later. Some of them never come.
Five Shapes, and You Probably Want the First One
Anthropic’s guide lays out five patterns, and the useful thing about the list is that four of them are more complicated than your first project needs to be. I have added the column their write-up does not have, which is what actually breaks first in each one when a mid-market team builds it.
| Pattern | What it does | What breaks first |
|---|---|---|
| Prompt chaining | Splits a job into steps that run in order, each one feeding the next, with a check between them | Nothing much. Start here. |
| Routing | Classifies what came in, then sends it to the right specialized handler | The catch-all bucket. Everything ambiguous lands there and nobody watches it. |
| Parallelization | Runs independent pieces at the same time, or runs one piece repeatedly and takes the consensus | Your API allowance, and your rate limits, usually in the same afternoon |
| Orchestrator and workers | A central model breaks the job into subtasks on the fly and hands them out | Debuggability. When it goes wrong you cannot tell which layer decided what. |
| Evaluator and optimizer | One model produces, a second critiques, and they loop until it clears a bar | Cost per outcome. The loop can run a long time on something a person would have rejected in four seconds. |
Prompt chaining covers a startling amount of real business work. Read the document, pull the fields, check them against the system of record, write the result, flag what did not match. Five steps, each one inspectable, each one a place you can stop the line.
Fancy is not the goal. Finished is. Nobody audits your architecture diagram.
Wiring It Up, and the Part That Bites in Month Two
Tools are where an agentic workflow stops being a chat window and starts touching your business. Three landmines, all of which cost me time before I learned them.
Give the workflow its own login. Not a person’s. Almost everybody builds the first one authenticated as whoever happened to be sitting there, and it works beautifully right up until that person changes their password, or takes a new role, or shows up in a quarterly access review where somebody tightens their permissions for perfectly good reasons. Then the workflow dies at two in the morning with an authentication error nobody is watching a queue for. Give it a named service account with its own role, provisioned for exactly the records it touches. When somebody later asks what this thing is allowed to do, the answer is a role you can open and read.
Give it the fewest tools that finish the job. OWASP put excessive agency on its 2025 Top 10 for LLM applications, and the definition is almost aggressively plain: too much functionality, too many permissions, or too much autonomy. If the workflow reads purchase orders, do not hand it a tool that can also delete them just because both arrived in the same connector. I made the longer version of this argument about the NetSuite MCP connector, where a tool can reach precisely as far as the authenticating role reaches and not one record further. Same principle, different wrapper.
Log the whole run, not the answer. When one of these misbehaves, the output tells you almost nothing. What you need is the trace: what it decided, which tool it called, what came back, what it did next. Teams that skip the trace spend their debugging time re-running the workflow and hoping it misbehaves again while somebody happens to be watching.
Somebody Has to Own It After It Works
The first version is the fun part. Month seven is where these quietly stop being trusted, and it is almost never because the model got worse.
Two things kill a working workflow. The first is that the ground moves underneath it. NetSuite ships two upgrades a year, and every other platform you are touching runs its own release calendar that nobody put on yours. A field gets a new default, a permission gets split into two, an endpoint starts returning an extra element. None of that breaks loudly. It produces slightly wrong output that a busy reviewer waves through, and by the time somebody notices, the trust is already gone. Put a name and a recurring date against re-testing the thing after each release. That is the whole control.
The second is change discipline, which we borrowed from our own change control process because it turns out to have nothing to do with being regulated. Every change to a live workflow gets classified before it ships, by one question: does this change what the thing is allowed to touch, or only how it words something? Those are different animals and they deserve different amounts of ceremony.
And never bundle them. A change that widens what the workflow can reach, riding along with three cosmetic tweaks in the same release, is how the one that mattered skips assessment entirely. We wrote that rule down after watching it happen somewhere it should not have happened.
The accountability half of this, a named human who owns the output rather than a tool that produced it, I set out in full in the rules we published for AI-assisted code generation, and Kris Drouet’s AI code review for engineering teams argues the same case from the merge button. No point in me writing it a third time.
I repeat this one a lot, though. A control nobody enforces is documentation, not a control.
Two Weeks, and You Will Know Whether This Is Real
Six moves. None of them need a budget line.
- Sit with the person who does the task. Not their manager. Watch them do it eight or ten times and write down every judgment call they make without noticing they made one. This step is where the whole thing lives, and it is the one that gets skipped for a vendor demo.
- Write the spec. Inputs, outputs, the exceptions you found in step one, and the explicit list of conditions where the thing stops and asks. If this takes you longer than an afternoon, you learned something valuable about the task.
- Build the shortest chain that could work. Three or four steps. Whatever tool your team already has a login for is fine, and the platform choice matters far less than everyone in the evaluation meeting believes it does.
- Run it in shadow mode. It produces output, a human does the real work, and you compare. A week of this tells you more than any pilot deck. Nobody downstream notices, which is exactly why you can afford to let it be bad.
- Count what it got wrong and sort the misses. Missing context, ambiguous spec, or genuinely hard. Only the third category is an AI problem. The first two are yours. The spec fixes both.
- Turn it on for a slice. One vendor, one region, one ticket queue. Keep the run cap. Keep the escalation path. Widen it when a full week goes by without a surprise.
Fourteen days, mostly other people’s afternoons. If it does not work, you have lost two weeks and gained a written specification for a process that did not have one, which several of my clients would tell you was worth the two weeks by itself.
Where the Numbers Actually Sit Right Now
Some perspective, because the noise level on this topic is genuinely unhelpful and the gap between the pitch decks and the deployments is enormous.
The Census Bureau’s Business Trends and Outlook Survey put national AI use at 19.8 percent of businesses in its data through May 2026, rising to 37 percent among firms with 250 or more employees and 39.7 percent in the Information sector. That is any AI use at all, measured over the prior two weeks. Not agents. The number counts everything.
Agents specifically are earlier than that. McKinsey’s State of AI survey found 23 percent of organizations scaling an agentic system somewhere in the business, but in any given business function the figure was no higher than 10 percent. Gartner, meanwhile, puts the cancellation rate above 40 percent by the close of 2027, blaming escalating cost, unclear business value, and risk controls that were never built.
Read those together and the conclusion is not that this does not work. It is that the failure rate belongs to projects that started at the wrong end, with a platform and an ambition instead of a task and a spec.
One more, and it is the one I would put on the wall. METR ran a randomized controlled trial in 2025 with 16 experienced developers across 246 tasks in codebases they already knew. With AI tools they were 19 percent slower. Afterward, having lived through it, they estimated they had been 20 percent faster. Nobody was lying. Perceived speed is simply not a measurement, which is why step four up there is shadow mode and not a survey.
What This Does and Does Not Do to Headcount
I get asked some version of “how many people does this replace” in most first conversations, and the honest answer disappoints everyone.
Your first workflow replaces nobody. Not one person. It removes a slice of somebody’s week that they did not enjoy and were not hired for. What changes at three or four workflows is the shape of the work, because reviewing, specifying, and owning the exceptions become a real job that somebody has to have time for, and that person is usually your best operations person, who is currently at capacity.
That is the part that turns into a hiring conversation, and it usually is not an AI hire. It is an ERP person, a data person, or an integration engineer who can read a trace and knows what a reconciliation is supposed to look like. Stack Overflow’s 2025 Developer Survey found 87 percent of developers were concerned about the accuracy of what agents produce and 66 percent named “almost right, but not quite” as their top frustration with AI output. Almost right is a category that only a human with domain knowledge can sort, and there is no tooling roadmap that removes it.
For what the market looks like from the recruiting side: KORE1 runs a median search of roughly 17 days across 30-plus U.S. metros, and a 92 percent retention rate at the twelve-month mark, which tells you these seats are being filled and are sticking. If the work is a defined project rather than a permanent chair, contract staffing is usually the right shape, and teams that want the agent-building skill specifically can go straight at the NetSuite MCP and agentic AI consultant bench.
Objections I Get, and What I Actually Say Back
We have nobody technical. Is this off the table?
Your first workflow does not need a developer. It needs somebody who writes clear instructions and is stubborn about exceptions, which is a different person entirely. The no-code platforms handle a prompt chain fine. The technical need shows up later, at the tool-authentication layer, and it is measured in days rather than in headcount.
Every vendor we talk to says their thing is agentic. How do I tell?
Ask what happens when it is not sure. A real agentic workflow has a defined answer, usually involving a named escalation path and a documented threshold. Repackaged automation answers by describing more features. Gartner calls the repackaging “agent washing” and reckons only a small fraction of vendors claiming the label are doing anything meaningfully different from the automation you bought in 2021.
What does the first one cost?
Two weeks of internal attention and platform fees somewhere in the tens of dollars a month. Genuinely. The costs that hurt arrive later and they are not licence fees. They are API allowances, the relay you needed for authentication, and the ongoing hour a week somebody spends on exceptions that nobody assigned to anyone.
Our data is a disaster. Do we have to fix that first?
Not all of it, no. You have to fix the slice your workflow touches, which is usually one field on one record type. Whole-company data cleanup is a project that eats a year and delivers nothing you can point at, and I have watched it become the reason a company never started.
What if it makes a mistake in front of a customer?
Then you picked the wrong first task. Nothing customer-facing goes in the first workflow, or the second. Internal work with an internal reviewer is where you learn the failure modes, and you learn them cheaply. Move outward once you have a month of boring logs.
Six months from now, how do I know if this paid off?
Hours returned to a named person, and exception rate over time. Not tokens consumed, not runs completed, and never a self-reported speed estimate, which METR’s trial demonstrated is the least reliable number in this entire category. If the exception rate is not falling by month three, the spec is wrong and no amount of model upgrade fixes a spec.
Nobody’s First One Was Good
Mine wasn’t. It read email attachments, pulled three fields, and got confused by any PDF that had been scanned rather than generated, which turned out to be about a fifth of them. We fixed it in an afternoon. It has run every business day since.
The gap between the companies doing this and the companies talking about it is not budget and it is not talent. It is that one group picked a boring task in a Tuesday meeting and the other is still comparing platforms. AI is fast and it is not careful, and the careful part is the part you supply, which is exactly why I keep calling it a high speed idiot and meaning it fondly.
Pick the task somebody complains about in standup. Write down what a good answer looks like. Give it two weeks.
If you get partway in and want a second read on the design, or you have concluded the person who should own this does not work here yet, talk to a KORE1 recruiter about the seat, or hit me up on LinkedIn. Either way, start with something boring.
