Cerramos el módulo 1 con la lista de nueve casos de uso candidatos de NovaMarket y con la promesa de construir los cimientos conceptuales. Empezamos por el más importante de todos: la noción de agente inteligente. Casi todo lo que verás en el resto del curso (un recomendador, un planificador de rutas, un asistente de atención al cliente, incluso un modelo de lenguaje) puede describirse como un agente que percibe su entorno, decide y actúa. Aprender a describir un sistema en esos términos, y a caracterizar el entorno en el que opera, es lo que permite elegir después la técnica adecuada: no se resuelve igual un problema en un entorno determinista y totalmente observable que en uno estocástico y parcialmente observable. En esta lección definiremos qué es un agente y su ciclo percibir-decidir-actuar, qué significa que actúe racionalmente, cómo describir cualquier sistema con el esquema PEAS, qué propiedades tienen los entornos, qué tipos de agente existen y, como puente hacia el módulo 3, cómo se formula un problema para que un agente pueda resolverlo. Todo ello aplicado a tres sistemas de NovaMarket: el asistente de atención al cliente, el recomendador y el planificador de rutas.

1. Qué es un agente inteligente
2. El ciclo percibir-decidir-actuar
3. Racionalidad y medida de rendimiento
4. La descripción PEAS aplicada a NovaMarket
5. Propiedades de los entornos
6. Tipos de agente
7. Formulación de un problema: puente hacia el módulo 3
8. Ejemplo en Python: del agente reflejo al agente basado en utilidad

En la lección 01-02 adoptamos la visión de la IA como la construcción de sistemas que actúan racionalmente. El concepto que hace operativa esa definición es el de agente. Un agente es cualquier cosa que:

• percibe su entorno a través de sensores, y
• actúa sobre ese entorno a través de actuadores.

La definición es deliberadamente amplia. Un termostato es un agente (sensor: termómetro; actuador: interruptor de la caldera). Un robot de almacén es un agente (sensores: cámaras, lectores de códigos de barras, encoders de las ruedas; actuadores: motores, pinza). Y un programa que responde correos también lo es, aunque no tenga cuerpo: sus sensores son las entradas de datos que recibe (el texto del correo, la base de datos de pedidos) y sus actuadores son las salidas que produce (un correo de respuesta, una llamada a la API del almacén). A los agentes puramente de software se les llama a veces agentes software o softbots.

Vocabulario básico que usaremos en todo el curso:

Fíjate en la distinción entre función y programa del agente. La función es una descripción abstracta ("qué debería hacer ante cada historial de percepciones"); el programa es cómo lo conseguimos. El chatbot de reglas que NovaMarket abandonó en 2015 y un asistente moderno basado en un modelo de lenguaje pueden aspirar a la misma función; lo que cambia radicalmente es el programa. Y aquí aparece la idea central del curso: en muchos casos la función es demasiado compleja para escribirla a mano regla a regla (que es lo que fracasó en 2015), así que se aprende a partir de datos, exactamente el cambio de paradigma que vimos en 01-02.

Todo agente, por simple o sofisticado que sea, repite el mismo bucle:

1. Percibir: los sensores capturan el estado (o una parte del estado) del entorno.
2. Decidir: el programa del agente, a partir de la percepción actual y, según el tipo de agente, de lo que recuerde, elige una acción.
3. Actuar: los actuadores ejecutan la acción, que modifica el entorno.
4. El entorno cambia (por la acción del agente y, a menudo, por sí mismo), y el ciclo vuelve a empezar.

Veámoslo con el recomendador que construimos al final de 01-03. En cada visita de un cliente a la ficha de un producto:

• Percepción: el producto que está viendo (y, en versiones más avanzadas, su historial y su carrito).
• Decisión: la función recomendar, que consulta la tabla de co-compras y elige los productos con más coincidencias.
• Acción: mostrar esos productos en la caja "también compraron".
• Cambio del entorno: el cliente hace clic (o no), añade al carrito (o no); si registramos eso, la próxima vuelta del bucle tendrá más datos.

Este último punto es importante: cuando las acciones del agente influyen en las percepciones futuras (lo que recomiendas hoy cambia lo que se compra mañana), el agente y el entorno forman un sistema cerrado, y eso tiene consecuencias que veremos al hablar de entornos secuenciales.

