Understand what you are calling an AI agent
An AI agent can choose steps and use tools to advance a task within limits defined by the system. A conventional workflow follows a more predictable sequence. Before buying or building, ask to see the concrete decisions involved: the name used in a presentation tells you less than the behaviour you can observe.
Imagine an assistant consulting information about a request and preparing a response. If it simply fills a message template after receiving known fields, much of the work can follow rules. If it decides which sources to consult, compares information and chooses a tool, you need to understand that autonomy and its stopping conditions.
The distinction between workflows and agents described by Anthropic is a useful technical reference. In my business assessment, I add a practical question: which freedom genuinely improves the result of this task? That makes it possible to discuss the design without assuming greater autonomy automatically creates greater value.
In Sextas Ímpares #151, about advertising management in the AI era, I showed a tool built with AI that executes rules. This Portuguese-language class helps explain why I separate how a system is built from how it operates once it is running in the business.
Choose a task with observable boundaries
An agent’s first task should have an understandable objective, identified information and a result someone can evaluate. Define what stays outside its scope: commercial decisions, data changes or external messages may require authorisation. A clear scope makes it easier to see whether the agent is helping or simply generating more activity.
One possible example is preparing a sales meeting brief from information the business is authorised to use. The agent consults relevant records, organises needs and highlights open questions. The person leading the meeting checks the brief and decides what to do with the information it contains.
In that example, I would not automatically allow the agent to send proposals, change terms or contact third parties. Those actions have different consequences from preparing notes. They may become part of another process, but need their own criteria. Combining everything in the first version makes benefits and errors harder to understand.
The page on sales automation with AI develops the journey between request, assignment and follow-up. The article on qualifying B2B opportunities with AI provides another context for preparing information. In both situations, the quality of the decision continues to depend on understanding the business and the person making contact.
Provide only the access the task requires
An agent’s access should match the actions needed for its task, separating consultation, proposals and executed changes. Check which data each tool can reach and who authorises permission changes. Instructions written to the model should be supported by effective limits in the integrations and on the server where actions are handled.
If the agent prepares a report, access to aggregated data may be sufficient. It does not need an entire contact database or permission to delete records. That choice reduces unnecessary information and makes reviewing what was used more straightforward. The same reasoning applies to files, accounts and external tools.
It also matters to separate the customers or teams using the system. Authorisation must be checked before data reaches the model. Asking an agent to ignore another company’s information still leaves that information in its context. I prefer the system to select only the records that the current session is allowed to consult.
The page on security for AI-built applications explains the rules I use for access, identifiers and secrets. They are criteria for reviewing the complete product. A model adds decisions that require observation, while the application’s access controls still need to work independently of what the model says.
Treat documents and messages as information to verify
An agent reading documents, pages or messages receives content that may be wrong or may try to influence its behaviour. That information should not gain authority to change permissions or system instructions. Preserve its origin, limit available actions and require confirmation when the result could affect people or change important data.
Imagine a document mixing commercial information with a sentence asking for every contact to be sent to another address. That sentence belongs to the incoming document. The system should prevent it becoming permission to send data, regardless of whether the model finds it convincing or relevant to the task.
Malicious instructions in external content, known as prompt injection, are among the topics covered by the OWASP project on language-model applications. The practical question for a business manager is which tools could cause consequences if the model misinterpreted an input and tried to act on it.
When reviewing a response, I want to return to the information supporting it. A summary can identify the document and distinguish recorded facts from open questions. That makes correction possible without relying on the model to explain its behaviour afterwards, since that later explanation can also be incomplete or inaccurate.
Test decisions, stopping behaviour and execution costs
Evaluating an agent means observing whether it chooses suitable steps, respects boundaries and stops when it cannot proceed safely. Include incomplete tasks and unexpected tool responses. Measure review effort and the cost of the complete execution as well, because a useful answer may involve several attempts and information requests before it is ready.
I would prepare examples with sufficient information, another with contradictory data and a request outside the agreed scope. In the first, I expect a supported result. In the second, I want the contradiction identified. In the third, the system should explain that it cannot perform the task and refer it to the responsible person.
It is useful to limit the number of steps and prevent loops that repeat the same search. When the agent reaches a limit, it should preserve the state needed for review. A process that keeps trying indefinitely becomes difficult to operate and can consume resources without adding information useful to the decision.
Compare the agent with a simpler alternative and with the team’s current work. The article on using AI beyond the chatbot helps explore possibilities. The final choice should consider the specific task, the quality required and who will supervise the system after the trial ends.
Prepare the move from a trial to daily work
Moving an agent into daily use requires an owner, useful records and a way to interrupt or correct actions. Confirm how changes to instructions, tools and models are approved. Monitoring should reveal changes in behaviour and support recovery when an integration or a decision stops working as the team expects it to.
An apparently small change can alter how sources are selected or requests classified. Keep reference examples and evaluate them again after changes. If the team repeatedly corrects the same problem, that information should reach the person maintaining the project, accompanied by enough context to reproduce the situation and review the cause.
I do not promise that an agent replaces an entire role. I want to understand the specific work it can take on and the conditions required to do it well. That discussion belongs in AI consulting for businesses, connecting technical possibilities with organisation, data and responsibility for delivery.
To assess an implementation, present the task to the SpartAds team. If you prefer to learn and discuss decisions in your own project, explore AI and business mentoring. Bring examples of the current work: they support a much more concrete discussion about how much autonomy the system should have.