Asistente de Inteligencia Artificial para Odoo 19

1.Cómo usar este manual

Una guía completa para quien va a configurar el asistente, para quien lo va a usar a diario y para quien tiene que responder por lo que la inteligencia artificial hace dentro del ERP.

Este manual documenta el módulo MRDC AI Base (mrdc_ai_base), que integra modelos de lenguaje de OpenAI, Google, Anthropic y otros proveedores dentro de Odoo 19. No es un chat decorativo: el asistente tiene herramientas con las que lee y escribe datos reales de la base de datos, genera reportes y archivos, envía correos, programa trabajos recurrentes y ejecuta misiones largas de varios pasos. Por eso el manual le dedica el mismo espacio a lo que el asistente puede hacer que a cómo se limita, se aprueba y se mide lo que hace.

Está escrito para tres lectores distintos:

• El administrador de Odoo, que instala el módulo, registra las claves de los proveedores, crea los agentes y define la gobernanza y los presupuestos (capítulos 3 a 9, 33 a 36).
• El usuario de negocio —gerencia, ventas, contabilidad, compras—, que conversa con sus datos, pide reportes, crea registros desde el chat y recibe los correos automáticos (capítulos 10 a 20 y 26 a 31).
• El responsable de mejorar al asistente, que cura las pistas de modelo, las recetas, la memoria y la base de conocimiento para que las respuestas sean exactas y baratas (capítulos 21 a 25 y 37 a 39).

Todas las capturas provienen de un ambiente de demostración real —la empresa ficticia Distribuidora El Quetzal, S.A., con ventas, compras, inventario, CRM y contabilidad de 2026— y todas las respuestas del asistente que aparecen son respuestas reales del modelo configurado (GPT-5.4 de OpenAI para el agente principal), obtenidas con las herramientas del módulo sobre esos datos. Los nombres técnicos de campos, herramientas y modelos aparecen en este formato.

Qué encontrará en cada bloque

2.Qué es MRDC AI Base y cómo funciona

Un modelo de lenguaje no sabe nada de su empresa. El módulo le presta ojos y manos dentro de Odoo —con permisos, límites y registro de todo lo que hace.

Un modelo de lenguaje (GPT, Gemini, Claude…) solo sabe conversar. Lo que convierte esa conversación en trabajo útil dentro del ERP es el ciclo de herramientas: el usuario pide algo, el modelo decide qué herramienta necesita, el módulo la ejecuta dentro de Odoo con los permisos del usuario que pregunta, le devuelve el resultado al modelo, y así hasta que el modelo tiene lo suficiente para responder. Una pregunta como «¿cuánto vendimos en julio y a quién?» termina en tres o cuatro llamadas: una para recuperar una receta validada de ventas por período, otra para agrupar pedidos por cliente, y la respuesta final con los números reales y la explicación de cómo se obtuvieron.

Las piezas, en una frase cada una

El menú de la aplicación

Al instalar el módulo aparece la aplicación MRDC AI con los menús de la figura siguiente. El orden refleja el uso: lo conversacional primero (Chat de IA, Consulta rápida), después la automatización (Misiones, Tareas programadas, Acciones pendientes), el Historial, los dos repositorios de inteligencia (Centro de hallazgos, Base de conocimiento) y, al final, la Configuración.

3.Instalación y requisitos

El módulo se instala como cualquier otro de Odoo 19; lo que hay que preparar antes son las claves de los proveedores y, si se quieren todas las funciones, tres paquetes de Python.

Requisitos

Instalación

1. Copie la carpeta mrdc_ai_base a una ruta incluida en el addons_path del servidor y reinicie Odoo (o actualice la lista de aplicaciones en modo desarrollador).
2. En Aplicaciones, busque MRDC - AI Base e instálelo. La instalación crea la aplicación MRDC AI, los tres agentes de fábrica, los temas, las pistas de modelo, las recetas de ventas y cobranza, la tabla de precios de modelos y tres acciones planificadas (capítulo 36).
3. Vaya a Ajustes → MRDC AI, pegue la clave del proveedor que va a usar y guarde (capítulo 4).
4. Abra MRDC AI → Configuración → Agentes de IA, elija el modelo de cada agente (el valor de fábrica es gemini-2.5-flash; cámbielo a un modelo del proveedor cuya clave registró) y active las capacidades que necesite (capítulos 6 y 7).
5. Pulse el icono de la varita mágica en la barra superior y escriba su primera pregunta.

Actualizar a una versión nueva

Reemplace la carpeta y actualice el módulo (Aplicaciones → MRDC - AI Base → Actualizar, o -u mrdc_ai_base desde la línea de comandos). Los datos marcados como noupdate —los agentes, las pistas y las recetas de fábrica que usted haya modificado— se respetan. Las nuevas funciones suelen añadir campos a los agentes (por ejemplo los modelos de respaldo o los reportes permitidos); tras actualizar conviene revisar el formulario de cada agente y activar lo que corresponda.

4.Configuración general: Ajustes → MRDC AI

Una sola pantalla concentra las claves de los proveedores, el agente por defecto, el modelo de embeddings, el presupuesto global y los límites de seguridad del ciclo de herramientas.

Vaya a Ajustes → MRDC AI. La sección está dividida en tres bloques: Proveedores, Valores predeterminados y Avanzado.

Proveedores

Valores predeterminados

• Agente de IA predeterminado (mrdc_ai.default_agent_id): el agente que se selecciona al abrir el panel de chat por primera vez. Si no se define, se usa el primero por secuencia (de fábrica, MRDC Assistant).
• Embeddings de la base de conocimiento (mrdc_ai.embedding_model): modelo que convierte los textos indexados en vectores. Las opciones son text-embedding-3-small y text-embedding-3-large de OpenAI y text-embedding-004 de Gemini. Si lo cambia, reindexe las fuentes (capítulo 24), porque los vectores de modelos distintos no son comparables.
• Presupuesto mensual de IA (mrdc_ai.monthly_budget_usd): tope global en dólares para todos los agentes, conversaciones, tareas y misiones del mes. Cuando se alcanza, cualquier llamada nueva se rechaza con un mensaje claro. 0 = sin tope (capítulo 35).
• Calidad de generación de imágenes (mrdc_ai.image_model_quality): calidad que usa generate_image / generate_and_set_image.

Avanzado: los frenos del ciclo de herramientas

• Máximo de iteraciones de herramientas (mrdc_ai.max_successive_calls): cuántas rondas «modelo pide herramienta → Odoo responde» se permiten por mensaje. Evita bucles en los que el modelo insiste en una consulta que falla. El valor del agente (Máx. iteraciones de herramientas, capítulo 8) tiene prioridad si está definido.
• Máximo de herramientas por iteración (mrdc_ai.max_tool_calls_per_call): cuántas herramientas puede pedir el modelo en una sola ronda.
• Tiempo de espera de la petición (mrdc_ai.request_timeout): segundos máximos por llamada al proveedor. Las llamadas que fallan con errores transitorios (429, 5xx) se reintentan con espera creciente hasta mrdc_ai.max_retries veces (3 por defecto).

5.Proveedores y modelos soportados

Nueve proveedores y unos sesenta modelos, seleccionables por agente. Lo que cambia entre ellos es el precio, la calidad del razonamiento con herramientas y si aceptan o no el parámetro de temperatura.

El desplegable Modelo del agente lista todos los modelos conocidos por el módulo, agrupados por proveedor. Cualquiera puede seleccionarse; solo funcionará si la clave del proveedor correspondiente está registrada en Ajustes. Esta es la familia soportada en la versión documentada:

Temperatura y modelos de razonamiento

