DEV Community: David San Nicolás Montero

the evolution of software development since the emergence of AI | The AI is a positive or negative event for software developers?

David San Nicolás Montero — Fri, 09 Oct 2026 10:05:59 +0000

It would be interesting to promote discussions on the evolution of software development since the emergence of AI, and how it has been transforming the sector and the jobs of many developers. In my experience, it's not advisable to swim against the current, so it would also be valuable to create a dedicated section to discuss and build technical AI applications that can boost our productivity and allow us to create more complex, useful developments that non-technical users cannot achieve.

Do you think the emergence of AI is a positive or negative event for software developers?

THE "BRAIN IN A JAR": WHY AI CANNOT EXECUTE CODE AND HOW TO ORCHESTRATE IT

David San Nicolás Montero — Thu, 08 Oct 2026 18:38:12 +0000

The Origins: From BASIC to Robotics

How did you first get into software development, and what originally attracted you to programming and building software?

The day I discovered programming was in my childhood. My father brought me the computer I had been begging for months to get: a cassette-tape Spectrum 128k. At that time, the internet didn't exist yet, so the "computer" (a keyboard that plugged into my CRT television) came with a book that taught you how to program in BASIC—an obsolete language where I learned to write if-then statements in English. Video games took 45 minutes to load, so eventually, I found it more entertaining to just program.

I wrote my first real successful project at age 15 in HTML. It was the website for my father's company. It was a massive success because there were hardly any websites back then, and not everyone had internet at home. Since the budget for that project was zero, I decided to turn my PC into a web server and host the site using my noisy dial-up modem.

With an overwhelming passion for technology, I studied to become an electronics developer. Since I am old, I had the fortune—or misfortune—of learning to program firmware in Assembly language, which over the years has given me the ability to understand memory and data flow at all levels.

When did you first become seriously interested in AI and LLMs, and what made you want to explore them beyond simply using AI chatbots?

After years of adventures dedicated to electronics, I one day decided to focus on robotics. I've spent the last 10 years in this sector integrating firmware, software, and, in recent years, artificial intelligence for self-diagnostic processes.

The field of knowledge in robotics is so broad (mechanics, electronics, firmware, software, multiple communication networks, and even AI) that rarely does a single person have the capacity to accumulate all that knowledge. My first prototypes using AI APIs were dedicated to automating breakdown prevention processes. They were complete integrations of electronics and software using a physical trigger to analyze an image of certain robot parts, which reduced preventive maintenance hours.

It was precisely this level of physical interaction and complex problem-solving that made me want to go beyond chatbots: discovering that AI could be integrated into the real world to execute actions.

The Genesis of Zyro Workspace and AutomaticIA

Your profile says you built an autonomous AI colleague because you hated manually formatting Google Slides and copying data into Drive. Can you tell us about that experience?

More than two years ago, some colleagues at my company proposed that I join the workers' legal representation to negotiate improvements with the management. The workers voted for me, and I started my new adventure as a union representative.

I discovered that we were spending a lot of energy advising colleagues and answering the same questions over and over again. So, I decided to program a chatbot with a RAG (Retrieval-Augmented Generation) database so that colleagues could ask questions anonymously, allowing me to dedicate my time to preparing for negotiations. This simple chatbot reached the hands of someone in the union's industrial federation, and shortly after, they offered me an office to help them optimize work processes using AI.

It was from this perspective that I understood the pain points of an administrative office and a law firm, and for them, I designed the first version of Zyro Assistant. They work within the Google ecosystem, so I thought about designing an agent that would connect directly to Google Workspace and execute certain tasks for me, without me ever having to touch the keyboard.

What motivated you to start AutomaticIA, and what are you ultimately trying to build with it?

AutomaticIA is not my first business venture. Fifteen years ago, I founded SGS Automatismos e Ingeniería, my small electronics engineering company, which today continues to operate in the hands of one of my partners. About three years ago, I decided to buy a small driving school business—a highly profitable venture outside the tech sphere.

Simultaneously with the process optimization I was carrying out at the industrial federation, I implemented automation projects within my own companies, saving many hours of work and making them highly profitable. By deeply analyzing the real economic value that my automation projects provided, I decided to venture into creating AutomaticIA to meet the digitalization needs of Spanish companies.

