Many agentic AI projects will be cancelled before they deliver value. In June 2025, Gartner said more than 40% of agentic AI projects will be cancelled by the end of 2027. It named three causes: rising costs, unclear business value and weak risk controls. All three are scoping problems, and you can fix them before any code is written.
This guide explains what goes wrong and gives a short checklist for scoping a first agent. It is written for CTOs, founders and product leads who are deciding whether to build one.
What an agent is, and what it is not
The word "agent" is used loosely. Anthropic draws a useful line. A workflow is a system where LLMs and tools are orchestrated through predefined code paths. An agent is a system where the LLM dynamically directs its own process and tool use.
That difference matters for your budget. A workflow is predictable and easier to test. An agent can handle open-ended work, but it can also take wrong turns that build on each other.
Gartner also warns about "agent washing". Vendors rebrand chatbots, assistants and RPA tools as agentic AI. The same report says only about 130 of the thousands of agentic vendors are real. Ask any vendor to show where the system decides its own next step. If it cannot, you are looking at a workflow, which may be exactly what you need.
The three reasons projects get cancelled
Many model calls per task, with no measure of cost per finished task.
A demo exists, but no business number is expected to move.
Permissions and approvals are added late instead of designed in.
1. Costs climb faster than expected
Agents make many model calls per task. Anthropic notes that agentic systems often trade latency and cost for better task performance. That trade is fine when the task is worth it. It is a problem when nobody has measured what one finished task costs.
2. Nobody can state the business value
Many pilots start with a demo, not a metric. A demo shows that an agent can do something. It does not show that the business needs it done. If the team cannot name the number that should move, the project has no way to prove itself when budgets are reviewed.
3. Risk controls arrive too late
An agent that can call tools can also call the wrong one. OWASP lists excessive agency in its Top 10 for LLM Applications 2025. The risk is that excess functionality, permissions or autonomy damages confidentiality, integrity or availability. Prompt injection sits first on the same list. Both are design decisions, not patches you add before launch.
Why "almost right" is the real quality problem
Developers already see this in everyday use of AI tools. The Stack Overflow 2025 survey reports that 45% name "almost right, but not quite" as their top frustration. It also reports that 66% spend more time fixing almost-right AI code.
An agent multiplies this effect. One slightly wrong step feeds the next step. By the end, the output looks confident and is wrong. That is why testing and review need to be part of the first design, not a final phase. Our own QA and testing practice treats QA as a gate for this reason.
A checklist for scoping your first agent
Use these questions before you commit budget. If you cannot answer one, pause.
| Question | What a good answer looks like |
|---|---|
| What task does the agent finish? | One task, described in a sentence, with a clear start and end |
| Which number should move? | A metric you already track, such as handling time or resolution rate |
| Is an agent really needed? | You tried a single call with retrieval, then a fixed workflow, and they fell short |
| What can it touch? | A short list of tools with the minimum permissions each |
| What can it never do alone? | Actions that cannot be undone need human approval |
| How will you test it? | An evaluation set built from real tasks, run before every release |
| When does it stop? | A step limit and a spend limit per task |
Start with the simplest design
Anthropic's advice is to use the simplest solution possible and only add complexity when needed. Often a single LLM call with retrieval and examples is enough. Move to a workflow when the steps are known. Move to an agent only when you cannot hardcode the path.
Keep a human at the checkpoints
Agents can pause for human feedback at checkpoints or when they are blocked. Use that. Put approval steps in front of anything that sends money, deletes data or contacts a customer. Remove a checkpoint only after the evaluation results justify it.
Build the evaluation set first
Collect real examples of the task and agree what a correct result looks like. Run every change against that set. Without it, you cannot tell whether a prompt change helped or hurt, and you cannot give a stakeholder evidence.
A worked example of good and bad scope
Take a support team that wants "an AI agent for customer service". That scope is too wide. It has no single task, no metric and no limit on what the agent may do.
Now narrow it. The agent drafts replies to refund-status questions. It can read order data and cannot issue refunds. A support person approves each reply. The metric is average handling time on those tickets. The step limit is small, and the evaluation set is a few hundred past tickets with approved answers.
This is an illustration, not a client result. It shows the shape of a scope that can be tested, costed and stopped. Once the draft quality is proven, the team can decide whether the agent may send low-risk replies alone.
Common mistakes to avoid
- Starting with the tool. Teams pick a framework first and look for a problem later. Pick the task first.
- Giving broad permissions "for now". Temporary access tends to stay. Grant the minimum and widen it with evidence.
- Skipping logs. If you cannot see each tool call, you cannot debug a bad run or explain a cost spike.
- Measuring only success cases. Track failures, retries and hand-offs to humans as well.
- Treating launch as the finish. Models, data and user behaviour change. Re-run the evaluation set on every release and on a regular schedule.
What a sensible pilot looks like
- 1Pick one taskOne sentence, clear start and end
- 2Build the test setReal examples with agreed correct results
- 3Run in a sandboxSmall tool list, step and spend limits
- 4Add human approvalFor anything that cannot be undone
- 5Review the dataExpand, keep as a workflow, or stop
A good first pilot is narrow and measurable. It covers one task, a small tool list, a step limit and a human approval step. It runs against real examples in a sandbox before any user sees it. It reports cost per completed task from the first week.
Then the team decides with data. Expand the agent, keep it as a workflow, or stop. Stopping early with evidence is a good outcome. It costs far less than a cancelled project.
How XOSOFT approaches this
Our AI and ML practice builds generative AI apps, agentic systems and evaluation harnesses. On our engineering teams, AI tools draft and engineers decide: every line is reviewed by a person, and AI never merges code. The same principle applies to the systems we build for clients. Humans stay accountable for decisions that matter.
If you are weighing a first agent, a Discovery Sprint is a low-risk way to test the idea against the checklist above. You can also book a technical call. It is a conversation with engineers, not a sales pitch.
Frequently asked questions
What is the difference between a workflow and an AI agent?
A workflow runs an LLM through code paths you define in advance. An agent decides its own steps and tool calls at run time. Workflows are more predictable. Agents suit open-ended tasks where you cannot fix the path.
Should a first AI project be an agent?
Usually not. Start with the simplest design that works, such as one LLM call with retrieval, then move to a workflow. Add agent behaviour only when it clearly improves the result.
How do you control the cost of an agent?
Set a maximum number of steps, cap spend per task, log every tool call and measure cost per completed task. Review these numbers every week during the pilot.
How do you test an AI agent before launch?
Build an evaluation set from real tasks, run the agent in a sandbox, score outputs against agreed criteria and keep a human approval step for any action that cannot be undone.
Need help with AI and machine learning?
Talk to the engineers who would do the work. We reply within one working day.