Agentes de IA locales en 2026: lo que realmente funciona (y lo que sigue fallando)

Datos rápidos

• Stacks probados: Cline + Ollama, Continue.dev Agent, LangGraph + Ollama (personalizado), AutoGPT-local, OpenInterpreter, MetaGPT local.
• Tareas probadas: investigación de temas, refactorización de múltiples archivos, triaje de borradores de correo, scrape-y-resumen, depuración de bugs.
• Hardware: Apple M5 Max 64 GB de memoria unificada y equipo con 2× NVIDIA RTX 3090 24 GB; ambos ejecutan Qwen3-Coder 30B Q4_K_M cómodamente con contexto de 32K.
• Modelos: Qwen3-Coder 30B (principal), GLM-5.1 32B, Gemma 4 27B, Llama 3.3 70B (los cuatro tool-callers fiables en mayo de 2026).
• Forma del veredicto: 2 stacks fiables en las 5 tareas, 3 stacks fiables en 1–2 tareas cada uno, 1 stack inutilizable.
• Coste: 0 € en tarifas de API. ~0,10–0,30 € en electricidad por tarea de varios pasos en un equipo de escritorio con GPU de 350W (menos de 0,05 € en un Mac).
• Patrón de supervisión que funciona: aprobar automáticamente las herramientas de lectura, aprobar manualmente cada herramienta de escritura/shell, revisar el registro de auditoría tras sesiones largas.

Cómo lo probamos: mismo modelo, mismas tareas, diferentes harnesses

• Backend: Ollama 0.5+ en macOS y Linux. Modelo principal Qwen3-Coder 30B Q4_K_M (contexto de 32K). Modelos secundarios (GLM-5.1 32B, Gemma 4 27B, Llama 3.3 70B) usados para verificar que los fallos en las llamadas a herramientas no eran un artefacto de un único modelo.
• Hardware: un MacBook Pro Apple M5 Max 64 GB y un escritorio Linux con 2× RTX 3090 24 GB. Ambos mantienen Qwen3-Coder 30B a una velocidad usable (>15 tokens/s).
• Tareas: investigación de temas (recopilar, deduplicar y resumir 8 fuentes sobre un tema de nicho), refactorización de múltiples archivos (renombrar un servicio en 12 archivos TypeScript), triaje de borradores de correo (resumir y redactar respuestas para una carpeta de 40 mensajes), scrape-y-resumen (leer 5 URLs y producir un resumen comparativo), depuración de bugs (encontrar por qué un test existente es inestable).
• Cadencia de ejecución: cada tarea se ejecutó 3 veces por stack durante el período de 30 días, con un prompt nuevo cada vez. El resultado se calificó como "completo sin supervisión", "completo con supervisión", "parcial" o "bloqueado / fallido".
• Métrica de supervisión: número de aprobaciones requeridas por tarea y la proporción de aprobaciones en las que rechazamos la acción propuesta. Una tasa de rechazo alta indica que el harness genera ruido que el humano debe filtrar.
• Restricción de honestidad: rangos, no porcentajes exactos inventados. "Fiable en las 5 tareas" significa 13–15 de 15 ejecuciones completadas; "falla en horizontes largos" significa 3–6 de 15 ejecuciones completadas sin intervención. Los veredictos son conservadores: cuando un stack funcionó pero solo con intervención no trivial, se cuenta como fallo a efectos de tareas sin supervisión.
• La fiabilidad de las llamadas a herramientas es la capa subyacente a todo esto. Para la comparativa del lado del modelo, consulta Mejores modelos locales para tool calling en 2026; la capa de protocolo se trata en Conectar Ollama a bases de datos y APIs con MCP.

Tabla de realidad de agentes: seis stacks, cinco tareas, veredictos honestos

Lo que funciona: Cline + Ollama es la elección por defecto

