What makes AI agents special? Customisation, memory, tools and flexibility

A regular customer sends your business a WhatsApp message:

Please send the usual order to the Westlands branch on Thursday. Use the back entrance this time—the front road is being repaired.

A normal chatbot can produce a warm reply. It may even include an emoji that nobody requested. But it does not necessarily know what “the usual order” means, whether the customer has two branches, what was delivered last time, whether Thursday is available or who may approve the order.

An AI agent can be designed to retrieve the customer's approved history, identify the likely order, check stock and delivery capacity, ask only for the missing detail, prepare the order and pause for confirmation before recording it.

If the customer returns tomorrow, the agent may also retrieve the open conversation and delivery note rather than greeting them as if they have never met.

That sounds like memory and initiative. It is—but not in the human sense.

The agent has no private recollection of traffic in Westlands. The application stored information and supplied the relevant part again. It did not “understand your business” through prolonged exposure to the office kitchen. Somebody chose its instructions, knowledge, tools, permissions and stopping points.

That composition is what makes an agent special. Not the title digital employee, and certainly not the animated sparkle beside the send button.

The executive answer

• A chatbot mainly produces a response; an agent can choose among approved steps and tools to pursue a goal.
• Customisation gives the agent a specific role, rules, knowledge, output format, permissions and escalation path.
• Memory is application-managed information stored and brought back into later work. It can be useful, incomplete, outdated or wrong.
• Tools let an agent retrieve records and invoke business services; permissions determine how much damage a mistake could cause.
• Flexibility is valuable when the path varies. Stable work often remains better as ordinary software or a fixed workflow.
• Important limits should live in deterministic rules, not in a polite instruction that the agent may interpret.
• Evaluate the business outcome and the changed records, not only whether the final paragraph sounds sensible.
• Begin with read or prepare access. Earn the right to act through evidence.

An AI agent is best understood as a model operating inside a designed system. The design is the product.

Chatbot, workflow and agent: who chooses the path?

The word agent is used generously. Sometimes it means a chatbot with a name. Sometimes it means software that can plan several steps, use tools and alter records. Management cannot govern a label, so let us separate the useful patterns.

Anthropic's engineering guidance makes a similar distinction between workflows, where code defines the path, and agents, where a model dynamically directs its process and tool use. It also recommends beginning with the simplest approach that works because agents exchange some predictability, cost and speed for flexibility.

That trade-off matters. A payroll calculation with known rules does not become better because a model may take an imaginative route through it. A fixed workflow is not less advanced when the work is fixed. It is simply honest about the road.

I think of it this way:

A railway timetable does not need an AI driver. Give the agent journeys where the road may be blocked—not jobs where every turn is already known.

THE FAMILIAR STARTING POINT

Helpful writing becomes grounded work.

WRITING ASSISTANT

DRAFT REPLY

Make this warmer and more concise.

UsesThe words and context it was given

→

CONNECTED AGENT

CustomerOrderPolicyDeliveryChecked reply

UsesAuthorised, current business records

The seven parts of a useful agent

OpenAI's business guide to agents describes agents as systems that plan, decide and act toward a goal within guardrails. In implementation, the names differ across platforms, but a useful business agent usually combines these parts:

1. A model to interpret language, reason over the available context and choose a next step.
2. Instructions describing the role, job, rules and boundaries.
3. Knowledge from approved documents, databases and business systems.
4. Tools that can search, calculate, retrieve, create a draft or call another service.
5. State or memory carrying relevant context through a task or across later interactions.
6. Controls for permissions, validation, approvals, escalation and logging.
7. Evaluation to determine whether the work actually reached the intended outcome.

Remove the tools and the system may only talk about work. Remove the knowledge and it may apply general answers where the business needs a current fact. Remove controls and “flexibility” becomes a generous word for uncertainty with system access.

THE SHARED FOUNDATION

Useful agents are more than a chat box.

