Cómo construimos el agente de PropPilot: decisiones técnicas y lecciones

Hay una diferencia enorme entre usar inteligencia artificial y construir un producto con inteligencia artificial. Lo primero lo puede hacer cualquiera con acceso a ChatGPT. Lo segundo requiere cientos de decisiones de arquitectura, muchas de ellas invisibles para el usuario final.

En este artículo abrimos la puerta del taller. Vamos a compartir las cinco decisiones técnicas más importantes que tomamos al construir el agente de PropPilot, los errores que cometimos por el camino y lo que haríamos diferente si empezáramos hoy desde cero.

Lo hacemos por tres razones: porque creemos en la transparencia como valor de producto, porque queremos contribuir a la conversación sobre IA agéntica en el sector inmobiliario (un tema que ya exploramos en nuestro artículo sobre CRMs agénticos), y porque documentar lo aprendido nos obliga a reflexionar con rigor.

Decisión 1: El LLM es el cerebro, no el producto

La primera tentación cuando construyes con modelos de lenguaje es tratar al LLM como el producto. “Tenemos GPT-4, ya está.” Es un error que vimos repetirse en docenas de startups durante 2024 y 2025.

Nuestra decisión fundacional fue tratar al LLM como un componente reemplazable. El modelo es el cerebro, pero el producto es el sistema nervioso completo: la orquestación, las herramientas, la memoria, las barreras de seguridad y la lógica de negocio que lo rodean.

En la práctica, esto significa que podemos cambiar de proveedor de modelo --- y lo hemos hecho varias veces --- sin tocar la experiencia del usuario. Cuando un modelo nuevo es más rápido, más barato o más preciso en una tarea concreta, lo sustituimos. El agente sigue comportándose igual porque la inteligencia del producto no reside solo en el modelo.

Esta decisión tuvo un coste inicial alto: construir una capa de abstracción lleva tiempo. Pero cada vez que hemos necesitado migrar, actualizar o combinar modelos, el retorno ha sido enorme.

La lección: si tu producto se rompe cuando cambia el modelo, no tienes un producto. Tienes un wrapper.

Decisión 2: Arquitectura basada en herramientas

El agente de PropPilot no “sabe” nada sobre las propiedades de nuestros clientes. No tiene la base de datos memorizada, ni los horarios de los comerciales, ni los precios actualizados. Lo que tiene son herramientas.

Adoptamos una arquitectura de tool-calling desde el primer día. Cuando un lead pregunta “¿Tenéis pisos de tres habitaciones en Chamberí?”, el agente no responde de memoria. Invoca una herramienta que consulta la base de datos de propiedades del promotor, filtra por los criterios relevantes y devuelve resultados actualizados.

Las herramientas principales del agente incluyen:

• Consulta de inventario: búsqueda en la base de datos de propiedades con filtros por zona, precio, tipología, disponibilidad.
• Gestión de calendario: comprobación de disponibilidad y creación de citas con comerciales.
• Perfil del lead: lectura y actualización del perfil del contacto en el CRM.
• Historial de conversación: recuperación de contexto de interacciones previas.
• Documentación del proyecto: acceso a materiales de venta, planos y fichas técnicas.

Este enfoque tiene una ventaja fundamental: los datos siempre están actualizados. El agente no puede decir que un piso está disponible si se ha vendido esa mañana, porque la herramienta consulta el dato en tiempo real.

La lección: un agente que “sabe” cosas es un agente que puede mentir. Un agente que consulta cosas es un agente que puede ser preciso.

Decisión 3: La memoria como ciudadano de primera clase

La mayoría de los chatbots tratan la memoria como un historial de chat: una lista de mensajes anteriores que se envía al modelo como contexto. Nosotros decidimos que eso no era suficiente.

En PropPilot, la memoria tiene estructura. No es solo “qué dijo el lead”, sino un perfil enriquecido que incluye:

• Preferencias explícitas: “Busco tres habitaciones, máximo 400.000 euros, cerca del metro.”
• Preferencias implícitas: si un lead siempre pregunta por la orientación, probablemente le importa la luz natural.
• Estado de la conversación: en qué punto del funnel está, qué información ya se le ha dado, qué objeciones ha planteado.
• Resúmenes de interacciones: no guardamos cada mensaje literal de conversaciones largas. Generamos resúmenes estructurados que capturan lo esencial.

Esta memoria estructurada permite algo que el historial de chat no puede: continuidad real entre canales. Si un lead habla por WhatsApp el lunes y por el formulario web el miércoles, el agente retoma la conversación donde la dejó, con todo el contexto.

La lección: la memoria no es un log. Es un modelo del cliente que se enriquece con cada interacción.

Decisión 4: Guardrails desde el día uno

Sabíamos que un agente inmobiliario que alucina es peor que no tener agente. Si el agente inventa un precio, una superficie o una condición contractual, el daño es real: legal, financiero y reputacional.

Por eso diseñamos un sistema de barreras de seguridad desde la primera iteración:

• Datos factuales solo de fuentes verificadas: el agente nunca genera datos numéricos (precios, superficies, plazos de entrega) por sí mismo. Siempre los obtiene de herramientas que consultan la base de datos del promotor.
• Restricciones explícitas de comportamiento: el agente tiene un conjunto de reglas que definen lo que no puede hacer. No puede negociar precios. No puede hacer promesas de entrega. No puede dar asesoría legal o fiscal.
• Validación de respuestas: antes de enviar ciertos tipos de respuestas, un segundo proceso verifica que los datos mencionados coincidan con los de la base de datos.
• Detección de intención fuera de alcance: si el lead pregunta algo que no está en el dominio del agente (hipotecas específicas, cuestiones legales complejas), el agente lo reconoce y deriva.

Lo interesante es que estos guardrails no hacen que el agente sea más lento o menos útil. Al contrario: al saber exactamente lo que puede y no puede hacer, el agente es más decisivo en lo que sí le corresponde.

La lección: la confianza se construye con límites claros, no con capacidades infinitas.

Decisión 5: Human-in-the-loop por diseño

Esta fue quizá la decisión más contraintuitiva. En un mundo donde se celebra la automatización total, decidimos que la escalación a humanos no es un fallo del sistema. Es una funcionalidad.

El agente de PropPilot está diseñado para detectar cuándo un lead necesita hablar con una persona y facilitar esa transición sin fricción. Los escenarios de escalación incluyen:

• Objeciones complejas: el lead tiene dudas que requieren empatía y negociación humana.
• Decisiones de compra avanzadas: cuando el lead está listo para reservar, la conversación la cierra un comercial.
• Situaciones emocionales: comprar una casa es una decisión vital. Hay momentos que requieren conexión humana.
• Solicitudes fuera de alcance: cualquier petición que el agente no pueda resolver con sus herramientas.

El agente no desaparece cuando escala. Prepara un resumen de la conversación para el comercial, de modo que el lead no tenga que repetir información. Y cuando el comercial termina, el agente puede retomar el seguimiento posterior.

La lección: el mejor agente no es el que lo hace todo. Es el que sabe cuándo dejar paso.

Los errores que cometimos

Sería deshonesto compartir solo las decisiones acertadas. Aquí van los tres errores más importantes:

Sobreingeniería de la primera versión

La primera arquitectura del agente era innecesariamente compleja. Teníamos múltiples capas de orquestación, un sistema de plugins demasiado abstracto y una lógica de routing que intentaba cubrir casos que no existían aún. Tardamos semanas en construir un sistema que luego simplificamos radicalmente.

La causa fue clara: diseñamos para el producto que imaginábamos en dos años, no para el que necesitábamos en dos meses. Empezar simple y añadir complejidad cuando el uso real lo demanda habría sido mucho más eficiente.

Demasiados canales a la vez

Intentamos lanzar el agente en WhatsApp, web chat, email y SMS simultáneamente. Cada canal tiene sus particularidades: límites de longitud, formatos de medios, tiempos de respuesta esperados, tonos conversacionales distintos.

Deberíamos haber dominado un canal primero --- WhatsApp, que es donde está la mayor parte de la interacción inmobiliaria en España --- y luego expandir. El resultado de lanzar todo a la vez fue que ningún canal funcionaba realmente bien en las primeras semanas.

Subestimar la importancia del tono

Dedicamos meses a la arquitectura técnica y días al tono de voz. Error. En el sector inmobiliario español, la forma de hablar importa enormemente. Un tono demasiado formal aliena a compradores jóvenes. Un tono demasiado coloquial genera desconfianza en compradores de mayor poder adquisitivo.

Tuvimos que iterar mucho sobre el sistema de prompts para encontrar un tono que fuera profesional sin ser frío, cercano sin ser irrespetuoso, y que se adaptara al registro del lead.

Qué haríamos diferente hoy

Si empezáramos hoy desde cero, con todo lo aprendido:

1. Empezaríamos por la evaluación, no por el desarrollo. Antes de escribir una línea de código del agente, construiríamos el framework de evaluación: cómo medimos si el agente hace bien su trabajo. Sin métricas claras, no puedes mejorar de forma sistemática. Es precisamente de esto de lo que hablaremos en nuestro próximo artículo sobre métricas que importan en IA agéntica.

2. Un canal, un caso de uso, bien hecho. WhatsApp, respuesta inicial a leads. Nada más hasta que las métricas digan que funciona.

3. Más tiempo en prompts, menos en abstracciones. La ingeniería de prompts es ingeniería real. Merece el mismo rigor que el diseño de APIs.

4. Involucrar a comerciales desde el día uno. Los mejores inputs para entrenar al agente no vinieron de nosotros. Vinieron de los comerciales que llevan años hablando con compradores de vivienda.

Conclusión

Construir un agente de IA para el sector inmobiliario no es un problema de IA. Es un problema de producto que usa IA como herramienta. Las decisiones más importantes no son qué modelo usar, sino cómo diseñar el sistema que lo rodea: sus herramientas, su memoria, sus límites y su relación con las personas.

Esperamos que este vistazo tras el código sea útil para otros equipos que estén construyendo agentes en real estate o en cualquier otro sector. Las lecciones son bastante universales: empieza simple, mide todo, respeta los límites y no subestimes el factor humano.

---

¿Quieres ver cómo funciona el agente de PropPilot en la práctica? Prueba nuestro Mystery Shopper: envía un lead de prueba a tu propia inmobiliaria y compara cómo responde tu equipo con cómo respondería PropPilot. Sin compromiso, sin coste, en menos de dos minutos.