• Qué es: Cline es una extensión de VS Code que convierte el editor en una superficie de agente autónomo. El modelo propone un plan en modo Plan, lo ejecuta en modo Act a través de una superficie de herramientas (read_file, write_to_file, replace_in_file, execute_command, list_files, search_files) y solicita aprobación entre pasos, a menos que las herramientas estén en una lista de permitidas.
• Por qué funciona: el harness tiene criterio propio. La superficie de herramientas es pequeña y estable, el flujo de aprobación es visible (cada paso es una tarjeta que aceptas o rechazas) y el modelo solo ve el editor, no toda la máquina. Los fallos son recuperables porque la última acción siempre está a un clic de revertir.
• Donde destaca: refactorizaciones de múltiples archivos (renombrar un servicio en 12 archivos en una sola tarea), depuración exploratoria de bugs ("encuentra por qué este test es inestable": Cline lee archivos de test adyacentes, rastrea dependencias, propone una hipótesis, edita, ejecuta el test) e investigación acotada que produce un entregable en markdown dentro del proyecto.
• Donde tropieza: tareas que no son de codificación y que requieren HTTP externo (sin navegador nativo). El triaje de borradores de correo solo funciona si conectas un servidor MCP o herramientas de shell, y en ese punto estás configurando tres cosas para hacer lo que haría directamente una herramienta más pequeña y acotada.
• Coste de supervisión: ~5–12 aprobaciones por tarea. La mayoría son herramientas de lectura (baratas, aceptación rápida). Las costosas son write_to_file y execute_command: configúralas para requerir aprobación manual y capturarás la rara llamada errónea antes de que aterrice.
• Coste de tokens: alto. Los contenidos completos de los archivos se transmiten a la conversación mientras el agente los lee. Una refactorización de 12 archivos con Qwen3-Coder 30B en contexto de 32K agota la ventana rápido: cambia a un modelo con contexto de 128K (DeepSeek Coder V3, Llama 3.3 70B) para trabajo no trivial.
• Para una configuración más detallada de Cline, incluidas las listas de aprobación automática, consulta Continue.dev vs Cline vs Aider: mejor agente de codificación local en 2026.

Lo que funciona: Continue.dev en modo Agent para tareas más ligeras

• Qué es: Continue.dev es principalmente una extensión de autocompletado y chat para VS Code y JetBrains, con un modo Agent que añade llamadas a herramientas (lectura/escritura de archivos, búsqueda en la base de código, ejecución en terminal) y un bucle de plan en múltiples pasos. El agente es más restringido que el de Cline: menos herramientas, horizontes predeterminados más cortos, comportamiento autónomo menos agresivo.
• Por qué funciona: la audiencia de Continue.dev son usuarios de autocompletado, por lo que el modo Agent hereda una UX de "pequeño, rápido, visible". Cada edición aterriza como una vista previa del diff antes de que el modelo toque el archivo. Los planes rara vez superan los 3–5 pasos, lo que mantiene el consumo de tokens modesto y el historial de auditoría corto.
• Donde destaca: tareas de uno o dos archivos, "explica esta región de la base de código", "reescribe esta función con estas restricciones", "añade un test para este método". El agente se ejecuta sin arrastrar toda la base de código a la conversación, por lo que un modelo con contexto de 32K es cómodo.
• Donde tropieza: planes de más de 5 pasos. Las refactorizaciones de múltiples archivos que necesitan 8 o más ediciones a veces se detienen tras 2–3 archivos y piden al usuario que continúe. Esto no es un bug: el harness es conservador respecto al horizonte del plan, pero significa que supervisas con más frecuencia que con Cline en la misma tarea.
• Coste de supervisión: ~4–8 aprobaciones por tarea, con peso en las vistas previas de diff (señal alta, aceptación rápida).
• Coste de tokens: notablemente menor que Cline porque Continue.dev usa su índice TF-IDF + embeddings para recuperar fragmentos relevantes en lugar de transmitir archivos completos. Un modelo con contexto de 32K completa la mayoría de las tareas cómodamente.
• Cuándo elegir Continue.dev Agent sobre Cline: cuando la tarea cabe en 2–3 archivos, cuando el presupuesto de tokens es ajustado, cuando ya usas Continue.dev para autocompletado y quieres una herramienta en vez de dos.

