What changes for anyone with an app or system
The short answer: your system is going to be used by something that isn't a person. An AI agent doesn't click buttons the way a person does. It calls functions, reads data and triggers actions, and it can only do that if your system offers an organized path for it.
In practice, systems with clear rules, a well-designed API and permissions separated by role are ready to receive agents. Systems where business rules are scattered across the screen, side spreadsheets and one employee's head are not. The agent will go wrong precisely where the rule was never written down.
You don't need to build an agent tomorrow. You need to avoid decisions today that make it impossible or dangerous later.
Why the topic heated up now
In recent weeks, Google announced that it is turning Gemini into an agent capable of planning, carrying out tasks and working across apps and company systems, starting with the enterprise market. The proposal includes delegating work to sub-agents and even giving the agent its own identity in the workplace, with an email address.
Almost at the same time, Microsoft launched new security features aimed at agents, including one that monitors the agents a company uses. Its messaging treats AI agents as something like an insider threat, because they have access and autonomy and don't always behave as expected.
Read the two moves together. Big companies are pushing agents into the workplace and, in the same breath, selling controls for them. That is a message for anyone building systems: the hard part isn't getting the agent to act, it's being able to limit and audit what it does.
Five things to get ready in your system
None of these is new in software engineering. The difference is that, with agents, the cost of not having done them goes up considerably.
If you are commissioning a new system, ask for each item in the scope. If you already have a system, use this list as a diagnostic.
- An API with clear operations: create order, cancel, check balance. Each operation with a defined name, input and output, not just screens that someone learned to use.
- Business rules on the server, not on the screen: discount limits, cancellation deadlines and maximum refund amounts must be validated on the back end, because the agent doesn't go through the screen.
- Permissions by role, with granularity: read separated from write, and write separated from sensitive actions such as paying, deleting and sending messages to customers.
- An audit log that says who did what: user, agent, time, data before and after. Without it, you find out about the error when a customer complains.
- A human confirmation point: irreversible or high-value actions go into an approval queue instead of running directly.
Treat the agent like a new employee, not a superuser
The most common mistake is giving the agent the master key because it's faster. A single credential with access to everything, pasted into a configuration file. It works in the demo and becomes a risk in the first week of real use.
The healthier path is to create a separate identity for the agent, with minimal permissions, as if it were an intern on their first day. It reads orders but doesn't change prices. It suggests a refund but doesn't approve it. When it needs more access, you grant it deliberately.
This matches what the market is signaling: if even the companies that make agents talk about identity and monitoring, it's because the models have erred enough that nobody trusts them blindly. Language models can misread an instruction, or be tricked by malicious text inside an email or document they read. That's why the rule has to be enforced on the server, not in the prompt.
Common mistakes when putting an agent to work
The first is starting with the most critical process. Start with something low-risk and high-volume: ticket triage, draft replies, customer record checks. If it gets something wrong, the cost is small and you learn how it behaves.
The second is not measuring. Before turning the agent on, define what a good result looks like: time per task, human correction rate, tasks that came back. Without that, opinion turns into team mood.
The third is thinking the agent replaces process design. If the manual flow is already confusing, the agent automates the confusion at higher speed. Map the process first, simplify it, and only then automate.
The fourth is ignoring the recurring cost. Each agent task consumes calls to a model, and agents that take several steps consume more. Ask for an estimate per task, not just the price of building the solution.
When an agent isn't worth it
My take: a good share of the cases where someone asks for an agent are better solved with ordinary automation. If the flow is always the same (order arrives, invoice is generated, customer is notified), deterministic code is cheaper, faster and predictable. An agent makes sense when there is real variation: free-form text, exceptions, decisions that depend on context.
Another sign that it's not time yet: you don't have organized data. An agent working on duplicate records and incomplete history only delivers wrong answers with a lot of confidence.
And if your problem is validating whether people would use the app, agents are not the first step. First you test the core flow with real users.
How to test the idea before spending on it
Before commissioning an AI integration, sketch the flow in a clickable prototype and see where the agent would come in: on which screen, with which permission, with which confirmation. That exercise alone reveals half of the rule and permission problems, without writing the back end.
At SKAD, the AI-generated prototype costs R$ 99 and comes with a rough estimate. It lets you see the app working and discuss these points with the team before deciding what is worth developing.
Frequently asked questions
What is an AI agent in an app?
It is an AI program that receives a goal, decides the steps and carries out actions in the system, such as querying data, creating records or sending messages. A chatbot only answers; an agent also acts.
Do I need to rebuild my system to use AI agents?
Not always. If it already has an organized API, server-side rules, role-based permissions and an audit log, you can integrate an agent gradually. If it doesn't, those adjustments come first.
Are AI agents safe?
It depends on how you limit their access. The risk drops when the agent has its own identity, minimal permissions, sensitive actions that require human approval and everything recorded in a log.
AI agent or ordinary automation: which should I choose?
If the process is always the same, ordinary automation works better and costs less. An agent pays off when there is free-form text, exceptions and decisions that change depending on context.
Conclusion
Before talking to any agent vendor, do a one-hour exercise: list five actions someone takes in your system today and, for each one, write down who can perform it, what limit exists and where it is recorded. Wherever an answer is missing, that is the work to do first. Then pick a single low-risk task for the first agent and measure the result for a few weeks before expanding.