Un agente que percibe y actúa no es necesariamente inteligente: el ELIZA de 01-01 percibía y actuaba. Lo que distingue a un agente racional es que elige, en cada momento, la acción que maximiza el valor esperado de su medida de rendimiento, dada la evidencia que le aportan sus percepciones y el conocimiento que tenga incorporado.

Desmenucemos la frase, porque cada pieza importa:

• Medida de rendimiento: el criterio con el que se evalúa el éxito del agente. Lo fija el diseñador, no el agente, y siempre debe expresar lo que queremos conseguir en el entorno, no cómo creemos que el agente debería comportarse. Es la parte más delicada del diseño.
• Valor esperado: como el agente rara vez tiene certeza sobre las consecuencias de sus acciones, se evalúan en promedio, ponderando por su probabilidad. Un recomendador no sabe si el cliente comprará, pero puede estimar que la probabilidad es mayor con un producto que con otro.
• Dada la evidencia y el conocimiento: la racionalidad se juzga con lo que el agente sabe, no con lo que se sabe a posteriori. Un planificador de rutas que elige la autopista y se encuentra un accidente imprevisto no ha sido irracional; habría sido irracional ignorar un aviso de tráfico que ya tenía.

Racionalidad no es lo mismo que omnisciencia (saber el resultado real de cada acción) ni que perfección (acertar siempre). Es "hacer lo mejor posible con lo que se sabe". Y un agente racional debe también recopilar información (preguntar al cliente el número de pedido antes de responder) y aprender de la experiencia cuando el entorno lo permite. Un agente cuyo comportamiento depende solo de lo que le programaron sus diseñadores tiene poca autonomía; uno que corrige sus decisiones con lo que percibe tiene más.

Elegir mal la medida de rendimiento produce agentes que "hacen trampas": optimizan exactamente lo que se les pidió, que no era lo que queríamos. Diego lo describe con una anécdota real de NovaMarket: durante un tiempo el equipo de atención al cliente cobraba un incentivo por "conversaciones cerradas por hora"; el resultado fue que muchas conversaciones se cerraban sin resolver el problema. Un agente artificial hace exactamente lo mismo, solo que más rápido y sin sentir vergüenza. Compara estas posibles medidas para el asistente:

La última fila es más compleja, pero es la que refleja el objetivo real. Regla práctica: define la medida de rendimiento en términos del resultado deseado en el entorno, combina varios criterios si hace falta, y pregúntate siempre "¿qué haría un agente que quisiera maximizar esto sin importarle nada más?". Retomaremos esta idea en 02-04 (ética) y en 04-05 (evaluación de modelos).

Para diseñar un agente conviene empezar por describir su entorno de tareas con cuatro elementos, que se recuerdan con el acrónimo PEAS:

• Performance (medida de rendimiento): ¿cómo se mide el éxito?
• Environment (entorno): ¿en qué mundo actúa? ¿qué hay ahí fuera?
• Actuators (actuadores): ¿qué puede hacer?
• Sensors (sensores): ¿qué puede percibir?

Vamos a aplicarlo a tres de los casos de uso de NovaMarket. Marta y Diego rellenaron esta tabla en una reunión, y es un buen ejercicio de cómo PEAS obliga a hacerse las preguntas correctas antes de escribir una línea de código:

Observaciones que salen de la tabla:

• En los tres casos la medida de rendimiento es compuesta: nunca es una sola cifra. Diego insistió en incluir el coste en las tres.
• El entorno del planificador de rutas es físico y cambia por sí solo (el tráfico); el del recomendador es puramente digital. Eso afectará a la técnica.
• Los sensores del asistente incluyen "historial de la conversación": es la pista de que el asistente necesitará memoria (lo veremos en los tipos de agente).

Cuando en el módulo 8 abordemos cómo desarrollar un proyecto de IA, la descripción PEAS será uno de los primeros entregables.

No todos los entornos son igual de difíciles. Se caracterizan con seis dimensiones, y la combinación determina qué técnicas son viables:

Algunos ejemplos clásicos para calibrar la intuición: un crucigrama es totalmente observable, determinista, secuencial, estático, discreto y monoagente (el caso más fácil). El ajedrez es igual salvo que es multiagente (competitivo). Un taxi autónomo es parcialmente observable, estocástico, secuencial, dinámico, continuo y multiagente (el caso más difícil, y por eso costó tanto). El póker añade a lo del ajedrez la observabilidad parcial (no ves las cartas del rival) y el azar del reparto.