01ChannelsEmail · meeting · WhatsApp · schedule

02PermissionsOnly the records this job needs

03Systems of recordCRM · ERP · policies · reports

04AgentUnderstands, retrieves and prepares

05Business rulesWhat may happen and what must stop

06Human checkpointJudgement, exceptions and approval

07Action logWhat was checked, decided and changed

Customisation is more than giving the agent a personality

An agent can sound formal, cheerful or reassuring. Tone is useful, especially in customer work, but it is the least consequential part of customisation.

The real customisation is operational.

Role and goal

“You are a helpful assistant” is too broad. A useful role might be:

Help authorised sales staff prepare repeat orders from approved customer, product, stock and delivery records. Do not confirm an order until the customer has reviewed the complete summary.

The role says who the agent serves, what outcome it prepares and where it must stop.

Business definitions

Words such as available, approved, late, active customer and usual order need company definitions.

Does available stock exclude reserved units? Does usual order mean the most recent order or the most frequent combination in 90 days? Does Thursday mean dispatch day or arrival day? These definitions are not prompt decoration. They determine whether the answer is useful.

Knowledge and sources

The agent needs approved sources and a rule for conflicts. Customer details may come from the CRM, stock from the ERP, delivery capacity from the dispatch system and product restrictions from a current policy.

The agent should show where important facts came from and say when a required source could not be checked. A confident guess is not a backup integration.

This is why organisational knowledge management in the age of AI deserves management attention. Connecting an agent to three conflicting policies gives the contradiction better conversational skills; it does not resolve it.

Tools and permissions

An agent does not need every available tool. It needs the smallest set required for the job.

For the repeat-order example, the first version may be allowed to:

• find a customer by an approved identifier;
• read recent completed orders;
• read current product, stock and delivery information;
• prepare a proposed order summary; and
• create a draft task for a salesperson.

It does not yet need permission to apply discounts, alter credit limits, confirm orders or message every customer in the CRM. Those would be separate capabilities with separate controls.

Output contract

Do not leave every response as unlimited prose. Define the information shape:

Likely repeat order
- Customer and branch
- Products, quantities and current prices
- Stock status
- Proposed delivery date
- Difference from the previous order
- Missing information
- Sources and time checked
- Required approval

Structured output is easier for a person to inspect and easier for software to validate. Prose can explain an exception; it should not hide the order quantity in paragraph five.

Escalation and stopping rules

Customisation also tells the agent what it must refuse, pause or hand over:

• customer identity is ambiguous;
• the requested item does not match an approved product;
• stock or price cannot be verified;
• the customer asks for a credit or policy exception;
• two records conflict; or
• the requested action exceeds the user's authority.

The most professional agent is not the one that completes every task. It is the one that knows which tasks it has not earned the right to complete.

What “memory” really means

When people say an agent remembers, three different things may be happening.

Working context

During one task, the agent keeps the messages, records and tool results needed for the next step. It remembers that the customer said Westlands branch because that information is still part of the active task.

Session history

The application stores a conversation or case and loads the relevant history when work continues later. Current agent frameworks describe sessions in exactly this practical way: conversation history is stored and reintroduced on later turns.

Longer-term stored facts

The application may store selected information outside the conversation: a customer's approved delivery preference, an unresolved complaint, a user's reporting format or a lesson accepted into a knowledge base. Later, a retrieval process decides whether that information is relevant.

The mental model I would use is not a colleague remembering your preferences over tea. It is a filing cabinet the software knows how to reopen.

That filing cabinet creates management questions:

• What is worth storing?
• Who can see it?
• Where did it come from?
• How can the person correct it?
• When does it expire?
• What happens when a newer fact contradicts it?
• Should this information have been stored at all?

Research systems such as Generative Agents use external records, retrieval and generated reflections to simulate longer-lived behaviour. Benchmarks such as LongMemEval test whether systems can retrieve details across sessions, reason about time, handle updated information and know when an answer is absent. The existence of these benchmarks is itself a useful warning: long-term memory remains a system-design and evaluation problem, not a human quality we can safely assume.

