vocion-core

Vocion (@vocion/core) é um framework aberto para executar o trabalho de agentes de IA em produção, em vez de apenas prototipá-lo. O README define o usuário pretendido como um engenheiro ou líder técnico que está movendo uma equipe de agentes para produção, e observa explicitamente quando o projeto não é adequado: um único chatbot, um script único ou um construtor no-code hospedado. Assume-se que você execute Postgres, mantenha a configuração no git e deseje um humano no loop em ações importantes. O pacote core não é publicado no npm; você clona o repositório e o executa por conta própria. O que a plataforma combina Vocion é descrito como um app Next.js mais esquema Postgres mais servidor MCP mais executor de workflow. Você autora Sources, Objects, Skills, Playbooks, Workflows, Missions, Automations, Agents e Teams como YAML e markdown no git, aplica-os ao banco de dados e obtém um runtime tipado com uma fila de revisão humana unificada, observabilidade e um ecossistema de plugins. Três modos de trabalho compartilham um único runtime: - Workflows: etapas determinísticas com portões de aprovação (approve) e pergunta (ask). - Missions: responsabilidades permanentes de final aberto, onde uma equipe de agentes planeja, trabalha e produz artefatos sob revisão. - Teams: múltiplos agentes agrupados sob um líder com um humano responsável. Outras capacidades declaradas incluem um pacote de conectores integrado para Google Ads, GA4, HubSpot, Gmail, Slack e Google Drive em um pipeline de ingestão incremental com escopo de cliente; um plano de controle multi-tenant com tokens Bearer de tenant que resolvem para um principal de permissão; uma API de escrita que expõe a fila de revisão via REST (endpoints de listagem de revisão e decisão); e MCP via HTTP como o plano de agentes e ferramentas. As permissões de descoberta e mutação são separadas, uma escada de autonomia com portões de aprovação governa a execução, e o isolamento entre clientes é aplicado no nível da query, e não por meio de prompts. A execução do agente é configurável através de uma única configuração, harness.runsOn. As opções documentadas são executar o loop do agente dentro do processo do app, no próprio container do projeto no AWS Bedrock AgentCore Runtime, ou entregue ao harness gerenciado da AWS, com a documentação explicando qual conta AWS paga pelos tokens em cada caso. Pacotes em camadas e contrato de plugin O repositório é a camada core de uma plataforma maior. O pacote SDK define o contrato de plugin estável, incluindo os tipos Skill e PluginManifest e tipos de cliente LLM. Conectores e skills são enviados como pacotes npm de plugins separados, e uma instalação inicial forkável é descrita como planejada em um repositório separado. Um plugin é um pacote npm que exporta um manifesto; o core carrega os manifestos no boot via SDK. O README mostra um exemplo de definição de skill construído com uma biblioteca de validação de esquema, declarando slug, nome, versão, provedor, um requisito de aprovação, esquemas de entrada e saída, e uma função de execução, exportada como um PluginManifest. Um plugin de referência de destaques de transcrição reside no diretório packages/plugins. Workspace como código Todo o contexto do tenant reside em um workspace: um diretório rastreado pelo git de YAML e markdown situado fora do checkout do repositório, tipicamente seu próprio repo, para que o contexto do cliente seja revisável em pull requests e nunca misturado ao core. Uma variável de ambiente aponta o app para ele; sem ela, nenhum workspace é configurado. Os tipos de entidades documentados e suas localizações incluem o manifesto do workspace, agentes (um arquivo YAML mais um arquivo markdown de system-prompt), equipes, skills, playbooks, missões, execuções de workflow criadas pela API, workflows, automações como o único lugar onde tempo e eventos residem, tipos de objetos com pesos de fonte e um prompt de classificação, fontes com tipo de conector e cadência de sincronização, regras de confiança para quais ações podem ser autoexecutadas, etapas de aprendizado como buckets nomeados de regras acumuladas, datasets de avaliação para casos de teste por agente e páginas de dashboard definidas pelo tenant. Um pacote base é enviado dentro do core e camadas abaixo de um workspace: você o fixa com uma diretiva extends, ativa agentes com uma lista use e substitui padrões com arquivos de mesmo slug. A aplicação de um workspace ao banco de dados registra uma linha de auditoria com uma versão do workspace, e as chamadas de ferramenta carimbam um hash do workspace para que as saídas possam ser rastreadas até os prompts que as produziram. Configuração e operações O início rápido é documentado como clonar e instalar, copiar o arquivo de exemplo de ambiente e definir uma URL de banco de dados, um segredo de autenticação e pelo menos uma chave de provedor LLM, iniciar os serviços de suporte com um script dev:up (Postgres, Langfuse, Temporal), executar migrações, criar o scaffold de um workspace, apontar WORKSPACE_PATH para ele, aplicá-lo e então iniciar o servidor de desenvolvimento na porta 3000 do localhost. Scripts do projeto também cobrem linting, verificação de tipos, testes, aplicação de workspace e execuções de avaliação. Para clientes MCP como Claude Code, Cursor ou Zed, há um comando stdio local para instalação de um único desenvolvedor, além de um endpoint HTTP remoto onde a organização é derivada de um token Bearer de tenant e cada chamada de ferramenta é limitada a essa organização sob o mesmo modelo de permissão de um humano. As credenciais são manipuladas em ambas as direções e gerenciadas a partir de uma página de dashboard. Tokens de entrada são emitidos pelo Vocion, armazenados apenas como um hash SHA-256 e exibidos em texto simples apenas uma vez. Chaves de fornecedores externos podem ser fornecidas por workspace, criptografadas em repouso com AES-256-GCM sob uma chave de criptografia de dados por organização, para que a própria conta do fornecedor do workspace seja faturada; uma chave ativa por plataforma por organização. Cada chamada de fornecedor externo resolve primeiro a chave armazenada do workspace e, em segundo lugar, a variável de ambiente do servidor, cobrindo modelos de chat, embeddings na ingestão e query, reranking, visão e geração de imagens, com dois caminhos internos mantendo-se na chave do servidor por design. A configuração de criptografia oferece um modo de vault local destinado ao desenvolvimento e um modo KMS recomendado para instalações que detêm chaves reais de clientes. A recuperação (retrieval) é nativa: pgvector com HNSW cosine mais busca de texto completo do Postgres, fundidos com reciprocal rank fusion entre os dois braços, com um rerank de LLM opcional. Modelos de embedding e rerank são configurações de nível de ambiente, enquanto a ponderação de recuperação por tipo e por agente é autora no workspace sem alterações de código. Stack e integrações A stack declarada é Next.js 16 com App Router, React 19 e TypeScript estrito, PostgreSQL 16 com um ORM, Auth.js / NextAuth v5 para tenancy de primeira parte com acesso baseado em funções através de associação de conta e projeto, OpenAI e Anthropic como provedores de LLM trocáveis por skill, Langfuse para rastreios de LLM e OpenTelemetry para spans e métricas, um executor de etapas de workflow durável em processo no Postgres, superfícies de chat do Slack onde mencionar um agente produz uma resposta em thread enquanto a fila de revisão permanece o único lugar onde qualquer coisa é aprovada (atrás de uma feature flag), e um plano de controle de worker externo para execuções de várias horas com leases, heartbeats, custo por execução e um reaper (também atrás de uma feature flag). Licença O projeto é source-available sob a Mozilla Public License 2.0, descrita como aprovada pela OSI e copyleft ao nível do arquivo: você pode usar, auto-hospedar, inspecionar, modificar e incorporá-lo em um sistema proprietário maior, e arquivos Vocion modificados permanecem abertos sob a MPL quando distribuídos, enquanto o código do aplicativo circundante permanece seu. O README afirma que dados, contexto de negócios, configurações de agentes, workflows, histórico de avaliação e saídas operacionais permanecem seus, e que o projeto é implantável em seu próprio ambiente. Certos usos, como white-labelling do próprio Vocion, distribuí-lo sob uma licença proprietária, um serviço gerenciado suportado por fornecedor, módulos empresariais proprietários ou garantias comerciais e níveis de serviço, requerem um acordo separado. O nome e os logotipos são marcas registradas da Metacto, Inc., e a MPL não concede direitos de marca registrada. Apontamentos de documentação O README linka um guia de início rápido que vai de um diretório vazio a uma força de trabalho de agentes funcional sem código, um arquivo escrito para agentes de codificação trabalhando no repositório, um índice de documentação legível por máquina, um guia de autoria de workspace, referências de campos por entidade, uma página de modelo de objeto descrevendo onde cada objeto é autorado, armazenado, executado e exibido, um guia de páginas de dashboard e documentação de implantação cobrindo múltiplos ambientes e um padrão de projeto pai. A orientação de contribuição cobre commits convencionais impostos por ferramentas, sign-off DCO e execução de verificações de tipo, testes e lint antes de commitar.