Most "AI assistants" for business are a language model with a friendly prompt. They sound helpful until you ask for something real: the status of my order, the price of this repair, whether you have this part. Then they guess. A useful agent does the opposite: it looks things up.
The core idea: tools, not guesses
An agent becomes useful when the model can call tools that talk to your actual systems: find an order, check stock, read the calendar, draft a reminder. The model decides which tool to use and explains the result. The facts come from your data, not from the model's memory.
customer asks ? model picks a tool ? tool reads real data ? model explains itSix rules I design every agent around
- Read from live data. Prices, stock, statuses and dates come from a tool result. If a tool cannot answer, the agent says so.
- Least privilege. The agent gets only the permissions of the person it serves. A customer's agent can see that customer's order, nothing else. Different jobs get different tools.
- Confirm what matters. Anything that moves money, deletes data or sends a message on someone's behalf waits for an explicit yes. The approval is part of the system, not a polite request in the prompt.
- Log every action. What was asked, which tool ran, what it returned. When something looks wrong you can see exactly why.
- Keep a human nearby. A person can take over any live conversation, and the agent knows when to hand over.
- Fail politely. If the model is slow or a tool is down, the visitor sees a clear message, not a stack trace or a made-up answer.
One agent or a team
A single agent with a dozen tools works for small jobs. As soon as the tasks differ (looking up work, researching a business, drafting a message), a small team is cleaner: a coordinator that only delegates, and specialists that each hold a narrow set of tools. It is easier to test, and a specialist that cannot send an email cannot be tricked into sending one. The agents on this site work that way, and you can try the sample ones on the Agents page.
Where it goes wrong
- Giving the agent write access "for convenience" and discovering the consequence later.
- Trusting text from outside (a web page, an email) as if it were an instruction.
- Skipping evaluation because the demo looked good.
I cover the last two in separate articles on testing agents and on prompt injection. The principle underneath all of it: an agent should be as constrained as a good employee in their first month, trusted with more only as it earns it.
Mubashir HussainForward deployed engineer