When the Agent Stops Advising
Imagine a marketing manager asking her AI agent to re-engage customers whose subscriptions are about to expire, while excluding those who have already opened a ticket. The agent identifies the target audience, crafts the message, and schedules the send. Meanwhile, in a development team, another agent receives a request, modifies the code, and generates the associated tests. In both cases, a natural-language intention becomes an action inside the information system. The agent must access data, understand business rules, and use tools equipped with actual permissions. Here, a mistake no longer yields a vague reply; it can reach the wrong customer, expose confidential information, or introduce a regression.
Autonomy overreach, poorly protected non-human identities, and a lack of logging are fully part of the risks of agentic applications. It is essential to inventory the agents, limit their permissions, and log their actions.
One question remains: what must the agent know to distinguish a meaningful action from a merely possible one?
Give Context Before Granting Rights
An agent does not understand your organization. It interprets what its instructions and its tools reveal to it. That is why, before acting, it must know the objective, the applicable rules, the exceptions, the technical constraints, and the expected level of trust.
In our above marketing scenario, a renewal date alone is not enough. You must also consider consent, ongoing incidents, customer value, and channel-specific rules. On the development side, the request must be tied to architecture, coding conventions, dependencies, security requirements, and acceptance criteria.
The quality of the action depends on the quality of the context. Outdated data or rules known only to a single expert undermine the whole.
You should also specify what the agent should do if it is in doubt. Should it stop, seek validation, or choose the least risky option? This threshold shapes the governance of data access.
Activating Data Without Losing Campaign Control
In customer engagement, the promise of agentic capabilities hinges heavily on the continuity between knowledge and activation. A unified data set that is inaccessible at decision time is of limited use. Conversely, instant activation based on poorly governed data can “industrialize” the error.
A customer engagement platform must bring together identity, history, consents, audiences, and channels. A typical “Customer Engagement Platform” such as imagino precisely offers an environment capable of centralizing data and activating it in real time. Its AI “Imogen” orchestrates audiences, journeys, content, and optimization from a business intent. With Imogen, this evolution can turn a marketing intention into concrete actions.
Arthur Lacroix, Head of Product Marketing at imagino, shares, “Until now, marketing teams had to navigate multiple tools to segment, analyze, or launch campaigns. Now they can simply express a business intent. But for that promise to become reality, the AI agents must imperatively access reliable, governed, and real-time activatable data.”
Of course, this access must remain bounded. The agent may propose an audience and a scenario, while a manager validates the send. For a recurring campaign, the company may allow it to act alone within a defined envelope: permitted segments, maximum frequency, open channels, and budget threshold. Each decision must remain traceable, with the ability to interrupt the journey.
The same principle applies to code, though cancellation takes a different form, with rollback, removal of a version, or deactivation of a feature. Hence the need to prepare the technical framework before accelerating production.
Bringing Agents into a Controlled Development Chain
One priority stands out: prepare the development chain for the arrival of AI agents. They need architecture decisions, conventions, documentation, and security rules. Without this context, an agent may deliver a functional modification while bypassing a standard, duplicating logic, or adding a brittle dependency.
The consulting and service company Inside reminds us that agents can already generate code, produce test scenarios, and control certain deliverables. Its Digital Hub advocates Software Craftsmanship, maintainability, and automated testing. These practices make outputs verifiable.
“With AI, the point of friction in software delivery shifts. Producing code faster is not enough: you must give agents the right context, integrate their interventions into a controlled development chain, and maintain clear human accountability. Practices of Software Craftsmanship, automated testing, and code review become essential to delivering reliable, secure software capable of evolving over time.” explains Mathieu Defianas, Head of the Digital Hub Excellence Center at Inside.
Practically, the agent can prepare a branch, run tests, and document its intervention without having permission to deploy to production. A reversible modification can be automatically merged if checks pass. A change in authentication, data model, or payment must remain subject to human review. This distinction cannot depend on momentary intuition; it must become a shared policy across business units, IT, security, and legal teams.
Building a Gradation of Autonomy
Of course, not all actions warrant the same level of control. You can indeed automatically authorize actions that are frequent, low-risk, observable, and easily reversible (for example, exploratory segmentation, drafting, or opening a code branch).
Next come actions that require validation. They have external effects or alter a shared asset: launching a campaign, merging code, updating a pricing, or changing a workflow. The agent prepares and estimates consequences, while a human picks the final decision.
Some operations must remain human when they strongly affect the business, touch sensitive data, or are hard to undo. OWASP even recommends human approval for privileged operations and logging of decisions, tool calls, and results. This supervision reserves human intervention for decisive points.
Also, autonomy depends on a perimeter, a technical identity, a budget, an execution time, and a rollback right. The more explicit these limits are, the faster the agent can act within its domain.
Before expanding its permissions, verify four elements: does it understand the context, does it use reliable data, are its actions observable, and can you undo them? This is the sine qua non condition to turning your agents’ autonomy into controlled operational capability.
Content provided by Cloudlist, the information hub for the IT sector