Clasifiquemos ahora los tres sistemas de NovaMarket:

Conclusiones prácticas de la clasificación:

• Ninguno de los tres es el "caso fácil". En el mundo real casi ningún problema lo es; los entornos totalmente observables y deterministas aparecen sobre todo en juegos y puzles, que es donde el módulo 3 introducirá los algoritmos de búsqueda antes de complicarlos.
• La observabilidad parcial y la estocasticidad son las que empujan hacia el aprendizaje automático (módulo 4) y el razonamiento con incertidumbre (06-03): si no puedes ver todo ni predecir con certeza, necesitas estimar.
• El carácter dinámico del planificador de rutas obliga a que el agente sea rápido y pueda replanificar: no sirve un algoritmo perfecto que tarde tres horas.
• El recomendador parece el más sencillo (estático, discreto, casi episódico), y por eso NovaMarket acertó al elegirlo como primer proyecto.

Los agentes se organizan en una escala de sofisticación creciente según qué información usan para decidir. Cada nivel incluye al anterior:

Decide mirando solo la percepción actual, mediante reglas condición-acción: "si el mensaje contiene 'dónde está mi pedido', responde con el estado del envío". Es rápido y fácil de entender, pero:

• Solo funciona bien si el entorno es totalmente observable: si la percepción actual no basta para decidir, se equivoca.
• No tiene memoria: si el cliente dio el número de pedido en el mensaje anterior, este agente ya no lo sabe.
• Puede entrar en bucles (repetir la misma pregunta una y otra vez).

El chatbot de 2015 de NovaMarket era exactamente esto, y su fracaso fue en gran parte por operar en un entorno parcialmente observable y secuencial con una arquitectura pensada para entornos totalmente observables y episódicos.

Añade un estado interno: una representación de lo que el agente cree que ocurre en el mundo, mantenida con dos tipos de conocimiento: cómo evoluciona el mundo por sí solo y qué efecto tienen las propias acciones. En el asistente, el estado interno es el contexto de la conversación (número de pedido ya identificado, si ya se ofreció una devolución, cuántas veces ha preguntado lo mismo el cliente). Sigue decidiendo con reglas, pero ahora las reglas pueden consultar la memoria. Esto resuelve la observabilidad parcial dentro de una conversación.

Las reglas dicen "qué hacer", pero no "para qué". Un agente basado en objetivos tiene una descripción explícita de la meta (entregar todos los pedidos del día dentro de su franja) y elige acciones razonando sobre sus consecuencias: "si voy primero a Delicias y luego a Actur, ¿alcanzo la meta?". Esto es más flexible: si cambia el objetivo (por ejemplo, priorizar un pedido urgente), no hay que reescribir las reglas, basta cambiar la meta. La contrapartida es que decidir exige buscar o planificar entre secuencias de acciones, que es lo que estudia el módulo 3.

Un objetivo dice si un estado es bueno o malo (binario). Pero muchas veces hay muchas formas de alcanzar la meta y unas son mejores que otras: llegar a todas las entregas es la meta, pero hacerlo en 6 horas es mejor que en 8, y molestar a un cliente con una llamada tiene un coste. Una función de utilidad asigna a cada estado (o resultado) un número que expresa cuánto lo valora el agente, y el agente racional elige la acción que maximiza la utilidad esperada. Es la traducción directa de la definición de racionalidad de la sección 3: la utilidad interna del agente debería coincidir con la medida de rendimiento externa. En el recomendador, la utilidad de recomendar un producto podría combinar la probabilidad de compra, el margen y una penalización por repetir siempre lo mismo.

Cualquiera de los anteriores puede además aprender: mejorar su función de decisión a partir de la experiencia. Conceptualmente tiene cuatro componentes: el elemento de actuación (el agente tal como lo hemos descrito), el elemento de aprendizaje (que lo modifica), el crítico (que compara los resultados con la medida de rendimiento e informa al elemento de aprendizaje) y el generador de problemas (que propone acciones exploratorias para descubrir cosas nuevas, como recomendar de vez en cuando un producto poco visto para ver si funciona). El módulo 4 dedica seis lecciones a cómo se aprende; aquí basta con situarlo en el mapa. Nuestro aprender_umbral de 01-02, que sustituyó el 300 € de Diego por 120 €, era un elemento de aprendizaje rudimentario.

