vocion-core

Vocion (@vocion/core) es un marco abierto para ejecutar el trabajo de agentes de IA en producción en lugar de limitarse al prototipado. El README define al usuario previsto como un ingeniero o líder técnico que traslada un equipo de agentes a producción, y señala explícitamente cuándo el proyecto no es adecuado: un único chatbot, un script puntual o un constructor no-code alojado. Asume que usted utiliza Postgres, mantiene la configuración en git y desea que un humano intervenga en las acciones importantes. El paquete core no se publica en npm; se clona el repositorio y se ejecuta por cuenta propia. Lo que combina la plataforma Vocion se describe como una aplicación Next.js más un esquema de Postgres más un servidor MCP más un ejecutor de flujos de trabajo. Usted crea Sources, Objects, Skills, Playbooks, Workflows, Missions, Automations, Agents y Teams como YAML y markdown en git, los aplica a la base de datos y obtiene un entorno de ejecución tipado con una cola de revisión humana unificada, observabilidad y un ecosistema de plugins. Tres modos de trabajo comparten un mismo entorno de ejecución: - Workflows: pasos deterministas con puertas de aprobación (approve) y consulta (ask). - Missions: responsabilidades permanentes abiertas, donde un equipo de agentes planifica, trabaja y produce artefactos bajo revisión. - Teams: múltiples agentes agrupados bajo un líder con un humano responsable. Otras capacidades declaradas incluyen un paquete de conectores integrado para Google Ads, GA4, HubSpot, Gmail, Slack y Google Drive en un pipeline de ingesta incremental con alcance de cliente; un plano de control multi-tenant con tokens Bearer de inquilino que se resuelven en un principal de permisos; una API de escritura que expone la cola de revisión a través de REST (endpoints de listado de revisiones y decisión); y MCP sobre HTTP como el plano de agentes y herramientas. Los permisos de descubrimiento y mutación están separados, una escalera de autonomía con puertas de aprobación gobierna la ejecución, y el aislamiento entre clientes se aplica a nivel de consulta en lugar de mediante prompts. La ejecución del agente es configurable mediante un único ajuste, harness.runsOn. Las opciones documentadas son ejecutar el bucle del agente dentro del proceso de la aplicación, en el propio contenedor del proyecto en AWS Bedrock AgentCore Runtime, o entregarlo al harness gestionado de AWS, con la documentación explicando qué cuenta de AWS paga los tokens en cada caso. Paquetes en capas y contrato de plugins El repositorio es la capa core de una plataforma más amplia. El paquete SDK define el contrato estable de plugins, incluyendo los tipos Skill y PluginManifest y los tipos de cliente LLM. Los conectores y skills se distribuyen como paquetes npm de plugins independientes, y se describe la planificación de una instalación de inicio bifurcable (forkable starter) en un repositorio separado. Un plugin es un paquete npm que exporta un manifiesto; core carga los manifiestos al arrancar a través del SDK. El README muestra un ejemplo de definición de skill construido con una librería de validación de esquemas, declarando slug, nombre, versión, proveedor, un requisito de aprobación, esquemas de entrada y salida, y una función de ejecución, exportada como un PluginManifest. Un plugin de referencia de transcript-highlights se encuentra en el directorio packages/plugins. Workspace como código Todo el contexto del inquilino reside en un workspace: un directorio rastreado por git de YAML y markdown situado fuera de la descarga del repositorio, normalmente su propio repo, para que el contexto del cliente sea revisable en pull requests y nunca se mezcle con el core. Una variable de entorno apunta la aplicación hacia él; sin ella, no hay workspace configurado. Los tipos de entidades documentados y sus ubicaciones incluyen el manifiesto del workspace, agentes (un archivo YAML más un archivo markdown de system-prompt), equipos, skills, playbooks, misiones, ejecuciones de workflow creadas por la API, workflows, automatizaciones (el único lugar donde residen el tiempo y los eventos), tipos de objetos con pesos de fuente y un prompt de clasificación, fuentes con tipo de conector y cadencia de sincronización, reglas de confianza para qué acciones pueden ejecutarse automáticamente, pasos de aprendizaje como buckets nombrados de reglas acumuladas, datasets de evaluación para casos de prueba por agente y páginas de dashboard definidas por el inquilino. Un paquete base se incluye dentro de core y se sitúa debajo de un workspace: se fija con una directiva extends, se activan agentes con una lista use y se anulan los valores predeterminados con archivos del mismo slug. La aplicación de un workspace a la base de datos registra una fila de auditoría con una versión del workspace, y las llamadas a herramientas estampan un hash del workspace para que los resultados se rastreen hasta los prompts que los produjeron. Configuración y operaciones El inicio rápido se documenta como clonar e instalar, copiar el archivo de ejemplo de entorno y configurar una URL de base de datos, un secreto de autenticación y al menos una clave de proveedor de LLM, iniciar los servicios de soporte con un script dev:up (Postgres, Langfuse, Temporal), ejecutar migraciones, crear el andamiaje de un workspace, apuntar WORKSPACE_PATH hacia él, aplicarlo y luego iniciar el servidor de desarrollo en el puerto 3000 de localhost. Los scripts del proyecto también cubren linting, comprobación de tipos, pruebas, aplicación de workspace y ejecuciones de evaluación. Para clientes MCP como Claude Code, Cursor o Zed, existe un comando stdio local para una instalación de un solo desarrollador, además de un endpoint HTTP remoto donde la organización se deriva de un token Bearer de inquilino y cada llamada a herramienta está limitada a esa organización bajo el mismo modelo de permisos que un humano. Las credenciales se gestionan en ambas direcciones y se administran desde una página del dashboard. Los tokens entrantes son emitidos por Vocion, almacenados solo como un hash SHA-256 y mostrados en texto plano una sola vez. Las claves de proveedores salientes pueden suministrarse por workspace, cifradas en reposo con AES-256-GCM bajo una clave de cifrado de datos por organización, para que se facture la cuenta del proveedor del propio workspace; una clave activa por plataforma por organización. Cada llamada saliente al proveedor resuelve primero la clave almacenada del workspace y luego la variable de entorno del servidor, cubriendo modelos de chat, embeddings en ingesta y consulta, reranking, visión y generación de imágenes, con dos rutas internas que permanecen en la clave del servidor por diseño. La configuración de cifrado ofrece un modo de vault local destinado al desarrollo y un modo KMS recomendado para instalaciones que contienen claves reales de clientes. La recuperación (retrieval) es de primera mano: pgvector con HNSW cosine más búsqueda de texto completo de Postgres, fusionados con reciprocal rank fusion entre ambos brazos, con un rerank de LLM opcional. Los modelos de embedding y rerank son ajustes a nivel de entorno, mientras que la ponderación de recuperación por tipo y por agente se define en el workspace sin cambios de código. Stack e integraciones El stack declarado es Next.js 16 con App Router, React 19 y TypeScript estricto, PostgreSQL 16 con un ORM, Auth.js / NextAuth v5 para tenencia de primera mano con acceso basado en roles a través de la membresía de cuenta y proyecto, OpenAI y Anthropic como proveedores de LLM intercambiables por skill, Langfuse para trazas de LLM y OpenTelemetry para spans y métricas, un ejecutor de pasos de workflow duradero en proceso sobre Postgres, superficies de chat de Slack donde mencionar a un agente produce una respuesta en hilo mientras que la cola de revisión sigue siendo el único lugar donde se aprueba cualquier cosa (detrás de un feature flag), y un plano de control de trabajadores externos para ejecuciones de varias horas con arrendamientos (leases), heartbeats, coste por ejecución y un reaper (también detrás de un feature flag). Licencia El proyecto es de código disponible bajo la Mozilla Public License 2.0, descrita como aprobada por la OSI y con copyleft a nivel de archivo: puede usarlo, auto-alojarlo, inspeccionarlo, modificarlo e integrarlo en un sistema propietario más amplio, y los archivos de Vocion modificados permanecen abiertos bajo la MPL cuando se distribuyen, mientras que el código de la aplicación circundante sigue siendo suyo. El README establece que los datos, el contexto empresarial, las configuraciones de agentes, los flujos de trabajo, el historial de evaluación y los resultados operativos siguen siendo suyos, y que el proyecto es desplegable en su propio entorno. Ciertos usos, como el white-labelling de Vocion, distribuirlo bajo una licencia propietaria, un servicio gestionado soportado por un proveedor, módulos empresariales propietarios o garantías comerciales y niveles de servicio, requieren un acuerdo separado. El nombre y los logotipos son marcas comerciales de Metacto, Inc., y la MPL no otorga derechos de marca. Indicadores de documentación El README enlaza una guía de inicio rápido que va desde un directorio vacío hasta una fuerza laboral de agentes operativa sin código, un archivo escrito para agentes de codificación que trabajan en el repositorio, un índice de documentación legible por máquina, una guía de autoría de workspace, referencias de campos por entidad, una página de modelo de objetos que describe dónde se crea, almacena, ejecuta y muestra cada objeto, una guía de páginas de dashboard y documentación de despliegue que cubre múltiples entornos y un patrón de proyecto padre. La guía de contribución cubre commits convencionales aplicados por herramientas, firma DCO y la ejecución de comprobaciones de tipos, pruebas y lint antes de hacer commit.