My ultimate goal with this project is to democratize access to advanced business technology by offering artificial intelligence consulting and the development of custom autonomous agents. We want to be the bridge that covers companies' digitalization needs, transforming traditional workflows into efficient systems where AI takes on the heavy administrative burden.

What is Zyro Workspace, and what problem are you trying to solve with this open-source Node.js SDK?

The first version of Zyro Assistant was built entirely—both backend and frontend—inside Google Drive using a Google Apps Script. For several months, I analyzed common bottlenecks across all departments in the federation. After building specific apps for various departments, I realized I could work on a universal tool that would increase overall productivity across the entire federation simultaneously.

Zyro Workspace is the result of over two years of work, testing, and solving bottlenecks in law firms and administrative departments. I noticed a pattern: although Google provided useful productivity tools in their corporate accounts, almost no one used them. They required a learning curve, and workers are simply too busy to stop, test, and learn new software.

Zyro Assistant solves this by integrating with all the tools in the Google ecosystem using only voice commands. You just tell Zyro what you need, and it guides you. As I integrated more functions, I decided to break through the limits of Apps Script and build a much more robust, complete version on Google Cloud. I developed an independent multi-agent PBX (telephone switchboard) software and integrated it with Zyro, making it the first autonomous, multi-functional agent capable of making real phone calls. Today, Zyro is used as the central orchestrator to interact with other custom-built applications for clients.

The Engineering Behind the Agent

What makes an AI agent fundamentally different from a traditional chatbot? When does an AI system actually become autonomous?

A chatbot only answers questions; an agent is given tools to carry out specific tasks. A chatbot has a single AI layer, whereas an agent capable of being truly autonomous and error-free has multiple layers of agents and skills managed by an orchestrator that interacts with the user.

From my experience in process optimization, total autonomy is a major point of friction. Today, most people are still not psychologically prepared to let an AI do a job that a person previously did autonomously. That is why it's crucial to carefully study which of the agent's processes will be autonomous and which will need confirmation.

In Zyro Assistant, we have given it many layers of background functions that gather information from its environment to give it the ability to be proactive and learn how its user works. The main rule is that it only has full autonomy in creative tasks—like generating a report before a meeting by analyzing the agenda, email interactions, and transcripts. However, it never has autonomy in destructive tasks, such as deleting an event or a document.

Why did you choose Node.js and JavaScript as the foundation for your work with autonomous AI agents?

The initial choice was a matter of pragmatism. Since Zyro's first prototype was born inside Google Apps Script (which runs on JavaScript's V8 engine), migrating to Google Cloud and Firebase made Node.js the path of least friction.

However, as the architecture grew more complex, I discovered Node.js offered unbeatable technical advantages for orchestrating AI in production. The current paradigm of autonomous agents is based on Function Calling. The LLM reasons and returns its execution intents in structured JSON formats. In Node.js, JSON is a first-class citizen. Parsing, validating, mutating, and routing the model's structured responses is an organic, fast process that avoids strict serialization overhead.

An AI agent is a massive orchestrator of input/output (I/O). When Zyro executes a mission, it is calling the Gemini API, searching Google Drive, scheduling in Calendar, and simultaneously waiting for an asynchronous webhook from our PBX after a call ends. The non-blocking Event Loop in Node.js is architecturally perfect for handling these concurrent waits without choking the server's processing resources.

What do developers often misunderstand about LLM Function Calling, and why is it so important?

The biggest misunderstanding is believing that the Artificial Intelligence is executing the code. There is a false illusion that by giving a tool to the LLM, the model magically "connects" to Google Calendar or an email API.

The technical reality is that the model is like a "brain in a jar": completely isolated from the outside world. All Function Calling does is apply an Inversion of Control. The model executes nothing; it simply reasons about which tool it needs to use and returns a structured JSON payload. It is you, in your middleware, who must intercept that JSON, validate security, execute the actual code, and return the result to the model.

The second huge mistake is trusting the JSON schema blindly. In production, AI hallucinates parameters, invents database IDs that don't exist, or tries to execute tools in the wrong order. If you don't design a robust backend capable of intercepting those errors, returning the stack trace to the model, and forcing a silent retry—a self-healing system—your agent will constantly break.

Trust, Security, and Event-Driven Architecture