Tabla resumen:

Cuando un agente basado en objetivos tiene que decidir qué secuencia de acciones le lleva a la meta, el primer paso es formular el problema de manera precisa. La formulación estándar tiene cinco componentes:

1. Estado inicial: dónde empieza el agente. Ejemplo: la furgoneta está en el almacén de Getafe con 40 pedidos cargados.
2. Acciones: qué puede hacer en cada estado. Ejemplo: desplazarse a cualquiera de las paradas pendientes.
3. Modelo de transición: qué estado resulta de aplicar una acción en un estado. Ejemplo: "ir a la parada 7" lleva a un estado con la furgoneta en la parada 7 y 39 pedidos pendientes.
4. Test de objetivo: cómo se reconoce que se ha alcanzado la meta. Ejemplo: no quedan pedidos pendientes y la furgoneta ha vuelto al almacén.
5. Coste del camino: un número que mide el coste de una secuencia de acciones. Ejemplo: kilómetros o minutos acumulados.

Con estos cinco elementos, resolver el problema consiste en encontrar una secuencia de acciones (un camino en el espacio de estados) que lleve del estado inicial a un estado objetivo, idealmente con coste mínimo. Aquí no vamos a resolver nada: los algoritmos que hacen esa búsqueda (anchura, profundidad, coste uniforme, A*) son el contenido de la lección 03-02, y las técnicas para cuando el espacio es demasiado grande para explorarlo entero, el de 03-04. Lo que sí conviene retener ahora son dos ideas:

• La formulación es una abstracción: eliminamos todos los detalles irrelevantes (el color de la furgoneta, la música que escucha el conductor) y nos quedamos con lo que afecta a la decisión. Elegir bien el nivel de abstracción es media solución.
• El coste es la versión "de búsqueda" de la medida de rendimiento: si defines mal el coste (solo kilómetros, olvidando las franjas horarias), el agente encontrará caminos óptimos para el problema equivocado.

Un segundo ejemplo, más discreto: el diagnóstico de una incidencia (caso 9). Estado inicial: incidencia abierta con síntomas conocidos. Acciones: hacer una comprobación (¿llegó el paquete?, ¿está dañado?, ¿coincide la referencia?). Transición: cada comprobación revela información y reduce las causas posibles. Objetivo: causa identificada. Coste: número de comprobaciones o tiempo del operador. Retomaremos este caso en el módulo 6 con sistemas expertos.

Vamos a construir un asistente de atención al cliente en miniatura y a hacerlo evolucionar por tres de los niveles de la sección 6. Usaremos solo Python estándar. El objetivo no es un asistente útil, sino ver en código qué diferencia a cada tipo de agente.

Salida:

Explicación línea a línea:

• reglas es una lista de pares (condicion, accion). Cada condición es una función anónima (lambda) que recibe la percepción y devuelve True si la regla se aplica. Esta es la esencia del agente reflejo: una tabla percepción → acción.
• percibir es el sensor: convierte el mensaje bruto en algo comparable (minúsculas, sin espacios sobrantes). Fíjate en lo frágil que es: si la primera regla buscara la frase completa "donde esta mi pedido" (sin tildes), el mensaje real "¿dónde está mi pedido?" (con tildes) no la activaría y el agente derivaría a humano sin motivo. Por eso la regla busca solo la palabra "pedido". Los agentes reflejo basados en cadenas de texto fallan ante variaciones triviales (tildes, sinónimos, erratas), y ampliar las reglas para cubrirlas todas es una carrera sin fin: es una de las razones por las que el procesamiento del lenguaje natural acabó recurriendo al aprendizaje (módulos 4 y 5).
• El segundo mensaje, "Es el 48213", es la respuesta a la pregunta del agente. Pero el agente reflejo no recuerda que acaba de preguntar por un número de pedido, así que no reconoce la respuesta y deriva a humano. Este es el fallo estructural del agente reflejo en un entorno secuencial, y exactamente el tipo de conversación que rompía el chatbot de 2015.

Salida:

Explicación:

• self.estado es el estado interno: lo que el agente cree del mundo. Aquí solo guarda si está esperando un número de pedido y cuál es.
• actualizar_estado implementa el "modelo": usa una expresión regular (\b\d{4,6}\b, un número de 4 a 6 cifras aislado) para detectar el número de pedido, pero solo lo interpreta como tal si estaba esperándolo. Es la combinación de percepción actual y memoria.
• Cuando el agente pregunta por el número (informar_estado_envio), registra el efecto de su propia acción (esperando_pedido = True). Esto es el segundo tipo de conocimiento del agente basado en modelo: qué efecto tienen mis acciones sobre el mundo (en este caso, sobre la conversación).
• El resultado: la misma conversación que rompía al agente reflejo ahora fluye. Con muy poco código hemos pasado de un agente inadecuado para entornos secuenciales a uno que los tolera. En un asistente real el estado sería mucho más rico (intención detectada, productos mencionados, tono del cliente), y con modelos de lenguaje ese "estado" es en gran medida el propio historial de la conversación (lo veremos en 05-05).

Supongamos ahora que, ante una queja por un retraso, el asistente tiene tres acciones posibles y quiere elegir la de mayor utilidad esperada. Para cada acción estimamos la probabilidad de que el cliente quede satisfecho y el coste para NovaMarket:

Salida:

Explicación:

• utilidad_esperada es la función de utilidad: traduce a un número lo que NovaMarket valora (un cliente satisfecho "vale" 15 € en fidelidad futura, cifra que Marta estimó a partir de la recompra media) menos lo que cuesta la acción.
• Cada acción tiene un resultado incierto (el cliente puede quedar satisfecho o no), por eso multiplicamos por la probabilidad: es la "esperanza" de la definición de racionalidad.
• elegir_accion recorre las opciones y se queda con la de mayor utilidad esperada. Aquí gana la disculpa: el cupón aumenta mucho la satisfacción pero su coste lo penaliza. Prueba a cambiar valor_cliente_satisfecho a 40 (un cliente muy valioso) y verás que la decisión cambia a cupon_5_euros. Esa sensibilidad es una virtud: la política se adapta cambiando las preferencias, no reescribiendo reglas.
• ¿De dónde salen las probabilidades 0,55, 0,80 y 0,90? Aquí están escritas a mano. En un sistema real se aprenderían de los datos históricos de incidencias y encuestas: ese es el paso al agente que aprende, y el contenido del módulo 4.

Con estos tres fragmentos has visto la escalera completa: reglas sobre la percepción actual, reglas más memoria, y elección por utilidad esperada. Un asistente moderno combina los tres niveles y añade aprendizaje.

• Confundir la medida de rendimiento con el comportamiento deseado. "Quiero que el asistente responda rápido" es un comportamiento; "quiero clientes satisfechos a bajo coste" es un resultado. Mide resultados, y pregúntate siempre cómo haría trampas un agente que optimizara ciegamente tu métrica.
• Juzgar la racionalidad a posteriori. Que una decisión salga mal no significa que fuera irracional. Evalúa con la información que el agente tenía en el momento de decidir.
• Elegir la arquitectura sin clasificar el entorno. El chatbot de 2015 fracasó por usar un agente reflejo en un entorno parcialmente observable y secuencial. Rellena la tabla de propiedades del entorno antes de decidir la técnica.
• Rellenar PEAS de forma vaga. "Entorno: internet" no sirve. Sé concreto: qué datos, qué usuarios, qué restricciones. La calidad del PEAS anticipa la calidad del proyecto.
• Sobredimensionar el agente. No todo necesita utilidad y aprendizaje. Si el entorno es realmente simple (una regla clara de negocio), un agente reflejo bien hecho es más barato, más rápido y más explicable. La sofisticación se justifica por el entorno, no por la moda.
• Olvidar el coste de las acciones. Diego tiene razón al insistir: una acción con gran probabilidad de éxito pero coste alto puede tener peor utilidad que una modesta y gratuita.
• Consejo: cuando te presenten cualquier sistema "inteligente", intenta rellenar mentalmente su PEAS y clasificar su entorno. En un minuto sabrás si el sistema es adecuado para el problema y qué puede fallar.

NovaMarket ha decidido empezar también por la previsión de demanda (caso 2): estimar cuántas unidades de cada producto se venderán la próxima semana para pedir a proveedores y reubicar stock entre Zaragoza y Getafe. Escribe su descripción PEAS y clasifica el entorno en las seis dimensiones, justificando cada una en una frase.

Para el planificador de rutas, indica qué comportamiento indeseado produciría cada una de estas medidas de rendimiento si fuera la única: (a) minimizar kilómetros totales; (b) maximizar entregas realizadas por hora; (c) minimizar quejas de clientes. Propón después una medida compuesta razonable.

