When not to build an AI agent
We spend a reasonable amount of our time telling potential clients that the thing they want to build isn't actually a good idea for an AI agent. Not because it can't be built, but because building it won't solve the problem they think they have — or it'll solve it in a way that creates more problems than it eliminates.
This is a more useful conversation to have before a project starts than during it.
The checklist
Work through these before commissioning anything.
Is the process well-defined enough to describe to a new employee? If you can't explain what the right decision looks like in most cases, you can't encode it into an agent. You might be able to use an agent to explore what the right decision is — but that's a different project, and it requires a different tolerance for error.
Is the volume high enough to justify the cost of building and maintaining it? An agent that automates ten decisions a week is probably not worth building. At a hundred a week it might be. At a thousand it usually is. The engineering cost is roughly fixed. The return scales with volume.
What happens when it gets something wrong? If the answer is "someone notices, fixes it manually, and the cost is a few minutes of time," then the error tolerance is high and automation makes sense. If the answer involves customer harm, legal liability, or irreversible consequences, the risk profile looks different and requires more careful design — or a different approach entirely.
Is the data the agent needs actually accessible? This sounds basic. It isn't. Many automation projects fail at the integration step, not the AI step. The scheduling system doesn't have an API. The CRM exports are monthly. The relevant data lives in email attachments that aren't structured. Building an agent that theoretically works is not the same as building one that can get the inputs it needs.
Are there simpler alternatives that you've actually evaluated? A no-code automation, a better-organised spreadsheet, a human process with a clearer handoff protocol, a feature in the tool you already use — these are worth considering before commissioning a custom agent build. They're faster to deploy, easier to maintain, and good enough for many problems.
The cases where it makes sense to wait
If the process itself is unstable — changing frequently, not yet settled, being actively redesigned — automating it now will create technical debt. You'll be maintaining an agent built for a process that no longer exists. Better to let the process stabilise and automate the steady-state version.
If the team doesn't have the capacity to handle the integration work on their side — API access, data cleaning, deployment infrastructure, a point of contact who can answer questions during build — the project will stall. Agents are not self-contained systems. They depend on the environment they're deployed into, and that environment needs to be in reasonable shape.
A note on starting small
The most reliable way to get a useful agent built is to start with a narrower problem than the one you originally identified. The scheduling agent that handles one appointment type, not all of them. The invoice reminder that covers the clear cases, not every possible situation. The intake classifier that handles the top three request categories, not the full taxonomy.
This isn't always politically comfortable — it can feel like settling for less. In practice it usually means you get something working in production within a reasonable timeframe, learn from it, and expand from a solid foundation. The alternatives — building something comprehensive that doesn't quite work and needs months of refinement, or building something that works but has to be rebuilt because the scope changed mid-project — are less satisfying outcomes.