Lo que falla: LangGraph + Ollama (frágil en horizontes largos)

• Qué es: LangGraph es una librería de orquestación de máquinas de estado. Defines nodos (funciones tipadas que llaman al modelo, ejecutan una herramienta, evalúan una condición) y aristas (transiciones). El runtime ejecuta el grafo, gestiona las ramificaciones y administra el estado entre pasos. Combínalo con un backend de Ollama y tendrás un agente local personalizado.
• Por qué falla como agente de escritorio: la superficie de fallo es el código de orquestación, no el modelo. Las máquinas de estado que parecen limpias en una pizarra entran en bucle cuando una herramienta devuelve datos inesperados: por ejemplo, una solicitud HTTP que devuelve 200 pero con cuerpo vacío, una lectura de archivo en una ruta que existe pero es un directorio. Depuras tu grafo tanto como el agente depura la tarea.
• Horizonte de plan: frágil más allá de 4–5 nodos. Cada punto de ramificación dobla la superficie de prueba. En el nodo 6 tienes un árbol de posibles rutas de ejecución y el modelo elige una que no anticipaste. El grafo entonces reescribe el estado de una manera que el siguiente nodo no puede consumir.
• Sin puerta de aprobación nativa: tú construyes las interrupciones humanas en el bucle. La librería lo soporta (la interrupción-y-reanudación está documentada), pero la implementación es tuya. Cline y Continue.dev te dan esto de forma gratuita.
• Donde realmente encaja: flujos de trabajo del lado del servidor donde controlas la forma de la entrada, la superficie de herramientas es fija y puedes escribir una suite de tests real para el grafo. Por ejemplo, un flujo de enrutamiento de soporte al cliente con tres herramientas deterministas y un nodo de modelo: ese es el punto óptimo de LangGraph.
• Veredicto para la pregunta del agente local: falla. Construir un orquestador LangGraph personalizado para hacer lo que Cline hace en una instalación es tiempo desperdiciado para el 90% de los usuarios. Hazlo solo si tienes una forma de flujo de trabajo que Cline no puede expresar y tienes la disciplina de testing para mantener el grafo honesto.

Lo que falla: OpenInterpreter es útil supervisado, peligroso sin supervisión

• Qué es: OpenInterpreter es una CLI que permite a un modelo escribir y ejecutar código (Python, shell, JavaScript, R) en tu máquina. El prompt interactivo solicita confirmación antes de ejecutar cada bloque, por defecto. El encuadre es "Code Interpreter de ChatGPT, en local".
• Por qué falla como agente autónomo: el prompt de seguridad es por bloque y el modelo propone regularmente comandos de shell que parecen benignos pero producen cambios de estado permanentes (rm en rutas profundas, pip install en el Python del sistema, git reset --hard). Confirmar cada bloque se convierte en el trabajo: no puedes hojear porque el coste de aprobar el bloque incorrecto es ilimitado.
• El modo de confirmación automática existe. Y es también de donde proviene cada historia de terror. No recomendamos ejecutar OpenInterpreter con confirmación automática en una máquina que tenga algo que te importe.
• Donde destaca: como bloc de notas supervisado. "Convierte este CSV a Parquet", "extrae metadatos de estos 200 PDFs", "reescribe este script Python para usar asyncio". Tareas donde te quedas en el terminal, observas cada comando y el modelo está haciendo el trabajo de escribir más rápido por ti.
• Donde falla: cualquier cosa que se parezca a la autonomía. Incluso con los prompts de confirmación activados, una tarea de 30 minutos promedia 40+ confirmaciones y los modos de fallo son variados (directorio de trabajo incorrecto, lecturas parciales, llamadas de red inesperadas).
• Coste de supervisión: esencialmente el 100%: supervisas cada bloque. Una tarea de "5 minutos" tarda más que hacerla a mano una vez que cuentas leer y aprobar.
• Veredicto: herramienta útil, categoría incorrecta. OpenInterpreter es un asistente de codificación que ejecuta código, no un agente autónomo. Puntuarlo contra Cline es el encuadre incorrecto; el encuadre correcto es "Cline entrega una funcionalidad, OpenInterpreter escribe un script puntual".