Your profile mentions Inversion of Control (IoC) architectures. How does IoC influence the way you design autonomous agents?

It shifts the security paradigm: we go from "trusting the AI" to "trusting the infrastructure." When you design an autonomous agent for a B2B corporate environment, companies' biggest fear is that the AI will hallucinate and delete confidential files. If you don't apply Inversion of Control, your only defense is writing rules in the System Prompt, which is incredibly fragile and vulnerable to prompt injection.

IoC allowed me to decouple the AI's "intent" from the actual "authorization." Since the Node.js middleware executes the action, we always inject the native OAuth2 token of the user operating the agent. The AI never holds master admin keys. Because the AI doesn't execute code directly, IoC also allows me to protect the user from parameter hallucinations. If the LLM makes a mistake formatting a date, my server intercepts that crash, feeds the raw error back to the AI in the background, and asks it to rectify. The user is completely unaware that an internal failure occurred.

Autonomous agents can take actions on behalf of users. How do you handle permissions and prevent an agent from taking an action it shouldn't?

Security is managed on the server through the principle of native token delegation (Zero-Retention). The AI doesn't know who you are or what permissions you hold. When it decides it needs to read a document, the backend intercepts that intent and executes the API call using the active user's OAuth token. If the human employee doesn't have corporate permission to view that document, neither does the AI.

For critical or destructive actions, we enforce a strict Human-in-the-Loop protocol mandated by the backend. The model can reason and propose deleting an event, but the middleware pauses the process and pushes that intent to the GUI for manual approval.

How do events change the way an autonomous agent operates compared with a traditional request-and-response application?

It completely changes the nature of the software: you go from having a "digital slave" that waits for your orders to having an "asynchronous coworker."

A classic Request-Response architecture is inherently synchronous and linear. But when you orchestrate complex API calls, RAG tools, and LLMs, a process can take 15 or 30 seconds. Keeping an HTTP connection open and blocking the user is not scalable. Migrating to an event-driven architecture in Node.js allowed me to implement true asynchrony.

For example, when I ask Zyro to call a client, the system doesn't block waiting for the person to pick up, talk, and hang up. Instead, Zyro dispatches the mission to the PBX and "goes to sleep," freeing up resources. When the physical call ends 5 minutes later, the PBX fires an asynchronous Webhook to our backend. That event "wakes up" Zyro, injects the call transcript into its context, and the agent proactively generates a summary notification. The agent is subscribed to reality, not just user clicks.

You also mention exploring ways of bypassing virtual DOMs for custom RPA extensions. What problem are you trying to solve?

Our idea is to take the agent out of the isolated UI and give Zyro "eyes and hands" so it can guide the user in their daily work across other websites. We leave DOM tree analysis as an absolute last resort due to the massive amount of AI tokens it can consume. Instead, our primary approach uses Computer Vision models. We capture an image of the screen of the user's active tab and pass it to the AI. The model visually analyzes the interface and returns the precise (X,Y) coordinates of where interaction is needed. From there, our extension dispatches real mouse events to those coordinates, effectively bypassing Virtual DOM blockers in modern frameworks.

The Reality of AI in Production

What has been the hardest part of turning your ideas about autonomous AI agents into a real open-source project?

Without a doubt, the hardest and most time-consuming part has been the paradigm shift in debugging. Anyone can integrate the Gemini or OpenAI API over a weekend and claim they've built an "agent." But making that agent handle dozens of simultaneous functions securely, without hallucinations, and with a near-zero error rate in production—that is the true architectural challenge.

*The three toughest technical barriers have been:

Debugging Non-Deterministic Systems: With LLMs, failure is statistical. Debugging forces you to build layers upon layers of validation in Node.js to encapsulate an unpredictable engine within a strictly deterministic environment.
Cognitive Overload and "Prompt Gravity": As I gave Zyro more skills, the model started confusing tools because of the context size. I had to investigate advanced context injection techniques (like Tail-end Overrides) to inject absolute reminders milliseconds before execution.
Designing Self-Healing: Achieving a minimal error rate forced me to design recursion loops in the backend. If the AI fails to execute a tool, the server intercepts the crash and feeds it back to the AI to correct its own hallucination in milliseconds, utilizing a circuit breaker pattern to prevent infinite loops.*

Looking ahead, where do you see autonomous AI agents heading in the next few years?

