Map the automation before naming the agent

The mistake

It is tempting to start an AI agent project by naming the agent and writing a big prompt. That is usually too early. The useful work is the workflow around the agent: what it reads, what it can change, who approves risky actions, and what happens when it is unsure.

For small businesses, this mistake is expensive because the first demo can look impressive while the everyday system underneath it is still weak. The agent can summarise an email, draft a reply, or generate a task list, but if nobody has defined where the email comes from, how tasks are stored, and what counts as a risky reply, the business has not really gained a working system.

That is why the first question should not be "what should the agent be called?" It should be "which repeated job is wasting enough time to deserve a safer loop?"

The better starting point

Map the current process like a machine. Find the repeated steps, the judgement calls, the handoffs, the tools involved, and the places where the business still needs a person in control.

The map does not need to be pretty. A plain list is enough:

• What triggers the work?
• Where does the information come from?
• What does a person check before acting?
• Which tools are updated at the end?
• What could go wrong if the system is too confident?
• Who needs to approve the risky cases?

This turns an AI agent from a personality into a process. It also reveals when you do not need an agent at all. Some jobs are better solved by a normal automation: move a file, send a reminder, create a row, rename an attachment, or copy data between tools. AI is useful when the task needs language, classification, summarisation, judgement, or messy input handling. It is not automatically useful just because the task is boring.

What to document before prompts

Prompts matter, but they should sit inside a clearer operating model. Before a prompt is written, write down the permissions and the failure paths.

Inputs are the first part. An agent reading from a shared inbox needs different rules from one reading a form, a spreadsheet, a CRM export, or a booking system. The source decides how stale the information can be, how mistakes are traced, and whether the agent is allowed to act immediately.

Actions are the second part. Drafting is low risk. Sending, deleting, publishing, refunding, cancelling, or changing customer records is higher risk. Those actions need approval, limits, or a clear rollback path. In many first versions, the best agent does not press the final button. It prepares the work so a human can approve it quickly.

Memory is the third part. A useful agent may need project context, customer preferences, product details, or previous decisions. That does not mean every conversation should be stored forever. Decide what gets remembered, where it lives, who can inspect it, and how wrong information gets corrected.

Escalation is the fourth part. If the input is incomplete, the answer is uncertain, or the requested action is outside the rules, the agent needs a boring, reliable handoff. "Ask Saby to check this" is sometimes a better feature than another thousand words of prompt.

The first slice

The first useful version should do one job clearly. It can draft, triage, summarise, score, hand off, or prepare work for approval. After that small loop is stable, the agent can earn more responsibility.

Good first slices are narrow enough to test in the real business within a week. Examples include:

• Read new project enquiries and produce a scored summary for review.
• Turn customer support emails into suggested replies and internal notes.
• Summarise form submissions and create draft tasks in the existing system.
• Check whether a website page has the basic AI-search signals in place.
• Review a weekly spreadsheet export and flag only the unusual rows.

Each of those slices has an input, a decision, an output, and a human review point. That makes the work measurable. You can compare the agent output against what a person would have done and decide whether the system is ready for more.

How to tell if the project is ready

An AI agent project is ready to build when the business can describe the job without using the word "agent". If the plain-English workflow makes sense, the agent can be fitted into it. If the workflow is still vague, a big prompt will only hide the vagueness for a while.

The safest route is usually automation first, agent second. Build the rails: intake, logging, permissions, review, and fallback. Then let the agent operate inside those rails. That is less flashy than naming the assistant on day one, but it is the difference between a demo and a system people can trust during a busy week.

Related capability

AI Agents

Custom agents that can answer, triage, draft, retrieve, and act inside real business workflows.