Lo que falla: MetaGPT Local (el juego de roles multiagente se rompe)

• Qué es: MetaGPT es un framework multiagente que simula un equipo de desarrollo de software. Un agente Product Manager escribe los requisitos, un agente Architect diseña, un agente Engineer codifica, un agente QA prueba. Cada agente es el mismo modelo subyacente con un prompt de sistema diferente y un conjunto de herramientas distinto.
• Por qué falla: el juego de roles multiagente asume que el modelo puede mantener una persona coherente a lo largo de muchos turnos y traspasar el contexto de forma fiable. En la práctica, con un modelo local de clase 30B, las personas se difuminan. El agente Engineer vuelve a ejecutar el análisis del agente PM. El agente QA reescribe código en lugar de probarlo. El estado del traspaso —lo que cada agente aprendió en su turno— es el bug.
• El problema más profundo: la abstracción multiagente añade turnos sin añadir capacidad. Un único agente con la misma superficie de herramientas y un scratchpad más largo hace la misma tarea en menos tokens con menos deriva. El encuadre de "equipo" es antropomórfico, no arquitectónico.
• Donde podría funcionar: tareas estrechamente definidas con límites de traspaso duros: por ejemplo, un flujo de trabajo de equipo de redacción (investigación → esquema → borrador → edición) donde cada paso tiene un entregable y el siguiente paso ignora el razonamiento previo. No encontramos un flujo de trabajo real donde MetaGPT superara a un harness de agente único con un prompt de lista de verificación.
• Veredicto: falla. El bug es conceptual, no de implementación. Los harnesses de agente único con prompts estructurados superan a los harnesses multiagente en cada tarea que ejecutamos.
• Para técnicas de prompting que mejoran la fiabilidad de cualquier bucle de agente único, consulta chain-of-thought prompting: el mismo patrón de razonamiento estructurado que ayuda a un modelo a pensar ayuda a un único agente a mantenerse coherente.

Inutilizable: AutoGPT-Local está prácticamente abandonado

• Qué ocurrió: AutoGPT fue el proyecto canónico de "agente autónomo" de 2023. El hype superó a la tecnología: los bucles de planificación nunca fueron fiables en tareas reales. El proyecto se estancó, el equipo de mantenedores se dispersó y el fork local-only se quedó rezagado respecto a cada actualización de dependencias durante más de 18 meses.
• Rotura concreta en mayo de 2026: la integración de Ollama asume una forma de API que cambió en 2024. Los prompts de planificación internos fueron ajustados para modelos de la clase GPT-3.5 y producen planes malformados en modelos de pesos abiertos modernos. Los problemas reportados en el repositorio en 2025 siguen abiertos y sin respuesta.
• El bucle de planificación deriva: en las ejecuciones que arrancaron, el agente típicamente entraba en un patrón de llamada circular de herramientas en 2–4 minutos: releyendo los mismos archivos, volviendo a ejecutar las mismas búsquedas, sin converger nunca en la tarea. Este es el modo de fallo bien conocido de los bucles autónomos sin acotar, exactamente lo que los harnesses acotados (Cline, Continue.dev) evitan por diseño.
• Veredicto: inutilizable. No inviertas un fin de semana en AutoGPT-local en 2026. El trabajo interesante se ha desplazado a harnesses acotados con puertas de aprobación explícitas; AutoGPT es un artefacto histórico, no una opción actual.
• Si sientes nostalgia: el repositorio original sigue en GitHub. La forma correcta de relacionarse con él es como lección: la autonomía era la abstracción incorrecta; la asistencia supervisada es lo que funciona.

