It may seem odd for a Guild that builds AI agents to publish this, but it needs saying: a good share of the requests that arrive as "we need an AI agent" are better served by something else. A rule. A form. A clearer web page. A report with an owner. A process that someone finally writes down.
An agent is the right tool when work needs judgement over varied, messy inputs, involves actions across systems, and happens often enough to matter. When those conditions are missing, an agent is an expensive and less predictable way of doing what something simpler would do better. Building one anyway does not just waste money. It teaches the organisation that agents disappoint, which makes the next — good — proposal harder to approve.
What an agent actually adds
It helps to be precise about what you are buying. A useful distinction, set out by Anthropic in its guidance on building agents, is between workflows, where models and tools follow paths defined in code, and agents, where the model decides its own steps and which tools to use. The same guidance gives the principle that settles most of these questions: find the simplest solution that works, and add complexity only when it is needed.
What an agent adds is the ability to handle variation: an email that does not follow the template, a request that combines three things, a situation the rules did not anticipate. What it costs is predictability. Its behaviour has to be evaluated rather than simply specified, monitored once it is live, governed with permissions and approvals, and paid for on every run. If the work has little variation, you are paying for a capability you do not use.
Eight signs you should not build one — yet
1. The rules are already known
If someone can write down exactly what should happen — this field, that threshold, this routing — then write it down as a rule or a workflow. Deterministic automation is cheaper, faster, testable line by line, and explainable to an auditor. A model can still help inside it, for one narrow step such as reading a document, without the whole thing becoming an agent.
2. The volume is low
An agent carries fixed costs that do not shrink with use: design, evaluation, integration, monitoring, review. For work that happens a handful of times a month, a good template or checklist, used by the person who already does it, will almost always win.
3. The process has not been designed
If three people describe the same process in three different ways, an agent will learn the confusion and execute it faster. Design the process first. The article Why automation without process design fails covers this pattern in detail.
4. Nobody will own it
Every agent needs a person accountable for its outcome: someone who reviews its exceptions, approves changes to its limits, and decides when it should be paused. If no such person exists, nobody will notice when it drifts. The cost of an unowned workflow explains why ownership comes first.
5. You cannot say what good looks like
If you do not know how the work performs today — how long it takes, how often it goes wrong, what it costs — you cannot tell whether an agent improves it. Without a baseline, every result is an opinion. Measure first; it is often the measurement itself that reveals the real problem.
6. The data is not reachable or not trustworthy
An agent acts on what it can see. If the information it needs lives in people's heads, in five systems that disagree, or behind systems with no way in, the project is an integration project wearing an agent's clothes. The hidden cost of disconnected business systems describes what to fix first.
7. The value depends on acting alone on irreversible decisions
If the business case only works when the agent makes high-stakes, irreversible decisions with no person reviewing them — approving credit, rejecting a claim, changing where money goes — then it does not work yet. Start with the agent preparing the decision and a person making it. In some cases the law decides for you: in the EU, for example, Article 22 of the GDPR restricts decisions based solely on automated processing that have legal or similarly significant effects on people. Check what applies where you operate.
8. The problem is somewhere else
This is the most common one. A team asks for an agent to handle a flood of enquiries, and the enquiries turn out to be caused by something upstream: a confusing page, a missing notification, a product defect, a policy nobody understands. An agent would absorb the symptom indefinitely. Fixing the cause removes the work.
What to build instead
| The request | Often better served by |
|---|---|
| "An agent to route incoming requests" with fixed categories | A form with the right fields and a routing rule |
| "An agent to answer common questions" | A clear page or knowledge article, then measure what is still asked |
| "An agent to watch this metric" | An alert with an owner and a written response |
| "An agent to update records across systems" | An integration, with one system as the source of truth |
| "An agent to do this monthly analysis" | A person with a good assistant, until the analysis is stable |
| "An agent to fix this messy process" | Process design, then automation of the parts that are now clear |
None of these is a failure. Several are the first step towards an agent that will actually work, because they leave behind a clear process, clean data, a baseline and an owner.
The middle ground
The choice is rarely "a fully autonomous agent or nothing". Between them sits a range of options that capture much of the value with less of the risk:
- A single model call inside a fixed workflow — classify this email, extract these fields from this invoice — with the rest of the process defined in code.
- An assistant for a person — drafting replies, summarising cases, preparing a decision — where the person remains the one who acts.
- An agent that only observes — it recommends actions while a person carries them out, which is the first level of the Citadel's trust model and the cheapest way to find out whether an agent would help.
The complete guide to AI agent architecture describes this as a ladder: climb a rung only when the one below fails for a reason you can name.
Oracle note — The most useful number in any agent proposal describes today, not tomorrow: how many, how long, how often wrong, at what cost. When that number is missing, I recommend measuring before building. Half the time the measurement changes the proposal.
When the answer changes
"Not yet" is not "never". The same work becomes a good candidate for an agent when the conditions change, and the signs are concrete:
- the volume has grown to the point where the fixed costs pay back;
- the process is written down, and the exceptions, not the rules, are where the time goes;
- there is a named owner who wants the work to improve;
- the current performance is measured;
- the data the agent needs is reachable from systems that agree;
- there is a place for a person to review what matters.
That list is close to how the Guild describes a good first mission on its use cases page: meaningful volume, clear rules, accessible data and human review.
An example
Illustrative example, not a client engagement.
An online retailer asks for an agent to answer "where is my order?" emails, which take up much of a support team's day. Before anything is built, the team samples a few weeks of these emails and finds that most arrive in the gap between payment and dispatch, because the shop sends no confirmation when an order leaves the warehouse.
The first change is a dispatch email with a tracking link. The volume of questions falls, and what remains is genuinely varied: lost parcels, partial deliveries, address changes. That residue may well justify an agent later, with a clear mission and a baseline to beat. It would have been a poor reason to build one at the start.
A short test
Before commissioning an agent, answer these honestly.
- Could a person write down the rules completely? If yes, consider a workflow first.
- Does the work happen often enough for fixed costs to pay back?
- Is the process designed, and described the same way by everyone who does it?
- Is there a named owner for the outcome?
- Do you know how the work performs today?
- Can the agent reach the data it needs, from systems that agree?
- Can a person review the decisions that matter?
- Have you ruled out an upstream cause that would remove the work altogether?
Two or more "no" answers usually mean the right first project is not an agent. The Guild's own advice on its AI agent development page is to start with the smallest agent that can deliver a meaningful result, and the Guild Assessment exists to show where agents, automation or better systems would pay off first — including, sometimes, that the answer is not an agent at all.
