AI agents don't solve everything: the technical checklist before implementing one

The framework that reached the board, but the decision belongs to architecture

Marcelo Palladino, Director of AI & Modernization and head of Dati Labs at Dati, published an article in Exame, a Brazilian business magazine, this week with three questions every executive should ask before approving budget for an AI agent. Read from the perspective of whoever signs the check, it's a cost-containment piece. Read from the perspective of whoever designs the system, it's something else: an architecture checklist disguised as a board agenda.

My position here is direct. Palladino's three questions are neither original nor revolutionary, any senior architect was already asking two of them before the word "agentic" existed. The framework's value lies in forcing the board to hear, in business language, what the technical team already knew and rarely managed to sell upward.

Question 1: do you need an agent or an if

The framework's first question is: what would happen with a traditional fixed-rules automation? In practice, this means comparing the cost of running a language model on every execution with the cost (near zero, once written) of a deterministic flow.

If the process has clear steps from start to finish, fixed rules win on three fronts: cost per execution, latency, and, most importantly, auditability. An agent that decides its own path on every call produces a different output on every attempt for the same input, which is an advantage in an ambiguous context and a serious problem when compliance asks you to reproduce exactly what happened in a specific case.

Palladino also names the middle ground that many teams already use without a label: a fixed flow that calls a model only at one specific point, to classify an email or extract fields from a document. This isn't an agent, it's a function with an LLM inside, and the difference in cost and risk surface between the two approaches is enormous.

Question 2: is your legacy system idempotent, or has that never been tested

The second question is, in my reading, the one that most exposes old technical debt being collected with interest. An agent talking to a slow legacy system will, at some point, resend a request that didn't get a response in time. If the backend can't identify that the request was already processed, the result is a duplicate charge, a duplicate invoice, a duplicate payment.

The core point here isn't about AI. It's about whether your system has, or doesn't have, an idempotency key (idempotency key) on critical endpoints, something payment teams have been handling for years with standards like Stripe's. The difference is that, before, this failure only showed up during traffic spikes or client retries over a bad connection. With an agent in the middle, it shows up every time the model decides to try again.

If the honest answer is "I don't know if our system handles this," the engineering priority isn't designing the agent. It's instrumenting the legacy system first.

Question 3: does the agent combine the three ingredients of the lethal trifecta

The third question is about security, and it's the one I most recommend taking literally into an architecture meeting. Palladino cites the term coined by independent researcher Simon Willison, known for creating the Django framework: the "lethal trifecta" (in the original English). It describes the combination of three factors in the same agent:

1. Access to the company's private or confidential data.
2. The ability to read untrusted external content (email, web page, a form received from outside).
3. Some channel of communication to the outside, even if it's just loading an image with data embedded in the URL.

When all three coexist in the same agent, a prompt injection attack hidden in an email or a page can instruct the model to leak internal data without anyone noticing in real time. Palladino's answer to this is correct, and it's the same one I'd give: mitigation can't depend on training the team to "be careful." It has to be in the architecture, structurally preventing a single agent from accumulating all three factors at once.

There's a technical detail in the piece that deserves highlighting: if you split the work among several specialized agents to separate the three factors, communication between them needs to be through structured data (JSON, a form, a defined schema), never through free text. Passing free text from one agent to another reopens the door for the same malicious instruction to cross the boundary you just designed.

The counterargument: "but platform guardrails already solve this"

The strongest point against this framework is to say that major agent platforms already offer granular permission layers, sandboxing, and function-calling policies that mitigate the lethal trifecta by default, making manual checking redundant. It's not a weak argument: tools like these reduce the attack surface, and ignoring them would be a step backward.

The problem is that a model guardrail is probabilistic, not deterministic. It reduces the chance of an attack succeeding, it doesn't eliminate it, because it still depends on the model correctly interpreting an adversarial instruction written precisely to fool that interpretation. Architecture that prevents the combination of the three factors in the system's structure is deterministic: there's no version of prompt injection that breaks a permission the agent simply doesn't have.

In short: a platform guardrail is an additional layer, not a substitute for the architecture decision. The two things should coexist, but if the board only funds the first because it's cheaper to explain in a meeting, the real risk hasn't gone down, it's just become invisible.

Where the agent actually pays for itself

Palladino himself is honest about the flip side: processes with non-standardized documents, long contracts, inconsistent invoices, and support that requires judgment about a specific customer history are exactly where fixed rules don't scale and the agent justifies its higher cost per execution.

The practical difference for whoever builds this is that this context isn't rare, but it also isn't the majority of processes at a typical company. The mistake the framework helps avoid isn't using agents, it's using an agent as the default answer for any ticket that mentions automation, without first running the three questions through the architecture that already exists.