Por qué los demos de agentes parecen mejores que la realidad

• Las tareas de los demos están acotadas. "Construye un juego de serpiente" o "resume este PDF" tienen una forma conocida, una superficie de archivos pequeña y una señal de éxito inequívoca. Las tareas reales son abiertas ("encuentra por qué nuestro flujo de pago pierde el 3% de los usuarios") y tienen una gran superficie de archivos, criterios de éxito ambiguos y efectos secundarios que amplifican los errores.
• Las ejecuciones de los demos están seleccionadas a mano. Un vídeo de demo de 30 segundos es el mejor de muchos intentos. Las ejecuciones donde el agente se bloqueó, alucinó una ruta de archivo o llamó a una función obsoleta no están en el corte. No ves la tasa de éxito; ves un éxito.
• Los prompts de los demos están sobre-especificados. "Refactoriza el servicio User para usar el nuevo patrón de repositorio" funciona en un demo porque el demo tiene el nuevo patrón documentado en un archivo que el agente encuentra. Tu tarea real tiene el patrón en un hilo de Slack de hace tres semanas. El modelo no tiene tu contexto; el demo sí.
• Los modelos de los demos son más grandes que tu modelo local. Los demos en la nube se ejecutan en modelos de frontera. Los agentes locales se ejecutan en lo que puedas servir a >10 tokens/s. Qwen3-Coder 30B es excelente en mayo de 2026, pero no es GPT-5, y los demos usan silenciosamente el modelo mejor.
• La conclusión: asume que cualquier demo representa el 10% superior de las ejecuciones. La expectativa razonable para una tarea real es la ejecución mediana, con una probabilidad del 20–30% de fallo que requiere intervención. Planifica para la mediana.

El coste de supervisión es la métrica real

• Tareas de supervisión baja (3–8 aprobaciones en total): Cline en una refactorización acotada, Continue.dev Agent en una tarea de un solo archivo. Hojeas las aprobaciones porque son principalmente operaciones de lectura y una o dos escrituras; el tiempo total de la tarea lo domina la latencia del modelo, no la fricción de las aprobaciones.
• Tareas de supervisión media (10–20 aprobaciones): Cline en una tarea de múltiples archivos que toca 8 o más archivos, Continue.dev Agent en cualquier cosa que empuje su horizonte de plan. Apruebas con más cuidado; el tiempo total de la tarea se divide aproximadamente a partes iguales entre el modelo y tú.
• Tareas de supervisión alta (40+ aprobaciones): OpenInterpreter haciendo cualquier cosa no trivial. El agente es un multiplicador de velocidad de escritura, no un multiplicador de productividad: sigues haciendo el trabajo cognitivo y leyendo cada bloque.
• Patrón de supervisión fallido: fatiga de aprobación. Tras ~30 aprobaciones en una sesión, los humanos empiezan a aprobar sin leer. El harness que requiere demasiadas aprobaciones te entrena a dejar de revisarlas, momento en el que la puerta de seguridad es ficticia.
• El ajuste correcto: listas de aprobación automática. Las herramientas de lectura (read_file, list_files, search_files, list_directory) son seguras para aprobar automáticamente. Las herramientas de escritura (write_to_file, replace_in_file, execute_command, browser_action con envío de formulario) no lo son. Esta única configuración es la diferencia entre un agente útil y uno tedioso.
• La unidad correcta: recuento de aprobaciones por tarea. Cuando evalúes un stack, cuenta las aprobaciones en una tarea real representativa, no en una tarea de demo. Si el recuento supera 20, el stack no te está ahorrando trabajo realmente.
• Para técnicas de prompting que reducen el coste de supervisión mejorando la calidad de las llamadas a herramientas, consulta chain-of-thought prompting.