Memory can fail in several ways. The right fact may not be stored. Retrieval may choose the wrong fact. An old preference may survive after the customer changes it. An untrusted message may attempt to insert a harmful instruction. A summary may remove the detail that mattered.

For consequential information, store the source and date, give it an owner or correction route, apply retention rules and distinguish a reported preference from an approved business fact.

Tools are where conversation becomes work

Tools let an agent cross the gap between saying and doing. A tool may search a document store, query an ERP, calculate a delivery estimate, prepare a file, create a service ticket or call a business API.

The ReAct research showed how language models can interleave reasoning with actions in an external environment, use observations from tools and update their next step. That loop is central to agent flexibility:

Understand the request
→ choose an approved tool
→ inspect the result
→ decide what is still missing
→ use another tool or ask a question
→ prepare the outcome
→ stop, approve or hand over

Consider the repeat order. The agent looks up the customer and finds two branches. Instead of guessing, it asks which branch. It retrieves the last Westlands order, but one product is discontinued. It searches for the approved replacement, checks stock, discovers that Thursday delivery is full and offers Friday. The path changed because the information changed.

A rigid flow would need every branch of that conversation anticipated in advance. An agent can handle some variation by choosing among approved capabilities.

This is the source of the value—and much of the risk.

Flexibility should live inside hard boundaries

An instruction such as “Never give a discount above ten per cent” is helpful context. A deterministic rule that rejects a discount above ten per cent is a control.

Use the model for work that benefits from interpretation:

• understanding an untidy customer request;
• deciding which approved record to inspect next;
• comparing evidence;
• drafting an explanation; and
• recognising that the case does not fit the normal path.

Use ordinary software and explicit approval for hard constraints:

• maximum discount or payment amount;
• required fields;
• identity and role checks;
• stock not falling below an agreed threshold;
• prohibited products, recipients or actions;
• manager approval above a limit; and
• a complete audit record.

A deterministic rule still enforces the maximum discount even if the agent has spent the afternoon feeling unusually generous.

The strongest business systems are often hybrids. Code controls the non-negotiable gate. The model handles the variable conversation and preparation around it. A person judges the exceptional or consequential case.

The permission ladder: earn the right to act

I would separate agent capability into five levels.

Each level needs evidence before moving up. A good demonstration at level one does not prove readiness for level five.

For approval to be meaningful, the reviewer needs the important facts, differences, sources and consequence—not a green button attached to a 14-page transcript. The agent should preserve state while waiting, then resume only the approved action. Human approval is not a ceremonial pause; it is a decision boundary.

For the management framework behind those levels, read what an AI agent should be allowed to do inside an ERP or CRM.

Flexibility creates new security problems

A connected agent may read emails, documents, websites or messages containing instructions written by other people. A malicious or compromised source can attempt to tell the agent to ignore its real job, reveal information or misuse a tool. This is commonly called indirect prompt injection.

OpenAI's prompt-injection guidance describes why agents working across untrusted content and consequential actions need layered safeguards. The UK's National Cyber Security Centre similarly recommends careful adoption of agentic AI, including small initial scopes, least privilege and meaningful human control.

No single sentence in the system prompt solves this. Reduce the possible consequence:

• give tools the minimum access required;
• separate untrusted content from trusted instructions;
• validate tool inputs and outputs;
• require approval before sensitive actions;
• avoid giving one agent a convenient chain from private data to public communication;
• log what was read, decided and changed; and
• have a clear stop and recovery path.

The question is not only “How likely is the agent to make a mistake?” It is also “What can one mistake reach?”

When an agent is the wrong choice

Do not use an agent merely because the software proposal becomes more exciting when the diagram contains a glowing circle.

A fixed workflow or ordinary application may be better when:

