Arquitectura
SHARA se organiza en cuatro capas: Cliente, API, Orquestación y Datos. Cada petición atraviesa todas, con aislamiento entre clientes en doble capa y un orquestador que decide qué especialista y qué modelo resuelven cada tarea.
Las cuatro capas
| Capa | Qué hace |
|---|---|
| Cliente | Lo único que se instala. Desktop App, Server Agent y conectores universales. |
| API | Punto de entrada autenticado. Aplica tenant, rate limits y cabeceras estrictas. |
| Orquestación | Amadeus delega a los agentes y un selector elige el tier de modelo. |
| Datos | Postgres con aislamiento multi-tenant en doble capa. |
1 · Cliente
Es lo único que se instala, y es universal en todos los planes:
- Desktop App (Electron firmado para Windows, macOS y Linux): notificaciones nativas, atajos y panel de aprobaciones. Es el cliente recomendado para el día a día.
- Server Agent (demonio sin interfaz): para entornos servidor que actúan a partir de eventos —cron, webhooks internos, colas—.
- Conectores universales (Gmail, Slack, CRM, ERP, etc.) que exponen tus herramientas como capacidades del equipo.
2 · API
Toda petición pasa por api.shara.aiginer.com/v1 y por una capa de aislamiento que extrae tu organización y la inyecta como filtro obligatorio antes de tocar la base de datos. Sobre eso:
- JWT firmado con expiración corta y refresh seguro.
- Rate limiting por API key y por IP.
- Logs estructurados sin datos personales en claro.
- Cabeceras estrictas: HSTS, CSP y X-Frame-Options.
3 · Orquestación
Amadeus analiza la petición, decide qué agente la resuelve y delega manteniendo el contexto. Un selector de modo elige el tier de modelo según horario, urgencia y cuota disponible; y un redactor de salida revisa la respuesta antes de devolverla para evitar filtraciones (por ejemplo, el proveedor real detrás de un alias).
4 · Datos y aislamiento multi-tenant
SHARA nunca mezcla datos entre clientes. El aislamiento es de doble capa:
- Aislamiento a nivel de base de datos: cada consulta queda acotada a tu organización; sin ese contexto, no se devuelve ninguna fila.
- Verificación a nivel de aplicación: una segunda capa impone el filtro de organización antes de tocar la base de datos. Es la doble comprobación.
El Plan Local usa exactamente el mismo modelo, pero la base de datos vive en infraestructura del cliente. Lee Plan Local.
Los cuatro tiers de modelo
El cliente nunca elige el modelo: lo decide Amadeus. Trabajas siempre con cuatro alias públicos, y el proveedor real detrás es indiferente para tu día a día (ver Sin lock-in).
| Tier | Para qué | Disponibilidad |
|---|---|---|
| Prelude | Rápido y económico. Tareas simples y modo ahorro nocturno. | Todos los planes |
| Sonata | Equilibrado. Opción por defecto en la mayoría de conversaciones. | Todos los planes |
| Symphony | Top-tier para tareas complejas. Lo usa Amadeus. | Max y superiores |
| Concerto | Motor local desplegable en infraestructura del cliente. | Plan Local |