Arquitectura

SHARA se organiza en cuatro capas: Cliente, API, Orquestación y Datos. Cada petición las atraviesa todas, con aislamiento entre clientes en doble capa, un orquestador que decide qué especialista y qué modelo resuelven cada tarea, y una capa de gobernanza que mantiene a la persona en el bucle de lo que importa.

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 planifica, delega a los especialistas y un selector elige el tier de modelo.
Datos	Postgres con aislamiento multi-tenant en doble capa.

La idea central es la misma que ilustra el diagrama de la página de inicio: tú hablas en lenguaje natural, Amadeus planifica y reparte el trabajo, los especialistas por departamento lo resuelven usando tus herramientas conectadas, y recibes un resultado consolidado y trazable. Debajo hay ingeniería de aislamiento, gobernanza y modelos, pero de cara a ti todo se reduce a pedir y recibir.

La mejor forma de entender la arquitectura es seguir una petición desde que la escribes hasta que recibes el resultado. Imagina que le dices a Amadeus: «Prepara el cierre de soporte de esta semana y propón un correo de seguimiento a los tres clientes con más incidencias». Esto es lo que ocurre por debajo:

1. Tú escribes en lenguaje natural. Tu mensaje entra por la API detrás de un token firmado. La capa de aislamiento fija tu organización como filtro obligatorio: desde aquí, ningún dato de otro cliente es accesible.
2. Amadeus planifica. Antes de razonar, se inyecta la identidad de tu empresa (tono, valores, reglas). Amadeus analiza la petición, la descompone en tareas y prepara un plan con lo que piensa hacer.
3. Amadeus delega. Reparte cada tarea al especialista adecuado con el contexto justo, sin filtrar datos entre agentes. El resumen de soporte va a Carlzon; el correo comercial se apoya en Carnegie si hay oportunidad de venta.
4. Los especialistas resuelven. Cada agente departamental trabaja su parte con el conocimiento de su área.
5. Usan tus herramientas vía conectores. Los agentes leen de tus integraciones (helpdesk, CRM, correo) con permisos delegados por OAuth. Leer es directo; escribir requiere tu aprobación.
6. Amadeus unifica. Reúne los resultados de los especialistas en una sola respuesta con tu tono, junto con las acciones que esperan tu visto bueno.
7. Recibes un resultado trazable. Toda la cadena queda en el log de auditoría (quién pidió qué, qué agente lo resolvió, qué modelo se usó, antes y después) y el consumo se contabiliza en STU.

Lo que recibes no es solo el texto: es el texto, las acciones propuestas y el rastro de cómo se llegó a él. Esa trazabilidad es lo que convierte una respuesta de IA en algo que puedes auditar, defender ante un cliente y mejorar con el tiempo.

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. Tienes el catálogo en Conectores.

Toda petición pasa por api.sharasaas.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. Doble verificación obligatoria para el CEO y los administradores.
• Rate limiting por API key y por IP.
• Logs estructurados sin datos personales en claro.
• Cabeceras estrictas: HSTS, CSP y X-Frame-Options.

Es el cerebro de SHARA y tiene tres movimientos: planificar, delegar y unificar. Amadeus analiza la petición, decide qué agente o agentes la resuelven y delega manteniendo el contexto, sin filtrar datos entre ellos. Cuando los especialistas terminan, Amadeus reúne sus salidas en una sola respuesta coherente con tu tono.

En paralelo actúan dos piezas clave: 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 que hay detrás de un alias. Los agentes departamentales solo hablan con su área; la coordinación entre departamentos pasa siempre por Amadeus.

SHARA nunca mezcla datos entre clientes. Conviene que sepas exactamente dónde se impone ese aislamiento, porque no todas las plataformas lo cuentan:

• En la aplicación, y es la línea que manda. Cada consulta lleva tu organización como filtro obligatorio, impuesto antes de tocar la base de datos. No es una comprobación de cortesía: es el mecanismo que garantiza el aislamiento en producción hoy.
• En la base de datos, como barrera adicional. Las 118 tablas con datos de cliente tienen activadas políticas de acceso por fila. Protegen frente a un acceso directo a la base de datos, y estamos migrando las consultas de la aplicación para que también pasen por ellas y el aislamiento quede impuesto dos veces de forma independiente.

Concerto Local (999 €/mes) usa exactamente el mismo modelo de arquitectura, pero la base de datos y la inferencia viven en infraestructura del cliente. Puede funcionar 100 % en local; el plan incluye además 60 M STU/mes de cuota en la nube por si en algún momento la quieres usar. Lee Concerto Local.

Sobre las cuatro capas hay una capa transversal que mantiene el control humano y la seguridad del gasto. No es un extra: es parte del producto, y es lo que diferencia a SHARA de un asistente suelto. Se compone de cinco mecanismos.

Cualquier acción con efecto en el mundo (enviar un correo, emitir una factura, modificar un registro) no se ejecuta: se genera como propuesta y aterriza en tu bandeja de aprobaciones. Tú la revisas, la editas si quieres y la apruebas o la rechazas. Una aprobación no la puede resolver un bot: requiere una credencial asociada a una persona. El humano en el bucle es una garantía de diseño, no una opción.