AI agents already possess the technical capability for total autonomy. As AI models advance exponentially, it is inevitable that agents will completely take over any job performed on a computer. When that time comes, our job will be to perform the only task AI cannot innately do: imagine, structure architectures, and have brilliant ideas for the AI to implement.

For Zyro Assistant, my medium-term vision is for it to become the foundation and orchestrator of a complete ecosystem of AI applications for all types of administrative management: ERP, CRM, OMS, BI, CPM, and BPM. AutomaticIA will serve as the consulting and distribution arm. We are developing a proprietary platform covering ERP, CRM, and BI, all connected and orchestrated natively by Zyro, featuring a universal database import program to eliminate vendor lock-in.

Finally, what advice would you give to a developer who wants to start building autonomous AI agents today?

Ground the weight of any AI project on solid software architecture. A very common mistake is placing AI at the structural base of the system. If you build on top of that, your project will be incredibly inefficient and will collapse very quickly. Build a robust traditional software foundation first, and use AI as an attached "engine," never as the foundation.

I would also advise having a clear understanding of the physical limits of the model you are using: its context window, inference speed, and token consumption. If you don't learn to strictly manage the amount of context you inject into the model, your system will be agonizingly slow and extremely expensive to maintain. Poorly calibrated tokens can cause a context window overflow, triggering hallucinations and cascading errors. Memory footprint management in complex agents must always be an absolute priority.

Construyendo el Sistema Nervioso de la IA: Node.js, Inversión de Control y el verdadero reto de los Agentes Autónomos

David San Nicolás Montero — Thu, 08 Oct 2026 08:33:50 +0000

Hoy en día todo el mundo afirma estar construyendo "Agentes de IA". Desde una perspectiva de ingeniería, ¿dónde está la frontera real entre un chatbot avanzado y un agente autónomo?

La frontera anatómica exacta es el Function Calling orquestado mediante Inversión de Control. Un chatbot, por muy avanzado que sea, es solo un generador estático de texto; te da las instrucciones para que tú hagas el trabajo.

El error más común de los desarrolladores junior es creer que al darle herramientas al LLM, el modelo "se conecta" a las APIs. La realidad técnica es que el modelo vive como un cerebro en un frasco, aislado del mundo. El modelo no ejecuta nada; simplemente razona y devuelve un JSON estructurado con una intención. La autonomía real nace cuando construyes un middleware robusto capaz de interceptar ese JSON, validar los permisos en el servidor, ejecutar la llamada a la API y devolverle el resultado al modelo en segundo plano. Cuando el agente asume la carga cognitiva y física de forma asíncrona, es cuando aporta valor económico real.

Hablas de Inversión de Control (IoC). ¿Por qué es tan crítica esta arquitectura cuando implementamos IA en entornos corporativos B2B?

Porque cambia el paradigma de seguridad: pasamos de "confiar en la IA" a "confiar en la infraestructura".

Si diseñas un agente sin IoC, tu única defensa contra las alucinaciones o la inyección de prompts es rogarle al modelo en el System Prompt que no borre archivos importantes. Eso es inaceptable en producción. Bajo el patrón de IoC, desvinculo la "intención" del modelo de la "autorización" real. Como es mi backend en Node.js el que ejecuta la acción, siempre inyectamos el token OAuth2 nativo del usuario de forma estricta (Zero-Retention).

Si la IA alucina y pide leer una carpeta financiera a la que ese empleado no tiene acceso, la API lo rechaza. El modelo puede intentar lo que quiera; es la infraestructura la que impone las barreras físicas deterministas.

Has elegido Node.js como el núcleo de tu orquestador, a pesar de que Python es el "rey" indiscutible de la IA. ¿Por qué esta decisión?

Python es imbatible para entrenar modelos y procesar datos, pero para construir el "sistema nervioso" de un agente en el mundo real, Node.js tiene ventajas insuperables.

Un agente autónomo orquestador se pasa la vida esperando. Cuando Zyro ejecuta una misión compleja, hace peticiones al LLM, busca en bases de datos vectoriales y puede quedarse esperando un webhook de nuestra centralita telefónica tras finalizar una llamada. El Event Loop no bloqueante de Node.js maneja esta asincronía masiva de forma natural sin asfixiar el servidor.

