Ctrl K
ComunidadGuías…
GITHUB · ANALIZADO

preloop

Preloop es un control plane de agente de IA autocontenido, que actúa como firewall MCP, gateway para modelos y punto de observabilidad. Permite gobernar, atribuir y visualizar las llamadas a herramientas y modelos.

Ficha actualizada 22 sept 2026, 22:23 · upstream 22 sept 2026, 22:13 · release v0.16.0

Ver códigoProblemas y ayudaRepositorio ↗Sitio oficial
00

Qué es preloop

Descripción editorial construida a partir del repositorio, su documentación y sus señales de mantenimiento.

Preloop es una solución open-source autocontenida que se sitúa entre los agentes de IA y todo lo que alcanzan, permitiendo gobernar, atribuir y visualizar cada llamada a herramienta y modelo. Se basa en cuatro pilares fundamentales: un firewall MCP para permitir, denegar o requerir aprobación sobre cualquier llamada a herramienta; un gateway de modelos compatible con OpenAI, Anthropic y Gemini, que incluye presupuestos, listas de modelos autorizados, contabilidad de tokens y atribución; políticas como código con aprobaciones humanas mediante YAML y CEL; y observabilidad de sesiones en tiempo real con un timeline único que registra llamadas a herramientas, modelos, políticas, aprobaciones, gasto y resultados.

El sistema permite onboarding de agentes existentes con un solo comando, habilitando el uso desde la consola, teléfono o observador. Soporta múltiples agentes como OpenClaw, Claude Code, Codex CLI, Cursor, Gemini CLI, Hermes, OpenCode y Windsurf, así como cualquier agente compatible con MCP. Las flujos pueden definirse mediante presets que revisan PRs, implementan issues o escanean vulnerabilidades, mientras que la observabilidad del runtime mantiene un timeline de sesiones al lado del flujo.

Se integra con GitHub, GitLab y Jira como disparadores de flujos, permitiendo automatizaciones desde presets incluidos en el repositorio. También permite iniciar flujos como hijos de otros flujos dentro de una misma cuenta, con presupuestos durables para cada turno y gates basados en la cabeza actual del código fuente. Los resultados finales se pueden recuperar mediante búsquedas explícitas o exportando inventarios y registros de fallos a archivos legibles por auditoría.

La arquitectura incluye un control plane centralizado que gestiona credenciales, políticas y presupuestos, mientras que los agentes operan con autonomía dentro de límites definidos. El sistema soporta exportación de datos para cumplimiento normativo (Art. 8 inventario, Art. 28 registro) y genera candidatos a incidentes bajo el Art. 17 de la Ley de IA.

CASOS DE USO
  • Gobernar un agente que realiza llamadas a herramientas como GitHub API o Jira API con políticas de aprobación por defecto
  • Implementar un flujo automatizado que revise PRs, implemente issues y escanee vulnerabilidades antes de publicar
  • Controlar el uso de modelos de IA en producción mediante presupuestos por modelo y atribución de tokens
  • Monitorear la ejecución de flujos de trabajo con observabilidad de llamadas a herramientas y decisiones humanas
  • Automatizar respuestas a tickets o issues desde un agente que consulta bases de datos internas o APIs externas
  • Gestionar el ciclo de vida de agentes de IA en producción, incluyendo onboarding, observabilidad y cumplimiento normativo
PUNTOS DESTACADOS
  • Soporta múltiples agentes (OpenClaw, Claude Code, Cursor, Gemini CLI) mediante plugins del runtime sin necesidad de reconfigurar cada uno
  • Permite la aprobación humana nativa a través de interfaces móviles, Slack, Mattermost o el propio agente con comando 'ask_user'
  • Ofrece observabilidad completa de sesiones: timeline único que registra llamadas a herramientas, modelos, políticas y aprobaciones en tiempo real
  • Soporta exportación de resultados para cumplimiento normativo (Art. 8 inventario, Art. 28 registro) mediante presets configurables
  • Permite la delegación de flujos entre agentes dentro de una misma cuenta con presupuestos durables por turno
  • Integra observabilidad OTLP sin reemplazar el ledger de gastos, exportando solo llamadas a modelos y herramientas
PRECAUCIONES
  • El firewall MCP requiere configuración manual o mediante presets; no hay un sistema de aprobaciones automático nativo
  • La observabilidad es limitada al runtime del agente; se pierde contexto sobre la ejecución previa del flujo si no se usa el timeline completo
  • No incluye capacidades de razonamiento profundo ni generación de contenido original, solo gestión y supervisión
  • El cumplimiento normativo (Art. 8/27) requiere configuración manual adicional por parte del usuario final
  • La observabilidad OTLP es opcional por defecto; no está integrada en el flujo principal sin configuración explícita
01

Perfil de infraestructura

Estimación inicial derivada del repositorio y de los servicios detectados.

CPU4 vCPUrecomendación inicial
MEMORIA4 GBRAM estimada
DISCO20 GBalmacenamiento base
COMPLEJIDADhighnivel de operación
02

Despliegue detectado

Qué señales reales de instalación hemos encontrado.

Docker Compose detectado

Instalación con Docker Compose: se ejecuta un contenedor de agente que consume una base de datos PostgreSQL y NATS. Se recomienda usar un volumen para persistencia de datos. Para producción, se recomienda desplegar en Kubernetes o Cloud Provider (AWS, GCP). El control plane puede ser self-hosted o usar Preloop Cloud. La configuración de políticas se realiza mediante YAML con CEL como lenguaje de expresión. Se recomienda habilitar observabilidad OTLP y exportación de logs para auditoría.

✓Dockerfile
✓Compose
—One-click
03

Stack y dependencias

Componentes inferidos a partir de manifests, configuración y documentación.

FRAMEWORKS
Next.jsFastAPIPython
SERVICIOS
PostgreSQLNATS
BASES DE DATOS
PostgreSQL
PUERTOS
3000800042228222
05

Puede sustituir a

Relaciones detectadas por el análisis del repositorio y su categoría.

06

Experiencia real de la comunidad

Ayuda a contrastar la estimación automática con instalaciones reales.

Todavía no hay datos comunitarios para este proyecto.