SHARA lleva cortes de gasto automáticos que frenan la actividad si el consumo se dispara, sin penalizar el uso normal:

Corte	Límite	En STU
Por ejecución	5 € en un run	1 M STU
Por hora	50 € en los últimos 60 min	10 M STU
Por día	400 € en las últimas 24 h	80 M STU

Si se alcanza cualquiera de estos umbrales, SHARA se detiene sola y avisa al administrador. Las ventanas son rodantes y los cortes se levantan solos cuando el consumo baja; un administrador puede levantarlos antes. Es la red de seguridad para que nada se descontrole mientras el equipo trabaja en segundo plano.

Antes de devolverte una respuesta, un redactor la revisa para evitar filtraciones: nunca debe escaparse el proveedor real que hay detrás de un alias de modelo, ni datos sensibles fuera de contexto. Trabajas siempre con los alias públicos (ver Sin lock-in); el proveedor real es indiferente para tu día a día y se mantiene confidencial.

Cada acción con efecto queda en un log de auditoría consultable: quién la pidió, qué agente la resolvió, qué modelo se usó, y el antes y el después del cambio. Esa trazabilidad de extremo a extremo es lo que te permite justificar el trabajo ante un cliente o ante una inspección, y también revisar y mejorar cómo trabaja tu equipo.

Cada llamada a un modelo se contabiliza en el momento y se ata a la organización que la originó, de modo que el consumo queda medido acción por acción. Así el coste es previsible y trazable: sabes qué se ha consumido, quién y en qué tarea, todo expresado en la misma unidad, los STU.

Los agentes no parten de cero en cada conversación. Su comportamiento se apoya en dos tipos de memoria complementarios.

La identidad corporativa vive en un fichero IDENTITY.md por agente: tono, valores, reglas y restricciones. Se inyecta al inicio de cada tarea, de modo que todo lo que produce el equipo sale con tu voz y no con una neutra de fábrica. No se reescribe de golpe: evoluciona por parches versionados, y cada parche queda registrado en auditoría, así que puedes afinar el comportamiento con seguridad y revertir si hace falta.

La memoria semántica retiene el conocimiento vivo de tu empresa (cómo se llaman tus productos, quiénes son tus clientes clave, cómo redactas tú) y lo recupera cuando es relevante para la tarea en curso. Es lo que hace que el equipo vaya ajustándose a tu forma de trabajar cuanto más lo usas, siempre dentro de tu organización y sin cruzar datos con otros clientes.

• Identidad: el «cómo debo comportarme» de cada agente. Estable, versionado, editable por ti.
• Memoria semántica: el «qué sé de esta empresa». Crece con el uso y se recupera por relevancia.
• Ambas quedan acotadas a tu organización por el aislamiento multi-tenant: la memoria de un cliente nunca alcanza a otro.

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	Máxima capacidad, para tareas complejas. Lo usa Amadeus.	Max y superiores
Concerto	Motor local desplegable en infraestructura del cliente.	Concerto Local

El selector de modo decide qué tier resuelve cada paso, buscando el equilibrio entre calidad, coste y velocidad. No es una elección fija por conversación: dentro de una misma tarea, unos pasos pueden ir en un tier ágil y otros en uno de máxima capacidad. Pesa varios factores:

• Complejidad de la tarea. Un resumen breve tira de Prelude; un análisis estratégico con matices tira de Symphony.
• Horario laboral. Fuera de tu horario, un modo ahorro baja de tier automáticamente para reducir coste sin afectar a lo que importa.
• Cuota disponible. El selector tiene en cuenta tu bolsa de STU para no dispararla en tareas que no lo requieren.
• Plan contratado. Symphony al máximo está en Max y superiores; Prelude y Sonata, en todos los planes.

El resultado es que pagas capacidad de gama alta solo cuando la tarea la pide, y ligereza cuando basta con ella. Todo esto ocurre de forma transparente: tú describes lo que necesitas y el sistema asigna el motor adecuado a cada paso.

El STU (Shara Token Units) es la unidad única de consumo de la plataforma: 1 STU = 1 token ponderado. En lugar de mezclar tokens de distintos modelos, precios por proveedor y unidades técnicas que cambian, todo el trabajo de los agentes se mide en la misma moneda: los STU. La salida pesa más que la entrada y los modelos más capaces pesan más por token, de modo que el coste es comparable y previsible se use el modelo que se use.

Cada plan incluye una bolsa mensual de STU; si la superas, el excedente se cobra a 5 € por millón de STU, y puedes ampliar la bolsa con un agente adicional (99 €/mes, +15 M STU). El consumo se contabiliza acción por acción y queda reflejado en la auditoría, de modo que en todo momento sabes cuánto has gastado y en qué. Tienes el detalle en STU y cuotas.

¿Quieres seguir? Mira el catálogo de agentes para ver a Amadeus y los 20 especialistas, Seguridad para el aislamiento y las aprobaciones en detalle, o Sin lock-in para entender por qué trabajas con alias de modelo.