Pasar de una arquitectura síncrona de Request-Response a una orientada a eventos permite que el agente libere el hilo principal, trabaje en segundo plano y reaccione proactivamente a la realidad (la llegada de un correo o el fin de una llamada). Además, Node.js respira JSON de forma nativa, lo cual es vital cuando toda la comunicación con el LLM mediante Function Calling requiere parseo y validación constante.

Mencionar RPA (Robotic Process Automation) con IA es un tema candente, pero te has encontrado con el problema del "Virtual DOM". ¿Cómo lo habéis resuelto?

Ese fue uno de los mayores dolores de cabeza. La realidad corporativa exige interactuar con sistemas legacy y CRMs de terceros sin APIs. Al intentar manipular el DOM nativo mediante scripts, fallábamos constantemente porque frameworks modernos como React o Vue ignoraban los cambios si su estado interno (Virtual DOM) no se actualizaba.

Enviar el árbol del DOM completo al LLM para que analice selectores era ineficiente y consumía demasiados tokens. La solución fue un enfoque multimodal basado en Computer Vision. En lugar de inyectar código en el subyacente, capturamos visualmente la pantalla activa y el modelo nos devuelve las coordenadas (X, Y) precisas de interacción. Luego, despachamos eventos de ratón reales sobre esas coordenadas. Hemos convertido al agente en un usuario físico, saltándonos por completo los bloqueos de los frameworks frontend.

¿Cuál dirías que es el reto de ingeniería más subestimado al construir este tipo de sistemas?

Depurar sistemas no deterministas. En el software tradicional, si algo falla, tienes un stack trace exacto. Con los LLMs, el fallo es estadístico. A veces el JSON es perfecto, y otras veces el modelo alucina un parámetro o se inventa un ID de base de datos.

Esto te obliga a diseñar sistemas de Self-Healing (auto-recuperación) en el backend. Si el LLM se equivoca, nuestro middleware intercepta ese "crash" antes de que llegue al frontend. Ocultamos el error al usuario, se lo devolvemos crudo a la IA en segundo plano y forzamos un reintento milisegundos después para que corrija su propio JSON. Y, por supuesto, esto requiere implementar circuit breakers estrictos para evitar bucles infinitos que devoren tu cuota de tokens.

¿Qué consejo le darías a un Arquitecto de Software que va a empezar a construir agentes autónomos hoy?

Que el éxito de un proyecto de Inteligencia Artificial casi no trata sobre Inteligencia Artificial; trata de ingeniería de software tradicional llevada al extremo.

El error más común es poner al LLM como los cimientos del proyecto. Si haces eso, tu sistema se derrumbará. Construye primero una arquitectura determinista, un middleware extremadamente robusto, y acopla la IA únicamente como un motor secundario.

Y, sobre todo, obsesiónate con la gestión del contexto. Conoce los límites físicos de los tokens y desarrolla técnicas (como Tail-end Overrides) para inyectar recordatorios absolutos antes de la ejecución. Si no optimizas la huella de memoria en cada ciclo, tu agente será lento, inestable y económicamente inviable de mantener en producción.

From Chatbots to Autonomous Agents: The Real Architecture of AI in Production

David San Nicolás Montero — Tue, 06 Oct 2026 22:18:29 +0000

Anyone can integrate the Gemini or OpenAI API over a weekend, give it a couple of basic tools, and upload a YouTube video claiming they've built an "autonomous agent." But making that agent handle dozens of simultaneous functions in a corporate environment securely, without hallucinations, and with a near-zero error rate is an entirely different architectural challenge.

Through my experience developing Zyro Workspace and founding AutomaticIA, I've learned the hard way that building successful Artificial Intelligence software, ironically, is hardly about Artificial Intelligence. It's about traditional software engineering taken to the extreme.

If you are thinking about integrating AI into your projects, here are the architectural lessons that separate a "digital slave" from a true "asynchronous coworker."

The Function Calling Illusion (The Brain in a Jar) The biggest misunderstanding when developers start using Function Calling is believing that the AI is executing the code. There is a false illusion that the model magically connects to Google Calendar or a database.

The technical reality is that the model is like a "brain in a jar": it is completely isolated from the outside world. All Function Calling does is apply an Inversion of Control (IoC). The model executes nothing; it simply reasons about which tool it needs and returns a JSON payload. It is you, in your middleware (in our case, Node.js), who must intercept that JSON, validate security, execute the actual code, and return the result to the model.

