The gap is not in the model
AI agents are one of the most discussed topics in AI at the moment, and they are often presented as the point where you hand the work over and sit back. Much of what they can do is genuinely impressive. An agent that reads files, calls tools, decides what to do next and keeps going for twenty steps without being prompted pushes automation further than anything most teams had access to two years ago.
The gap is usually not in the model. It is in everything around it: the instruction it was given, the systems it depends on, and the checks that catch it when it goes the wrong way. Companies building frontier models have an interest in presenting agents as close to omnipotent, and users blinded by these claims skip groundwork that used to be necessary.
This produces a set of expectations that quietly degrade the work. Below are five that come up regularly in our work with clients, along with the cost associated with each one and what to do instead.
One example runs through all of them: an agent connected to a shared cloud folder that reads incoming client invoices, extracts a few fields and files them under a naming convention. It is deliberately mundane. Most agent work is.
1. The instructions are too vague
The most common problem is also the easiest to fix. Models are better than they were, and with tools they can work a lot out for themselves, but they cannot recover intent that was never stated.
Compare a vague instruction, such as "go through the documents in the shared folder and organise them", with a precise one: process the PDF invoices in /clients/inbound/; for each file, extract the invoice number, supplier name and total; rename the file to YYYY-MM-DD_supplier_invoice-number.pdf and move it to /clients/processed/; and do not change the contents of any file.
The first version does not define "organise", so the agent has to. It lists the folder, opens several files to work out what they are, possibly reads ones that were never relevant, and forms its own view of what a tidy folder looks like. Every one of those steps is tokens, and tokens are time and money. If you already know the agent will only ever see invoices, and only ever needs to rename and move them, that belongs in the instruction rather than being rediscovered on every run.
The cost is the visible part. The more consequential effect is that exploration is where non-determinism gets its opening. Each decision the agent makes for itself is a decision that may not match the one you would have made, and those decisions compound across a long run.
Narrowing the scope reduces the space the agent has to improvise. It does not tell it what to do at the edges. The instruction above says nothing about a scanned image with no extractable text, or an invoice missing a number, which is the subject of the next section.
2. The environment is assumed to just work
Agents now sit between several systems at once: a local filesystem, cloud storage, an API, sometimes a database. Every connection is a place where a run can stop halfway. The Wi-Fi drops and the agent on your laptop can no longer reach the cloud folder. An API key expires. A rate limit lands at file forty of two hundred.
The interruption itself is rarely the damage. The damage is a half-finished run that looks finished. An agent that renamed thirty invoices, lost its connection and stopped leaves a folder in two states, with no record of which files are in which.
You cannot predict every failure, but you can decide in advance what happens when one occurs: write progress somewhere durable, so a run can resume rather than restart; treat a failed tool call as a stop condition rather than something to work around; notify a person whenever a run ends without completing; and make each step safe to repeat, so re-running a partly processed folder does not process anything twice.
These guardrails only cover the failures you anticipated. The rest are caught by someone noticing that a run ended oddly, which is why the notification matters more than the list of specific failure cases.
3. Known problems are left for the agent to solve
Prompting techniques still apply to agent instructions, and few-shot prompting is probably the most useful of them. If you already know which cases are awkward, the agent should not be discovering them on your behalf at runtime.
For example: some invoices arrive as .jpeg scans rather than PDFs, and if the filename follows the INV- convention they should be processed the same way as PDFs; if a file has no readable invoice number, it should move to /clients/needs-review/ and the run should continue with the next file rather than guessing a number.
Two things in that example are easy to leave out. The first is what happens to the problem item, and the second is whether the run continues. Without both, an agent meeting an unreadable scan either invents a plausible invoice number or abandons the remaining hundred and eighty files, and neither behaviour is one you chose.
Examples can only cover cases you have already met. New ones will keep appearing, which is the real argument for a defined needs-review destination rather than an agent improvising: it gives the unknown cases somewhere to accumulate where you will see them.
4. The outcome is not specified
There are many ways to do the same thing. Programming is the clearest example. Engineers can build the same feature from completely different directions, which is why teams adopt conventions, style guides and review standards. An agent knows none of those unless you teach it or provide examples.
Specifying the outcome means naming the artefacts, not just the goal. For example, when the run finishes, write a summary to /clients/processed/log.csv with one row per file: original filename, new filename, supplier, total, and status of either processed or needs-review.
A specified output is also a checkable output. Without the log there is no way to answer what the agent actually did, other than reading the folder and inferring.
What this does not give you is correctness. The log confirms that every file was accounted for and that each row has the right shape. However, it does not confirm that the total was read from the right line of the invoice. Specifying the output makes checking and evaluation possible, but the verification is still a separate step.
5. The process is expected to be repeatable
This follows from the previous point. Many people expect a prompt to execute like code, line by line, in order. Models do not work that way. The instruction is added to the context, the model produces a probability distribution over possible next tokens and samples from it, and small variation early in a run can change what happens much later. Two runs of the same instruction over the same folder may take different routes, and occasionally produce different outcomes.
The response to this is not better wording. Sections 1 to 4 reduce how much room the agent has to vary, and that is worth doing, but no instruction removes the variation entirely. What removes the risk is verification at the boundaries: a check after the extraction stage rather than only at the end of the run, so that a wrong turn is caught while there are still thirty files left rather than after all two hundred have been renamed.
Checks cost time and money, so they belong where a mistake is expensive to undo. Renaming a file is cheap to reverse. Sending an invoice to a client is not.
Keeping instructions short without losing precision
There is an obvious tension between the sections above and the length of the final instruction. Everything so far argues for more detail, while a model's ability to follow instructions declines as those instructions get longer. Both are true, and they are resolved by where the information lives rather than by how much of it there is.
Stable information belongs in the instruction file, skill or workflow description that the agent loads every time: paths, naming conventions, output format, the handful of edge cases you already know about. Individual messages to a running agent stay short. Information that is only needed occasionally should sit somewhere the agent can access it through a tool or a skill, rather than occupying context on every run whether it is relevant or not.
A few practical habits follow from this: use explicit paths when asking an agent to read, create or modify a file, rather than describing where the file probably is; when you send a follow-up message in response to something the agent did, name the file or tool it should use next, since a follow-up is where scope quietly widens; write short, precise sentences instead of long paragraphs of context, since length is not the same as clarity and the model pays for both; and keep skill and workflow descriptions to a plain statement of what they do, letting descriptions reference each other so an agent can follow the chain when it needs more detail rather than carrying all of it at once.
Not every one of the five problems shows up in every project. A few of them together are enough to make an agent's output noticeably worse, slower and more expensive at the same time.
Copying a human process onto an agent
There is a second version of this problem that has nothing to do with instructions. It is the assumption that an existing process should be handed to an agent in exactly the shape a person performed it.
Human processes carry steps that exist because a person was doing them: a check that compensates for something being easy to misread, an approval that exists because the previous step was manual, a batching decision made around someone's working day. Some of those steps are load-bearing and some are artefacts. Translating all of them faithfully produces an agent that is slower than it needs to be in some places and unguarded in others.
One of our clients wanted to automate their podcast workflow. Although many steps were already done by AI, the whole workflow was still mainly manual. The AI is not yet that good at editing the raw recording, but transcribing the audio and finding the best bits from interviews for social media turned out to be a clear and easy win for the client. Especially after teaching the AI the brand voice and formats, the client was delighted with the quality of what it produced.
Instructions are only part of the system
A clear instruction improves the odds of a good run. It is not the whole of what makes an agent dependable, and it is the part that gets the most attention because it is the part that feels like writing.
When an agent touches a process that matters, the instruction should sit alongside limits on what the agent can reach, so a mistake stays inside the folder it was given; a record of what each run did, kept outside the conversation; checkpoints where a person confirms before an irreversible step; notifications when a run ends incomplete; cost and duration monitoring, so a run that starts exploring is visible before the invoice arrives; and testing against real inputs, including the awkward ones, rather than clean examples.
Conversation history is not reliable storage for any of this. Rules that matter to a process belong in an instruction file or specification that is loaded every time, not in a message somewhere earlier in a long run.
Final thoughts
Agents have moved the boundary of what can be delegated, but they have not removed the work of defining what done means. Most of the difference between an agent that saves a day a week and one that quietly creates work is groundwork that used to be obvious and now feels optional.
Take one process you already run manually. Write the instruction with explicit paths, a named output and two edge cases you have actually seen. Run it twice on the same input and compare what each run produced. The difference between those two runs is the amount of room the instruction is still leaving open.
For further reading, see Anthropic's guide to building effective agents , OpenAI's practical guide to building AI agents , and Microsoft's guidance on marketplace AI agent and app best practices .
What keeps your agents on task? We are always interested in how people build their systems, and particularly in the guardrails that turned out to matter. Get in touch if your processes need automation or you want help implementing AI in your business.