Firekeep

Código fuente disponible, memoria compartida autoalojada, contexto de trabajo, coordinación y evidencia para Claude Code, Codex, Kiro, OpenCode y clientes MCP.

GitHub

Prueba este MCPPatrocinado

Documentación

Firekeep

Tus agentes no deberían trabajar como desconocidos.

Conecta Claude Code, Codex, Kiro, OpenCode y otros clientes MCP a través de un único Keep compartido y autoalojado.

Cada problema resuelto debería hacer más fácil el siguiente. Firekeep preserva la experiencia detrás del trabajo — conocimiento duradero, estado de trabajo, procedimientos, coordinación y evidencia inspeccionable — y la pone a trabajar en la siguiente sesión, herramienta o máquina.

Úsalo para tu propia continuidad en una estación de trabajo. Añade compañeros de equipo cuando los necesites sin tener que empezar el contexto del equipo desde cero.

Sitio web · Instalación · Tour del producto · Firekeep Studio · Evidencia · Privacidad · Soporte

Un solo Keep, en todos los entornos de ejecución

flowchart LR
    A["Claude Code<br/>stores a proven fix"] --> K[("your self-hosted<br/>Keep")]
    K --> B["Codex<br/>recalls the fix + evidence"]
    K --> C["Kiro<br/>reuses the procedure"]
    K --> D["OpenCode / MCP client<br/>continues informed"]

Los agentes conservan sus interfaces nativas y las sesiones propiedad del proveedor. Lo que se transmite es el contexto de Firekeep que registran y recuperan explícitamente a través del mismo gateway MCP local. Eso significa que una persona puede cambiar de herramienta sin perder el hilo, y un equipo puede adquirir contexto una vez y transmitirlo.

Ver cómo Claude Code y Codex comparten un mismo Keep →

Instalar Firekeep

El instalador configura Claude Code, Codex, Kiro y OpenCode juntos (además de Claude Desktop cuando su directorio de configuración existe), y luego pregunta dónde debería vivir tu servidor Firekeep. El flujo de configuración completo está en la guía de instalación.

curl -fsSL 'https://firekeep.ai/latest/install?src=github' | sh    # macOS / Linux
irm 'https://firekeep.ai/latest/install.ps1?src=github' | iex      # Windows PowerShell

El servidor actual requiere linux/amd64 y necesita Docker Compose v2, dos núcleos de CPU x86-64 y Git; se recomiendan 16 GB de RAM para la pila predeterminada. Se vincula a 127.0.0.1 de forma predeterminada. Consulta las notas de requisitos y dimensionamiento antes de elegir un host.

¿Probando Firekeep por primera vez? Comparte qué funcionó y dónde te quedaste atascado →

Cobertura de entornos de ejecución

Client Kit: configura Claude Code, Codex, Kiro y OpenCode juntos; Claude Desktop se añade cuando su directorio de configuración existe. Otros clientes MCP pueden usar la ruta genérica.
Claude Code: MCP gestionado, instrucciones y hooks de ciclo de vida. Su hook previo a herramientas compatible puede bloquear de forma estricta una edición, escritura o acción de shell.
Codex: MCP gestionado más orientación AGENTS.md. Codex no expone hooks nativos, por lo que la automatización del ciclo de vida y la aplicación previa a la edición no están implícitas.
Kiro CLI: un agente Firekeep con nombre con MCP, dirección y hooks de ciclo de vida. En la superficie validada de Kiro CLI 2.12.1, su hook previo a la edición es consultivo.
Firekeep Studio: ejecuta Codex, Claude Code, Kiro CLI y Grok en un único espacio de trabajo de escritorio. El adaptador directo de Grok no tiene memoria Keep, hooks ni briefing; Studio informa ese límite en lugar de heredar el estado de otro entorno de ejecución.

Consulta la guía de integración y la matriz de entornos de ejecución de Studio para obtener los detalles mantenidos.

Recuperación medida, con el método adjunto

En la ejecución aceptada de LongMemEval-S del 2026-08-28, Firekeep logró 97.7% de Evidence Recall@10: al menos una sesión de evidencia etiquetada apareció en los primeros diez resultados para 459 de 470 preguntas puntuadas. La medición cubre la recuperación, no la precisión de la respuesta generada; es una ejecución determinista corregida en lugar de un intervalo de confianza de múltiples ejecuciones.

Metodología · Datos de resultados

El problema que resuelve Firekeep

Las personas no construyen juicio profesional releyendo cada correo electrónico, documento, ticket o archivo fuente desde el principio. Recuerdan lo que sucedió, por qué una decisión funcionó, cómo se diagnosticó una falla y qué procedimiento se mantuvo en la práctica. Esa experiencia cambia cómo abordan el siguiente problema.

Los agentes deberían mejorar de la misma manera. Firekeep conecta el conocimiento, el estado de trabajo, la coordinación y la evidencia detrás del trabajo para que el siguiente agente pueda comenzar con la experiencia que el último ganó.

Mapa detallado de capacidades

