awesome-llm-apps (100+ agentes)

git clone https://github.com/Shubhamsaboo/awesome-llm-apps.git

awesome-llm-apps, de Shubhamsaboo, es una colección viva de más de cien apps y agentes de IA con su código fuente abierto, organizados en trece categorías que cubren asistentes, RAG, automatización, agentes multi-paso, herramientas creativas y más. En una frase: en vez de construir tu agente desde cero, clonas el que más se parece a lo que quieres hacer y lo adaptas.

El problema que resuelve es muy concreto. Cuando empiezas con agentes, la cantidad de patrones posibles (orquestación, memoria, recuperación, herramientas, evaluación) abruma. Leer artículos teóricos no es lo mismo que ver código que funciona. Este repositorio te da esa segunda parte: ejemplos reales, ejecutables, comentados, con sus dependencias y sus puntos débiles a la vista.

Le rinde a desarrolladores intermedios que ya tocaron alguna API de LLM y quieren ver cómo se ensambla un agente completo, a equipos que buscan un punto de partida para su propia herramienta interna, y a curiosos avanzados que aprenden mejor leyendo código que leyendo documentación. Le sobra a quien busca una solución llave en mano sin tocar código: este es un catálogo de ejemplos, no un producto terminado.

Por qué importa

Antes de los repositorios “awesome” especializados, aprender a construir agentes implicaba leer la documentación de OpenAI o Anthropic, intuir patrones a partir de ejemplos sueltos en blogs, y reinventar la rueda en cada proyecto. Cada uno escribía su propio loop de razonamiento, su gestión de memoria, su integración con tools. Era lento y propenso a errores conceptuales.

Con un repositorio así, el “después” es que entras, eliges una categoría (por ejemplo RAG sobre documentos) y tienes en pocos minutos cinco implementaciones distintas para comparar: la sencilla, la que usa LangChain, la que usa LlamaIndex, la que mete reranking, la que añade un agente de evaluación. Ver las diferencias entre ellas te enseña más en una tarde que muchos cursos.

Lo que cambia en el día a día es que cuando alguien te pide “un chatbot que responda sobre nuestros PDFs”, no parpadeas: vas al repositorio, eliges el patrón que mejor encaje y empiezas adaptando, no escribiendo desde cero. La velocidad de la primera iteración baja de días a horas.

Cómo se usa en la práctica

El paso a paso del frontmatter (explorar, clonar, abrir la carpeta, leer el README) describe la mecánica. Lo importante son las decisiones que tomas en cada fase para que el ejemplo se convierta en algo tuyo y no en otra carpeta muerta en tu disco.

Empieza por leer la lista de categorías en el README principal del repositorio. Cada categoría agrupa varios agentes con un patrón común. No te lances al primero que veas: dedica diez minutos a comparar tres o cuatro de la misma categoría y entender por qué eligen tecnologías distintas (un mismo problema con LangChain, con LlamaIndex y con código vanilla suele enseñar mucho).

Cuando elijas un agente concreto, mira primero la antigüedad del último commit en esa subcarpeta. El repositorio es enorme y no todas las subcarpetas se mantienen a la misma velocidad. Si llevan año sin tocarse, es probable que las versiones de librerías estén obsoletas; aun así puede servirte como guía conceptual, pero prepárate para actualizar imports.

Al clonar, considera trabajar solo en un subdirectorio en lugar de duplicar todo el repositorio en tu proyecto. Puedes copiar la carpeta del agente que te interesa a un repositorio nuevo tuyo y construir desde ahí, dejando el clon original como referencia limpia para mirar otros ejemplos sin contaminar tu árbol.

Cada agente trae su requirements.txt, package.json o equivalente. Crea un entorno aislado (venv, uv, nvm, lo que uses) por agente, no instales todo en el mismo sitio. Eso evita conflictos de versiones entre ejemplos. Las claves de API de servicios externos van siempre en variables de entorno o .env que no entran en git.