El estilo de respuesta del agente (capítulo 6) se traduce en un valor de temperatura. Algunos modelos de razonamiento —gpt-5, gpt-5-mini, o1, o3, o4-mini, deepseek-reasoner, los sonar de razonamiento— rechazan ese parámetro. El módulo lo sabe y simplemente no lo envía para ellos, de modo que puede cambiar de modelo sin tocar nada más.

Precios de modelos

En Configuración → Precios de modelos está la tabla de costo por millón de tokens de entrada y de salida de cada modelo (27 precios de fábrica, editables). Con ella el módulo calcula el costo en dólares de cada mensaje, de cada ejecución de tarea y de cada paso de misión, y controla los presupuestos. Si un modelo no tiene precio, su costo se registra como cero: añada una fila si incorpora un modelo nuevo.

6.Los agentes: crear y configurar

Un agente es una configuración completa de la IA: el modelo que piensa, las instrucciones que lo gobiernan, las capacidades que tiene y los límites que no puede cruzar. Puede haber tantos como roles necesite la empresa.

Vaya a MRDC AI → Configuración → Agentes de IA. La vista kanban muestra los agentes con su avatar, descripción y modelo; de fábrica existen tres, todos marcados como agentes del sistema (no se pueden borrar, sí modificar o archivar):

• MRDC Assistant: asistente general; consulta, analiza, navega y genera reportes. Es el candidato natural a agente predeterminado y el que más capacidades recibe.
• Ask AI: especialista en consultas en lenguaje natural; descubre modelos y campos y responde con datos, conciso y tabular.
• Report Generator: especialista en reportes de negocio con análisis y recomendaciones.

El formulario del agente

El formulario tiene cinco grupos en la cabecera y un cuaderno con dos pestañas. Los grupos Enrutamiento de modelos, Costo y presupuesto y Gobernanza se explican en los capítulos 8 y 9; aquí van los dos primeros.

Configuración de IA

Capacidades

Siete casillas que habilitan bloques de herramientas. Se detallan en el capítulo 7; la regla general es dar a cada agente solo lo que su función exige.

La pestaña Prompt del sistema

Es la instrucción base que define la personalidad, el método de trabajo y los límites del agente. El módulo la completa automáticamente en cada petición con secciones que usted no tiene que escribir: la fecha y hora actuales en UTC, el usuario y la compañía, la memoria confirmada, el resumen de la conversación, el conocimiento curado disponible (pistas y recetas), las reglas de escritura cuando las escrituras están habilitadas, las pautas de las respuestas rápidas y, si el usuario está mirando un registro, el contexto de ese registro.

La pestaña Temas y herramientas

Los temas (capítulo 33) agrupan instrucciones especializadas —consultas en lenguaje natural, generación de reportes, navegación— que se añaden al agente. Los tres agentes de fábrica ya tienen los suyos; al crear un agente nuevo puede arrastrar los que correspondan.

Crear un agente nuevo

1. En Agentes de IA pulse Nuevo, póngale nombre, descripción y avatar.
2. Elija el modelo principal y, en Enrutamiento de modelos, un modelo rápido y uno de respaldo (capítulo 8).
3. Escriba el prompt del sistema: rol, tono, formato y reglas del negocio.
4. Marque las capacidades mínimas. Para un agente de solo consulta: Herramientas de Odoo y Generación de reportes.
5. En Gobernanza, restrinja los modelos (sale.*, account.move, res.partner) y los dominios de correo si el agente va a enviar correos (capítulo 9).
6. Defina un presupuesto mensual y guarde. El agente aparece de inmediato en el selector del panel de chat.

7.Capacidades: qué puede hacer cada agente

Siete casillas deciden qué herramientas recibe el modelo. Cada una abre un bloque concreto; lo que no está marcado ni siquiera se le describe al modelo, así que no puede pedirlo.

Cómo se combinan con las tareas y las misiones

Las capacidades del agente son el techo. Cada tarea programada y cada misión tiene además sus propios permisos (Permitir operaciones de escritura, Permitir enviar correo, Permitir notificaciones) que solo pueden restringir: una tarea no puede escribir si su agente no tiene escrituras, aunque la casilla de la tarea esté marcada. Además, las tareas en modo aprobación y las misiones con aprobación de escrituras no ejecutan las herramientas de escritura ni el correo: las encolan como acciones pendientes (capítulo 28).

8.Enrutamiento de modelos, costo y presupuesto del agente

Tres modelos por agente —principal, rápido y de respaldo—, un modo de selección de herramientas que ahorra tokens y un presupuesto mensual que frena el gasto antes de que duela.

Enrutamiento de modelos

Costo y presupuesto

• Presupuesto mensual (USD): gasto estimado permitido para este agente en el mes calendario, sumando conversaciones, ejecuciones de tareas y pasos de misión. Al llegar al 80 % el módulo notifica una sola vez al usuario y al administrador; al 100 % rechaza las llamadas nuevas con «El agente … agotó su presupuesto mensual». 0 = sin tope.
• Este mes (USD): el gasto real acumulado, calculado con la tabla de precios de modelos. Es un campo de solo lectura que se recalcula al abrir el formulario.
• Máx. iteraciones de herramientas por ejecución: tope de rondas modelo↔herramientas por petición para este agente (0 = el valor global de Ajustes). Una tarea compleja con recetas suele resolverse en 8–15 rondas; un valor de 25–30 es un buen techo.

El presupuesto global de Ajustes (capítulo 4) se comprueba antes que el del agente y suma lo de todos los agentes. Los dos se evalúan al inicio de cada mensaje, ejecución o paso; una respuesta en curso nunca se corta a mitad por presupuesto.

9.Gobernanza: hasta dónde llega cada agente

Las capacidades dicen qué tipo de cosas puede hacer el agente; la gobernanza dice sobre qué y cuánto. Las políticas se evalúan en un solo lugar, tanto cuando el modelo llama a una herramienta como cuando alguien aprueba una acción pendiente.

Lo que la gobernanza no sustituye

Las políticas se suman a la seguridad de Odoo, no la reemplazan. El agente ejecuta cada herramienta con el usuario que conversa (o el usuario dueño de la tarea o misión), de modo que los grupos de acceso, las reglas de registro y las compañías permitidas del usuario siguen mandando. Hay además listas de bloqueo internas que no se pueden desactivar: call_method nunca llama a métodos privados, a unlink, write, create directos ni a modelos sensibles (usuarios, claves, parámetros, reglas, módulos); el SQL de solo lectura rechaza cualquier verbo que no sea de lectura y las tablas de credenciales.

10.El panel de chat

La varita mágica de la barra superior abre un panel flotante que acompaña al usuario por todo Odoo; también existe como pantalla completa en MRDC AI → Chat de IA.

Anatomía del panel

Historial y búsqueda

El botón Historial despliega las conversaciones recientes del usuario con el agente, con un buscador por título; al seleccionar una, se cargan sus mensajes. Cada fila tiene un icono de papelera para borrarla. Las conversaciones son privadas de cada usuario: nadie más las ve en el panel, y en el menú Historial de la aplicación solo el administrador ve las de todos (capítulo 34).

Maximizar

El botón de maximizar amplía el panel a casi toda la ventana, cómodo para leer reportes y tablas largas. El menú MRDC AI → Chat de IA ofrece además una pantalla completa con la lista de conversaciones a la izquierda y la conversación a la derecha.

Adjuntar archivos

Con el clip se adjuntan hasta 10 archivos por mensaje, de máximo 15 MB cada uno y 40 MB en total. Se aceptan imágenes (PNG, JPG, GIF, WebP), PDF, Word, Excel, CSV y texto; el módulo comprueba el tipo real del archivo, no solo la extensión, y rechaza lo demás con un mensaje en español. Las imágenes se envían al modelo como imágenes (los modelos con visión las interpretan); los documentos de texto se transcriben al contexto; los demás se describen. El agente puede, por ejemplo, leer una factura en PDF adjunta y crear el proveedor y la factura de compra.

