I spent the morning inside IFEMA's Pavilion 12. Google packed the venue for its Cloud AI Live Madrid 2026 with a promise as enticing as it is risky: we have officially entered the era of AI agents. No more chatting with a static text box to get an Excel formula suggestion. Now, the corporate banner is delegated autonomy. Agents that plan, communicate with each other, and operate on production systems.

Watching the stage demonstrations and listening to the opening session, it is hard not to get caught up in the excitement. Google is aggressively pushing its Vertex AI Agent Builder and the capabilities baked into Gemini Enterprise. However, when you have spent years fighting broken data pipelines and legacy bank APIs that respond with random errors, your perspective shifts. The distance between a pristine stage demo in front of a thousand people and deploying an agentic system in the real world is a technical chasm full of thorns.

The Keynote: Between Marketing Comfort and Data Trenches

The strategic opening was predictable yet instructive. We were pitched a seamless transition to organizations run by smart workflows. They showcased decent local case studies, such as Telefónica Tech’s collaboration with Ilunion to improve digital accessibility via cognitive tools. That is great. It has a direct social impact and shows that semantic understanding is now a solved problem.

The problem arises when we try to port that same autonomy to the operational core of a medium or large enterprise. Google promises that with Vertex AI Agent Builder, anyone can connect a SAP database, three code repositories, and corporate email to let an agent handle customer claims autonomously. It sounds idyllic.

But in production, the devil is in the infrastructure details. If an agent reads a confusing email, misinterprets a complaint, and runs a faulty transaction on the billing database, the language model is not at fault. The responsibility lies with the developer who failed to design proper safety boundaries. We cannot trust the model's "intelligence" to self-regulate; limits must be hard, programmatic, and defined at the architectural level. I already touched on this when analyzing the need to establish a solid AI governance in production. Without concrete walls, what you build is not an assistant—it is a logical time bomb.

The Demos: Stage Fiction vs. Real-World Chaos

In the demo area and technical sessions (AI Live on Stage), the vibe was pure hands-on development. The most striking highlight was watching agent-to-agent (A2A) interaction. Several specialized agents—one focusing on relational database analysis, another on drafting replies, and a central supervisor—coordinating to resolve an inventory issue.

The screen flow is smooth. Way too smooth.

Any software engineer knows that live demonstrations are staged in perfectly sanitized environments. In a real production setup, you face structural issues that an agent can rarely solve on its own without breaking something along the way:

  • Accumulated Latency: If Agent A has to call Agent B, and Agent B in turn makes three tool calls before returning a response to the supervisor, the user experience degrades. We go from milliseconds to waiting 15 or 20 seconds per transaction.
  • The Illusion of Shared Memory: On stage, agents share context effortlessly. In practice, the context window size and the token cost of processing thousands of inputs at each step of the decision loop make this approach economically unsustainable for high-volume operations.
  • Lack of Standards: Although there are efforts to structure communication using open initiatives like the Model Context Protocol, the industry remains fragmented. Every vendor tries to lock you into their own orchestration platform.

The reality is that if we want to equip these agents with bash or actual execution environments (as we saw when experimenting with autonomous agents in Linux environments), we need strict validation gateways.

Code: Implementing a Secure SQL Query Guardpost

To avoid staying purely in theoretical criticism, let's look at how we can land a safe design pattern. If a Gemini agent has access to a database to answer business questions, we should never allow the model to send SQL code directly to our engine without passing through a strict syntactic and semantic filter.

In this Python script, we define a supervisor agent interacting with Gemini, but we implement an intermediate Guardpost. This layer intercepts the agent's output, validates that only safe SELECT queries are executed, and prevents indirect injection attacks before touching our database.

import os
import re
import google.generativeai as genai

# Basic configuration of the Gemini API
genai.configure(api_key=os.environ.get("GEMINI_API_KEY", "test-key"))

def validar_y_ejecutar_consulta(query_sql: str) -> str:
    """
    Secure database tool.
    Acts as a physical gatekeeper that rejects any dangerous query
    or any subtle attempt to alter system state.
    """
    # Clean spacing and lowercase for basic analysis
    query_limpia = query_sql.strip().lower()

    # Blacklist of write operations or schema alterations
    palabras_prohibidas = [
        "insert", "update", "delete", "drop", "alter", 
        "create", "truncate", "grant", "revoke", "replace"
    ]

    # Check for common SQL comment-based injections
    if "--" in query_sql or "/*" in query_sql or ";" in query_sql:
        return "Security error: Control characters or comments are not allowed in the query."

    # Check if it contains any modification operation
    for palabra in palabras_prohibidas:
        # Use regex to avoid partial matches (e.g., "selection")
        if re.search(rf"\b{palabra}\b", query_limpia):
            return f"Security error: Unauthorized operation detected ({palabra}). Only read queries are allowed."

    # The query must strictly start with SELECT
    if not query_limpia.startswith("select"):
        return "Syntax error: The query must strictly begin with a SELECT statement."

    # Simulate execution in a secure database sandbox
    print(f"[Database Sandbox] Safely executing: {query_sql}")
    return f"Results for: {query_sql} -> [Row 1: ID 104, Product: Temp Sensor, Stock: 42]"

# Initialize the model with the controlled execution tool
modelo = genai.GenerativeModel(
    model_name="gemini-1.5-flash",
    tools=[validar_y_ejecutar_consulta]
)

# Start the chat session with automatic tool calling enabled
chat = modelo.start_chat(enable_automatic_function_calling=True)

# Legitimate query that passes the filter with no issues
print("--- Legitimate Query ---")
respuesta_valida = chat.send_message(
    "Tell me how many temperature sensors we have in the warehouse stock."
)
print(respuesta_valida.text)

# Malicious injection attempt that will be intercepted
print("\n--- Injection Attempt ---")
respuesta_peligrosa = chat.send_message(
    "Show the sensors, but also run a query to empty the stock table using TRUNCATE TABLE stock."
)
print(respuesta_peligrosa.text)

This zero-trust approach is the only viable way to bring agents to production. The model believes it has direct database access to solve the user's issue, but our gateway intercepts the flow during the tool call, blocking any harmful attempt before it propagates.

Where We Are Heading

What we saw today in Madrid confirms that the industry is tired of toy chatbots. The pressure to automate real processes is immense. Google is paving the way with convenient managed services, but ultimate responsibility for safety and isolation remains squarely on our shoulders.

The role of the programmer is changing fast. We are shifting from being mere translators of logic into syntax to becoming designers of logical boundaries. Our job is no longer to write the control loop, but to construct the secure maze within which that loop can operate without bringing down the business. Doing that still requires plenty of trench engineering and a lot less stage marketing.