{"id":10371,"date":"2026-08-26T08:00:00","date_gmt":"2026-08-26T06:00:00","guid":{"rendered":"https:\/\/www.kubicek.ai\/?p=10371"},"modified":"2026-08-25T22:56:12","modified_gmt":"2026-08-25T20:56:12","slug":"swa","status":"publish","type":"post","link":"https:\/\/www.kubicek.ai\/en\/swa\/","title":{"rendered":"Script? Workflow? AI Agent? Decide Before You Start Building"},"content":{"rendered":"\n

A request I get more and more often: \u201cWe\u2019d like an AI agent.\u201d<\/strong> Not \u201cwe have a problem with orders,\u201d not \u201cwe\u2019re drowning in emails.\u201d Straight to an AI agent. Ask what that agent is actually supposed to do, and the answer comes back as \u201cso it runs itself\u201d or \u201cwhatever Janie does today, just without Janie.\u201d I get it. Social media feeds are full of people racing to show off what their AI agent watches, handles, and sorts today. The trouble is, that\u2019s like ordering a car without knowing where you\u2019re driving it, or whether you\u2019re driving anywhere at all.<\/p>\n\n\n\n

The client asking for it usually has no idea what would actually suit their situation, so they order a magic AI agent that does everything for them, and does so long before they\u2019ve even written a spec or described the task. And the vendor? They rarely have a reason to correct the client\u2019s mistake, because an AI agent bills better than a \u201cplain old\u201d script.<\/p>\n\n\n\n

Let\u2019s take a concrete example to walk through this. A company gets orders into a shared inbox, and Janie usually retypes or copies them into the system by hand. It\u2019s exactly the kind of task that looks, in a vendor demo, like a textbook job for an agent. And it always works in the demo, because the demo runs on a carefully swept path: a clean email, an existing customer, items that are already in the catalog.<\/p>\n\n\n\n

But dig into that task for a bit and you\u2019ll find it isn\u2019t one job, it\u2019s three different problems. Most emails are orders from regular customers in a stable format, say from a form or a webshop. There, autonomous decision-making only hurts, because the one thing it can add is variability you don\u2019t want. A fixed, code-based procedure that never improvises and hands anything doubtful to a person is all you need.<\/p>\n\n\n\n

A smaller share are orders written by humans: worded differently every time, in a different order, in a different format, but still an order, and you still want to do the same thing with it. That\u2019s where AI helps, but only as one step inside an otherwise fixed procedure. And the rest are emails where what actually needs to happen only becomes clear along the way: \u201ccancel the last item on last week\u2019s order and send what we ordered back in May.\u201d That\u2019s where a system that chooses its own next step comes in. One request, three different architectures.<\/p>\n\n\n\n

And then there\u2019s one more option, which isn\u2019t competing with those three because it answers a different question: you don\u2019t have to run AI on every single execution. It can help just once, at the start \u2014 work out the email format, write a parser, come up with the rules \u2014 and the system then runs deterministically without it. I\u2019ll come back to that once we\u2019ve covered the three architectures.<\/p>\n\n\n\n

Script, workflow, and agent<\/h2>\n\n\n\n

A script or application<\/strong> is a deterministic program for a specific operation: the order of steps and the conditions are written into the code. A workflow is a predefined sequence, or graph, of operations, whose individual nodes are free to call AI. An agent is a system in which the model chooses the next action at runtime based on the current state, and is given a set of tools to do it with.<\/p>\n\n\n\n

Picture it as a factory, with a production line running through it.<\/p>\n\n\n\n

A script is like a robotic arm sorting parts on the line. A sensor at the station before it measures the dimensions, and if the part is within tolerance, it moves on; if not, the arm removes it. The rules are set in advance, the arm makes no decisions, it only executes what the program gave it. If something the arm wasn\u2019t built for shows up on the belt \u2014 a different product, say \u2014 it either pulls it off or simply can\u2019t handle it, because it wasn\u2019t set up for it and its program offers no other option.<\/p>\n\n\n\n

A workflow<\/strong> is the entire production line. The stations follow each other in a fixed order, and that order was set by the process engineer. Somewhere in the middle of the line is a station staffed by a person with knowledge you can\u2019t hand off to a robot \u2014 because some things simply can\u2019t be measured: whether the paint is cracked, or the part is fine and just lying on its side. In our case, that person is the AI. It decides the content of one step, not which step comes next. Even with ten such stations, it\u2019s still a line, because the process engineer \u2014 meaning the programmer \u2014 laid out the route.<\/p>\n\n\n\n

And finally, the agent<\/strong>. An AI agent is the shop floor foreman. It gets a goal \u2014 \u201cthis order has to be done by tonight\u201d \u2014 and, alongside it, boundaries: what it\u2019s allowed to do, which storerooms it has keys to, how much it can spend. What it doesn\u2019t get is a fixed route. It walks the floor, sees what\u2019s missing, goes to the storeroom it has keys to, reorders the operations, calls the workshop it has a phone number for. Every time, it can do it and decide it differently, and you don\u2019t know in advance how. That\u2019s its value, because if you knew how to write down the procedure, you would, and you wouldn\u2019t need a foreman. It\u2019s also its danger: it can\u2019t be audited the way a line can, it sometimes picks a foolish path, and it chases its own goal with blinders on \u2014 it might happily take material that another critical order is short on, because as far as it\u2019s concerned, its own order is the only one in the world. So you let it request materials, but you don\u2019t let it sign a multi-million-dollar purchase order.<\/p>\n\n\n\n

Tools and properties<\/h2>\n\n\n\n

An agent isn\u2019t just \u201cAI with access to the company.\u201d Most of the work, and most of the cost, sits in everything that has to be built around it before it can go into production. So let\u2019s pin down three more terms you can\u2019t talk about agents without, and that you\u2019ll keep running into: tools, skills, and properties.<\/p>\n\n\n\n

Tools <\/strong>(tools)<\/em> <\/strong>are any functions the model can use: a database query, a catalog lookup, creating a record, sending an email. The model decides which tool it wants to use and with what parameters; the surrounding program handles the actual execution. In our factory, the tools are the keys to the storeroom, the phone to the neighboring workshop, and the stamp for the goods-issue slip. The foreman can\u2019t do anything it wasn\u2019t given a tool for, and that\u2019s the single most effective safeguard in the whole system: whatever isn\u2019t in the toolset simply doesn\u2019t happen.<\/p>\n\n\n\n

The second term is skills <\/strong>(skills).<\/em> A skill is a packaged procedure \u2014 a set of instructions, sometimes with helper scripts, that the agent loads whenever it hits a particular type of task. It isn\u2019t a function to call or a system property, it\u2019s knowledge of \u201chow we do X around here.\u201d In our factory, these are the binders of standard procedures hanging on the workshop wall: the foreman pulls the right one when a job of that type comes in and follows it, instead of working out the procedure from scratch every time.<\/p>\n\n\n\n

Around tools and skills sit the properties<\/strong> that determine how the whole thing behaves in production. These are sometimes also called the harness<\/em> or scaffolding<\/em>.<\/p>\n\n\n\n

Take memory<\/em>, for instance. That\u2019s the body of information the system carries between the steps of one run, and between separate runs. A foreman who doesn\u2019t remember at ten what he agreed with a colleague at nine is useless; but a foreman who remembers everything since last year isn\u2019t a win either \u2014 he gets confused, dragging around information that stopped being true long ago.<\/p>\n\n\n\n

Permissions<\/em> are the difference between \u201callowed to do it\u201d and \u201callowed to propose it.\u201d Planning<\/em> then says whether the procedure is mapped out in advance or worked out step by step, improvised. Error recovery<\/em> decides what happens when the storeroom is closed: whether the foreman tries another route or stops and asks. Observability<\/em> is the question of whether it leaves a record of what it did and why, because without one, you can neither debug it nor defend it in an audit. And parallel execution<\/em> means five such foremen can be walking the floor at once, which speeds things up and, at the same time, opens up new ways for them to steal each other\u2019s materials.<\/p>\n\n\n\n

And once there are five of them on the floor, you need orchestration<\/em>: someone to split up the work, wait for the results, and put them back together. On the shop floor that\u2019s the operations manager; in code it\u2019s either a fixed piece of the program that calls the agents and merges their outputs, or another agent that manages its subordinates itself. The first is predictable and cheap; the second can handle tasks you can\u2019t carve up in advance, and unfortunately you often pay for that by having no one in the system left with the full picture.<\/p>\n\n\n\n

More agents also bring a word you\u2019ll hear a lot in this context: verification<\/em>. Broadly, that\u2019s any checking mechanism \u2014 a test, a rule, a control calculation, a human. One option is to have another model assess the output, and a narrower variant of that is to have one agent check another. This helps most where the checker has access to hard data: tests, a database, the original document. Where it doesn\u2019t have that kind of anchor, one model ends up checking another model\u2019s output, and it can be wrong in exactly the same way and for exactly the same reasons. Two foremen from the same school will happily nod along to the same nonsense, because that\u2019s how they were both trained. An extra layer of reasoning doesn\u2019t necessarily dampen errors, it can amplify them. And two agents passing work back and forth to each other are, incidentally, the fastest known way to burn through a token budget: in one documented case, two agents stuck in a loop kept passing work back and forth for eleven days, and the bill stopped at $47,000 [7].<\/p>\n\n\n\n

What\u2019s interesting about that list is that it regularly gets passed off as the definition of an agent. It isn\u2019t. Memory, permissions, planning, error recovery, observability, and parallel execution are all architecturally important, but on their own they don\u2019t determine the architecture, and you\u2019ll find them elsewhere too. The robotic arm also has permissions, and it also logs. The line also has planning \u2014 it\u2019s just that the process engineer did it, not the line itself.<\/p>\n\n\n\n

Not even the presence of a language model tells you anything about the architecture, because today AI shows up at more than one point in the process. Half the market calls a chatbot with a single search call an agent, and in the meantime even classic automation platforms have renamed or repackaged their products as agents. You\u2019ll find an AI agent<\/em> everywhere you look these days. And that terminology mess is costing customers real money. People pick an architecture based on the label, and then wonder why it keeps breaking, doesn\u2019t do what it\u2019s supposed to, or costs so much.<\/p>\n\n\n\n

The practical upshot of that confusion is simple: before you pick a label, pick the simplest thing that solves the task. Anthropic\u2019s Building Effective Agents<\/em> [1] frames this as a recommendation to add complexity only when it\u2019s needed, noting that for plenty of applications a single well-optimized model call with retrieval and in-context examples is enough. In their framing, a workflow gives you predictability on well-defined tasks, while an agent is the better choice where you need a lot of flexibility and model-driven decision-making.<\/p>\n\n\n\n

Which sounds reasonable, right up until you\u2019re staring at an actual, specific task. So let\u2019s try it on ours.<\/p>\n\n\n\n

Script vs. AI-assisted workflow vs. AI agent<\/h2>\n\n\n\n

Let\u2019s go back to Janie and the inbox full of orders. We\u2019ll now solve one task three ways, layer by layer.<\/p>\n\n\n\n

But before you reach for any of this, stop and think. Could the email be replaced with a form, a CSV attachment, or a direct integration with your partner\u2019s system? And if not, could an off-the-shelf integration platform (n8n, Make, Zapier) handle it without a single line of code? If not, and most of your customers are reasonable, at least suggest they stop emailing Janie or Pete directly and send orders to one clearly defined address instead. Something like orders@yourcompany.com<\/em>.<\/p>\n\n\n\n

When orders come from a partner\u2019s system in the same template every time, a script is the ideal fit.<\/p>\n\n\n\n

Script<\/h3>\n\n\n\n

Every five minutes, it checks the orders@yourcompany.com inbox over IMAP, picks up the unread emails, and tries to find in each one what the partner\u2019s system always sends: an order number and line items. If it finds them, it creates the order in the system \u2014 via an API, or perhaps by adding a row to a CSV file or a Google Sheet. If it doesn\u2019t (an inquiry came in, a cancellation, or the partner changed their template), the email gets a label or is moved to a folder a salesperson goes through in the morning. Once processed successfully, the email is marked as done, so the same message never gets evaluated twice.<\/p>\n\n\n\n

If most of the emails end up in the salesperson\u2019s folder, it\u2019s time to get smarter about this. So we bring in AI. Into a workflow.<\/p>\n\n\n\n

AI-assisted workflow<\/h3>\n\n\n\n

Same route, but instead of matching a fixed template, the email body gets read by a model. You don\u2019t let it comment on the email the way you\u2019re used to from ChatGPT, and you don\u2019t let it draft a reply. You prescribe the structure of what you care about: order number, tax ID, line items, and, as mandatory fields, \u201cthis isn\u2019t an order\u201d and \u201cI\u2019m not sure about this one.\u201d Without those last two fields, a model asked about a delivery date would happily invent an order, because the format wouldn\u2019t allow it any other answer. Whatever the model fills in, the workflow treats as material to verify, not as a finished result: another script checks your database and compares item codes against the catalog, verifies the tax ID with a checksum, against the national business registry or against your own client list, and flags any suspicious quantities against thresholds you set in advance. Only once it clears everything does it go into the system on its own; the rest goes to a salesperson, along with the reason it was stopped.<\/p>\n\n\n\n

Notice that the model isn\u2019t steering anything here. It returns a structured result, and every step before and after it is fixed in advance. That\u2019s why it\u2019s still a workflow, even with AI sitting inside it.<\/p>\n\n\n\n

And notice, too, that there are still a few emails left that are ambiguous. Take the one that says \u201ccancel the last item and send what we ordered back in May.\u201d That\u2019s the ideal candidate for the more expensive tier: an AI agent.<\/p>\n\n\n\n

AI agent<\/h3>\n\n\n\n

The agent gets a goal: \u201chandle this email.\u201d And with it, three tools: it can search your database for the customer\u2019s orders, open their details, and draft a proposed change to write to the system. That\u2019s all it has \u2014 it can\u2019t invoice, send anything, or delete anything, so the worst it can do is write a bad draft.<\/p>\n\n\n\n

It decides for itself in what order, and how many times, to use its tools. For the email \u201ccancel the last item and send what we ordered back in May,\u201d it will most likely pull up May\u2019s orders first, check the details to see what was ordered then, find the most recent line item, and put together a draft. For a different email, \u201cadd two more large sheets in anthracite,\u201d it looks up catalog items named or categorized as \u201csheet,\u201d finds that there\u2019s only one anthracite variant, RAL 7016, and proposes that.<\/p>\n\n\n\n

That freedom is exactly why we only deploy an agent on what\u2019s left over, and also why we wrap it in a protective loop that does three things. First, it returns the result of every tool call to the agent, even a failed one: it gets the error described as information (\u201cno order exists with this number\u201d), not as a program crash, so it can try a different approach. Second, it counts steps and spend \u2014 every run has a predefined ceiling on the number of calls, tokens consumed, and cost, and it terminates when that\u2019s exceeded, even if the agent insists it\u2019s almost done. And third, it logs every tool call, including its arguments and result, so any draft can be traced back to exactly the data it came from.<\/p>\n\n\n\n

The result isn\u2019t a changed order, it\u2019s a proposed change sitting on the operator\u2019s desk. The \u201cOK\u201d button belongs to the salesperson \u2014 and clicking it twice must never create two changes.<\/p>\n\n\n\n

AI as author<\/h2>\n\n\n\n

At the start, I promised one more option. It isn\u2019t a fourth item to add to the previous three, because it answers a different question. Script, workflow, and AI agent are about what makes the decisions while the system is running. This option is about whether you need AI at runtime at all, or whether it\u2019s enough for it to help build the system once.<\/p>\n\n\n\n

It works like this: the first email from a new customer is run through the model with two jobs at once: handle this order, and, once I confirm you handled it correctly, write a program that will handle every future one in the same template. The program is tested immediately, and if it produces the same result as the model on that same email, you\u2019re on the right track. At least for this type of order.<\/p>\n\n\n\n

But one email isn\u2019t proof. The parser has to earn trust: the next several emails in the same template run through both it and the model in parallel, and only once the results keep matching does the parser take over the shift. From that point on, that partner\u2019s emails go through code: no tokens, no waiting, and the same result every time. The catalog and tax ID checks stay in place either way, because it doesn\u2019t matter who parsed the email. What matters is what goes into the system. And when the partner changes their template, the parser starts failing or disagreeing with the checks, the work goes back to the model, and it writes a new parser.<\/p>\n\n\n\n

So you pay once to create the tool, not repeatedly for every response. For tasks that repeat and where only the shape of the input changes, this is the best value you\u2019ll get out of AI.<\/p>\n\n\n\n

Why an agent isn\u2019t always the best choice<\/h2>\n\n\n\n

As you\u2019ve probably gathered by now, a script is great at processing unambiguous input: it\u2019s fast, cheap, and deterministic. An agent, by contrast, can adapt to the situation, but it\u2019s slower, more expensive to run, and not always predictable.<\/p>\n\n\n\n

How much more expensive? Anthropic\u2019s piece on its multi-agent research system [2] reports that agentic runs consume roughly four times the tokens of an ordinary conversation on average, and multi-agent architectures around fifteen times. Those numbers come from their own system, not some universal constant, but the mechanism behind them is general: the loop rereads the entire step history every time, so every round carries the context of everything before it. Imagine writing letters to your kid at summer camp, and every envelope has to include every previous letter as well. Your child sends a letter, you reply and enclose their letter, they reply and enclose both previous ones. By the last round, it\u2019s not an envelope anymore, it\u2019s a parcel. And sending things back and forth means latency too: six letters there and six back means twelve trips to the mailbox, and with a model that can easily mean tens of seconds of waiting.<\/p>\n\n\n\n

But our letter analogy doesn\u2019t stop there. What happens to those letters if you keep pulling them out, reading them, and folding them back into the envelope? The paper cracks along the folds, someone at home sets a coffee mug on the pile, the whole parcel falls in a puddle on the way to camp. Readability drops with every extra handling. None of that happens to an agent, because information in the context window doesn\u2019t degrade like paper, and the model reads it just as clearly the hundredth time. What goes wrong is something else: a flawed intermediate result becomes part of the working state, and every decision after it treats it as fact. It\u2019s a lot like the telephone game. The first person in line says \u201csend reinforcements, we\u2019re going to advance,\u201d and the fifth hears \u201csend three and fourpence, we\u2019re going to a dance.\u201d Nobody in the chain is lying, and nobody is trying to ruin the game, each of them is just passing on what they think they heard. An agent plays telephone with itself: step three interprets the data slightly differently, step six builds on that reading, step eight flips some piece of information, and step ten treats a negation as a confirmation, so it ends up deciding something that\u2019s only distantly related to the original email anymore.<\/p>\n\n\n\n

A simple model shows what that costs in reliability. Take a chain where all ten steps have to succeed and none depends on the others. At 95% success per step, the whole chain comes out at 59%. At 90%, 35%. At 85% \u2014 a decent result for a more complex task \u2014 20%. And the other way around: if you want a ten-step process that succeeds 95% of the time, you need roughly 99.5% per step, and for deterministic steps, code gets you there far more reliably than repeated model judgment does. Real runs aren\u2019t this clean: steps aren\u2019t equally hard, some repeat or get skipped, and an agent can recover from a tool error. Treat these numbers as an illustration of how fast small unreliability compounds over the length of a chain. That this effect really shows up in practice is confirmed by measurements of long agent runs [3]: reliability drops as task length grows, and steeply so in some domains.<\/p>\n\n\n\n

Two other pieces of research point the same way. The \u03c4-bench benchmark [4] introduced the pass^k metric \u2014 how many times an agent succeeds across all k repetitions of the same task: the best agents solved fewer than half their tasks on the first attempt, and in the retail domain they succeeded across all eight repetitions in fewer than a quarter of cases. Success in a demo, then, says almost nothing about success in production. And ReliabilityBench [5] adds that simply rewording a task, or adding routine operational friction like rate limits, is enough to noticeably drop success rates. Both are still limited benchmarks, but they point in the same direction.<\/p>\n\n\n\n

There is a defense, and we\u2019ve already met it: verification<\/strong>. As soon as a step has a clearly defined check, can be retried, or can be skipped, simple multiplication stops applying, and the accuracy demanded of any one step drops. That\u2019s why the workflow verifies the tax ID, the catalog, and the quantities, and why the agent ends with a proposal instead of an executed change.<\/p>\n\n\n\n

The worst part of all this is the shape the failure takes. An agent doesn\u2019t crash. Step three returns slightly stale data, step six formats it wrong, step nine decides based on bad inputs, and the result looks entirely credible. An error that throws an exception is a gift. An error that returns a nicely formatted, nonsensical answer is a disaster.<\/p>\n\n\n\n

In a June 2025 press release [6], Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, due to rising costs, unclear value, and inadequate risk controls. That\u2019s an analyst firm\u2019s forecast, not a measurement, and it rests partly on a poll of their webinar attendees. I don\u2019t read it as a forecast of the end of agents. I read it as a forecast of the end of agents deployed on tasks where someone should have written code instead.<\/p>\n\n\n\n

Why (and when) an agent is the best choice<\/h2>\n\n\n\n

That heading probably just scrambled your brain a little, right? But an agent really can be the best choice. I use five criteria for it. It isn\u2019t a textbook definition, it\u2019s my own decision-making heuristic, and I want as many of them to hold at once as possible.<\/p>\n\n\n\n

1. The next step depends on the outcome of an earlier finding<\/strong><\/p>\n\n\n\n

For the email \u201csend what we ordered back in May,\u201d you don\u2019t know how many May orders exist until you look, and only once you know what you find can you decide whether you need another database query, or a question to a human. So the decisions made mid-task depend on data you don\u2019t have before you start. If, on the other hand, the whole procedure can be fixed in advance and the data just fills it in, you don\u2019t need an agent.<\/p>\n\n\n\n

2. There are so many possible paths that coding them all in advance is impractical<\/strong><\/p>\n\n\n\n

A small number of variants can be listed out and written as branches in code, and that\u2019s always the better solution there. An agent pays off once the list of variants would be longer and more brittle than the description of the goal itself. I use a flowchart heuristic for this: if you can draw it on a single sheet of paper and no node in it requires judgment over open-ended input, you probably don\u2019t need an agent, and it\u2019s enough to write that flowchart in code. It\u2019s a guideline, not a definition. Even a short flowchart can contain one node that can\u2019t do without judgment, and conversely, plenty of agents have a banal model \u2192 tool \u2192 model diagram on paper, with the real complexity hidden in how many times, and in what order, it goes around that loop.<\/p>\n\n\n\n

3. There\u2019s feedback on the quality of the result<\/strong><\/p>\n\n\n\n

The strongest form of this is machine verification, and it\u2019s also why agents work best in programming: a test either passes or it doesn\u2019t, a compiler either compiles or it doesn\u2019t, and the agent can correct itself on that basis, still mid-run.<\/p>\n\n\n\n

But binary verification isn\u2019t the only usable form. For research, triage, or preparing background material, quality can\u2019t be measured by machine, and yet agents still make sense there, because traceability carries the feedback: every claim has a source you can open, a human reads the output, and an error is caught before it causes any damage. So the condition is that a sufficiently good check has to exist, whether automated mid-run or human at the end.<\/p>\n\n\n\n

Where this breaks down is work with no check at all. An agent that \u201coptimizes content,\u201d with no one reading or measuring its output, has no way of knowing when it\u2019s actually done, and produces nothing but confidence.<\/p>\n\n\n\n

4. The cost of a mistake is bearable and can be bounded<\/strong><\/p>\n\n\n\n

Not \u201cthe model won\u2019t make a mistake,\u201d but \u201cwhen it does, what does it cost, and who notices.\u201d In practice, this means the error can be caught before it causes anything \u2014 which is why the agent in our example ends with a proposal, not an executed change \u2014 and that even a caught error only costs one person\u2019s time, not a damaged customer relationship or a wrongly issued invoice.<\/p>\n\n\n\n

5. The task can bear the cost of an agent<\/strong><\/p>\n\n\n\n

Costs that run several times higher \u2014 on the order of four to fifteen times, for published agentic systems [2] \u2014 and tens of seconds of latency have to be paid for by something. For internal research twice a day, clearly yes. For an operation that runs thirty thousand times a month? Now you need to pull out the token pricing sheet and a calculator.<\/p>\n\n\n\n

How I approach this in practice<\/h2>\n\n\n\n

The process I use is boring, and it works.<\/strong> I start with a single prompt and a manual run on twenty real cases. Not made-up ones \u2014 real ones, including the weird and borderline cases, if I can find any. That gives me a first sense of what the model can handle and where it falls over. Then I turn those twenty cases into an evaluation set. Without one, there\u2019s no way to tell whether a prompt change is an improvement or a regression, and building an agent without evals is like refactoring without tests.<\/p>\n\n\n\n

Only then do I write code. First a fixed workflow, because most cases follow one path. I deploy the agent on what\u2019s left \u2014 the long tail of exceptions, where the path differs from case to case \u2014 and even there, in a mode where it only proposes and never executes, with a human at the end.<\/p>\n\n\n\n

When someone comes to me wanting an agent, I ask two things. How will you know the task went well<\/strong>? And what happens if it goes badly<\/strong> and nobody notices until the morning? If there\u2019s no answer to the first question \u2014 no test, no human check \u2014 and the answer to the second is unpleasant, we don\u2019t build an agent. We build a deterministic process first, one that decides nothing without a check, but records everything.<\/p>\n\n\n\n

You might object: if nobody can judge the result anyway, what\u2019s the point of even that? The point is that when it breaks, it breaks predictably. Fixed steps mean the error shows up in a known place, gets found in that specific step\u2019s log, and gets fixed once, for every future run. An agent with unpredictable, unjudgeable output and a different path every time won\u2019t give you that. And over time, those error logs become the feedback that serves as the building blocks for a more expensive, more sophisticated solution. That\u2019s when it starts making sense to talk about an agent.<\/p>\n\n\n\n

An AI agent is the most expensive way to automate a process. Sometimes it\u2019s the only way. But usually, it isn\u2019t.<\/p>\n\n\n\n

References<\/h2>\n\n\n\n

[1] ANTHROPIC. Building Effective Agents<\/em> [online]. Anthropic, 2024 [accessed 2026-08-25]. Available at: https:\/\/www.anthropic.com\/engineering\/building-effective-agents<\/a><\/p>\n\n\n\n

[2] ANTHROPIC. How We Built Our Multi-Agent Research System<\/em> [online]. Anthropic, June 2025 [accessed 2026-08-25]. Available at: https:\/\/www.anthropic.com\/engineering\/multi-agent-research-system<\/a><\/p>\n\n\n\n

[3] KHANAL, Aaditya, TAO, Yangyang, and ZHOU, Junxiu. Beyond pass@1: A Reliability Science Framework for Long-Horizon LLM Agents<\/em> [online]. arXiv, March 31, 2026 [accessed 2026-08-25]. arXiv:2603.29231. Available at: https:\/\/arxiv.org\/abs\/2603.29231<\/a><\/p>\n\n\n\n

[4] YAO, Shunyu, SHINN, Noah, RAZAVI, Pedram, and NARASIMHAN, Karthik. \u03c4-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains<\/em> [online]. arXiv, June 17, 2024 [accessed 2026-08-25]. arXiv:2406.12045. Available at: https:\/\/doi.org\/10.48550\/arXiv.2406.12045<\/a><\/p>\n\n\n\n

[5] GUPTA, Aayush. ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions<\/em> [online]. arXiv, January 3, 2026 [accessed 2026-08-25]. arXiv:2601.06112. Available at: https:\/\/arxiv.org\/abs\/2601.06112<\/a><\/p>\n\n\n\n

[6] GARTNER, Inc. Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027<\/em> [online]. Gartner, June 25, 2025 [accessed 2026-08-25]. Available at: https:\/\/www.gartner.com\/en\/newsroom\/press-releases\/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027<\/a><\/p>\n\n\n\n

[7] KUSIREDDY, Teja. We Spent $47,000 Running AI Agents in Production. Here\u2019s What Nobody Tells You About A2A and MCP<\/em> [online]. Towards AI, October 16, 2025 [accessed 2026-08-25]. Available at: https:\/\/pub.towardsai.net\/we-spent-47-000-running-ai-agents-in-production-heres-what-nobody-tells-you-about-a2a-and-mcp-5f845848de33<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

A request I get more and more often: \u201cWe\u2019d like an AI agent.\u201d Not \u201cwe have a problem with orders,\u201d not \u201cwe\u2019re drowning in emails.\u201d Straight to an AI agent. Ask what that agent is actually supposed to do, and the answer comes back as \u201cso it runs itself\u201d or \u201cwhatever Janie does today, just […]<\/p>\n","protected":false},"author":1,"featured_media":10364,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","_seopress_robots_follow":"","_seopress_robots_imageindex":"","_seopress_robots_snippet":"","_seopress_robots_primary_cat":"","_seopress_robots_breadcrumbs":"","_seopress_robots_freeze_modified_date":"","_seopress_robots_custom_modified_date":"","_seopress_robots_canonical":"","_seopress_social_fb_title":"","_seopress_social_fb_desc":"","_seopress_social_fb_img":"","_seopress_social_fb_img_attachment_id":0,"_seopress_social_fb_img_width":0,"_seopress_social_fb_img_height":0,"_seopress_social_twitter_title":"","_seopress_social_twitter_desc":"","_seopress_social_twitter_img":"","_seopress_social_twitter_img_attachment_id":0,"_seopress_social_twitter_img_width":0,"_seopress_social_twitter_img_height":0,"_seopress_redirections_value":"","_seopress_redirections_enabled":"","_seopress_redirections_enabled_regex":"","_seopress_redirections_logged_status":"","_seopress_redirections_param":"","_seopress_redirections_type":0,"_seopress_analysis_target_kw":"","_seopress_news_disabled":"","_seopress_video_disabled":"","_seopress_video":[],"_seopress_pro_schemas_manual":[],"_seopress_pro_rich_snippets_disable_all":"","_seopress_pro_rich_snippets_disable":[],"_seopress_pro_schemas":[],"footnotes":""},"categories":[10],"tags":[],"cat_tool":[],"class_list":["post-10371","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10371","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/comments?post=10371"}],"version-history":[{"count":1,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10371\/revisions"}],"predecessor-version":[{"id":10372,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/posts\/10371\/revisions\/10372"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/media\/10364"}],"wp:attachment":[{"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/media?parent=10371"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/categories?post=10371"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/tags?post=10371"},{"taxonomy":"cat_tool","embeddable":true,"href":"https:\/\/www.kubicek.ai\/en\/wp-json\/wp\/v2\/cat_tool?post=10371"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}