Tareas que nunca debes confiar a un agente

• Escrituras en bases de datos de producción. Un modelo que emite con confianza una consulta DELETE FROM users WHERE active = false contra una tabla real es el incidente para el que existe este artículo. Ejecuta las herramientas de base de datos con roles de solo lectura por defecto; activa un rol de escritura separado solo para las tareas que lo requieran explícitamente y solo durante la duración de esas tareas.
• Cualquier cosa con dinero o autenticación. APIs de pago, emisión de tokens OAuth, creación de cuentas, cambios de roles y permisos. El coste de una llamada errónea es ilimitado; el beneficio de la automatización es pequeño.
• Planificación de horizontes largos de más de 8–10 pasos. Los agentes derivan en horizontes largos. El patrón correcto es "el modelo propone un plan, el humano aprueba el plan, el modelo ejecuta el plan paso a paso", no "el modelo planifica y ejecuta una tarea de 25 pasos de forma autónoma".
• Tareas en las que no puedes verificar el éxito rápidamente. Una tarea de scrape-y-resumen que puedes leer en 2 minutos es un buen candidato. Una tarea de "investiga este mercado y produce un informe" que no puedes verificar en menos de una hora no lo es: confiarás en el informe porque verificarlo cuesta más que reescribirlo.
• Cualquier cosa que toque archivos que no tienes respaldados. Aísla el servidor del sistema de archivos en un único directorio de trabajo. Trata el espacio de trabajo como desechable. Si el agente puede acceder a archivos fuera del espacio de trabajo, has configurado el agente incorrectamente.
• Infraestructura multiinquilino o compartida. Los agentes locales son herramientas de máquina personal en 2026. Los runners de CI compartidos, las bases de datos multiinquilino y las cuentas de nube compartidas son la superficie de ataque incorrecta para un bucle de agente sin supervisión.

Decisión: elige tu stack

Lo que probablemente traerá 2027

• La fiabilidad de las llamadas a herramientas seguirá aumentando. La tendencia de Llama 3 → Llama 3.3, Qwen2.5 → Qwen3 y el salto de Gemma 3 → Gemma 4 apuntan todos a lo mismo: el entrenamiento de tool-calling es el paso de post-entrenamiento más barato y de mayor impacto. Los modelos de clase 7B probablemente se convertirán en tool-callers fiables a finales de 2026 / principios de 2027, lo que bajará significativamente la barra de hardware para los agentes.
• Los horizontes de plan se alargarán. El horizonte fiable actual de ~5 pasos probablemente alcanzará los 8–10 pasos sin los problemas de deriva. Esto hace mejores a los agentes acotados estilo Cline; no hace que funcionen los agentes sin acotar estilo AutoGPT.
• Los sistemas multiagente no tendrán su gran avance. El problema estructural (estado de traspaso, deriva de persona, trabajo redundante) no es una cuestión de escala del modelo. Los harnesses de agente único con scratchpads más largos seguirán superando al juego de roles multiagente.
• El modelo de "asistente supervisado" gana. Los agentes que entreguen trabajo en 2027 parecerán un Cline 2.0: mejores superficies de herramientas, aprobaciones más fluidas, horizontes de plan más largos, no un relanzamiento exitoso de AutoGPT.
• Advertencia honesta: cualquiera de estas predicciones podría estar equivocada. La tecnología avanza lo suficientemente rápido como para que una versión de modelo en el tercer trimestre de 2026 pudiera cambiar la ecuación del coste de supervisión. Vuelve a evaluar este artículo en noviembre de 2026.

Errores comunes al elegir y ejecutar agentes locales

