Un motor de conocimiento independiente, donde Obsidian es solo uno de los conectores.
KOS construye una representación digital de tu conocimiento: ingesta cualquier fuente (Obsidian, PDF, Git, email, web…), la transforma en entidades y relaciones dentro de un grafo de conocimiento, mantiene memoria de largo plazo y razona sobre todo ello mediante agentes coordinados por un planner.
La pregunta que responde el sistema:
¿Cómo hago que una IA piense utilizando exactamente el mismo conocimiento que tengo yo, pero mejor organizado que mi propia memoria?
Fase 0 — Fundaciones (en curso): arquitectura documentada, entorno de desarrollo e infraestructura base. El desarrollo de código comienza en la Fase 1, una vez cerrados los documentos de diseño.
Toda decisión de diseño vive en docs/:
| Documento | Contenido |
|---|---|
| 00 — Visión y objetivos | Qué es KOS, para quién, y qué NO es |
| 01 — Arquitectura general | Los 10 dominios del sistema y sus fronteras |
| 02 — Modelo de dominio y ontología | Entidades, relaciones y esquema del grafo |
| 03 — Arquitectura de agentes | Planner, agentes especializados y coordinación MCP |
| 04 — Memoria y aprendizaje | Tipos de memoria y aprendizaje continuo |
| 05 — Ingesta y actualización | Pipeline de conectores → parser → grafo |
| 06 — APIs y contratos | Contratos entre servicios y API pública |
| 07 — Roadmap por versiones | v0.1 → v1.0 |
| 08 — Plan de sprints | Implementación sprint a sprint |
| 09 — Guía de desarrollo y despliegue | Convenciones, entorno local, CI/CD |
| 10 — Estructura del proyecto | Árbol de archivos objetivo y dónde vive cada cosa |
| ADRs | Architecture Decision Records |
kos/
├── docs/ # Documentos de arquitectura y ADRs
├── apps/
│ ├── api/ # FastAPI — API pública y orquestación (Fase 1)
│ ├── web/ # React + TS + Vite + Tailwind + shadcn/ui (Fase 1)
│ └── workers/ # Celery — ingesta, embeddings, grafo (Fase 1)
├── packages/
│ ├── core/ # Modelo de dominio, ontología, contratos internos
│ ├── connectors/ # Conectores de ingesta (Obsidian, PDF, Git…)
│ ├── agents/ # Planner, Retrieval, Graph, Memory… (Fase 4)
│ └── mcp-tools/ # Servidores MCP de herramientas
├── infra/ # Configuración de servicios (init de Postgres, etc.)
├── docker-compose.yml # Infraestructura local completa
└── Makefile # Atajos de desarrollo
| Capa | Tecnología |
|---|---|
| Backend | FastAPI + Pydantic |
| Frontend | React + TypeScript + Vite + Tailwind + shadcn/ui |
| Agentes | Arquitectura propia + MCP |
| LLM local | Ollama |
| Embeddings | bge-m3 / nomic-embed-text |
| Vector DB | PostgreSQL + pgvector |
| Grafo | Neo4j |
| Cache / colas | Redis + Celery |
| Almacenamiento | MinIO (S3 compatible) |
| Observabilidad | OpenTelemetry + Prometheus + Grafana |
| Contenedores | Docker Compose (Kubernetes más adelante) |
Las decisiones detrás de cada elección están registradas como ADRs.
Requisitos: Docker Desktop y make.
cp .env.example .env # ajusta credenciales si quieres
make up # levanta Postgres, Neo4j, Redis, MinIO y Ollama
make ps # estado de los servicios
make down # detiene todoServicios locales:
| Servicio | URL | Credenciales por defecto |
|---|---|---|
| PostgreSQL + pgvector | localhost:5432 |
kos / ver .env |
| Neo4j Browser | http://localhost:7474 | neo4j / ver .env |
| Redis | localhost:6379 |
— |
| MinIO Console | http://localhost:9001 | ver .env |
| Ollama (nativo en Mac) | http://localhost:11434 | — |
- El núcleo no depende de ninguna fuente. Obsidian, Notion o Gmail son conectores intercambiables.
- El activo es el modelo de conocimiento (ontología + grafo + memoria), no el LLM.
- El LLM nunca accede directamente a los datos: siempre pasa por el planner.
- Local-first: todo funciona en tu máquina sin enviar conocimiento a terceros.
- Docs antes que código: ninguna fase empieza sin su diseño cerrado.