Capturar la pantalla

El botón de la cámara toma una captura de la vista actual de Odoo y la adjunta al mensaje: sirve para preguntar «¿qué significa este error?» o «¿por qué esta factura está en este estado?» sin copiar nada. En las vistas que no son formulario, lista ni kanban —tableros, informes dinámicos, pantallas especiales— el panel la toma automáticamente al enviar, porque ahí no hay registros que capturar como datos.

Dictar por voz

El micrófono graba audio en el navegador (requiere HTTPS o localhost y permiso del usuario) y al detenerlo lo transcribe con el servicio de audio de OpenAI; el texto aparece en la caja de entrada para revisarlo antes de enviar. El idioma por defecto de la transcripción es español.

Cancelar una respuesta

Si el agente se está tardando —una cadena larga de herramientas, una consulta pesada— el botón Cancelar de la línea de tiempo pide la cancelación. El módulo la atiende en la siguiente frontera de herramienta: el ciclo se detiene, la conversación recibe el mensaje «⏹️ Respuesta cancelada por el usuario» y nada de lo que estaba por escribirse se escribe.

Retroalimentación

Debajo de cada respuesta del agente hay dos pulgares. Marcar 👍 o 👎 guarda la retroalimentación en el mensaje (solo el dueño de la conversación puede hacerlo), y con 👎 el panel pide opcionalmente un comentario. Esa señal queda en el Historial para que el responsable del asistente revise las respuestas malas y mejore prompts, pistas y recetas (capítulo 38).

11.Conversar con los datos: consultas en lenguaje natural

Pregunte como le preguntaría a un analista. El agente descubre el modelo, elige la receta o la agrupación correcta, ejecuta la consulta con sus permisos y explica de dónde salió cada número.

Las respuestas de este capítulo son reales, obtenidas en el ambiente de demostración con el agente MRDC Assistant (GPT-5.4) sobre los datos de 2026 de Distribuidora El Quetzal. Cada figura muestra la pregunta tal como se escribió y la respuesta tal como llegó.

Ventas del mes y clientes principales

Vale la pena detenerse en ese último detalle: el agente no solo responde, declara la base de cálculo (pedidos confirmados, sin impuestos) y señala la inconsistencia entre dos fuentes. Eso sale de las pistas de modelo (capítulo 21), que le enseñan que amount_total incluye impuestos y amount_untaxed no.

Cuentas por cobrar vencidas

Existencias y rotación

Oportunidades del CRM con Ask AI

Cómo razona el agente una consulta

1. Entender qué se pide y en qué modelo vive: si duda, llama a get_available_models o lee la pista del modelo con get_model_hint.
2. Preferir una receta. Si existe una receta validada que responde la pregunta (list_recipes / run_recipe), la usa: es más barata y está aprobada por una persona.
3. Si no hay receta, construye la consulta con read_group (totales, promedios, conteos por grupo), search_records (listas con campos concretos) o count_records; y si tiene SQL habilitado y la agrupación es compleja, run_sql_query.
4. Responder con contexto: cuántos registros encontró, qué filtros aplicó, qué base de cálculo usó, y un enlace directo (get_record_link) cuando nombra un documento.

12.Reportes, gráficas, documentos e imágenes

Con la capacidad de generación de reportes el agente devuelve tablas formateadas, gráficas interactivas y archivos descargables —PDF, Excel, CSV, texto, HTML— construidos a partir de los datos que acaba de consultar.

Reportes en tabla y gráficas

generate_report ejecuta una agrupación sobre un modelo (dominio, campos a sumar, agrupar por, ordenar, límite) y la devuelve como tabla HTML con título; generate_chart hace lo mismo pero dibuja una gráfica de barras, líneas, pastel o dona que se renderiza dentro del chat con Chart.js y se puede abrir a pantalla completa con un clic.

Documentos descargables

generate_document crea un archivo y lo adjunta al mensaje con un botón de descarga: PDF a partir de HTML (tablas, encabezados, estilos), XLSX a partir de una matriz de filas (la primera fila son los encabezados), CSV, TXT y HTML. El adjunto queda en el mensaje de la conversación y su identificador puede pasarse a send_email o send_notification para enviarlo.

Imágenes

generate_image crea una imagen a partir de una descripción (relación de aspecto y calidad configurables) y la muestra en el chat; generate_and_set_image hace lo mismo y la guarda en el campo de imagen de un registro —por ejemplo la foto de un producto que no la tiene—, lo que requiere la capacidad de escritura. Ambas usan el proveedor de OpenAI.

Tres maneras de obtener un reporte: cuál usar

13.Reportes oficiales de Odoo: facturas, libros y estados de cuenta

Cualquier reporte que Odoo sepa imprimir —la factura, el libro de ventas de la SAT, un estado de cuenta, una orden de compra— el agente puede generarlo en PDF, Excel o HTML, adjuntarlo y enviarlo por correo, sin que nadie abra el asistente del reporte.

Los reportes de Odoo son registros de ir.actions.report. Hay dos familias: los que se imprimen sobre registros (la factura, el pedido, la orden de compra) y los que se piden a través de un asistente con parámetros (los libros de la SAT de l10n_gt_extra, los reportes contables con fechas, el libro mayor). El agente maneja las dos con dos herramientas:

• list_reports: lista los reportes disponibles (nombre, identificador XML, modelo, formatos) filtrando por modelo o por texto; para los reportes de asistente muestra además los campos del asistente y cuáles son obligatorios.
• render_report: genera el reporte en pdf, xlsx (cuando el reporte tiene versión Excel) o html (que además devuelve el contenido para incrustarlo en un correo). Para reportes sobre registros se pasan los ids; para los de asistente, los valores del asistente —y los campos relacionales aceptan nombres, no solo ids: «Facturas de Cliente (FEL)», «IVA por ventas 12%».

El libro de ventas de la SAT por correo

Cómo lo hace por dentro

1. Resuelve el reporte por id, por identificador XML (l10n_gt_extra.action_reporte_ventas) o por nombre exacto, y comprueba las políticas: Reportes permitidos y Modelos permitidos del agente.
2. Si el modelo del reporte es un asistente, lo crea con los valores recibidos (resolviendo nombres a ids y avisando si un nombre es ambiguo o no existe), llama a su método de impresión (print_report, export_xls… detectados automáticamente o indicados en wizard_method) y usa los datos y el contexto que ese método devuelve —exactamente lo que haría el botón en pantalla.
3. Renderiza con el motor de reportes de Odoo (_render_qweb_pdf / _render_qweb_html) o captura la exportación Excel del asistente. Para reportes sobre registros verifica que el usuario pueda leerlos y respeta el máximo de registros por operación.
4. Guarda el resultado como adjunto y devuelve su id; el agente lo pasa a send_email o lo deja descargable en el chat.

14.Crear y modificar registros desde el chat

Con la capacidad de escritura el agente crea contactos, pedidos, facturas y cualquier registro, actualiza campos y pulsa los botones de la vista. Lo hace con su usuario, con verificación posterior y, si así se configura, con aprobación humana.

Un contacto nuevo en dos turnos

Las herramientas de escritura

Las reglas que el agente recibe

Cuando la escritura está habilitada, el prompt del sistema incorpora automáticamente una sección de operaciones de escritura que el modelo debe seguir: consultar siempre get_fields antes de crear (campos requeridos, solo lectura, relaciones); resolver clientes y productos por nombre y confirmar el correcto antes de usarlos; crear las líneas de un documento junto con el documento; verificar lo guardado y corregir con update_record si algo no coincide con la intención; no inventar campos ni valores; no ejecutar un botón sin antes descubrirlo con get_record_actions; y reportar siempre qué cambió, con el enlace al registro.