Capacidad	Qué significa
Memoria	Los agentes recuerdan qué funcionó, qué falló y qué importa entre sesiones. Recuperación semántica + de grafo, puntuación de confianza, manejo de contradicciones, cuatro tipos de memoria (referencial / procedimental / episódica / transitoria) con decaimiento de recuperación según el tipo, envejecimiento recuperable de archivo primero, y recuperación consciente de tokens con síntesis LLM opcional. La recuperación se reordena según los resultados de sesión registrados (memoria ponderada por resultados) y según la retroalimentación del agente sobre el conocimiento que realmente se utilizó (`memory_feedback`).
Piloto automático de conocimiento	La base de conocimiento se mantiene sola sin decidir nada por sí misma. Cuando dos memorias no confirmadas entran en conflicto genuino, ninguna se descarta silenciosamente — ambas permanecen recuperables, marcadas como en disputa, hasta que un veredicto humano (`/memory/contested/resolve`). Un reaper de sesiones cierra sesiones bloqueadas/abandonadas para que las fallas cuenten en la puntuación de resultados. Cada cola de revisión (habilidades en borrador, habilidades obsoletas, propuestas de procedimientos, pares en disputa, cartas muertas de evaluación) llega a una sola bandeja de entrada con un resumen semanal, y `/memory/{id}/evidence` muestra cada señal detrás del rango de una memoria en una sola lectura.
Continuidad de equipo	Las memorias llevan procedencia verificada de espacio de trabajo/miembro más una etiqueta `agent_id` de entorno de ejecución no confiable y proyecto. Los informes de actividad por contribuyente y los briefs de traspaso sintetizados por LLM permiten que un agente continúe donde otro lo dejó.
Continuidad de sesión	Los planes, decisiones y progreso registrados a través de las herramientas de sesión sobreviven a la compresión de contexto. Las sesiones bloqueadas se detectan automáticamente en el siguiente inicio y se ofrecen para reanudación con una instantánea periódica del espacio de trabajo (rama git, commits recientes, estadísticas de diff) incrustada en la sombra.
Conciencia del entorno	Los recolectores configurados de Docker, git y archivos monitorean el estado operativo en lugar de depender solo de prompts. Los reinicios de contenedores, nuevos commits y cambios de archivos fluyen hacia un flujo de eventos reproducible.
Coordinación de agentes	Canales compartidos, tablón de anuncios, cola de tareas estructurada, leases de recursos con tokens de monotonicidad de vallado, registro de presencia y mensajes directos. Los agentes concurrentes pueden asignar trabajo, rastrear progreso y usar leases para prevenir ediciones superpuestas; los clientes con hooks bloquean una edición cuando otro agente ya tiene el lease del archivo.
Gateway de predecir-luego-actuar	Los agentes declaran intención antes de acciones consecuentes (`action_before` → `allow
Habilidades	Los agentes crean manuales reutilizables de "qué hacer cuando sucede X" a través de la herramienta `skill_create` (del lado del cliente, con contexto completo de sesión); un pipeline de docs→habilidades redacta más a partir de wikis/runbooks bajo revisión humana. Las mejores coincidencias se inyectan en el briefing de la siguiente sesión. (La auto-síntesis del lado del servidor existe detrás de `SKILL_SYNTHESIS_ENABLED` pero está desactivada por defecto — el despliegue solo con CPU no puede ejecutar el LLM de generación en un tiempo viable.)
Runbooks aplicados	Una habilidad cuyos pasos llevan coincidencias de comandos es un runbook que un humano puede armar: `advise` (avisos de ronda 1), `require_ack` (un comando coincidente es desafiado y procede solo después de un reconocimiento auditado — permiso de un solo uso vinculado a espacio de trabajo, miembro, sesión, hash de comando, paso, versión de bundle y ejecución), o `block` (falla cerrada, con un recibo del servidor que el cliente requiere antes de honrar un permiso). La evidencia se puntúa por éxito — un paso cuenta solo cuando su comando sale con 0 — y cada evento de aplicación cae en un libro de desviaciones (panel + bandeja de entrada), almacenando hashes de comandos, nunca texto de comandos. Los modos los establece un humano en una ruta solo de administrador; los agentes pueden proponer runbooks, nunca armarlos. Opt-in a través de `PROCEDURE_ENABLED`, actualmente en dogfooding en nuestros propios despliegues — ver docs/guides/living-procedures.md.
Tablero de decisiones	Cuando una aclaración necesita más que un par de preguntas, el agente abre un tablero de navegador local precargado con evidencia recuperada de la memoria del equipo — mejores preguntas, informadas por lo que el equipo ya aprendió. El gateway local está al frente del proceso del Tablero de decisiones y de Cortex `/decision/synthesize`.
Instrucciones vivas	La capa de instrucciones se mide a sí misma: una tabla de cumplimiento por instrucción calculada determinísticamente a partir de la reproducción (¿las sesiones recordaron antes de responder, registraron mientras avanzaban, declararon acciones consecuentes?), con tendencia a lo largo del tiempo, segmentos por entorno de ejecución y recibos de exposición — las sesiones llevan un hash de contenido del texto de instrucción que realmente les llegó, y cualquier cosa no verificable se reporta como desconocida en lugar de contarse. Honesta sobre sus límites por construcción: mide el comportamiento, no si el comportamiento ayudó. Las reescrituras redactadas por flota bajo veredicto humano y validación A/B están en la hoja de ruta.
Libro de confianza	Un registro de empleo por agente construido a partir de las declaraciones que los agentes ya hacen a través del gateway (`action_before`/`action_after`): conteo de acciones declaradas, tasa de conciliación, calibración de predicción-coincidencia (Brier sobre confianza declarada vs resultado conciliado), reversiones, sesiones, primera/última vez visto. Solo visibilidad — reporta, nunca bloquea. Honesto por construcción: la calibración es comportamiento no competencia, solo se ven las acciones declaradas, `agent_id` es una etiqueta auto-reportada, por lo que el registro es por identidad declarada, y la calibración lee señal insuficiente por debajo de un umbral en lugar de inventar un número. La mitad aplicadora (un broker de capacidades que convierte el registro en autonomía ganada) está en la hoja de ruta.
Auto-evaluaciones + Descubrimiento de patrones	Métricas de calidad calculadas a partir de trazas de reproducción al completar la sesión. La detección de patrones está habilitada; la promoción/validación automatizada y los endpoints de experimentos A/B están implementados pero desactivados por defecto hasta que un despliegue tenga suficiente volumen de sesiones para usarlos responsablemente.
Reproducción y explicabilidad	Cada lectura/escritura de memoria, evento de ciclo de vida de sesión, cambio de entorno, acción de coordinación y decisión del gateway se registra como una traza estructurada. Inspecciona, reduce y reconstruye el contexto en cualquier evento anterior.
Secretos cifrados	Bóveda respaldada por Fernet para credenciales de infraestructura, tokens de API y cadenas de conexión. Distinta de la memoria — los secretos nunca aparecen en la recuperación.
Conocimiento empresarial	Ingiere documentos de la empresa (páginas wiki, tickets, documentación de API) — manualmente o mediante recolectores programados de Confluence. Los fragmentos caen en el almacén vectorial y aparecen naturalmente durante la recuperación de memoria junto con las memorias operativas.
Inteligencia de código	Búsqueda de símbolos basada en tree-sitter, grafos de llamadores, mapas de arquitectura y análisis de impacto que devuelve fragmentos de símbolos en lugar de archivos completos — se ejecuta del lado del cliente a través del gateway local (`firekeep-symdex` se instala con el kit). 38 herramientas MCP (8 herramientas de análisis ocultas por defecto detrás de `SYMDEX_ANALYTICS_ENABLED`).

Por qué Firekeep es diferente

Firekeep no es otro envoltorio de chatbot ni capa de orquestación de prompts.

Es una capa operativa para agentes de IA conectados — infraestructura que se sitúa detrás de tus herramientas existentes y las mejora.

Autohospedado por defecto. El servidor, los almacenes de datos, los embeddings y el modelo de generación predeterminado se ejecutan en tu infraestructura. La salida a terceros solo ocurre cuando optas por un conector o un proveedor externo de Symdex AI.
Profundo donde ocurre el trabajo. La codificación es el flujo de trabajo más sólido implementado, con Symdex para inteligencia de código. No es el límite del producto: Docdex incorpora carpetas de documentos seleccionadas al mismo Keep, Maildex incorpora el correo de un miembro (IMAP de solo lectura, siempre privado del miembro, firekeep maildex add), y las capas compartidas de continuidad, coordinación, gobernanza y evidencia son independientes del dominio.
Persistencia + observabilidad. La mayoría de las herramientas de agentes se centran en hacer al agente más inteligente en el momento. Firekeep se centra en lo que ocurre entre sesiones y después de que algo sale mal.
Nativo de MCP. Cuatro servicios remotos y dos backends locales del cliente exponen herramientas de Model Context Protocol a través de una única puerta de enlace stdio local firekeep. Los adaptadores incluidos configuran Claude Code, Claude Desktop, Codex, Kiro y OpenCode; otros clientes MCP pueden configurarse manualmente.
Independiente del agente. Cambia el cliente agente sin reconstruir la capa subyacente de memoria y coordinación. Cursor tiene una ruta MCP manual documentada; Aider actualmente no tiene un adaptador incluido.
Descubrible mediante A2A. Relay publica una tarjeta de agente Agent-to-Agent en /.well-known/agent.json para el descubrimiento de capacidades. Esto es solo descubrimiento, no un endpoint de ejecución de tareas A2A.

Detalles de instalación y operación

Un comando, dos preguntas obligatorias: la identidad del agente a la que se atribuye cada memoria, sesión y evento de reproducción, y dónde está tu servidor Firekeep — configúralo en esta máquina con Docker, canjea un código de unión, apunta a uno que ya esté en ejecución, o decide más tarde (firekeep doctor entonces te dice cómo terminar). Configurarlo aquí ejecuta firekeep init por ti; ese instalador no pregunta nada, y la máquina se inscribe sola una vez que la pila está activa, por lo que firekeep doctor está en verde sin panel, sin túnel y sin clave pegada. Imprime el comando listo para pegar para tu segunda máquina cuando termina.

El instalador ofrece entonces una solicitud omitible para el archivo de reglas de otro cliente MCP; los cuatro adaptadores incluidos se renderizan de cualquier manera.

Las imágenes actuales del servidor apuntan a linux/amd64: ejecútalas en un host Linux x86-64, o mediante Docker Desktop con soporte de contenedores amd64. El bootstrap del cliente se prueba en CI en Ubuntu, Debian, Alpine, Fedora, Rocky, Arch y openSUSE (x86_64 y aarch64); macOS ejecuta el mismo script pero no está cubierto por CI.

Requisitos y dimensionamiento — firekeep.ai/docs.html#requirements
Instalación del servidor — firekeep.ai/docs.html#server
Conexión de agentes y compañeros — firekeep.ai/docs.html#connect
Solución de problemas — firekeep.ai/docs.html#troubleshooting

Desde este checkout

bash install.sh              # build the server from source
bash install.sh --pull       # the same installer against the published images
cd client && ./install       # the kit from this checkout (.\install.ps1 on Windows)
firekeep install             # re-render the runtime adapters only

install.sh no solicita nada: la dirección del host se detecta y la contraseña de Neo4j se genera (--ip / --neo4j-password, o FIREKEEP_VPS_IP / FIREKEEP_NEO4J_PASSWORD, anulan cualquiera de las dos). Regresa tan pronto como la pila esté activa en lugar de bloquearse en la descarga del modelo de ~3.3 GB — hasta que eso termine, las escrituras de memoria devuelven status="partial" (almacenadas y en cola para relleno, aún no buscables) y firekeep doctor lleva una fila WARN de embeddings indicándolo. bash install.sh --wait-for-models se bloquea en su lugar.

Operar el servidor después — acceso y autenticación, el panel, copias de seguridad, actualizaciones, exponer puertos deliberadamente — está en docs/DEPLOYMENT.md.

Eliminarlo

firekeep uninstall            # remove the client kit from this machine
firekeep uninstall --server   # also tear down the server + ALL its data

firekeep uninstall elimina solo lo que el kit instaló — los bloques de Firekeep en la configuración de cada runtime (tus propios ajustes permanecen intactos), el lanzador y su entrada en PATH, y ~/.firekeep — y pregunta primero (--yes omite la solicitud). Nunca toca un servidor que configuraste. --server además ejecuta docker compose down -v en la pila que esta máquina aprovisionó, eliminando los volúmenes de Neo4j/Qdrant/Redis — cada memoria, sesión y secreto, permanentemente — detrás de una confirmación separada de pérdida de datos que una desinstalación simple o --yes nunca pueden activar. Haz una copia de seguridad primero (docs/DEPLOYMENT.md) si podrías querer los datos de vuelta.

Firekeep Studio

Descargar para Windows · Descargar macOS universal · Explorar Studio →

studio/ es un cliente de escritorio separado para personas que quieren que Firekeep sea la única aplicación de agente que abren. Da a Codex, Claude Code, Kiro CLI y Grok una superficie de conversación neutral al runtime: cualquier runtime compatible puede ser el principal explícito, otros runtimes pueden revisarlo en contextos nuevos de solo lectura, y /compare, /consensus, un espacio de trabajo compartido explícito, entrada de voz en Windows y salida de voz del sistema, guardas de tokens conscientes de caché, sesiones locales nombradas y codificadas por color, descubrimiento en vivo de modelo/razonamiento del proveedor y controles tipados del Client Kit están integrados. El runtime seleccionado es visualmente explícito, el inspector completo se puede ocultar, y Studio enlaza al panel desde la conexión existente del Client Kit sin exponer sus credenciales. Los diagramas Mermaid encerrados se renderizan como diagramas nativos ampliables, y el Panel de Decisiones existente de Firekeep se abre como un panel nativo de pregunta/evidencia/acción dentro de Studio. Su push autenticado local preserva el long poll original, evitando un turno extra del agente solo para descubrir que el panel está listo. El selector de runtime principal muestra disponibilidad en vivo y contexto de transporte, el desplazamiento de respuestas respeta a los lectores que se alejan de la cola, y copiar/pegar usa operaciones de portapapeles nativas de solo texto limitadas. Las respuestas completadas lideran cada ejecución mientras los eventos de trabajo detallados se pliegan en un registro de trabajo. Una vista Agentes neutral al runtime coloca Codex, Claude, Kiro, Grok o cualquier adaptador futuro con capacidad de chat en paneles seleccionables con continuaciones nativas independientes; el compositor compartido apunta al panel seleccionado, y las ejecuciones activas permanecen serializadas para la seguridad del espacio de trabajo. El Modo Misión añade un arnés limitado por resultados: un escritor principal, comprobaciones locales deterministas, reparación limitada, evidencia de revisión independiente, aceptación humana explícita y un resultado de tarea almacenado por separado de la prosa de cada agente.

Studio consume límites estructurados compatibles con el proveedor en lugar de raspar TUIs, mantiene la autenticación del proveedor propiedad del proveedor (excepto claves API cifradas por el SO), y continúa usando el Client Kit de Python existente dondequiera que la configuración nativa de un runtime proporcione memoria Keep, hooks, política y conectividad. Las tarjetas de runtime informan esa evidencia explícitamente; el adaptador directo de Grok xAI está claramente marcado como sin memoria Keep en lugar de heredar la afirmación de otro runtime. La compilación de vista previa y los comandos del instalador, los límites de seguridad, la matriz de runtimes y el inventario completo de comandos / están en el README de Studio.

Studio 0.4 incluye un instalador de Windows x64 y un instalador de macOS universal desde un canal de lanzamiento aislado y firmado. Las compilaciones empaquetadas verifican actualizaciones de Studio poco después del lanzamiento; Windows descarga e instala una actualización verificada al reiniciar, mientras que macOS usa actualizaciones automáticas nativas solo cuando el lanzamiento está firmado y notarizado por Apple. La página de lanzamiento actual, las sumas de verificación y ambos instaladores se publican bajo Lanzamientos de Firekeep Studio.

Un Flujo de Trabajo Real

Esto es lo que ocurre cuando un agente usa Firekeep:

1. La sesión comienza. En runtimes con hooks de ciclo de vida, el cliente obtiene primero el GET /briefing agregado de Cortex, incluyendo memorias relevantes, tareas, estado del entorno y habilidades. El agente entonces llama a ctx_start_session("fix auth middleware bug"); Bridge crea la sesión duradera y el shim la vincula a ese informe.

2. Exploración de código. En lugar de leer cada archivo, el agente llama a search_symbols("auth middleware") y get_callers("require_scope") en Symdex. Obtiene una lista dirigida de archivos y llamadores en milisegundos.

3. Verificación del entorno. Sentinel ha estado observando Docker. Detectó que el contenedor cortex-api se reinició 3 veces en la última hora y envió una alerta al canal #alerts de Relay. El agente ve esto en su contexto.

4. El trabajo ocurre. El agente edita archivos, ejecuta pruebas y registra progreso importante con ctx_update. Bridge persiste lo que se registró explícitamente. Cuando la ventana de contexto se comprime, el agente llama a ctx_get_shadow y recupera ese estado de trabajo duradero — planes, decisiones, progreso y conocimiento de archivos.

5. La sesión se completa. El agente llama a ctx_complete_session, opcionalmente pasando una autoevaluación estructurada — task_result ("success" / "partial" / "failure", el resultado de la TAREA, no el del RPC) más hasta 10 afirmaciones cortas de task_evidence que la respaldan. La calificación solo se acepta del propietario verificado de la sesión y se almacena como el único resultado autoritativo de esa sesión, nunca sobrescrito. Bridge marca atómicamente la sesión como completa y pone en cola la destilación en segundo plano en memoria episódica; los fallos se reintentan y eventualmente se mueven a una cola de mensajes muertos visible. Las autoevaluaciones calculan métricas de calidad a partir del rastro de reproducción — una sesión sin calificación reconocida se lee como unknown en lugar de un éxito adivinado, por lo que la puntuación basada en resultados (Memoria Ponderada por Resultados, tendencias de calidad) nunca cuenta el silencio como una victoria. La próxima vez que alguien trabaje en middleware de autenticación, las memorias estarán allí una vez que la destilación tenga éxito.

6. ¿Algo salió mal? Abre la pestaña Reproducción en el panel. Carga la sesión. Ve cada acción, cada lectura de memoria, cada punto de decisión. Haz clic en un evento de fallo y ejecuta la reducción — retrocede a través de la cadena causal para ayudar a identificar la causa raíz.

Arquitectura

Local Machine                               VPS
┌──────────────────────────┐              ┌────────────────────────────────────┐
│ Claude / Codex / Kiro /  │              │ FirekeepCortex   — Memory & RAG    │
│ OpenCode / MCP client    │              │ FirekeepBridge   — Sessions        │
│           │              │              │ FirekeepSentinel — Monitoring      │
│  one `firekeep` gateway  │◄──── MCP ───►│ FirekeepRelay    — Coordination    │
│    ├─ symdex (local)     │              │ Dashboard        — Web UI          │
│    └─ decision (local)   │── Browser ──►│ Neo4j · Qdrant · Redis · Ollama    │
└──────────────────────────┘              └────────────────────────────────────┘

Symdex y el Panel de Decisiones se ejecutan del lado del cliente como servidores MCP locales a stdio (instalados con el kit) — Symdex debe ser local al árbol de trabajo que indexa, por lo que ya no es un contenedor VPS.

Las dos flechas que cruzan ese límite no son alcanzables públicamente por defecto. De fábrica, el lado VPS escucha en loopback y requiere una clave API, por lo que la mitad de la máquina local lo alcanza a través de un túnel SSH, una red privada o un front end HTTPS que configures deliberadamente. Consulta docs/DEPLOYMENT.md → Acceso y autenticación.

Servicio	Qué hace
FirekeepCortex	Memoria a largo plazo. RAG semántico + de grafos, ciclo de vida de archivo/restauración, consolidación por ciclos de sueño, cuatro tipos de memoria con decaimiento según tipo, memorias versionadas con puntuación de confianza, supersesión automática por contradicción, habilidades creadas por agentes (`skill_create`) + un pipeline de docs→habilidades, y la Puerta de Enlace de Agentes (superficie de predecir-y-actuar).
FirekeepBridge	Persistencia de sesión. Preserva el contexto de trabajo (planes, decisiones, progreso, conocimiento de archivos) a través de compresiones de contexto. Auto-destila a Cortex al completarse. Detección de sesiones bloqueadas con reanudación mediante instantánea del espacio de trabajo. Un recolector de sesiones abandona sesiones inactivas por más de 72h para que las sesiones abandonadas se registren como no exitosas en la puntuación de resultados. Emite eventos del ciclo de vida de sesión al flujo de reproducción.
FirekeepSentinel	Observador del entorno. Salud de Docker, commits de git, cambios de archivos. Transmite alertas a Relay en errores. Reinicios de contenedores, nuevos commits y cambios de archivos fluyen a un flujo de eventos reproducible.
FirekeepRelay	Coordinación de agentes. Canales pub/sub en tiempo real, tablón de anuncios persistente, cola de tareas estructurada, arrendamientos de recursos con tokens de cercado monótonos, registro de presencia, mensajes directos y un endpoint de tarjeta de agente A2A para descubrimiento externo.
Dashboard	Interfaz web que cubre coordinación, memoria, diagnósticos, dispositivos, miembros, políticas, bóveda y operaciones.
Firekeep Studio	Consola de escritorio local opcional y arnés de Misión para agentes primarios, verificación determinista, revisores independientes, dictado de Windows, respuestas de voz del sistema, comparación entre runtimes y control del Kit de Cliente. No es un servicio VPS.

Inteligencia de código (FirekeepSymdex — 38 herramientas MCP, 8 análisis ocultos tras una bandera) y el Panel de Decisiones (firekeep-decision) se ejecutan del lado del cliente como servidores MCP stdio-local instalados con el kit, no como contenedores VPS.

Módulos compartidos (sin contenedores adicionales): Motor de Reproducción (registro de trazas estructurado en todos los servicios), Autenticación (ámbitos de claves API), Bóveda (almacenamiento de secretos cifrado con Fernet), Corpus (ingesta de documentos de negocio → fragmentos vectoriales; recolectores programados de Confluence), Auto-Evaluaciones (10 métricas de calidad de Nivel 1 + seguimiento de tendencias + detección de regresiones), Motor de Patrones (detección de estrategias; la validación de promociones y los experimentos A/B están desactivados por banderas de características por defecto), Motor de Políticas (verificaciones de seguridad compuestas previas a la edición — arrendamiento, riesgo de archivo, denegación de rutas, salud de sesión, fallo reciente), Puerta de Enlace de Agentes (superficie de predecir-y-actuar con caché de ruta rápida para acciones repetidas de bajo riesgo), Habilidades (creadas por agentes vía skill_create + borradores de docs→habilidades bajo revisión humana; síntesis del lado del servidor desactivada por defecto), Mejoras de Memoria (envejecimiento compuesto con archivo primero, vista previa/auditoría/restauración, presupuestos de tokens, pasada de síntesis LLM, entrada de incrustación limitada + ajuste para reducir).

Para la especificación de diseño completa, consulta docs/DESIGN.md.

Dashboard

Accede en http://localhost:8040 en el host, o mediante un túnel desde otro lugar (docs/DEPLOYMENT.md → Llegar al dashboard). Tiene su propio inicio de sesión de autenticación básica (usuario admin; la contraseña se escribe una vez en dashboard/.htpasswd.cred). Detrás de eso, nginx inyecta la clave API del dashboard en cada llamada de backend, por lo que la SPA funciona contra la pila protegida por autenticación sin que pegues una clave en el navegador.

Pestaña	Qué muestra
Resumen	Salud del servicio, estadísticas rápidas, eventos y memorias recientes
Sesiones	Sesiones activas/en pausa/completadas/abandonadas, inspector de contexto en sombra
Eventos	Flujo de eventos de Sentinel con filtros de fuente y severidad
Relay	Cola de tareas, canales, tablón de anuncios, mensajes directos, reclamaciones/arrendamientos activos
Alcance	Sesiones de aclaración de FirekeepScope — pantallas activas, indicaciones de respuesta
Memoria	Búsqueda de recuperación, navegadores de activos/archivo, restauración con un clic, vista previa/auditoría de mantenimiento, formulario de almacenamiento, contribuyentes, estadísticas de espacios de nombres/etiquetas
Habilidades	Tarjetas de habilidades creadas por agentes y derivadas de documentos — revisar, activar, editar, retirar — más las tarjetas de runbook de Procedimientos Vivos: insignia de modo de aplicación y control de modo administrador, estadísticas de observación por paso, vista de desviación y una advertencia de NO APLICADO ACTIVAMENTE cuando un runbook armado no tiene una sesión que mantenga el paquete actual
Conocimiento	Ingesta de docs→habilidades (pegar / URL) + la cola de aprobación de habilidades en borrador
Autopiloto	La bandeja de revisión (habilidades en borrador/obsoletas/re-revisión, propuestas de procedimientos, desviaciones de runbook, pares de memoria en disputa, cartas muertas de evaluación), el resumen de "qué cambió esta semana", la tabla de cumplimiento de Instrucciones Vivas (tasas por instrucción, tendencia, segmentos por runtime, estados de exposición) y la tarjeta de Libro de Confianza (declarado/reconciliado/calibración/reversiones por agente) — solo lectura; propone e informa, nunca muta
Patrones	Tarjetas de estrategias descubiertas; controles de validación de promoción y experimentos cuando sus banderas de características están habilitadas
Operaciones	Trabajadores, profundidades de cola, agentes activos, información del almacén vectorial, contador de Disciplina (llamadas de memoria sin etiquetar)
Políticas	Reglas de política en tiempo de ejecución para verificaciones de seguridad previas a la edición, alternar por regla
Bóveda	Gestión de secretos cifrados (respaldada por Fernet, Redis DB 7)
Reproducción	Líneas de tiempo de trazas de sesión, inspector de eventos, reducción de causa raíz
Evaluaciones	Métricas de calidad agregadas, tarjetas de puntuación por sesión, tendencias de calidad
Dispositivos	Credenciales de dispositivos y comandos de inscripción de un solo uso
Miembros	Personas e invitaciones de miembros de un solo uso

El dashboard es una SPA estática sin dependencias. Sin paso de compilación, sin npm, sin framework.

Documentación

Documento	Contenido
docs/DEPLOYMENT.md	Ejecutar un servidor: acceso y autenticación, actualización, copias de seguridad, solución de problemas, desarrollo local (instalación en firekeep.ai/docs.html)
docs/CONFIGURATION.md	Todas las variables de entorno, asignación de bases de datos Redis, características de inteligencia
docs/MCP-TOOLS.md	Referencia completa de herramientas MCP en el servidor y backends locales registrados del cliente; el inventario visible varía según el registro de dex y las banderas de características
docs/DESIGN.md	Especificación completa de arquitectura, contratos de servicio, puntos de integración
docs/COMPARISON.md	Comparación característica por característica vs. Claude Code base
docs/SETUP-CODEX.md	Guía de integración de Codex
docs/SETUP-CLAUDE-CODE.md	Guía de integración de Claude Code
docs/MULTI-AGENT.md	Inteligencia de agentes: informe previo al vuelo, informe de sesión, coordinación multiagente
studio/README.md	Matriz de runtime de Firekeep Studio, comandos, modelo de seguridad, desarrollo y empaquetado

Pila Tecnológica

Servicios de servidor Python 3.11 (el cliente admite Python 3.10+) / FastAPI / FastMCP / Neo4j / Qdrant / Redis / Ollama / Docker Compose / tree-sitter / TypeScript / Electron / React

Las incrustaciones y la generación del lado del servidor usan Ollama local por defecto, por lo que la ruta del servidor por defecto no tiene factura de API de modelos. Symdex puede usar opcionalmente Anthropic, Gemini o un endpoint compatible con OpenAI para resúmenes de símbolos y andamiaje; habilitar uno de esos proveedores puede enviar fragmentos de código fuera de la máquina e incurrir en costos del proveedor. La indexación automática en segundo plano desactiva explícitamente los resúmenes de IA.

Hoja de Ruta

Funcionando ahora

Ciclo de vida completo de la memoria (aprendizaje, recuerdo, decaimiento, detección de contradicciones, versionado)
Cuatro tipos de memoria (referencial / procedimental / episódica / transitoria) con decaimiento de recuerdo según el tipo; los aprendizajes directos se guardan por defecto como episódicos, mientras que la consolidación de eventos en bruto clasifica el conocimiento extraído
Recuerdo consciente de tokens con síntesis opcional por LLM
Envejecimiento compuesto con archivo primero (edad × acceso × confianza) con vista previa en el panel, auditoría y restauración; las memorias confirmadas, las habilidades y los fragmentos del corpus nunca se archivan por edad, y la purga automática dura está desactivada por defecto
Continuidad del equipo: procedencia verificada de espacio de trabajo/miembro más agent_id y project en tiempo de ejecución, informes de contribuyentes, resúmenes de traspaso sintetizados por LLM
Persistencia de sesión mediante compresiones de contexto, con detección de fallos y reanudación mediante instantáneas del espacio de trabajo
Emisión de reproducción de puente en el ciclo de vida de la sesión (iniciada / actualizada / completada / abandonada)
Monitoreo de Docker + git + archivos con alertas Relay; la actividad de contenedores/commits/archivos fluye al flujo de reproducción
Coordinación de agentes: canales, tablón de anuncios, arrendamientos con token de exclusión, cola de tareas estructurada, registro de presencia, mensajes directos
Resumen previo al vuelo que reúne inteligencia de todos los servicios al inicio de la sesión; muestra advertencias de disciplina cuando las llamadas de memoria llegan sin encabezados de identidad
Informe posterior a la sesión: finalización guiada con actualizaciones de tareas y limpieza de arrendamientos
Soporte multiagente (asignación de tareas, sondeo de bandeja de entrada, aplicación de arrendamientos de archivos)
Habilidades: creadas por agentes mediante skill_create (del lado del cliente) + un pipeline de documentos→habilidades (pegar / URL / recopiladores programados de Confluence) que redactan habilidades bajo revisión humana; las mejores coincidencias se inyectan en el siguiente resumen (la auto-síntesis del lado del servidor existe detrás de SKILL_SYNTHESIS_ENABLED, desactivada por defecto)
Turno nocturno: firekeep night-shift drena la cola de destilación de sesiones que llena el enganche de fin de sesión, ejecutándose en tu propia máquina contra un modelo local — LM Studio u Ollama, auto-detectado, sin configuración — y escribiendo memorias y borradores de habilidades atribuidos a la sesión original en lugar del trabajador. Mantiene la generación completamente fuera del servidor; los modelos alojados en la nube se rechazan por defecto para que el contenido de la sesión no pueda salir de la máquina
Tablero de decisiones: tablero de aclaraciones local generado por agentes, pre-poblado con evidencia de memoria del equipo recuperada (servidor stdio firekeep-decision + Cortex /decision/synthesize)
Modo personal / de omisión: /personal dentro de la sesión (o firekeep personal / FIREKEEP_BYPASS=1) hace que Firekeep quede completamente inactivo para trabajo privado — los enganches, el sidecar, el tablero de decisiones y el shim respetan una única puerta is_bypassed(); se limpia automáticamente al final de la sesión
Motor de patrones: detección de estrategias, clasificación de categorías (procedimental / riesgo / conductual) y controles de cuarentena; la promoción/validación automatizada está implementada detrás de PATTERN_VALIDATION_ENABLED=false por defecto
Marco de experimentos: conjuntos de datos nombrados, pruebas de significancia chi-cuadrado, intervalos de confianza del tamaño del efecto y experimentos controlados de consejos de estrategia detrás de PATTERN_EXPERIMENTS_ENABLED=false por defecto
Bucle de retroalimentación opcional para medir si los consejos del resumen mejoran los resultados cuando la validación de patrones está habilitada
Motor de políticas en tiempo de ejecución: comprobaciones compuestas previas a la edición (arrendamiento, riesgo de archivo, denegación de ruta, salud de sesión, fallo reciente)
Puerta de enlace de agentes (predecir-luego-actuar): MCP action_before / action_after, la puerta de enlace devuelve allow | rethink | block, caché de ruta rápida para acciones repetidas de bajo riesgo
Bóveda de secretos cifrada (Fernet) con herramientas MCP y API REST
Trazas de reproducción con reducción de causa raíz y reconstrucción de contexto por evento
Auto-evaluaciones: 10 métricas de calidad de nivel 1 calculadas al completar la sesión, seguimiento de tendencias, detección de regresiones
Knowledge Autopilot ronda 1 (visibilidad, nunca mutación autónoma): recuerdo ponderado por retroalimentación + la herramienta memory_feedback, un recolector de sesiones Bridge para que las sesiones fallidas cuenten como fallos, manejo de disputado-no-superado para conflictos de memoria no confirmados con veredictos humanos, la bandeja de revisión de Autopilot + resumen semanal, y un libro de evidencia por memoria (/memory/{id}/evidence) — ver docs/guides/knowledge-autopilot.md
Living Instructions rondas 1 + 2 (medición): la tabla de cumplimiento por instrucción en la pestaña Autopilot (predicados congelados a una línea base pre-registrada), tendencia a lo largo del tiempo y el contrato de medición de la ronda 2 — hashes del contenido de la instrucción estampados en el bloque renderizado, cinco encabezados de atribución, segmentos por tiempo de ejecución y estados expuesto/no-expuesto/desconocido con todo lo no verificable reportado como desconocido. Las reescrituras bajo veredicto humano y las variantes A/B entregadas en el resumen están en la hoja de ruta — ver la especificación de diseño en docs/ROADMAP.md
Dreaming: consolidación de memoria automatizada + perfiles de personas (DREAM_ENABLED, desactivado por defecto)
Living Procedures rondas 1 + 2: habilidades observadas como procedimientos con propuestas de frecuencia/eficacia bajo revisión humana y — ronda 2 — Runbooks Enforced: coincidencias de pasos de comando, aplicación de advise/require_ack/block armada por humanos con evidencia con puerta de éxito, un protocolo de desafío→reconocimiento→permiso de un solo uso, modo de bloqueo con cierre ante fallo y un libro de desviaciones por espacio de trabajo mostrado en el panel y en la bandeja de Autopilot (PROCEDURE_ENABLED, desactivado por defecto; dogfooding antes de cualquier anuncio) — ver docs/guides/living-procedures.md
Trust Ledger ronda 1: un registro de empleo por agente agregado bajo demanda a partir de eventos de la puerta de enlace de reproducción (GET /autopilot/trust + una tarjeta en el panel) — recuentos declarados/conciliados, calibración de coincidencia de predicciones, reversiones, sesiones. Solo visibilidad, global al despliegue, fórmulas congeladas pre-registradas antes del primer número publicado. El broker de capacidades de aplicación (autonomía ganada) es una ronda posterior
Endurecimiento de tenencia del corpus: fuentes de documentos privadas por miembro con un filtro de visibilidad compartido en cada salida, identidad de punto con ámbito de fuente (texto idéntico entre miembros ya no colapsa en un punto eliminable), autorización de fuente consciente del principal y una puerta de generación comprometida — infraestructura general debajo de los próximos dexes del cliente
Una puerta de enlace MCP local degradante registrada por cada adaptador, que agrega cuatro servicios remotos más el Tablero de decisiones local del cliente y los dexes registrados
El registro de dexes: los dexes son los índices de dominio que el Keep entiende, listados y cambiados con firekeep dex list|add|remove contra ~/.firekeep/dexes.json. Las tres ruedas se incluyen empaquetadas y verificadas por suma de comprobación con cada versión — el registro controla la actividad, no la instalación. Symdex y docdex están registrados por defecto (desde el cliente 1.2.0, un registro ausente se siembra con ambos); firekeep dex remove es el interruptor de apagado y las eliminaciones persisten entre actualizaciones — ver docs/guides/dexes.md
Inteligencia de código: firekeep-symdex del lado del cliente detrás de la puerta de enlace (38 herramientas, 8 análisis ocultos detrás de una bandera), montado cuando se registra como dex
Documentos: firekeep-docdex del lado del cliente — carpetas que un humano registra (firekeep docdex add ~/Notes) extraídas a texto e ingeridas en el corpus, apareciendo a través del memory_recall ordinario. Privado para el miembro por defecto incluso en un Keep compartido, --shared para el espacio de trabajo; md/txt/pdf/docx, sin OCR; la eliminación de un archivo local elimina su réplica del corpus en la siguiente sincronización
Correo electrónico: firekeep-maildex del lado del cliente — buzones IMAP que un miembro registra (firekeep maildex add), solo lectura (cada apertura es EXAMINE, cada recuperación es PEEK; sin capacidad de envío en la rueda), siempre privado del miembro
Pipeline de conocimiento documentos→habilidades (knowledge_ingest, ingesta por URL) + recopiladores programados opcionales de Confluence (SP3)
Panel web con gestión de Dispositivos y Miembros junto con memoria, coordinación, reproducción, políticas y operaciones
Endpoint de tarjeta de agente A2A (/.well-known/agent.json) para descubrimiento externo
Ingestión de conocimiento empresarial: dividir documentos en almacén de vectores, mostrar durante el recuerdo de memoria
Notificaciones webhook (Slack, Discord, HTTP genérico)
Autenticación: ámbitos de API por clave (memory:read/write, session:read/write, replay:read, eval:read, admin, …), activados por defecto, con claves inicializadas por el instalador

Prometido (los dos peldaños de la hoja de ruta publicados en firekeep.ai)

Instancias vinculadas — múltiples servidores Firekeep compartiendo conocimiento en una organización, para que lo que un equipo aprende sea recordable por otro
Perfiles de dominio — experiencias separadas (codificación y documentos hoy; investigación en el futuro) como perfiles del mismo kit de cliente sobre un cerebro compartido: nunca productos separados, nunca almacenes de memoria separados

El registro de decisiones detrás de ambos — perfiles-no-clientes, el prerrequisito de la capa de vinculación, el control de señales de resultados, la secuenciación — está en docs/ROADMAP.md.

Planificado (más pequeño)

Exportación de métricas Grafana
Ingestión de conector Jira (auto-sincronización de wiki/Confluence ya enviada, opcional)
Versionado y reversión de habilidades

Estado

Firekeep está en desarrollo activo y se usa a diario. Las implementaciones principales — memoria, sesiones, monitoreo de entorno, coordinación, reproducción, el kit de cliente y Symdex — están cubiertas por más de 4,000 pruebas automatizadas que pasan en el repositorio actual. La arquitectura está diseñada para un despliegue de un solo host.

Este repositorio público, con código fuente disponible, está en acceso temprano.

Licencia

Firekeep tiene código fuente disponible bajo BUSL-1.1, y el uso de producción auto-alojado es gratuito para individuos y para equipos — un espacio de trabajo de cualquier tamaño, en infraestructura que controlas, gratis para equipos mientras Firekeep esté en acceso temprano. El nivel comercial es gobernanza y soporte Enterprise (escribe a sales@firekeep.ai). Cada versión se convierte a Apache-2.0 cuatro años después de su primera publicación pública. Ver LICENSE para la concesión completa y docs/LICENSING.md para el estado. Symdex permanece bajo esta licencia hasta que su Core independiente se extraiga y se publique por separado bajo Apache-2.0.