Alessandro Pieraccini

Hi and thank for this sharing. I think that Bare metal here depends a lot on how much you actually keep it busy. If the agent works in bursts and then sits idle for hours, you’re still paying for that GPU. I’d start by comparing the actual monthly cost of bare metal with APIs at different usage levels. Including prompt caching, max_steps, retries that don’t keep firing forever... if you can remove some of the waste from the loops, I imagine the gap can narrow quite a bit. Good Work!

Hi and thank for this article. With a dashboard, you can still see part of the path. We know which filters and dimensions have been applied; just from the way the data behaves, we might notice that after a join the rows have doubled and the revenue no longer adds up. With an agent, you could ask why sales have dropped and get the answer directly. In between, it may have run several queries and joins, pulled a metric from the semantic layer... but we don’t see that part. That is what leaves me more doubtful about agentic self-service BI. I would keep at least the executed queries and the definition of the metric accessible. Also the source the data came from, when needed. Otherwise, when the number does not add up, reconstructing what happened becomes quite complicated.

Thank for sharing this article. What convinces me most is exactly this: some rules should not be entrusted to the agent. If Claude Code must not read ~/.kube or touch certain directories, I would rather have the operating system prevent it than hope a policy in the prompt is always respected. A prompt injection or a misinterpreted command is enough to change the problem quite a bit. Here, sandboxing almost seems more important than the model itself.

The point I find most interesting is that, beyond a certain level of complexity, the problem stops being only about context management and becomes a state management problem. If the operational state lives inside the prompt, retries and handoffs can introduce errors that are difficult to detect. For long-running workflows, I think it is more robust to separate working context, a persistent state store and an audit log, using idempotency keys and versioning to avoid duplicated side effects and context drift.

Hi and congratulations on this article. It covers many aspects of Agentic AI and I think I will have to read it a few more times to fully understand it. I still haven’t managed to get rid of my doubts around prompt injection. Putting that aside, I also still need to understand how the cost of using these systems will actually be structured. Does it still make sense to talk about cost per token, or should we start talking about cost per outcome? And even if we accept that, should we then separate the cost between successful outcomes and retry cost? Thanks again for the article, I’ll definitely read it again more carefully over the next few days!

Thank you for the article, very interesting especially because it brings the topic of Agentic AI outside the demo and into a context where an error can have real economic consequences. Linking the agent's autonomy and automation to actions for which an error is reversible also through rollback or human in the loop is actually an intelligent way to manage this process. For example, it makes me think of dynamics related to autonomous driving, which over the years has had to deal with errors and responsibilities and still hides some legal grey areas. Off topic aside, retrieving through APIs and deterministic tools elements that should not be interpreted and the ground truth is equally important. Actually, progressively increasing autonomy while reducing the possibility and consequences of errors seems like an oxymoron, but by reasoning element by element and introducing guardrails we can gradually get closer to it. Congratulations again and thank you for the article

Grazie per la condivisione, mi è piaciuto molto il taglio dell’articolo. La parte che trovo più interessante è che più autonomia diamo agli agenti, più il problema diventa capire fin dove possiamo davvero lasciarli agire. La microVM aiuta, ma poi restano permessi, rete, secret, rollback e soprattutto la possibilità di capire cosa è successo quando qualcosa va storto. Credo che la difficoltà con gli agenti sarà proprio riuscire a farli lavorare senza perdere il controllo del processo.

Hi, and thank you for this great article. The passage about the risk of turning every action into a confirmation is correct and particularly challenging. If the agent has to ask permission for everything, the system does not differ in any way from a “click-by-click” model, and maybe it would not even make sense. Equally complex is understanding how to design thresholds, rollback and history well, therefore thinking not only about what AI can do, but also about how to make it possible to recover when it makes a mistake.

Hi and thank you for the great article, I find it very interesting. I really liked the passage where the agent takes on a real identity class. In fact, when an element of a system has the ability to write, RBAC, least privilege and immutable audit trails become essential elements of the architecture. By now we have started to live with the fact that these systems sometimes get tripped up by very simple things and since their autonomy is growing (and I don’t think this trend will reverse in the future), it becomes necessary to reconstruct precisely who authorized each action, what was modified and with what result.

Thank you for the article, very accurate and above all easy to understand. I think the real step forward happens when we stop considering SQL and Python as separate tools and start thinking about where it makes sense to process the data and where instead it makes sense to move it. For example, filtering and aggregating correctly on the database side before bringing everything into Python can make the analysis much more efficient, especially as datasets start to grow. So, to really take advantage of the synergy between these tools, I believe we need to understand how to build a sensible and sustainable data flow, in addition to knowing the correct syntax (which is obviously absolutely fundamental).