Confirmaciones y aprobación

En el chat, el agente pregunta antes de actos con consecuencias (confirmar un pedido, validar una factura, cambiar muchos registros) salvo que el usuario ya lo haya pedido explícitamente. En tareas programadas en modo aprobación y en misiones con aprobación de escrituras las herramientas de escritura no se ejecutan: cada llamada se convierte en una acción pendiente con una vista previa «valor actual → valor propuesto», que una persona aprueba o rechaza (capítulo 28).

15.Métodos y acciones de servidor: el mayor alcance

Cuando ninguna herramienta dedicada encaja, la capacidad de métodos y acciones de servidor deja al agente llamar a cualquier método público de un modelo y ejecutar las acciones de servidor del menú «Acción», con listas de bloqueo que no se pueden apagar.

Las cuatro herramientas

Ejemplo real: una nota interna en la oportunidad

La tarea por evento del capítulo 29 califica cada oportunidad nueva del CRM y publica su análisis como nota interna. No existe una herramienta «publicar nota», así que el agente usa call_method sobre crm.lead.message_post con el cuerpo en HTML y el subtipo de nota. La figura muestra las llamadas registradas en la ejecución.

Lo que nunca se permite

• Métodos privados (que empiezan por _) ni los métodos de bajo nivel create, write, unlink, read, search y similares: para eso están las herramientas dedicadas, que validan y registran.
• Modelos sensibles: usuarios, grupos, reglas de acceso, claves de API, parámetros del sistema, módulos, adjuntos de sistema, el propio módulo de IA.
• Lo que no esté en Métodos permitidos o Acciones de servidor permitidas cuando esas listas están definidas, ni más registros que el máximo por operación.

16.SQL de solo lectura

Para agregaciones complejas, uniones y cubos por fecha que el ORM hace pesados, el agente puede consultar PostgreSQL directamente —solo leer, dentro de una transacción de solo lectura y con las tablas sensibles vetadas.

Cómo se protege

1. La consulta debe empezar por SELECT o WITH; cualquier otro verbo se rechaza antes de tocar la base.
2. Una lista de palabras prohibidas bloquea modificaciones y funciones peligrosas (insert, update, delete, drop, alter, copy, pg_sleep, pg_read_file, dblink, set…) y las tablas de credenciales (res_users_apikeys, auth_totp, ir_config_parameter, cualquier cosa con password).
3. Se ejecuta dentro de un punto de guardado con SET LOCAL transaction_read_only = on: aunque algo se colara, PostgreSQL impide escribir; al terminar se revierte el punto de guardado, así que no deja rastro en la transacción.
4. Se aplica un límite de filas (200 por defecto, ajustable en la llamada) y las políticas del agente: si Modelos permitidos está definido, las tablas de la consulta deben corresponder a modelos permitidos.
5. Se registran la consulta, la duración y el tamaño del resultado en las llamadas a herramientas de la conversación o de la ejecución.

Cuándo prefiere SQL y cuándo no

El agente recurre a SQL cuando la pregunta exige agrupar por semanas o trimestres, cruzar varios modelos, calcular percentiles o promedios móviles, o cuando una agrupación del ORM devolvió demasiadas filas. Para consultas sencillas sigue usando read_group y search_records, que conocen etiquetas, monedas y traducciones. Las pistas de modelo le indican en qué tabla vive cada cosa (sale_order, account_move, account_partial_reconcile…) y qué trampas evitar.

17.Contexto de pantalla y navegación

El panel sabe dónde está el usuario. Puede leer el registro o la lista que tiene delante, responder sobre «esta factura» sin que nadie copie el número y devolver enlaces que abren directamente el menú o el documento correcto.

«Puedo ver lo que estás viendo»

Cuando el usuario está en una vista de un modelo, el panel muestra la barra de contexto con el modelo y, si es un formulario, el registro abierto. Al enviar un mensaje, el módulo captura el contexto —modelo, tipo de vista, id del registro o ids visibles y dominio de la lista— y lo entrega al agente como texto: «El usuario está viendo el pedido S00042 de Hotel Vista al Lago…». Con el icono de la mira el usuario fuerza una captura de los datos visibles antes de preguntar. Así funcionan preguntas como «¿por qué este pedido no se puede facturar?» o «resume las oportunidades de esta lista».

Enlaces que abren Odoo

Dos herramientas hacen que el agente no solo hable sino que lleve al usuario al lugar correcto:

• get_menus: busca entre los menús a los que el usuario tiene acceso (por palabras: «facturas cliente») y devuelve el id y la ruta completa; el agente responde con un enlace /odoo/ir.ui.menu/ que abre ese menú.
• get_record_link: devuelve la URL directa de un registro (/odoo//). El agente la usa cada vez que nombra un documento que acaba de crear o modificar.

18.Correo y notificaciones

El agente envía correos con cuerpo HTML y adjuntos, mensajes a la bandeja de Odoo y avisos emergentes en tiempo real. Todo queda registrado y, en las tareas en modo aprobación, todo pasa primero por una persona.

Reglas y límites

• Los destinatarios se limpian (espacios, separadores, duplicados) y, si el agente tiene Dominios de correo permitidos, cualquier dirección fuera de esos dominios se rechaza con el motivo.
• Los adjuntos solo pueden ser los generados en la misma conversación o ejecución (documentos, reportes oficiales, gráficas exportadas): el agente no puede adjuntar archivos arbitrarios de la base.
• En el chat, la regla por defecto es confirmar destinatario y contenido con el usuario salvo que ya los haya dado explícitamente; las instrucciones de una tarea pueden indicar «envía sin confirmar» porque ahí no hay nadie a quien preguntar.
• En tareas en modo aprobación y en misiones con aprobación de escrituras, send_email se encola como acción pendiente con el asunto y el cuerpo completos visibles en la vista previa; se envía al aprobar.
• El envío real depende del servidor de correo saliente de Odoo. Si no hay ninguno o falla, el correo queda en estado de error en la lista técnica y la herramienta devuelve el aviso; la tarea lo refleja en su respuesta.

19.Consulta rápida

Una pregunta, una respuesta, sin abrir una conversación: el asistente de Consulta rápida es la vía más corta para un dato puntual, y si la respuesta vale la pena se guarda como conversación.

En MRDC AI → Consulta rápida se abre un asistente con el selector de agente y una caja para la pregunta. Preguntar a la IA ejecuta el mismo ciclo de herramientas del chat y muestra la respuesta formateada, los adjuntos generados, las herramientas que se usaron y los tokens consumidos. Nueva pregunta limpia el formulario y Guardar en conversación crea una conversación con ese intercambio para seguirla después en el panel.

20.Historial de conversaciones

Cada conversación queda guardada con sus mensajes, adjuntos, llamadas a herramientas, tokens, costo y retroalimentación. Es la materia prima para auditar y para mejorar al asistente.

MRDC AI → Historial lista las conversaciones: nombre (el agente lo deduce del primer mensaje), agente, usuario, número de mensajes y última actividad. Un usuario normal ve solo las suyas; el administrador ve todas.

La conversación por dentro

El formulario muestra la pestaña Mensajes con cada turno: fecha, rol (usuario, asistente, sistema), contenido y tokens de entrada y salida. Al abrir un mensaje del asistente se ve su contenido renderizado en HTML, el texto original y, en Llamadas a herramientas, cada herramienta invocada con sus argumentos, su resultado (recortado), la duración en milisegundos y el tamaño del resultado; además el costo estimado en dólares, el modelo realmente usado y la retroalimentación 👍/👎 con su nota.

Resumen automático

Para que una conversación larga no cueste más a cada turno, el módulo genera cada 10 mensajes un resumen de lo anterior con el modelo rápido del agente y lo guarda en la conversación. Al siguiente mensaje, el agente recibe el resumen más los últimos mensajes (según el límite de historial del agente), no todo el hilo. Los datos confirmados —«el cliente es X», «la fecha acordada es Y»— sobreviven así aunque el mensaje original ya no se reenvíe.

Qué hacer con el Historial

• Auditar: qué preguntó quién, qué herramientas se ejecutaron, qué registros se tocaron y cuánto costó.
• Mejorar: filtrar las respuestas con 👎, leer la llamada que falló o el número que salió mal, y convertir la lección en una pista de modelo, una receta o una línea del prompt (capítulo 38).
• Reutilizar: abrir una conversación antigua desde el panel y continuarla; el agente recupera el resumen y el contexto.

21.Conocimiento curado I: pistas de modelo

Una pista de modelo es lo que un consultor experimentado le contaría a un analista nuevo sobre un modelo de Odoo: qué campos importan, cuáles engañan y dónde está el dato correcto. El agente la recibe justo cuando va a usar ese modelo.

Los modelos de lenguaje conocen Odoo en general, pero no los detalles que deciden si un número es correcto: que amount_invoiced de un pedido no está almacenado y además incluye IVA, que los cobros conciliados desde el extracto no crean account.payment, que date_order está en UTC y un día de Guatemala va de las 06:00 a las 05:59 UTC del siguiente. Las pistas de modelo (Configuración → Pistas de modelo) guardan ese conocimiento por modelo técnico.

Cómo llegan al agente

• Cuando el agente llama a get_fields o a una herramienta sobre un modelo que tiene pista, el módulo adjunta la pista al resultado. El agente la lee en el momento exacto en que la necesita, sin gastar tokens en los modelos que no toca.
• El agente también puede pedirla directamente con get_model_hint; el prompt del sistema le recomienda hacerlo antes de get_fields cuando una receta falla.
• La sección «Conocimiento curado» del prompt le dice qué modelos tienen pista y qué recetas existen, para que sepa que están ahí.

Escribir una buena pista

1. Empiece por la tabla y los estados que cuentan («solo posted»).
2. Liste los campos que importan y diga de cada uno si está almacenado, en qué moneda y si incluye impuestos.
3. Escriba las TRAMPAS en mayúsculas: lo que parece correcto y no lo es, con la alternativa correcta.
4. Añada las convenciones locales: zona horaria, cómo se llama al cliente (commercial_partner_id), qué excluir (anticipos, secciones).
5. Pruebe: haga la pregunta que antes salía mal y compruebe que ahora el agente cita la pista.

22.Conocimiento curado II: recetas

Una receta es una consulta parametrizada que una persona probó y validó. El agente la prefiere sobre cualquier consulta improvisada: es más exacta, más barata y repetible.

En Configuración → Recetas viven las consultas validadas. Cada una tiene un nombre técnico (sales_confirmed_by_week), una descripción de lo que devuelve, un tipo (SQL o ORM), la consulta, sus parámetros y el último resultado de prueba. El módulo trae diez recetas de ventas, facturación, cobranza y cartera:

Anatomía de una receta

• Tipo SQL: una consulta de solo lectura con marcadores con nombre (%(date_from)s). Se ejecuta con la misma protección de solo lectura del capítulo 16 (sin la comprobación de palabras prohibidas, porque la validó una persona).
• Tipo ORM: un JSON con modelo, dominio, campos y agrupación que se ejecuta con formatted_read_group; respeta reglas de registro y multiempresa, ideal para usuarios con acceso parcial.
• Parámetros (JSON): nombre, tipo (date, datetime, int, float, str, bool), si es obligatorio y valor por defecto; los valores today y now se resuelven al ejecutar.
• Probar ejecuta con parámetros de muestra y guarda el resultado; Validar la marca como validada (solo entonces el agente la ve); Volver a borrador la retira del catálogo sin borrarla.

Cómo las usa el agente

El prompt del sistema le muestra el catálogo de recetas validadas (nombre, descripción y parámetros). Ante una pregunta, el agente llama a run_recipe con el nombre y los parámetros en JSON y recibe las filas; si necesita explorar, list_recipes con un texto. En las instrucciones de una tarea programada se puede obligar a usar recetas («usa SIEMPRE las recetas validadas con run_recipe»), como en el caso práctico del capítulo 31: eso convierte un reporte que antes costaba veinte llamadas exploratorias en seis llamadas exactas.

Crear recetas a partir de una ejecución

En la ejecución de una tarea (capítulo 27) el botón Extraer recetas recorre las consultas SQL y las agrupaciones que el agente hizo en esa corrida y las propone como recetas en borrador, con sus parámetros detectados. Es la forma más rápida de capitalizar una consulta que salió bien: se revisa, se prueba, se valida y a partir de ahí el agente la reutiliza.

23.Memoria: lo que el agente no vuelve a preguntar

Preferencias del usuario, decisiones confirmadas, hechos de la empresa. La memoria guarda lo que debe sobrevivir a la conversación y lo inyecta en el contexto de las siguientes —con ámbitos, caducidad y un filtro que rechaza secretos.

Tres ámbitos

Cómo funciona

• Al inicio de cada petición el módulo añade al prompt la sección «Memoria (hechos confirmados antes; no volver a preguntar)» con las memorias vigentes del usuario, del agente y de la conversación.
• El agente guarda con remember_fact(clave, valor, ámbito) y borra con forget_fact(clave); la clave hace de identificador: guardar de nuevo la misma clave actualiza el valor.
• Un filtro de secretos rechaza valores que parezcan claves de API, contraseñas o tokens, y lo dice.
• La caducidad (Expira el) permite hechos temporales: «durante agosto la promoción es…»; las memorias vencidas se ignoran.
• El origen indica quién la creó: el usuario, el agente o el resumen automático.

24.Base de conocimiento (RAG): políticas, manuales y registros

Textos, documentos adjuntos y registros de Odoo indexados con embeddings para que el agente responda «según la política de crédito…» citando lo que la empresa escribió, no lo que el modelo supone.

MRDC AI → Base de conocimiento administra las fuentes. Cada fuente se trocea en fragmentos, cada fragmento se convierte en un vector con el modelo de embeddings de Ajustes y se guarda con su texto. Cuando el agente llama a search_knowledge, el módulo combina dos búsquedas —semántica (coseno entre vectores) y léxica (texto completo en español)— y devuelve los pasajes más relevantes con su fuente, para que el agente los cite.

Tipos de fuente

El agente citando la política

Permisos y multiempresa

• Cada fuente tiene compañía; una regla de registro hace que los usuarios solo vean y busquen en las fuentes de sus compañías (o las globales).
• Al devolver un pasaje de un adjunto, el módulo comprueba que el usuario pueda leer ese adjunto; al devolver uno de un registro, que pueda leer ese registro. Lo que no puede ver, no se le muestra ni al agente que le responde.
• La herramienta search_knowledge solo se ofrece al agente cuando existe al menos una fuente indexada: así no gasta tokens describiéndola en bases sin conocimiento.

25.Centro de hallazgos

Cuando el agente detecta algo que merece atención —un cliente que cruza los 30 días de mora, un producto que se agota, una semana atípica— no solo lo menciona en un correo: lo registra como hallazgo con números, responsable, fecha límite y estado.

MRDC AI → Centro de hallazgos es una bandeja de trabajo. Cada hallazgo tiene severidad (información, aviso, crítico), categoría (ventas, cobranza, facturación, inventario, compras, otros), una explicación con los datos que lo sustentan, una acción recomendada, el monto involucrado, el registro relacionado (cliente, producto, documento), el responsable, una fecha límite y el estado (nuevo, visto, hecho, descartado).

Quién los crea

• El agente, con la herramienta create_insight, desde una conversación o —sobre todo— desde una tarea programada: «si algún cliente supera 30 días de mora, registra un hallazgo crítico». El hallazgo guarda el agente, la tarea y la ejecución que lo generaron.
• Una persona, a mano, para usarlo como bandeja de pendientes del negocio.

Deduplicación

Si el agente vuelve a detectar el mismo hallazgo (mismo nombre y mismo registro) dentro de 14 días, no crea otro: incrementa el contador de ocurrencias y actualiza la fecha de última vez visto. Una tarea diaria de cobranza no llena la bandeja de duplicados; muestra cuántos días seguidos un cliente aparece en mora.

Flujo de trabajo

Al asignar un responsable, el módulo le envía una notificación interna («Te asignaron…»). Los filtros Abiertos, Críticos y Mis hallazgos, y las agrupaciones por severidad, categoría y estado, sirven para repartir el trabajo. Los hallazgos respetan la compañía.

26.Tareas programadas: el agente trabaja solo

Un reporte cada lunes a las 07:00, un seguimiento de cobranza diario, una calificación de cada oportunidad nueva. La tarea programada le da al agente instrucciones, un horario o un disparador, permisos propios y una memoria, y deja constancia de cada corrida.

MRDC AI → Tareas programadas lista las tareas con su agente, dueño, modo, disparador, intervalo, próxima y última ejecución, último estado y acciones pendientes. Una tarea puede crearse a mano desde este menú o desde el chat, pidiéndoselo al agente (herramienta schedule_ai_task).

El formulario

Lo que el agente recibe además de las instrucciones

En cada corrida el módulo antepone un contexto de tarea: nombre, fecha y hora local del inicio (en la zona del dueño), programación, modo de ejecución, permisos, la memoria de la tarea y las últimas instantáneas de KPIs, y unas reglas fijas —un error de herramienta no es una «inconsistencia de datos», no hay que revisar crons ni la cola de correo, las reglas se aplican literalmente, los correos no llevan destinatarios de relleno como «». Esas reglas nacieron de corridas reales que fallaron por interpretaciones demasiado creativas.

Programar desde el chat

La herramienta acepta nombre, instrucciones, intervalo, primera ejecución (fecha, día de la semana, día del mes y hora local), modo y permisos. Tiene sus propias salvaguardas: rechaza instrucciones con marcadores sin rellenar (, ), una tarea semanal sin día de la semana toma el día de hoy, una mensual el día de hoy, y la hora por defecto es las 08:00 local. list_ai_tasks y update_ai_task permiten pausar, reanudar o reprogramar desde la conversación.

Ejecutar ahora y desactivar

El botón Ejecutar ahora lanza una corrida inmediata (sin mover la programación) y abre la ejecución resultante: es la forma de probar una tarea nueva. Desmarcar Activo la pausa sin borrar su historial; archivar el agente también la detiene.

27.Ejecuciones: qué pasó en cada corrida

Cada corrida de una tarea deja una ejecución con la respuesta completa del agente, cada herramienta que llamó, los tokens, el costo, el instantánea de KPI, las acciones encoladas y el error si lo hubo.

Estados

• En cola: corridas por evento esperando a que el cron las tome.
• En ejecución: con una reserva (lease) de tiempo; si el servidor muere a mitad, otro trabajador la retoma cuando la reserva vence, hasta un máximo de dos intentos; después queda en error con el motivo.
• Éxito: el agente terminó y, si corresponde, envió lo que debía.
• Pendiente de aprobación: terminó dejando acciones en la cola (modo aprobación).
• Error: el agente no pudo terminar (proveedor caído sin respaldo, presupuesto agotado, agente archivado, excepción interna); el detalle está en la pestaña Error.

Las pestañas

Retroalimentación y recetas

La ejecución admite retroalimentación (👍/👎 y nota) del dueño, igual que los mensajes del chat, y el botón Extraer recetas propone como recetas en borrador las consultas SQL y agrupaciones de la corrida (capítulo 22). Una corrida buena se convierte así en un activo reutilizable; una mala, en una pista de modelo o una corrección de las instrucciones.

28.Modo aprobación y acciones pendientes

El agente propone, una persona decide. En modo aprobación cada escritura, método, acción de servidor o correo se convierte en una acción pendiente con vista previa, que se aprueba o rechaza desde Odoo —de forma idempotente y sin saltarse las políticas.

La tarea «Seguimiento de cobranza» del ambiente de demostración corre en modo aprobación: revisa la cartera, y para cada cliente con saldo vencido propone una nota de seguimiento en el contacto y un correo a contabilidad. Nada de eso se ejecuta solo: queda en MRDC AI → Acciones pendientes.

Qué se encola

Las herramientas de lectura, los reportes y los documentos se ejecutan normalmente: lo que se encola es solo lo que cambia datos o sale de Odoo. El agente recibe como resultado de la herramienta «quedó en cola como acción pendiente #N» y sigue trabajando; su resumen final lista lo propuesto.

Aprobar y rechazar

• Aprobar ejecuta la acción en ese momento como el dueño de la tarea, vuelve a evaluar las políticas del agente (modelos, métodos, dominios de correo, límite de registros) y guarda el resultado o el error en la propia acción.
• Antes de ejecutar, comprueba que el registro no cambió desde que el agente lo propuso (compara la fecha de modificación guardada al encolar): si alguien lo editó entretanto, la acción falla con «el registro cambió» para no pisar trabajo ajeno.
• La aprobación es idempotente y con bloqueo: dos personas pulsando Aprobar a la vez no ejecutan dos veces; la segunda recibe «ya no está pendiente».
• Rechazar la descarta con su estado. Aprobar todo / Rechazar todo en la tarea o en la ejecución resuelven todas las pendientes de una vez.
• Al encolar, el módulo deduplica: la misma acción con los mismos argumentos en la misma corrida no se encola dos veces (clave de idempotencia con índice único), aunque el modelo la repita.

29.Tareas por evento: reaccionar a lo que pasa en Odoo

En lugar de un horario, un disparador: cuando se crea una oportunidad, cuando se confirma un pedido, cuando llega una factura. La tarea recibe los registros que la dispararon, se deduplica y se procesa en cola con reintentos.

Cómo se arma

1. Cree la tarea con Tipo de disparador = Evento, elija el modelo (por ejemplo crm.lead) y los minutos de deduplicación: el mismo registro no vuelve a disparar la tarea dentro de esa ventana aunque se guarde varias veces.
2. Pulse Crear acción de servidor. El módulo genera una acción de servidor de código sobre ese modelo que llama a run_for_records(records) de la tarea. Esa acción aparece en el menú Acción de la lista del modelo (para dispararla a mano sobre una selección) y puede engancharse a una automatización de Odoo (al crear, al actualizar, al cambiar de etapa) si la aplicación de automatizaciones está instalada.
3. Escriba las instrucciones pensando en que «los registros disparadores vienen en el contexto del evento»: el agente recibe el modelo, los ids y los nombres de los registros.

Qué pasa al dispararse

• run_for_records descarta los registros ya procesados dentro de la ventana de deduplicación, crea una ejecución en cola con los ids y despierta el cron.
• El cron toma la ejecución con bloqueo, la marca en ejecución con una reserva de tiempo y la corre con el agente y el dueño de la tarea. Si el trabajador muere, la reserva vence y otro la retoma (máximo dos intentos).
• El agente trabaja con el contexto del evento y sus herramientas; en la demostración, lee la oportunidad, el historial del cliente y publica una nota interna con call_method → message_post.

30.Memoria y KPIs de las tareas

Una tarea que corre cada semana debe recordar los criterios que fijó y los números de la semana pasada. Tiene su propia memoria y guarda una instantánea de KPI en cada corrida; ambos se le inyectan en la siguiente.

Memoria de la tarea

En la pestaña Memoria de la tarea hay pares clave/valor con su origen. Los crea el agente con la herramienta remember(clave, valor) durante una corrida («criterio de ventas: pedidos confirmados sin IVA; las cotizaciones no cuentan») o una persona a mano, y se borran con forget. En cada corrida el contexto de la tarea los lista bajo «Memoria de la tarea», de modo que una decisión de criterio tomada en agosto sigue aplicándose en noviembre.

Instantáneas de KPI

La herramienta save_kpis recibe un objeto plano de indicadores —en el caso práctico: period, sales_untaxed, invoiced_untaxed, collected, backlog_untaxed, receivable_total, receivable_60_plus, orders_count, invoices_count— y lo guarda en la ejecución (pestaña Instantánea de KPI). El campo Límite de historial de KPIs de la tarea define cuántos instantáneas anteriores se inyectan en la siguiente corrida (por defecto los últimos 8).

Para qué sirven juntos

• Comparativos baratos y coherentes: «vs. semana anterior» sale dla instantánea, no de una consulta nueva que podría usar un criterio distinto; las instrucciones del caso práctico dicen «usa las instantáneas cuando existan y la receta cuando no».
• Validaciones entre corridas: el agente puede detectar que la cartera subió 40 % en una semana y señalarlo como incidencia o hallazgo.
• Continuidad de criterio: si en una corrida se decidió excluir anticipos, la memoria lo conserva y la instrucción no tiene que reescribirse.

31.Caso práctico: el reporte semanal de ventas por correo

De principio a fin: una tarea que cada lunes a las 07:00 envía a gerencia un correo HTML con ventas, facturación, cobranza, backlog y cartera, validaciones y acciones recomendadas, usando solo recetas validadas y guardando sus KPIs para la semana siguiente.

1. El objetivo

Gerencia quiere, cada lunes a primera hora, un solo correo que responda: ¿cuánto vendimos la semana pasada y cómo se compara?, ¿cuánto facturamos y cobramos?, ¿qué pedidos llevan dos semanas sin facturar?, ¿cómo está la cartera y quién debe?, ¿qué cinco cosas hay que hacer esta semana? Y que nunca deje de llegar: si un dato falta, que lo diga en el correo en vez de no enviarlo.

2. Las piezas que hacen falta

1. Un agente con herramientas de Odoo, reportes y envío de correo; en la demostración, MRDC Assistant con GPT-5.4 y respaldo GPT-4.1 mini.
2. Las recetas de ventas, facturación, cobranza, backlog y cartera, validadas (capítulo 22). Son las que hacen que la corrida sea exacta y barata.
3. Las pistas de modelo de sale.order, account.move y account.partial.reconcile, por si una receta falla y el agente tiene que consultar por su cuenta.
4. La tarea: semanal, lunes 07:00 hora de Guatemala, modo autónomo, con permiso de correo, sin escrituras, dueño el gerente comercial, con Límite de historial de KPIs 8 y una memoria inicial con el criterio de ventas.

3. Las instrucciones

Las instrucciones completas están en la figura del capítulo 26. Su estructura es la que recomendamos para cualquier reporte recurrente:

• Qué enviar, a quién y la regla de oro: «el correo SIEMPRE se envía; si una fuente falla, la sección lleva ⚠️ SIN DATO y la incidencia va al anexo».
• Parámetros: compañía, moneda y formato de números, la definición exacta de la ventana (semana ISO anterior, con la conversión UTC/hora local para campos datetime).
• Fuentes: receta por receta, con qué parámetros y para qué sección; «usa SIEMPRE run_recipe; si una falla, get_model_hint antes que get_fields».
• Memoria: leer la memoria y las instantáneas; al final, save_kpis con la lista exacta de indicadores.
• Validaciones numeradas (V1 subtotales, V2 la semana no supera al rango que la contiene para la misma métrica, V3 fórmula de la variación) con la aclaración de que van al anexo y no bloquean.
• Formato del correo: asunto con cifras, secciones numeradas, semáforo de KPIs con la regla de colores, tablas con sus columnas, acciones recomendadas con responsable y fecha, anexo, firma.
• Reglas de redacción y el cierre: «envía una sola vez con send_email; no busques crons ni revises mail.mail; termina con un resumen de 3 líneas».

4. La corrida

Con Ejecutar ahora la tarea corre y abre su ejecución: 14 llamadas a herramientas (11 recetas, save_kpis, un documento y send_email), unos 71.000 tokens de entrada y 0,22 USD. La respuesta final del agente es el resumen de tres líneas; el correo ya está en la bandeja del gerente.

5. Lo que aprendimos poniéndolo en producción

32.Misiones: trabajo largo y autónomo

Para objetivos que no caben en una respuesta —revisar todo un catálogo, depurar una cartera de contactos, preparar un cierre— el agente planifica, ejecuta paso a paso con notas de trabajo y reintentos, y deja las escrituras a la aprobación de una persona.

Una misión (MRDC AI → Misiones) tiene un objetivo en lenguaje natural, un agente, un dueño y permisos. Al iniciarla, el agente produce un plan de pasos; si la misión exige aprobación del plan, espera a que el dueño lo revise; después ejecuta los pasos uno a uno, cada uno con su propio presupuesto de herramientas, guardando notas de trabajo que los pasos siguientes leen, y termina con un resumen. Puede crearse desde el menú o desde el chat con start_ai_mission.

El formulario

Ciclo de vida

• Iniciar pasa a Planificando; el cron «Process Missions» (cada 5 minutos) o el botón Procesar ahora ejecutan la planificación. El plan aparece en la pestaña Plan como pasos numerados con descripción.
• En En ejecución, cada ciclo del cron procesa hasta mrdc_ai.mission_steps_per_cycle pasos (3 por defecto); cada paso se confirma por separado, así que un fallo nunca pierde el trabajo ya hecho. Un paso que falla se reintenta; a la tercera, la misión queda en Error con el motivo y puede reanudarse (los pasos fallidos vuelven a pendientes).
• Pausar detiene entre pasos; Reanudar continúa; Cancelar la cierra. Marcar como hecha la cierra sin más pasos.
• Mientras corre, la misión tiene una reserva de 30 minutos que se renueva en cada paso (latido); si un servidor muere, otro la retoma al vencer la reserva.

Las herramientas propias de la misión

Además de las del agente, en una misión el modelo dispone de complete_step (cerrar el paso con un resumen factual), update_working_notes (añadir o reemplazar las notas de trabajo que leerán los siguientes pasos) y, en la planificación, propose_plan. Las herramientas de chat (programar tareas, recordar) se retiran.

33.Temas y herramientas especializadas

Los temas agrupan instrucciones y herramientas por especialidad y se asignan a los agentes. Son la forma de que dos agentes compartan un método de trabajo sin duplicar prompts.

En Configuración → Temas hay tres de fábrica: Consultas en lenguaje natural (descubrimiento automático de modelos y campos), Generación de reportes (tablas y análisis) y Navegación de datos (llevar al usuario a registros y vistas). Cada tema tiene nombre, descripción, secuencia y un bloque de instrucciones que se anexa al prompt del agente que lo tenga.

Cuándo crear un tema

• Cuando dos o más agentes necesitan la misma especialidad («cómo analizamos la cartera en esta empresa», «cómo se redactan las notas al cliente»).
• Cuando quiere poder activar o desactivar un bloque de instrucciones sin editar el prompt de cada agente.
• Cuando una integración añade herramientas propias (por ejemplo un módulo de mensajería o de comercio electrónico): el tema es el lugar natural para describir cómo y cuándo usarlas.

34.Seguridad y permisos

El módulo no inventa un sistema de permisos: usa los de Odoo. Cada usuario ve sus conversaciones, tareas y misiones; los administradores ven todo; y el agente nunca puede más que la persona en cuyo nombre actúa.

Dos niveles de usuario

Reglas de registro

• Conversaciones y mensajes: solo el dueño (y el administrador).
• Tareas, ejecuciones y acciones pendientes: el dueño de la tarea; las acciones pendientes de una misión, el dueño de la misión.
• Misiones y pasos: el dueño.
• Memorias: lectura de las propias, las de sus conversaciones y las compartidas del agente; escritura solo de las propias y de conversación; las de agente, solo administradores.
• Fuentes de conocimiento e insights: por compañía (globales o de las compañías permitidas del usuario).

El agente actúa como el usuario

Todas las herramientas se ejecutan con el usuario de la conversación, o con el dueño de la tarea o misión en las corridas desatendidas. Las búsquedas devuelven lo que ese usuario puede leer; las escrituras fallan con el mismo error de acceso que tendría en la interfaz; los reportes oficiales verifican la lectura de los registros; las aprobaciones se ejecutan como el dueño de la tarea. La única excepción deliberada es la escritura de la retroalimentación 👍/👎, que se hace con privilegios elevados después de comprobar que quien vota es el dueño de la conversación.

Protecciones adicionales

• Adjuntos: tipos y tamaños limitados, verificación del tipo real; los adjuntos generados por el agente se ligan a su mensaje; la base de conocimiento comprueba el permiso del adjunto o registro original antes de mostrar un pasaje.
• Secretos: la memoria rechaza claves y contraseñas; el SQL de solo lectura bloquea las tablas de credenciales y parámetros; las claves de proveedores no se leen desde herramientas.
• Listas de bloqueo fijas en métodos y modelos sensibles (capítulo 15) y las políticas por agente (capítulo 9).
• Cancelación y topes de iteraciones, de herramientas por ronda y de tiempo por petición: ningún mensaje puede girar indefinidamente.
• Transacciones: cada herramienta corre en un punto de guardado; si falla, se revierte solo ella y el agente recibe el error; la respuesta sigue. El SQL es de solo lectura por construcción.
• Concurrencia: las tareas, las corridas por evento y las misiones se toman con bloqueo y reserva; las aprobaciones son idempotentes; el encolado deduplica con índice único.

35.Costos y presupuesto

Cada token cuesta. El módulo lo cuenta por mensaje, por corrida y por paso, lo convierte a dólares con la tabla de precios y lo frena con dos presupuestos: el global y el de cada agente.

Dónde se ve el costo

Qué hace subir el costo y cómo bajarlo

Los presupuestos

• Global (Ajustes): al alcanzarse, toda llamada nueva de cualquier agente se rechaza con «El presupuesto mensual global de IA se agotó».
• Por agente: aviso único al 80 % (notificación interna al usuario y al administrador) y rechazo al 100 %.
• Ambos se reinician con el mes calendario y se evalúan al inicio de cada petición; las tareas programadas que se rechazan quedan en error con ese motivo y vuelven a intentarlo en su siguiente programación.

36.Automatizaciones internas y observabilidad

Tres acciones planificadas mueven el módulo por detrás, y todo lo que el agente hace deja rastro: en la interfaz, en los registros y en el log del servidor.

Las acciones planificadas

Qué se registra y dónde mirarlo

• En la interfaz: cada mensaje y cada paso conservan las llamadas a herramientas con argumentos, resultado recortado, duración en milisegundos y tamaño del resultado; las ejecuciones y misiones guardan estado, error, tokens y costo; las acciones pendientes, su resultado o error al aprobarse.
• En tiempo real: la línea de tiempo del panel recibe por el bus de Odoo cada herramienta que empieza y termina, con su etiqueta en español («Ejecutando receta sales_orders_in_period», «Generando reporte Libro de ventas»).
• En el log del servidor: las llamadas a proveedores con su modelo, los reintentos y los cambios a modelo de respaldo, cada herramienta ejecutada (nivel INFO), los errores de herramienta con traza (ERROR) y los avisos de transacciones recuperadas.

Salud del sistema en tres preguntas

1. ¿Corren las tareas cuando deben? Tareas programadas → Próxima ejecución en el pasado con Última ejecución antigua significa que el cron no está corriendo o que la tarea está fallando: mire la última ejecución.
2. ¿Se está gastando lo esperado? Agentes → Este mes; Ejecuciones ordenadas por costo; mensajes con 👎.
3. ¿Hay trabajo atascado? Ejecuciones en En ejecución con reserva vencida (se retoman solas), misiones en Error (reanudar tras corregir), acciones pendientes antiguas (aprobar o rechazar).

37.Resolución de problemas

Los mensajes de error del módulo están pensados para decir qué pasó y qué hacer. Esta tabla reúne los más frecuentes, su causa y la salida.

38.Buenas prácticas: instrucciones, prompts y mejora continua

Lo que separa un asistente que impresiona el primer día de uno que sigue siendo útil en el mes seis es la disciplina con que se escriben las instrucciones y se capitalizan los errores.

Escribir instrucciones para tareas y misiones

1. Una sola salida y una regla de oro. «Envía UN correo a X» y «el correo SIEMPRE se envía; si falta un dato, dilo dentro». Un agente sin salida obligatoria encuentra razones para no entregar.
2. Defina los términos. «Ventas = pedidos confirmados (state = sale), sin IVA, por date_order en la zona America/Guatemala». Cada palabra ambigua («ventas», «cobrado», «vencida») es una base de cálculo distinta en manos del modelo.
3. Nombre las fuentes. Recetas por nombre y con qué parámetros; si no hay receta, el modelo y los campos. «Usa SIEMPRE run_recipe» ahorra la mitad del costo.
4. Numere las validaciones y diga qué pasa si fallan. «V1…, V2…; si falla, va al anexo como incidencia; no bloquea el envío.» Y limite cada validación a lo que compara: «la misma métrica».
5. Describa el formato con precisión: asunto con cifras, secciones, columnas de cada tabla, fila de totales, reglas de redacción (nombres cortos, sin tablas repetidas, números junto a cada afirmación), firma.
6. Cierre el bucle: «envía una sola vez; la respuesta de la herramienta es la confirmación; no revises crons ni correos; termina con un resumen de 3 líneas».
7. Pruebe con Ejecutar ahora, lea la traza de herramientas y el resultado, corrija la instrucción —no el resultado— y repita hasta que dos corridas seguidas salgan bien.

Escribir el prompt del sistema

• Rol, tono, idioma, formato de números y moneda, y las 5–10 reglas del negocio que nunca cambian. Nada más.
• Todo lo que empiece con «cuando consultes el modelo X…» va a una pista de modelo.
• Toda consulta que se repite va a una receta.
• Todo dato que cambia (responsables, políticas, promociones) va a la memoria del agente o a la base de conocimiento.

Capitalizar los errores

Operación

• Un agente por rol (gerencia, ventas, cobranza) con capacidades mínimas; no un superagente para todos.
• Empezar las tareas con escritura en modo aprobación; pasar a autónomo tras varias corridas aprobadas sin cambios.
• Revisar semanalmente: 👎 del historial, ejecuciones en error, acciones pendientes viejas, hallazgos abiertos, gasto por agente.
• Revisar trimestralmente: precios de modelos, modelos nuevos más baratos, recetas que ya nadie usa.

39.Referencia rápida de herramientas

Las 40 herramientas que el agente puede recibir, con sus parámetros principales, la capacidad que las habilita y el grupo al que pertenecen en el modo de selección bajo demanda.