Modifica AgenteConModelo para que, si el cliente repite tres veces una consulta que el agente no sabe resolver (acción derivar_a_humano), el agente lo detecte y añada al mensaje de derivación el texto "Veo que no consigo ayudarte". Necesitarás un contador en self.estado. Explica qué propiedad del entorno hace necesaria esta memoria.

Solución 1.

Entorno: parcialmente observable (no vemos las intenciones de los clientes ni las acciones de la competencia); estocástico (la demanda tiene azar); secuencial (una previsión errónea hoy deja stock que condiciona el mes siguiente; además, la propia recomendación y las promociones cambian la demanda); estático en el momento de calcular (se hace de noche con datos cerrados; el mundo no cambia durante el cálculo); discreto en las unidades, aunque las series temporales de ventas suelen tratarse como continuas; monoagente en primera aproximación (aunque la competencia y los proveedores son agentes que influyen). Es un problema de predicción típico de aprendizaje supervisado sobre series temporales, que se retomará en el módulo 4.

Solución 2.

• (a) Minimizar kilómetros: el agente agrupará paradas cercanas ignorando las franjas horarias prometidas; entregará tarde a quien esté "de paso" más adelante. También podría dejar pedidos sin repartir si eso reduce kilómetros (¡el mínimo es no salir!), salvo que se obligue a entregar todo.
• (b) Maximizar entregas por hora: premiará las entregas fáciles (portales accesibles, cliente en casa) y postergará las difíciles indefinidamente; incentiva a "marcar como entregado" sin comprobar.
• (c) Minimizar quejas: puede llevar a no prometer nunca franjas (no hay incumplimiento si no hay promesa) o a asignar recursos desproporcionados a los clientes que más se quejan.
• Medida compuesta: porcentaje de entregas dentro de la franja prometida (obligatorio entregar todo lo asignado) + coste total (kilómetros × coste por km + horas × coste por hora) + penalización por incumplimiento de jornada laboral + satisfacción del cliente en encuestas de entrega. Con pesos acordados con Diego.

Solución 3.

El tercer mensaje produce el texto ampliado. La memoria es necesaria porque el entorno es secuencial: la decisión correcta ante "necesito la factura" depende de cuántas veces se ha dicho ya, algo que la percepción actual, por sí sola, no contiene (observabilidad parcial de la conversación si no se guarda el historial). Nota: en este ejemplo simple el agente deriva a humano desde la primera vez; en un asistente real la derivación es una acción cara (ocupa a una persona) y el contador serviría para decidir cuándo escalar en lugar de seguir intentándolo.

En esta lección hemos definido el concepto que vertebra todo el curso: el agente inteligente, que percibe su entorno mediante sensores y actúa mediante actuadores en un ciclo continuo de percibir-decidir-actuar. Hemos precisado qué significa que un agente sea racional (elegir la acción que maximiza la medida de rendimiento esperada con la información disponible) y hemos visto que definir bien esa medida es la decisión de diseño más delicada. Hemos aprendido a describir cualquier sistema con el esquema PEAS y a clasificar su entorno en seis dimensiones (observabilidad, determinismo, episódico/secuencial, estático/dinámico, discreto/continuo, mono/multiagente), aplicándolo al asistente, al recomendador y al planificador de rutas de NovaMarket. Hemos recorrido la escalera de tipos de agente (reflejo simple, basado en modelo, basado en objetivos, basado en utilidad, que aprende) y la hemos visto en código con la evolución de AgenteReflejo a AgenteConModelo y a la elección por utilidad esperada. Por último, hemos presentado la formulación de problemas (estado inicial, acciones, transición, objetivo, coste) que el módulo 3 utilizará para resolverlos con algoritmos de búsqueda.

En la siguiente lección, Tipos de Inteligencia Artificial, cambiaremos de escala: en lugar de mirar dentro de un agente, clasificaremos los sistemas de IA en su conjunto según su capacidad (estrecha, general, superinteligencia), su funcionalidad (reactivos, con memoria limitada, teoría de la mente, autoconciencia) y otras dicotomías útiles, y situaremos en ese mapa los nueve casos de uso de NovaMarket. Verás que los "agentes reactivos" y "con memoria" que acabamos de programar tienen su correlato directo en esa clasificación.