Adaptar es el paso clave. La primera ronda es solo cambiar el prompt y la fuente de datos para que responda sobre lo tuyo. La segunda es endurecer: añadir logs, manejar errores, controlar costes (los loops de agente pueden disparar tokens si no pones límites). La tercera, si va a producción, es montar evaluación: un set de preguntas y respuestas esperadas, y métricas mínimas que el agente debe superar.

Si Claude Code te ayuda en este flujo, ábrele la carpeta del agente y pídele primero un resumen de qué hace cada archivo. Eso te ahorra leer todo y te permite atacar solo lo que vas a cambiar.

Casos de uso reales

Soporte interno con RAG. Una empresa quiere que su equipo pregunte a un bot sobre sus manuales y políticas. Toman un ejemplo de RAG con PDFs del repositorio, cambian la fuente por su carpeta de manuales, ajustan el prompt al tono de la empresa y lo despliegan internamente. De idea a primera versión usable en dos días.

Prototipo de producto. Un equipo de producto necesita validar si “agente que resume reuniones y crea tareas en Notion” es viable. Cogen un agente de orquestación del repo, le enchufan transcripción de audio por su lado y la API de Notion por el otro. En una semana tienen demo para enseñar a inversores, sin haber escrito el bucle de razonamiento desde cero.

Aprendizaje personal. Una desarrolladora con experiencia en backend quiere aprender cómo se monta un agente con tools. Clona el repo, monta tres ejemplos progresivos (uno simple, uno con memoria, uno con varias tools) y entiende los patrones leyendo código en lugar de leyendo cinco libros.

Investigación académica. Un estudiante de máster compara distintas arquitecturas de agente para su TFM. El repositorio le da, en un solo sitio, varios baseline reproducibles contra los que comparar su propia propuesta sin perder semanas en reimplementaciones.

Errores comunes y cómo evitarlos

• Asumir que un ejemplo es producción-ready. No lo es: es código didáctico. Auditalo y endurécelo antes de exponerlo a usuarios reales.
• Instalar todas las dependencias en el mismo entorno y acabar con conflictos de versiones. Aísla por agente con un entorno virtual o equivalente.
• Olvidar las claves de API en el código al subir a un repositorio público. Usa siempre variables de entorno y revisa el .gitignore.
• No mirar la fecha del último commit del subdirectorio. Si está congelado, esperaba versiones de librerías que ya cambiaron.
• Copiar el agente sin entenderlo y luego no saber por qué falla. Dedica una primera lectura completa antes de modificar.
• Subestimar el coste en tokens al adaptar un loop de agente. Pon límites duros de iteraciones y de presupuesto desde el primer prototipo.

Cuándo NO usarla

Si lo que buscas es un producto cerrado que funcione sin que toques nada, este repositorio no es tu sitio: aquí siempre hay código que adaptar. Si necesitas garantías de soporte, mantenimiento y SLAs, una plataforma comercial (un framework gestionado, un SaaS) encaja mejor que partir de un ejemplo open source. Y si tu caso es muy estándar (un chatbot básico con un par de FAQs), puede que un constructor sin código resuelva en una tarde lo que el repositorio te pediría programar.

Combinarla con otras herramientas

awesome-llm-apps + Claude Code + un orquestador (n8n, Inngest) es un combo natural: el repositorio te da el patrón base del agente, Claude Code te ayuda a adaptarlo y el orquestador se encarga de que se ejecute en eventos del mundo real (correos, formularios, cron). Para llevar el agente a interfaz humana, súmale algo como respond.io si va a WhatsApp, o un frontend simple con Vercel si va a web.

Mini-ejercicio

Clona el repositorio, elige un agente de la categoría de asistentes o RAG, móntalo en un entorno virtual nuevo y consigue que responda al menos a tres preguntas con datos tuyos (no los de demostración). Sabrás que está bien si las respuestas usan tus datos, los logs muestran las llamadas al modelo y el coste por consulta es razonable para tu caso.