Inversion of Control (IoC): Trust the Infrastructure, Not the AI When you design a B2B agent, companies' biggest fear is that the AI will hallucinate and delete confidential files. If your only defense is writing rules in the System Prompt like "do not delete important documents," you have an incredibly fragile system.

The paradigm shift is moving from "trusting the AI" to "trusting the infrastructure":

Zero-Retention (Native Delegation): We decouple "intent" from "authorization." The backend executes actions by injecting the active user's native OAuth2 token. If the AI hallucinates and asks to read a confidential folder that the employee doesn't have access to, the API simply rejects it. The infrastructure enforces the physical boundaries.
Human-in-the-Loop: For destructive actions (like sending a mass email or deleting an event), the server intercepts the intent, pauses execution, and forces the user to confirm the action in the UI. The model doesn't even know it has been paused.

Event-Driven: From Digital Slave to Asynchronous Coworker A classic Request-Response architecture blocks the user with a loading icon. This is acceptable for a simple chatbot, but when you orchestrate LLM queries, RAG, and complex API calls, the process can take seconds or minutes.

By migrating to an event-driven architecture (leveraging Node.js's non-blocking Event Loop), we achieve true asynchrony. For instance, if you ask Zyro to call a client, the agent dispatches the mission to our PBX (telephone switchboard) and "goes to sleep," freeing the main thread. When the physical call ends minutes later, the PBX fires an asynchronous Webhook, "wakes up" Zyro, injects the transcript, and the agent proactively decides to send a follow-up email. The agent is subscribed to reality.

The Real Challenge: Debugging and Self-Healing In traditional software, if the code fails, you get an exact stack trace. With LLMs, the failure is statistical. Sometimes the AI invents a non-existent ID or hallucinates a parameter due to context weight.

To operate in production, you need to design Self-Healing recursion loops in the backend. If the AI fails to execute a tool, the server intercepts the crash, hides the error from the user, and feeds it back to the AI in the background, forcing it to correct its own hallucination in a matter of milliseconds. (All this, of course, protected by a circuit breaker pattern or watchdog to prevent infinite loops and burning through your tokens).

The Ultimate Advice for New AI Developers
If you are going to build an agent today, ground the weight of the project on solid software architecture. Placing AI at the structural base of a project will cause it to collapse quickly. Build a robust traditional software foundation first, and use AI as an attached engine, never as the foundation.

And above all: master your context footprint management. If you don't learn to strictly manage the amount of information you inject into the model, you will cause context window overflows. The model will forget its initial instructions, unleashing a cascade of hallucinations and errors. Optimizing prompts and calibrating tokens isn't a luxury; it's a matter of survival in production.

Cómo construir una IA que genera presentaciones de Google Slides autónomamente en Node.js

David San Nicolás Montero — Sat, 26 Sep 2026 08:29:25 +0000

Los Modelos de Lenguaje (LLMs) son increíbles redactando propuestas comerciales, pero se estrellan cuando intentas que le den formato corporativo a ese texto. La mayoría de tutoriales te enseñan a generar texto en la terminal, pero en el mundo B2B real, los usuarios no leen terminales: leen presentaciones corporativas, PDFs y hojas de cálculo.

Hoy vamos a construir un puente entre la Inteligencia Artificial Zyro y Google Workspace. Te enseñaré cómo crear un skill (habilidad) en Node.js que permite a un agente inteligente orquestar la API de Google Slides para generar presentaciones completas desde cero, aplicando tu plantilla corporativa.

Para no reinventar la rueda con la gestión de webhooks, esquemas OpenAPI y el enrutamiento de la IA, utilizaremos el Zyro Skills SDK, una librería open-source diseñada para inyectar herramientas personalizadas en agentes autónomos de forma segura mediante Function Calling.

El concepto: Inversión de Control y Memoria Descentralizada

En lugar de darle a la IA las llaves de tu Google Cloud (un riesgo de seguridad enorme), utilizaremos un patrón descentralizado. La IA decide qué contenido debe ir en la presentación, pero es nuestro servidor Node.js quien ejecuta el cómo. Además, el SDK de Zyro gestiona automáticamente un session_id anónimo, permitiendo que nuestro skill mantenga su propia base de datos (memoria descentralizada) sin sobrecargar el contexto del LLM.

Requisitos Previos

Node.js instalado.
Una Service Account de Google Cloud con la API de Google Slides y Google Drive habilitadas.
El ID de una presentación de Google Slides que servirá como "Plantilla Maestra" corporativa.

Paso 1: Configuración del Proyecto

Iniciamos nuestro proyecto e instalamos el SDK junto con la librería oficial de Google:

npm init -y
npm install express cors googleapis dotenv

Paso 2: Inicializar el SDK de Zyro

Creamos nuestro archivo index.js. Aquí instanciamos la clase principal ZyroSkill, que levantará un servidor Express configurado para escuchar al orquestador de la IA.

const { ZyroSkill } = require('./src/index'); // Ajusta la ruta a tu SDK
const { google } = require('googleapis');

// 1. Inicializar el SDK
const slidesSkill = new ZyroSkill({
    name: "Generador de Presentaciones Corporativas",
    description: "Permite al orquestador clonar plantillas de Google Slides e inyectar contenido dinámico generado por la IA.",
    port: process.env.PORT || 3000
});

Paso 3: Registrar la Acción para Google Slides

Utilizamos el método registerAction de tu SDK. Aquí definimos el esquema JSON que la IA debe respetar al enviarnos los datos, y la función asíncrona que ejecutará la clonación del documento en Google Drive.


// 2. Definir Acción: Crear Presentación
slidesSkill.registerAction(
'generar_google_slides',
'Genera una presentación comercial en Google Slides a partir del nombre del cliente y los textos clave.',
{
type: 'object',
properties: {
clientName: {
type: 'string',
description: 'Nombre de la empresa cliente para el título del archivo'
},
diapositivas: {
type: 'array',
description: 'Lista de textos a inyectar en las diapositivas',
items: { type: 'string' }
}
},
required: ['clientName', 'diapositivas']
},
async (parameters, context) => {
const { session_id } = context;
const { clientName, diapositivas } = parameters;
// 3. Autenticación silenciosa con Google Service Account
    const auth = new google.auth.GoogleAuth({
        keyFile: './google-credentials.json',
        scopes: [
            '[https://www.googleapis.com/auth/presentations](https://www.googleapis.com/auth/presentations)', 
            '[https://www.googleapis.com/auth/drive](https://www.googleapis.com/auth/drive)'
        ]
    });

    const drive = google.drive({ version: 'v3', auth });
    const slides = google.slides({ version: 'v1', auth });
try {
console.log([Sesión: ${session_id}] Generando propuesta para: ${clientName});

        // 4. Clonar la Plantilla Maestra en Drive
        const copyResponse = await drive.files.copy({
            fileId: process.env.TEMPLATE_ID,
            requestBody: { name: `Propuesta Comercial - ${clientName}` }
        });

        const newPresentationId = copyResponse.data.id;

        // 5. Dar permisos para que cualquiera con el enlace pueda editar
        await drive.permissions.create({
            fileId: newPresentationId,
            requestBody: {
                role: 'writer',
                type: 'anyone'
            }
        });
// 6. Preparar las sustituciones de texto para Slides
const requests = [
{
replaceAllText: {
containsText: { text: '{{CLIENTE}}', matchCase: true },
replaceText: clientName
}
}
];

        // Añadimos un reemplazo automático por cada elemento del array
        diapositivas.forEach((texto, index) => {
            requests.push({
                replaceAllText: {
                    containsText: { text: `{{TEXTO_${index + 1}}}`, matchCase: true },
                    replaceText: texto
                }
            });
        });

        // 7. Inyectar los textos generados por la IA en la presentación
        await slides.presentations.batchUpdate({
            presentationId: newPresentationId,
            requestBody: { requests }
        });

        // 8. Devolver el resultado limpio al Orquestador
            return {
                mensaje: 'Presentación clonada y generada correctamente.',
                url_documento: 'https://docs.google.com/presentation/d/' + newPresentationId + '/edit'
            };

        } catch (error) {
            console.error('Error en API de Google:', error);
            throw new Error('Fallo al generar la presentación: ' + error.message);
        }
    }
);

// Arrancamos el servidor de Skills
slidesSkill.start();