• Error 1: optimizar para la autonomía. "¿Cuánto tiempo puede ejecutarse sin supervisión?" es la métrica incorrecta. "¿Cuántas aprobaciones para completar la tarea?" es la correcta. Elegir un stack según benchmarks de autonomía te da AutoGPT; elegir según el coste de supervisión te da Cline.
• Error 2: modelos pequeños para trabajo de tool-calling. Cualquier cosa por debajo de 7B (y la mayoría de los modelos de propósito general de 7B–13B sin fine-tuning de tool-calling) emite llamadas a herramientas malformadas. Usa Qwen3-Coder 30B, GLM-5.1 32B, Gemma 4 27B o Llama 3.3 70B y deja de pelear con el harness.
• Error 3: contexto de 32K para trabajo de múltiples archivos. Cline transmite el contenido completo de los archivos a la conversación; una tarea de 8 archivos puede agotar los 32K tokens antes de razonar. Usa un modelo con contexto de 128K (DeepSeek Coder V3, Llama 3.3 70B) para tareas de múltiples archivos no triviales.
• Error 4: aprobar todo automáticamente. El interruptor de "aprobar todo" es la rampa de entrada a "el agente borró mis archivos". Aprueba automáticamente solo las herramientas de lectura; exige aprobación manual para escrituras y shell.
• Error 5: escrituras en bases de datos de producción desde un agente. Ejecuta un rol de solo lectura por defecto. Un rol de escritura separado existe solo durante la duración de las tareas que lo requieran explícitamente. El coste de una escritura errónea es ilimitado.
• Error 6: construir un orquestador LangGraph personalizado antes de probar Cline. El 90% de los casos de uso de "necesito un agente personalizado" están suficientemente acotados como para que Cline + unos pocos servidores MCP sea la respuesta correcta. Construye algo personalizado solo cuando la forma del flujo de trabajo sea genuinamente incompatible con los harnesses existentes.
• Error 7: perseguir demos. Los demos son el mejor de muchos intentos. Planifica para la ejecución mediana: 70–80% de éxito en tareas reales, 20–30% que requieren intervención. Cualquier cosa que se llame "completamente autónomo" en 2026 es marketing, no ingeniería.
• Error 8: ignorar el rastro de auditoría. Tras cada sesión larga de agente, lee el registro de acciones. Los patrones emergen: el mismo tipo de error tres ejecuciones seguidas te dice que hay que ajustar una regla de aprobación o cambiar el modelo.

Fuentes

• Repositorio de Cline en GitHub — agente de codificación autónomo, documentación de la superficie de herramientas, configuración de aprobación automática.
• Documentación de Continue.dev — modo agent, indexación de la base de código, configuración de proveedores.
• Documentación de LangGraph — librería de orquestación, semántica de máquinas de estado, interrupciones de humano en el bucle.
• Repositorio de OpenInterpreter en GitHub — agente de ejecución de código, modos de seguridad, integración de modelos locales.
• Repositorio de MetaGPT en GitHub — framework multiagente, definiciones de roles, configuración de proveedor local.
• Biblioteca de modelos de Ollama — modelos locales disponibles, indicadores de soporte de tool-calling, opciones de cuantización.

FAQ

Lecturas relacionadas

• Conectar Ollama a bases de datos y APIs con MCP: configuración de agentes locales 2026 — lo que habilita a los agentes bajo el capó; capa de protocolo para herramientas de sistema de archivos, base de datos, navegador y GitHub.
• Mejores modelos locales para tool calling en 2026 — la capa del modelo; benchmarks cara a cara de los tool-callers recomendados (Qwen3-Coder, Gemma 4, GLM-5.1, Llama 3.3).
• Continue.dev vs Cline vs Aider: mejor agente de codificación local en 2026 — comparativa de harnesses adyacentes para trabajo de tipo codificación.
• Agentes de IA locales para flujos de trabajo empresariales y cumplimiento en la UE — contexto aplicado para empresas que operan bajo GDPR / EU AI Act.
• Mejores LLM locales en 2026 — referencia de modelos para el panorama más amplio de pesos abiertos.
• Power Local LLM Hub — biblioteca completa de guías.