• inputs and steps are stable;
• the output must be exactly reproducible;
• a rule engine can express the decision clearly;
• the process is safety-critical and model discretion adds no value;
• latency or variable model cost is unacceptable; or
• the organisation cannot yet provide reliable data, permissions and ownership.

An AI assistant may be enough when the user needs drafting, explanation or navigation and no tools or persistent state are necessary.

An agent becomes interesting when all three are true:

1. the work has a worthwhile business outcome;
2. the path varies enough to benefit from model judgement; and
3. the organisation can bound, observe and evaluate the discretion it gives.

Evaluate the outcome, not the confidence

Agent demonstrations are persuasive because we naturally watch the final response. A polished answer, however, can hide an incorrect record change. An awkward answer can accompany a correctly completed task.

Anthropic's guide to evaluating AI agents recommends inspecting both what happened during the run and the resulting state of the environment. It also highlights repeated trials because agents may take different paths across runs.

For the repeat-order agent, measure:

• correct customer and branch identification;
• correct products, quantities, prices and availability;
• missing information detected before preparation;
• inappropriate actions blocked;
• approvals requested at the right time;
• order records matching the approved summary;
• handovers containing enough context for a person; and
• time and correction effort compared with the current process.

Include normal cases, messy cases and hostile inputs. Test duplicate customer names, a stale preference, a discontinued item, a conflicting price, unavailable stock, a request outside the user's role and an untrusted document telling the agent to ignore its rules.

If the team only checks whether the customer reply sounds friendly, it has evaluated the wrapping paper and left the order unopened.

A sensible first pilot

Begin with one narrow job in a process the team understands. I would prefer a read-and-prepare use case where the source and expected outcome can be checked.

For example:

When an existing wholesale customer requests a repeat order through an approved channel, prepare an order summary from current customer, product, stock and delivery records. Ask for missing details and require a salesperson to approve before recording anything.

Then:

1. define repeat order, available stock and the approval boundary;
2. identify the authoritative records and their owners;
3. give the agent only read tools and a draft output at first;
4. collect past cases and create difficult test cases;
5. inspect tool calls, sources, decisions, output and final records;
6. run with a small authorised group;
7. measure corrections, time, blocked errors and completed useful work; and
8. expand permission only when the evidence supports it.

The purpose of the pilot is not to prove that agents are the future. It is to learn whether this agent improves this work under these controls.

Special does not mean human

AI agents are special because they bring several useful capabilities together. They can interpret an imperfect request, retrieve the right context, choose among approved tools, carry state across steps, adapt when the situation changes and prepare or perform a bounded action.

Those capabilities can make software feel less like a form and more like a capable interface to the business. They can also make the system less predictable than a fixed workflow.

The responsible compromise is not to remove flexibility. It is to place flexibility where it earns its keep, surround it with hard boundaries and measure what happened after the prose ended.

So when somebody proposes an AI agent, ask five questions before admiring its name:

1. What goal is it pursuing?
2. Which knowledge and tools may it use?
3. What does it store, and for how long?
4. Which decisions are fixed by rules or people?
5. How will we know the business outcome is correct?

Clear answers make an agent more useful. Vague answers do not make it more intelligent; they merely give the demo more room to improvise.

For the management architecture behind connected agents, read why the chatbot is not the strategy. For four concrete business patterns, continue with practical AI agents your business may need.

Research and helpful links

• Read OpenAI's business leader guide to working with agents
• Read Anthropic's distinction between workflows and agents
• Review the ReAct research on reasoning and acting with external tools
• Explore the Generative Agents memory architecture
• Review LongMemEval's evaluation of long-term interactive memory
• Read OpenAI's guidance on prompt injection in agents
• Review the NCSC's advice on adopting agentic AI carefully
• Read Anthropic's guide to evaluating AI agents

Research checked on 28 August 2026. Agent capabilities, platform features and security guidance continue to change. This article provides strategic and operational guidance, not a guarantee that a particular deployment is safe or suitable.