De "chatarra" a cerebro digital: cómo convertimos una MacBook Pro 2011 en un Agente de IA
¿Tienes una computadora vieja acumulando polvo en algún cajón? Antes de donarla o desecharla, considera esto: con el software correcto, ese hardware puede convertirse en un agente de inteligencia artificial funcional que trabaja para ti las 24 horas, sin pagar por servidores en la nube.
Eso fue exactamente lo que hicimos. Una MacBook Pro del 2011 con 4GB de RAM, disco duro mecánico y un procesador de doble núcleo, se convirtió en un asistente con IA conectado a Telegram, capaz de procesar imágenes y responder consultas en tiempo real. Este artículo documenta cada decisión técnica, cada obstáculo y cómo lo resolvimos.
Si tienes computadoras sin usar o quieres explorar la automatización con IA sin invertir en infraestructura nueva, esta historia es para ti.
Las especificaciones del equipo: el punto de partida
La MacBook Pro con la que trabajamos no era precisamente un servidor de alto rendimiento:
| Componente | Especificación |
| Procesador | Intel Core i5 2.4GHz (dual-core) |
| RAM | 4GB DDR3 1333MHz |
| Almacenamiento | 500GB HDD SATA |
| GPU | Intel HD Graphics 3000 |
| Pantalla | 13.3" 1280×800 |
| macOS máximo | macOS Sierra (10.12) |
Las limitantes son evidentes: poca RAM, almacenamiento lento y un sistema operativo que Apple dejó de soportar hace años. Pero esas restricciones, en lugar de ser el fin del proyecto, fueron el mapa para encontrar la arquitectura correcta.
El primer plan: LangChain + Ollama (y por qué no funcionó)
La idea inicial era usar Ollama para correr un modelo de lenguaje de forma local y conectarlo a un agente mediante LangChain. Es una combinación popular, bien documentada y muy flexible.
El problema fue uno solo: 4GB de RAM no son suficientes.
Los modelos de lenguaje con 7 mil millones de parámetros (7B) o más necesitan entre 4 y 8GB solo para cargarse en memoria. Si además agregas el sistema operativo, los servicios del agente y cualquier tarea paralela, el equipo simplemente se congela. Tampoco era viable Docker en versiones antiguas de macOS, que tiene soporte muy limitado para contenedores modernos.
Ollama: el servicio que habíamos considerado para correr modelos localmente, confirma en su documentación que los modelos de 7B requieren al menos 8GB de RAM para correr con estabilidad. En nuestro caso, simplemente no había margen.
Aquí es donde hay que elegir entre rendirse o replantear la estrategia.
Exploramos otros frameworks antes de decidir:
| Framework | Especialidad | ¿Por qué no en este caso? |
| LangChain | Integración con múltiples APIs | Pesado para ejecutar con modelos locales |
| LlamaIndex | RAG (conectar IA con documentos) | Requiere modelo local o API con buena latencia |
| CrewAI | Múltiples agentes con roles | Overhead innecesario para un solo asistente |
| AutoGen | Agentes que se hablan entre sí | Demasiado complejo para el objetivo |
| Pydantic AI | Datos estructurados y código limpio | Ideal en producción, pero requiere más setup |
| Nanobot | Rapidez y simplicidad | ✅ El elegido |
La clave no era hacer más con el hardware era hacer menos con el hardware local y dejar que un modelo en la nube hiciera el trabajo pesado.
La decisión correcta: Ubuntu Server como sistema operativo
macOS, incluso en versiones antiguas, consume recursos significativos solo para mantener su interfaz gráfica, servicios de sincronización y procesos en segundo plano. Para un servidor que nadie va a usar frente a pantalla, todo eso es desperdicio puro.
Ubuntu Server elimina esa capa por completo. Sin interfaz gráfica, sin servicios innecesarios, sin actualizaciones automáticas de sistema que interrumpan el proceso del agente. Solo una terminal y los recursos que tú decides usar.
La ventaja operativa es real:
- Eficiencia de RAM: Libera entre 500MB y 1GB que macOS usaría en segundo plano.
- Estabilidad 24/7: Linux está diseñado para correr de forma continua sin degradación de rendimiento.
- Control total: Tú decides qué corre, cuándo y con qué prioridad.
- Acceso remoto limpio: SSH funciona perfecto desde cualquier red.
El modelo de uso es simple: la MacBook queda cerrada, conectada al router por Ethernet y a su cargador. Nadie la toca físicamente. Toda la interacción ocurre desde el celular, vía Telegram.
Configuración del servidor: los comandos que importan
Al instalar Ubuntu Server en la MacBook, hay una serie de configuraciones que son indispensables para que funcione como servidor estable. Estas son las más importantes:
1. Evitar suspensión con la tapa cerrada
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target
2. Zona horaria y sincronización de hora (crítico para los bots de Telegram)
sudo timedatectl set-timezone America/Monterrey
sudo timedatectl set-ntp true
3. Firewall básico con acceso SSH
sudo ufw allow OpenSSH
sudo ufw enable
4. Memoria virtual (swap) para compensar los 4GB de RAM
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
Esto agrega 2GB de memoria virtual. No reemplaza la RAM física en velocidad, pero evita que el sistema se congele cuando la memoria física se satura.
5. Control de brillo para proteger la batería
Con la pantalla al 0%, la batería se preserva más y el calor generado disminuye. En un equipo que corre cerrado y conectado, es una optimización sencilla pero importante.
Instalando Nanobot: el framework del agente
Nanobot es un framework minimalista diseñado para construir agentes de IA que se comunican por canales de mensajería. Ya lo habíamos usado antes en nuestro proyecto de infraestructura privada con una laptop como servidor, y la experiencia confirmó que es una opción sólida para hardware con recursos limitados. No necesita Docker, no necesita modelos locales y su instalación cabe en una sola línea:
uv tool install nanobot-ai
nanobot onboard
Si el sistema no reconoce el comando nanobot, ejecuta primero:
source $HOME/.local/bin/env
Cuando aparece el mensaje 🐈 nanobot is ready!, el framework está activo y listo para configurarse.
Elección del modelo: MiniMax 2.7
Probamos varios modelos durante la configuración:
- Gemini Flash: Rápido y gratuito, pero inconsistente en tareas complejas.
- Claude Haiku: Muy bueno en razonamiento, costo razonable.
- MiniMax 2.7: Excelente balance entre velocidad, costo y capacidades multimodales. ✅
MiniMax 2.7 es un VLM (Vision Language Model), lo que significa que puede procesar imágenes además de texto. Esa capacidad resultó ser el centro del problema más interesante del proyecto.
Configurando el bot de Telegram: la interfaz del usuario
Telegram es el canal de comunicación entre el usuario y el agente. Configurarlo toma menos de cinco minutos:
- Busca @BotFather en Telegram (con palomita azul verificada).
- Escribe
/start y luego /newbot.
- Define un nombre visible (ej. AI Agent) y un username que termine en
bot (ej. aiagent_bot).
- BotFather te entrega un token guárdalo, es la llave de acceso al bot.
- Busca @userinfobot y dale Start. Te dará tu User ID numérico.
El User ID sirve para restringir el acceso: configuras el agente para que solo responda a tu ID y no a cualquier persona que encuentre el bot.
El problema de la visión: cuando el modelo empieza a inventar
Esta fue la parte más interesante del proyecto. Al enviar imágenes al agente, el modelo respondía con descripciones detalladas... pero incorrectas. Describía texturas, empaques y colores que simplemente no estaban en la foto.
¿Por qué? Porque el agente no tenía acceso real a las imágenes. Nanobot no estaba pasando el contenido visual al modelo, solo el texto del mensaje. El modelo, sabiendo el contexto del proyecto (contenido de belleza para Forbela Beauty), usaba su memoria de entrenamiento para adivinar qué podría haber en la imagen. Y adivinaba mal.
Este comportamiento tiene un nombre: alucinación contextual. El modelo llena los vacíos de información con lo que estadísticamente tiene más sentido según el contexto, aunque sea incorrecto.
La solución fue implementar el MCP oficial de MiniMax, que le da capacidad real de visión al agente. Tres puntos de configuración en ~/.nanobot/config.json fueron clave:
- API Key: El campo estaba vacío, había que completarlo con la clave de MiniMax.
- Ruta absoluta de uvx: El sistema no encontraba el ejecutable. Se resolvió usando la ruta completa:
/home/ai_agent/.local/bin/uvx.
- Paquete correcto: Se migró de
minimax-coding-plan-mcp al paquete completo minimax-mcp, que incluye todas las herramientas disponibles, incluyendo visión.
Con ese cambio, el agente dejó de inventar y comenzó a describir con precisión lo que realmente estaba en cada imagen.
Casos de uso reales para empresas
Este proyecto demuestra algo más amplio que reutilizar hardware: los agentes de IA no requieren infraestructura costosa para aportar valor operativo. Algunas aplicaciones concretas para empresas:
Soporte interno automatizado: Un agente conectado a Telegram puede responder preguntas frecuentes del equipo, políticas de vacaciones, procedimientos, contactos sin intervención humana.
Monitoreo de operaciones: El agente puede recibir alertas de sistemas internos y resumirlas en lenguaje natural, evitando que los equipos técnicos tengan que revisar dashboards constantemente.
Procesamiento de documentos e imágenes: Con visión habilitada, el agente puede recibir fotos de documentos, facturas o productos y extraer información estructurada automáticamente.
Asistente de contenido: Como en el caso de Forbela Beauty, el agente puede apoyar equipos de marketing a analizar material visual y generar descripciones o ideas de contenido.
Conclusión: el hardware no es la limitante, la estrategia sí
Una MacBook de 15 años no se convierte en un agente de IA por tener el mejor procesador o más memoria se convierte porque se tomaron las decisiones correctas en cada paso: cambiar el sistema operativo, elegir un framework liviano, delegar el peso computacional a la nube y resolver los problemas uno a uno cuando aparecieron.
Antes de tirar ese equipo viejo, vale la pena preguntarse qué puede hacer todavía. Una laptop olvidada en un cajón, con la arquitectura correcta, puede convertirse en un asistente que trabaja por ti las 24 horas, procesa imágenes, responde preguntas y automatiza tareas, sin pagar por servidores en la nube ni comprar hardware nuevo.
Esa es la mentalidad que aplicamos en fencode: no siempre se necesita reemplazar todo para modernizar operaciones. A veces, la solución más eficiente es rediseñar cómo se usa lo que ya tienes y darle una segunda oportunidad a lo que creías que ya no servía.
¿Tu empresa tiene equipos sin usar o procesos que podrían automatizarse con un agente de IA? Contáctanos en fencode.dev y exploramos juntos qué se puede construir con lo que ya tienes.