Un agente de IA para diseño de interiores: Claude sin RAG ni LangChain

En Habr se ha publicado un análisis de un agente de IA basado en Claude para automatizar el diseño de interiores: 712 líneas de código en lugar de frameworks de RAG.

De qué componentes consta el agente

Los papeles de los dos modelos de Claude se reparten claramente según el tipo de tarea. La interfaz de chat funciona con Claude Haiku 4.5: el modelo responde con rapidez a las preguntas de los clientes, precisa la solicitud y conduce el diálogo. De la generación de conceptos de diseño se encarga Claude Sonnet 4.6, que convierte los deseos del cliente en una descripción estructurada del interior. Las fotografías que ilustran los conceptos se obtienen de la biblioteca de Pexels, una opción bastante más barata y rápida que generar imágenes con DALL-E.

Parámetros clave de la solución:

• Claude Haiku 4.5: diálogo con el cliente, rápido y económico
• Claude Sonnet 4.6: generación de conceptos de diseño estructurados
• Pexels API: selección de fotografías en lugar de DALL-E
• Un único archivo main.py, 712 líneas de código y dos prompts de sistema
• Nada de orquestadores, bases vectoriales ni frameworks sobre la API

La elección de esta arquitectura no es casual. Para un estudio con presupuesto limitado y un flujo reducido de clientes, una pila de RAG completa supone un exceso de ingeniería. Haiku sale más barato en el diálogo, y Sonnet solo entra en juego cuando hace falta generación creativa estructurada. No tiene sentido resolver un problema de escala que todavía no existe.

¿Qué problemas aparecieron en la práctica?

El primer detalle poco evidente es el umbral de caché de prompts de Claude Haiku 4.5. La caché de contexto solo se activa a partir de 4096 tokens. Si el prompt de sistema es más corto, cada solicitud se trata como nueva y la caché no funciona en absoluto. Con una carga intensa, esto afecta de forma apreciable tanto al coste de las solicitudes como a la latencia de las respuestas.

El segundo matiz es el comportamiento de Sonnet 4.6 con la salida estructurada. A veces el modelo envuelve la respuesta JSON en un bloque de texto adicional en lugar de devolver JSON limpio. En ese caso, el `json.loads()` estándar falla con un error. El autor probó varias estrategias de parseo y se quedó con un envoltorio sencillo con lógica de fallback, más fiable que capturar el JSON con expresiones regulares.

«No es una guía de un experto, sino más bien un diario de decisiones.

He intentado explicar con honestidad por qué tomé cada una», explica el desarrollador.

Merece atención aparte la lógica de reparto entre modelos. El autor intentó procesarlo todo con un solo modelo, pero pronto comprobó que conviene usar Haiku donde importan la velocidad y el coste, y Sonnet donde se necesita calidad en la salida estructurada. El intento de ahorrar generando los conceptos con Haiku dio resultados notablemente peores.

¿Dónde empezará a fallar este enfoque?

El desarrollador señala con franqueza los límites de su solución. Un único archivo de 712 líneas funciona bien para un MVP y un estudio pequeño, pero al escalar surgirán problemas:

• Con el crecimiento de la base de clientes hará falta almacenar el historial de conversaciones, y no se podrá prescindir de una base vectorial o de un almacenamiento externo
• Si el estudio quiere recibir y analizar fotografías de los clientes, necesitará un pipeline multimodal
• Registrar los logs del agente en un archivo no es viable con varios usuarios simultáneos y carga real
• A medida que el proyecto crece, los prompts son más difíciles de probar y versionar dentro de un único archivo

La principal conclusión del autor: para una tarea con límites estrechos y bien definidos, prescindir de RAG no es una solución perezosa, sino una decisión de arquitectura consciente. Los frameworks resuelven problemas reales de escala, pero también generan otros nuevos: complejidad, dependencias y overhead de infraestructura. Si el problema aún no ha aparecido, no conviene crearlo por culpa de la herramienta.

Qué significa esto

La publicación demuestra que la API de Claude basta para un agente en producción sin frameworks auxiliares, siempre que la tarea sea lo bastante concreta. Para los desarrolladores que empiezan a crear agentes con Claude, es un análisis honesto de problemas reales: el umbral de caché de Haiku 4.5, el parseo de JSON de Sonnet 4.6 y el reparto deliberado de tareas entre modelos de distinto nivel.

¿Cómo usar Claude para un agente de diseño?

El artículo muestra una arquitectura con dos modelos: Claude Haiku 4.5 responde a las preguntas de los clientes y precisa la solicitud, y Claude Sonnet 4.6 genera los conceptos de diseño.

¿Hace falta RAG para un agente basado en Claude?

No necesariamente. El agente descrito funciona sin frameworks de RAG ni bases de datos vectoriales: todo el sistema cabe en 712 líneas de código.

¿Se puede usar Claude para diseño de interiores?

Sí. En este caso se usa Claude Sonnet 4.6 para generar conceptos de diseño y Claude Haiku 4.5 para interactuar con los clientes.

¿Hace falta RAG para un agente de IA basado en Claude?

No necesariamente. La aplicación de ejemplo no utiliza RAG: el sistema funciona con dos prompts de sistema y 712 líneas de código.