Visão geral da plataforma

Orquesta é uma plataforma colaborativa de orquestração de prompts que transforma prompts em linguagem natural em código de produção. Sua equipe escreve o que quer construir, e os agentes de IA cuidam do código, dos PRs e do deploy.

A plataforma oferece vários caminhos de execução: um agente local conectado via WebSocket com todos os recursos da Claude CLI, VMs na nuvem com execução direta via SSH, o Batuta AI para roteamento autônomo de tarefas e uma API de agentes externos para integração com IAs de terceiros.

Início rápido

Comece a usar em menos de 5 minutos:

npm install -g orquesta-cli orquesta-agent\norquesta-agent --token YOUR_PROJECT_TOKEN

Tour de integração

Novos usuários recebem um tour guiado interativo na primeira visita ao painel. O tour cria um projeto de demonstração com dados de exemplo e percorre 9 áreas principais da plataforma.

Conceitos principais

Agente local

O pacote orquesta-agent conecta sua máquina local ao painel do Orquesta via WebSocket. Ele recebe prompts, os executa usando a Claude CLI e transmite os logs de volta em tempo real.

# Install globally (orquesta-cli gives the `orquesta` command, orquesta-agent the daemon)\nnpm install -g orquesta-cli orquesta-agent\n\n# Or use npx (not recommended for VMs — can timeout)\nnpx orquesta-agent --token YOUR_TOKEN

Conectando a um projeto

Gere um token no painel (Projeto → Agente → Configuração) e depois execute:

orquesta-agent --token oat_abc123...

Vários agentes por projeto

Conecte vários agentes ao mesmo projeto: um no seu notebook de desenvolvimento, outro no staging, outro em produção. Cada agente recebe seu próprio token e roda de forma independente.

# Dev laptop
orquesta-agent --token oat_dev_token --name "Dev Laptop"

# Staging server
orquesta-agent --token oat_staging_token --name "Staging VM"

# Production server
orquesta-agent --token oat_prod_token --name "Prod Server"

Ao enviar um prompt, você pode escolher qual agente o executa no seletor de agentes. Recursos:

• Status online/offline por agente, com indicadores verdes
• Seletor de agentes quando vários estão online
• Execução paralela: cada agente executa prompts de forma independente
• Nomes personalizados de agentes pelo flag --name

O agente irá:

• Validar o token com a API do Orquesta
• Estabelecer uma conexão WebSocket via Supabase Realtime
• Enviar heartbeats a cada 30 segundos
• Escutar comandos EXECUTE no canal do projeto
• Informar ao painel sua versão e capacidades

Fluxo de execução de prompts

Quando um prompt é enviado:

1. O painel transmite um comando EXECUTE pelo canal Realtime
2. O agente o recebe e o coloca na fila (somente execução sequencial)
3. O agente inicia um processo da CLI claude com o prompt
4. A saída é transmitida de volta ao Supabase como entradas de log
5. Ao concluir, o agente informa o status, os commits do git e o uso de tokens

Motor de código: qual CLI executa seus prompts

O agente não contém um modelo. Ele inicia uma CLI de código que já está instalada e autenticada na máquina, de modo que cada prompt roda na sua assinatura. Escolha o motor por projeto em Configurações → Agente, no chip do cabeçalho do projeto ou no assistente de configuração enquanto conecta o agente. O assistente mostra o mesmo seletor e as mesmas marcas, então o motor é escolhido antes do primeiro prompt, e não depois de uma falha.

# Cursor's headless agent — install once on the agent machine
curl https://cursor.com/install -fsS | bash
cursor-agent login

# Windows (PowerShell)
irm 'https://cursor.com/install?win32=true' | iex

# AWS Kiro CLI — macOS / Linux, install once on the agent machine
curl -fsSL https://cli.kiro.dev/install | bash
kiro-cli login          # AWS Builder ID (free) or IAM Identity Center
kiro-cli whoami         # what the agent checks to show the login mark

A escolha chega a um agente em execução no próximo heartbeat, sem reiniciar. O agente informa qual motor está realmente executando; assim, se o que você escolheu não estiver instalado, o painel mostra o substituto em vez de fingir em silêncio. Cada prompt concluído é marcado com seu cli_type e exibe um selo na linha do tempo.

Dois problemas diferentes recebem duas marcas diferentes em Configurações → Agente. ✗ significa que o motor não está instalado: o agente recorre ao próximo que tiver. ! significa que ele está instalado, mas sem login: nada é substituído, porque o binário existe, então os prompts rodam e falham na autenticação do próprio motor até você executar o login dele nessa máquina (cursor-agent login, claude login, kiro-cli login). Cada motor guarda sua própria credencial: o Orquesta nunca a vê e não pode fazer o login por você.

Hooks de IDE — espelhe sessões do Claude Code e do Cursor

O fluxo acima é o dispatch: o Orquesta envia o trabalho para o agente. Os hooks seguem o sentido oposto — você continua trabalhando na sua própria IDE e o Orquesta espelha o que aconteceu. Nada é executado de volta no seu editor, e nenhum daemon precisa estar em execução.

Execute isto uma vez por repositório. Sem --client, ele configura as duas ferramentas:

# Claude Code + Cursor
orquesta-agent init --token oat_abc123...

# Only one of them
orquesta-agent init --token oat_abc123... --client cursor
orquesta-agent init --token oat_abc123... --client claude

Ele grava .orquesta.json (vínculo com o projeto — mantenha-o no gitignore, pois contém o token em texto puro) além de .claude/settings.json e/ou .cursor/hooks.json. Os hooks existentes são preservados; ao executar init novamente, as entradas do Orquesta são atualizadas em vez de duplicadas.

Os prompts espelhados chegam com source: terminal e um selo Local CLI; a coluna cli_type (claude-code ou cursor-cli) define o selo da ferramenta ao lado. Eles são excluídos do dispatch do agente, então uma sessão com hooks nunca é reexecutada.

Solução de problemas

Dashboard

O dashboard é o hub central para gerenciar projetos, enviar prompts, acompanhar a execução e colaborar com a sua equipe.

A Home (/dashboard/home) é uma visão centrada em chat: escolha um projeto no seletor e converse com o agente dele. A barra lateral esquerda lista seu histórico agrupado por dia — chats da Home, sessões de terminal interativas, sessões locais de hooks e prompts avulsos — e uma conta nova cai aqui com um primeiro projeto já pronto e um checklist de configuração em quatro etapas (máquina pronta, escolher seu modelo, primeiro prompt, convidar alguém — GitHub, Supabase e o restante ficam no modo Advanced). Cada projeto tem o seu próprio endereço, /dashboard/home/<projectId>. Ao trocar a partir do Advanced, o projeto em que você estava é mantido. Quando um projeto já tem histórico, as sugestões vêm dele — primeiro as propostas abertas do Auto Agent, depois continuações do trabalho recente. O painel direito pode ser ocultado e traz um painel de Atividade (as ferramentas que o agent está executando, como nas sessões interativas) e um de Artefatos (arquivos alterados e links gerados pela IA). A chave Operator / Advanced da barra lateral alterna entre a Home e o dashboard completo; a Home mostra apenas onde o agente é executado, e reconfigurá-lo é feito no modo Advanced. Cada chat da Home funciona como um chat: no Claude CLI (agente 0.2.267+), cada chat é uma sessão real do Claude, retomada a cada nova mensagem, de modo que o Claude mantém toda a conversa — o que leu, executou e respondeu — e "sim, faça isso" se refere ao que acabou de ser discutido. Em outros CLIs, agentes mais antigos ou uma máquina que nunca viu o chat, a mensagem leva consigo os turnos anteriores do chat (os últimos 8, cortados para caber). Os logs de um agente abrem no próprio lugar, abaixo da resposta, ao vivo enquanto ele trabalha, sem sair do chat. Os mesmos chats estão no Orquesta Terminal: o botão Operator os abre em tela cheia sobre os seus painéis, para que você baixe o Terminal, entre na conta e converse com o agente de qualquer projeto sem abrir o dashboard. A Home está disponível em inglês, espanhol e português. A aba Settings → Integrations de um projeto agrupa tudo ao que ele está conectado — Code (GitHub, com o repositório vinculado e o ciclo de feedback de PRs), Ship (Vercel, Supabase), Work intake (Linear, Slack, Telegram) e Talent (Derplins) — cada um com seu status, aquilo a que está vinculado e um botão de desconectar; skills e configurações personalizadas ficam em Advanced. O antigo assistente de configuração foi aposentado: links com ?setup=true levam a essa aba, ou à visão da VM para hospedagem.

Máquina Orquesta gratuita. Contas que entram com o Google podem obter uma máquina gratuita na nuvem, pela Home ou ao criar um projeto, com o agente e o orquesta-cli pré-instalados e o projeto configurado para rodar na Batuta. Ela hiberna após 48 horas sem prompts e acorda automaticamente quando você envia um; o prompt espera na fila enquanto ela inicia. Máquinas adicionais são pagas, na aba Agent do projeto.

Prompts e execução

A aba Prompts é onde você envia trabalho para o agente de IA. Cada prompt pode incluir:

• Conteúdo — Descrição em linguagem natural do que construir
• Tags — Categorize como bug, feature, refactor, urgent, docs
• Atribuição — Atribua a um membro específico da equipe
• Prioridade — Marque com estrela os prompts importantes
• Specs estruturadas — Use modelos de relatório de bug, especificação de feature ou melhoria com critérios de aceitação

Os prompts podem vir de várias origens:

Gerenciamento

A seção Management inclui:

• Tickets — Acompanhe itens de trabalho da integração com o Linear ou criados manualmente
• Requirements — Defina e acompanhe os requisitos do projeto com análise assistida por IA
• QA — Instruções de garantia de qualidade e acompanhamento de testes
• Planning — Crie planos com itens, marcos e detalhamentos gerados por IA

Sinais sonoros

O dashboard toca breves sinais sintetizados para resultados — uma execução concluída ou com falha, um agente conectando ou caindo e qualquer coisa aguardando a sua resposta. A interface em si é silenciosa: abrir um modal, alternar uma chave ou trocar de aba nunca emite som. Os sinais de agente e de chat só tocam enquanto a aba está em segundo plano.

Desative-os, ajuste o volume ou ouça cada sinal em Profile → Sound. A preferência é armazenada por dispositivo, e todo o conjunto é silenciado automaticamente se o seu sistema pedir movimento reduzido.

Logs e histórico

O streaming de logs em tempo real mostra cada etapa da execução do agente — comandos executados, arquivos modificados, operações do git e mais. Os logs são categorizados por nível (info, warning, error) e tipo (command, output, status, git). A página History mostra uma linha do tempo cronológica de toda a atividade do projeto.

Atividade ao vivo

A aba Activity da barra lateral — o primeiro ícone no painel retrátil ao lado do terminal e da linha do tempo de prompts — mostra o que o agente está fazendo agora em linguagem simples: “Edited public-queries.ts”, “Running the test suite”. A etapa atual fica fixada no topo; abaixo dela está cada etapa até agora com as linhas adicionadas e removidas em cada arquivo, e um resumo de arquivos alteradosno final.

Ela acompanha uma sessão interativa ao vivo a partir do stream da sessão, então funciona com todos os CLIs, inclusive o orquesta-cli, e na aba Prompts acompanha o prompt em execução. É o mesmo stream da aba Logs, lido para quem não quer ler a saída das ferramentas: leituras repetidas de arquivo são agrupadas em uma linha, etapas de bookkeeping ficam ocultas, e uma etapa com falha mostra o erro em vez do payload bruto. Nada novo é registrado para produzi-la.

Cada etapa também traz um chip de área colorido que diz o que ela altera, e não qual arquivo tocou — Database, API, Interface,Dependencies, Deploy / CI, Config, Tests, Docs, ou umDestructive vermelho para exclusões, drops e hard resets. Uma faixa de resumo no topo do painel soma tudo isso, de modo que “esta execução tocou o banco de dados três vezes” fica legível sem abrir um único arquivo. Etapas que apenas leem algo não têm chip, porque ler não altera nada.

Artifacts — arquivos que o agente criou

Quando uma execução produz algo que vale abrir — um relatório HTML, um gráfico, um PDF, um CSV, um site compilado — o agente pode publicá-lo: o orquesta-cli tem a ferramenta publish_artifact, e qualquer CLI pode simplesmente gravar o arquivo em .orquesta/artifacts/. Quando o prompt termina, o agente (≥ 0.2.273) envia esses arquivos e eles aparecem primeiro no cartão Artifacts do Operator com um link de download, mantidos por 30 dias (máx. 25 MB por arquivo, 50 arquivos / 100 MB por prompt; .enve arquivos com cara de chave nunca são enviados). Na microVM sob demanda isso está sempre ligado, porque o disco morre com a sessão. Nas suas próprias máquinas é opcional: Configurações → Agente → Artifacts.

Cada artefato, e cada arquivo do painel Context files de uma sessão interativa, tem dois botões: Abrir mostra em uma nova aba (HTML, imagens, PDF e texto aparecem em vez de baixar; o resto é baixado) e Compartilhar copia um link público getorquesta.com/share/… que qualquer pessoa abre sem conta. A renderização acontece em uma origem de armazenamento separada, nunca em getorquesta.com, então uma página feita por IA não acessa sua sessão. O link pode ser revogado na mesma linha, e o de um artefato para de funcionar quando o artefato expira.

O Claude Code não tem ferramenta de publicação, então quando ele responde com um bloco <antArtifact> (uma página HTML, um SVG, um documento Markdown) o bloco é salvo como artefato desse prompt alguns segundos após terminar — sem configuração. Projetos novos começam com uma etapa Uso no cartão de configuração (chat, sessão interativa, prompts avulsos, embed ou hook) que decide onde o projeto abre; a etapa de hospedagem inclui a microVM da Orquesta, com as 10 primeiras execuções por organização grátis (depois $0.25/h).

Tarefas na barra lateral

A aba Tasks da barra é um único feed de tudo o que aguarda trabalho neste projeto — tickets locais, itens de plano, issues do Linear, prompts agendados e prompts atribuídos a você — cada um marcado com a sua origem, filtrável por fonte.

Run faz o que a tela em que você está entende por executar. Em uma sessão interativa, envia a tarefa ao terminal ao vivo imediatamente. Na aba Prompts, ele despacha para o agente: uma tarefa que já é uma linha de prompt — um ticket local, um prompt atribuído a você — é executada no próprio lugar, de modo que a execução permanece ligada a ela e o ticket se fecha sozinho ao terminar; qualquer outra coisa vira um novo prompt. Ao lado, Start carrega a tarefa na caixa de prompt para revisão em vez de enviá-la, e Prompt primeiro transforma a história em um prompt de implementação concreto.

Memória e contexto

O painel Memory armazena o contexto persistente do projeto, que é incluído em toda execução de prompt. Isso inclui decisões de arquitetura, convenções de código, problemas conhecidos e conhecimento específico do projeto. A memória é resumida automaticamente e injetada no contexto do Claude CLI.

Auto Context

Prompts curtos como "sim", "deploy" ou "faça isso" recebem automaticamente o contexto das últimas tarefas concluídas. Não é preciso ativar Include Context — o agente sempre sabe o que veio antes. Para prompts mais longos, use a chave Include Context para ter controle explícito.

O agente também pode buscar contexto detalhado durante a execução, se precisar de mais informações:

# Agent can call this during execution
curl -s https://getorquesta.com/api/agent/recent-context \
  -H "Authorization: Bearer $ORQUESTA_TOKEN" | jq .

Auto Agent

O Auto Agent analisa o seu projeto — planos, trabalho recente, memória, tickets abertos — e decide o que construir em seguida. Ele funciona em dois modos, ambos na aba Auto Agent do projeto.

Modo em segundo plano (propor e aprovar). Ative a chave e escolha uma frequência. A cada ciclo, o agente escreve propostas — título, por que importa, o prompt exato a executar e uma classificação de risco — em uma caixa de entrada. Ele não escreve código e não executa nada. Você confere a caixa de entrada uma vez por dia, edita algum prompt se quiser e aprova os que valem a pena; só então o agente trabalha. As propostas rejeitadas são lembradas, então ele deixa de sugerir a mesma coisa.

Os ciclos saem baratos porque a maioria deles nem chega a acontecer: um ciclo é ignorado quando o seu agente local está offline, quando a caixa de entrada já tem propostas aguardando (esvaziá-la é tarefa sua — empilhar mais é só ruído) e quando nada mudou desde o último ciclo (mesmo commit, nenhum prompt novo). As três condições são decididas por leituras no banco de dados, então um "a cada 6 horas" nominal em um projeto parado não gasta nenhum token.

Executar agora (primeiro plano). O ciclo original, em "Run now": o agente escolhe tarefas e as executa imediatamente enquanto você acompanha, até o limite de iterações que você definir. O ciclo roda no servidor, então sobrevive a trocas de aba, travamentos do navegador e deploys.

Autonomia (executar sem o clique). Em Settings, "Run approved work automatically" permite que propostas dentro dos limites que você definir sejam executadas sem ninguém clicar em Approve. Vem desativada por padrão e não será ativada sem um comando de verificação — o comando que prova que o seu projeto continua funcionando (npm test, pytest -q, make check). Trabalho que ninguém revisa e que nada verifica não é automação, então o Orquesta se recusa a fazê-lo.

Cada execução autônoma trabalha na sua própria branch auto/… a partir do seu commit atual, faz a tarefa e então executa o seu comando de verificação. Com saída 0, ela conclui conforme o fluxo de git do seu projeto — fast-forward e push, ou abre um pull request e deixa a branch base intacta. Com qualquer outro código de saída, ela reverte a branch, devolve o repositório ao commit do qual partiu e devolve a proposta à caixa de entrada com as últimas 100 linhas da falha anexadas. Ela nunca tenta de novo: uma tentativa de máquina por proposta, e depois uma pessoa decide.

Quatro limites a controlam. Um teto de risco e um teto de tamanho — qualquer coisa acima deles ainda espera por você, e uma proposta que não declarou o seu risco é tratada como média, portanto fica bloqueada no padrão. Dois orçamentos móveis de 24 horas, uma contagem de tarefas e um valor em dólares, o que acabar primeiro (planos de modelo com tarifa fixa realmente não custam nada por execução e reportam US$ 0, então neles quem limita é a contagem de tarefas). E um circuit breaker que pausa o projeto após N falhas consecutivas e não manda a ninguém um e-mail surpresa — a aba diz o motivo, e você retoma por lá.

Toda execução sem supervisão é listada em "Autonomous runs" com a sua branch, o commit do qual partiu, o código de saída da verificação, se a árvore foi restaurada e a saída da falha. Uma execução que falhou e não pôde ser revertida aparece destacada em vermelho — é o único caso em que vale olhar a máquina.

Workstreams (várias perguntas permanentes, um projeto). Um projeto raramente tem um único propósito. "Triar os bugs", "ler o feedback dos clientes e decidir o que construir" e "olhar o marketing e a ação comercial" são três perguntas diferentes, e fazê-las como uma só se resume a qualquer uma que o modelo achar mais legível. Crie workstreams no painel Workstreams do projeto e a aba Auto Agent ganha um seletor: cada stream tem a sua própria frequência, a sua própria caixa de entrada, os seus próprios limites e o seu próprio orçamento de 24 horas, e cada cérebro é informado para que serve o seu stream e instruído a não propor nada em vez de invadir outro.

Um workstream pode apontar para um diretório, mas não é obrigatório. O stream é o que define o trabalho; o diretório decide apenas se dois streams podem rodar ao mesmo tempo. Streams em diretórios diferentes rodam em paralelo. Streams que compartilham um diretório — e qualquer stream em um projeto que seja uma única pasta — se revezam, porque duas branches autônomas na mesma árvore de trabalho é uma corrida que ninguém vence. Um stream apontado para a raiz do projeto é exclusivo em relação a todos os outros, já que os contém.

Esse diretório pode ficar abaixo da raiz do repositório — um stream que é dono de repo/server ainda pode criar branches, fazer commits e reverter. Sob isolamento de sistema de arquivos, o sandbox torna gravável apenas o diretório de trabalho, então o agente também abre o diretório git do repositório que o contém (e, no caso de um worktree, o repositório principal no qual ele grava objetos). Sem isso, tal stream poderia editar código e nunca criar uma branch, e o erro pareceria um disco falhando em vez de uma configuração.

Cada stream tem um tipo, porque nem toda pergunta termina em um commit. Um stream Code altera o repositório: trabalha na sua própria branch, precisa passar por um comando de verificação e é revertido se não passar. Um stream Analysis lê e reporta — feedback de clientes, logs de erro, o estado do mercado — e não precisa de comando de verificação, porque não há nada a desfazer. Um stream Action faz algo fora do repositório, como enviar um e-mail ou abrir um ticket, e nunca roda sem supervisão: sempre espera por uma pessoa, independentemente da configuração de autonomia. Mudar um stream para Action desativa a autonomia dele.

A visão do swarm. Quando um projeto tem dois ou mais workstreams, a aba Auto Agent os desenha como um grafo: o agente raiz no topo, um nó por stream abaixo dele, com o tipo, o diretório, a caixa de entrada e a contagem de 24 horas em cada um. Uma aresta verde significa que aquele stream está em execução agora; uma âmbar significa que ele está armado e parado porque outra execução está segurando o seu diretório — a regra de fila acima, mostrada em vez de descrita. Você pode fixar a visão em qualquer um dos modos nas configurações do projeto ou ao criá-lo, para um projeto que será um swarm antes de existir o seu primeiro stream.

Clique em um nó e um painel à direita mostra o que é aquele stream, o que ele fez por último e as suas execuções recentes; renomeie-o por ali clicando no nome. Arraste os cartões para organizar o grafo como o projeto realmente se parece na sua cabeça — a organização fica lembrada no seu navegador, por projeto, e é só sua: mover um cartão não o move para mais ninguém. O controle de reset recoloca tudo no lugar.

O seu padrão de terminal. O mesmo painel tem Use as my terminal default: as sessões interativas naquele projeto passam a abrir naquele workstream já selecionado (também configurável com a estrela ao lado de Run in no terminal). É uma preferência sua, guardada no seu navegador, e não algo que o restante da equipe herda. O cabeçalho do terminal sempre indica o workstream em que você está (recarregar a página o mantém), e uma sessão iniciada em um workstream abre com a descrição desse workstream carregada como missão, para que o agente comece por ela em vez de perguntar o que fazer (agente 0.2.265 ou posterior).

Entrar em uma sessão em andamento preserva o passado dela. Quando você entra em uma sessão que já está ativa, ou recarrega a página enquanto uma está em execução, a conversa até aqui é carregada no scrollback do terminal (e no painel History) antes de a tela ao vivo ser desenhada, de modo que rolar para cima mostra os turnos anteriores e não apenas a última tela. Somente sessões do Claude, agente 0.2.266 ou posterior.

Abaixo do grafo, O que o swarm fez reúne todos os streams em uma única cronologia dos últimos quatorze dias — propostas e execuções intercaladas, porque uma proposta e a execução que veio dela são uma só história — com os totais da janela: execuções, verificadas, revertidas e reversão com falha contadas à parte das demais, pois esta última significa que uma branch foi deixada para trás na máquina. Clique em qualquer linha para ir ao stream de onde ela veio.

Um e-mail de resumo diário lista o que está aguardando revisão e só é enviado quando algo novo chegou — uma proposta ignorada nunca vira um incômodo diário.

Meet — uma videochamada com o agente

O Meet, no menu Agent do projeto, é uma videochamada com o seu agente em um clique. Pressione "Start meet": o dashboard abre uma chamada em meet.apuchat.com dentro da própria página e envia o agente para entrar nela. Fale em voz alta — sua fala é transcrita no seu navegador e chega ao agente como texto; as respostas dele são faladas de volta e também aparecem na transcrição ao lado da chamada, para que nada do que foi dito se perca quando a chamada terminar.

Cada projeto tem a sua própria sala de meet persistente, separada do chat da equipe e dos canais de coordenação, de modo que o agente só é acordado para uma chamada que você iniciou. "Invite" mostra um link protegido e uma senha para trazer mais alguém; "Open in a new tab" executa a mesma chamada fora do dashboard se o seu navegador bloquear o microfone em uma página incorporada. O agente precisa estar online para responder.

Meets anteriores. Todo meet realizado a partir do dashboard é gravado como texto — quem disse o quê, e quando — e listado abaixo do cartão "Start meet" com data, duração e número de linhas; abra um para ler a transcrição completa. A gravação é apenas a transcrição (nenhum áudio ou vídeo é armazenado) e é escrita pela aba do dashboard que está na chamada, portanto um meet em que se entrou apenas por uma aba comum do navegador não é guardado.

No celular. O Meet também está no app do Orquesta: abra um projeto, toque em "Meet with the agent" e a chamada funciona dentro do app da mesma forma, com a transcrição ao vivo e os seus meets anteriores. Se o agente executa o dispatch mas não permanece na sala, a tela da chamada diz "agent didn't join" em vez de esperar em silêncio — alguns projetos recusam uma chamada pelas próprias regras, e isso é mostrado com transparência.

Como o agente responde. Cada coisa que você diz é respondida por um modelo rápido do lado do Orquesta, que lê o que o Orquesta já sabe sobre o projeto — suas notas, prompts recentes e seus resultados — de modo que as perguntas são respondidas em um ou dois segundos sem tocar na sua máquina. Quando você pede trabalho de verdade (olhar o código, executar os testes, verificar um log, alterar algo), ele diz "one moment" e entrega um prompt normal ao agente do projeto; enquanto isso é executado, você ouve uma breve atualização a cada meio minuto, e o resultado é lido em voz alta quando chega. O agente permanece na chamada enquanto você fala ou enquanto há trabalho em andamento, e sai após cerca de três minutos de silêncio (30 minutos no máximo). Falar de novo o traz de volta.

Hey Orquesta — voz com as mãos livres para todos os seus projetos

O Hey Orquesta (na barra lateral) é um companheiro de voz que fica acima de todos os projetos aos quais você tem acesso — para quando você está caminhando ou dirigindo e não pode ler uma tela. Ative o modo mãos livres, e ele escuta, responde em voz alta e escuta de novo.

• "How is ehive-dev doing?" — lido do Orquesta: se o agente está online, o que está em execução e as últimas linhas de log, e o que terminou recentemente. Nenhum agente é acordado para isso.
• "Tell the ehive-dev agent to run the tests" — vira um prompt normal naquele projeto, atribuído a você, e o agente é acordado na hora. Requer permissão para executar prompts no projeto.
• "Email me when ehive-dev finishes" — o Orquesta envia um e-mail quando o trabalho em andamento (ou a tarefa que você acabou de pedir) é concluído ou falha, com um breve resumo do resultado.

O reconhecimento de fala e a voz rodam no seu navegador (Chrome, Edge ou Safari). Os projetos são identificados pelo nome, então um nome parecido o bastante funciona; se dois projetos coincidirem, ele pergunta qual. O mesmo endpoint, POST /api/companion/turn, aceita uma sessão do dashboard ou um token de CLI oclt_, que é o que o app móvel usa.

O Hey Orquesta está incluído nos planos Pro e Max — você o recebe quando qualquer organização da qual você faz parte estiver em um deles. Em outros planos, a tela mostra um cartão de upgrade e o endpoint responde 402.

As respostas são faladas com a voz Grok (com a voz do navegador como alternativa) e escolhem o idioma pela chave ES/EN na tela. Toda conversa é guardada: o botão de histórico lista as anteriores e, dentro de uma delas, mostra o que cada agente fez com o trabalho que você entregou (status ao vivo e resultado). Quando você pergunta como esse trabalho foi, o companheiro lê o resultado atual em vez de adivinhar. O orb no cabeçalho da página o abre de qualquer lugar. No modo mãos livres, o microfone permanece aberto enquanto ele fala, então você pode interromper com um novo pedido a qualquer momento; enquanto ele pensa, diz um breve "one moment" em vez de ficar em silêncio.

Colaboração em equipe

O Orquesta oferece quatro papéis com permissões granulares:

Chat do projeto

Cada projeto tem um chat em tempo real integrado, baseado no Supabase Realtime. Os recursos incluem conversas em threads, anexos de arquivos, confirmações de leitura e indicadores de digitação. O chat é ideal para discutir prompts, revisar resultados e coordenar o trabalho.

Pergunte ao agente do projeto. Digite @agent no chat de um projeto e ele responde com base no histórico do próprio projeto — o que rodou por último, como foi, o que ainda está em aberto. Ele apenas informa; nunca executa nada e só conhece o projeto em que está. O handle é por projeto — dê um nome a ele em Settings → Agent → Chat Handle (por exemplo @elclaudio) — e ele responde dentro da thread em que você perguntou. As respostas vêm do servidor, então funcionam mesmo quando a máquina do agente está offline.

Transforme uma mensagem em tarefa. Passe o mouse sobre qualquer mensagem do chat e clique no ícone de tarefa para abri-la como um item do plano — título e descrição vêm preenchidos a partir da mensagem, e você escolhe o plano e o responsável. A tarefa mantém um selo From chat para que você saiba o que surgiu na conversa.

Inicie uma reunião. O botão Meet no cabeçalho do chat abre a sala de vídeo do projeto e publica um cartão Join na conversa, para que qualquer pessoa que esteja lendo possa entrar com um clique. Vídeo e áudio vão de navegador para navegador — a sala só transporta a sinalização, e nada do que é dito nela é gravado. Cada pessoa recebe seu próprio link ao clicar em Join, e é por isso que o cartão é um botão e não uma URL para colar.

Agentes que consultam agentes

O agente de um projeto pode perguntar ao de outro. Dentro de uma organização, um agente lista seus pares com GET /api/agent/directory e envia uma solicitação com POST /api/agent/requests: uma consulta (pergunta, roda somente leitura do outro lado e é aprovada automaticamente) ou um encargo (ordem de trabalho, aguarda aprovação humana na aba Callable do projeto). A solicitação é um prompt comum no projeto de destino; ao terminar, a resposta volta ao projeto que perguntou como um prompt de acompanhamento, ou ele consulta GET /api/agent/requests/{id}, que também entrega links de download dos arquivos produzidos (até 256 MB cada). Cadeias limitadas a dois saltos, ciclos recusados e limite diário por projeto. Só aparecem e podem se perguntar os projetos com coordenação habilitada (settings.coordination.enabled); uma solicitação aceita timeout_min opcional (padrão 30 para consulta, 240 para encargo, máximo 720), após o qual é cancelada, e o token de um agente pode ficar preso a IPs de origem.

Handles permanentes e DMs ao dono. Cada agente de projeto pode ter um handle permanente @<projeto>-agent que não expira, com o dono na lista de permitidos. Um agente bloqueado numa decisão escreve a uma pessoa permitida com POST /api/agent/dm; a resposta, por até 24 horas, vira um prompt que mostra ao agente a própria pergunta e a tarefa que a originou.

Identidade do agente

Settings → Agent Identity é o único lugar que responde a “quem é este agente e como falo com ele”. Cada endereço em que o agente responde costumava ficar em uma tela diferente — o handle do chat em Settings, o @handle do Apuchat em Coordination, o email no painel Inbox — e por isso ninguém conseguia ver a identidade completa de uma só vez. Esta aba reúne tudo. A identidade é por projeto, e a aba é apenas para owners e admins.

Dê ao agente o próprio email. Por padrão, o email de um agente é uma caixa de entrada descartável do apumail, o que serve para passar um endereço a um agente externo em uma única troca, mas não serve para nada que você queira continuar recebendo — o apumail a libera após 24h de inatividade. Defina um endereço aqui (qualquer caixa de correio atendida pelo apumail, mais o token da sua caixa de entrada) e ele passa a ser o email do agente; a caixa descartável continua onde está e deixa de ser a resposta. O token é verificado no apumail antes de ser salvo, armazenado criptografado e nunca mais exibido — um token que é apenas salvo falha mais tarde como uma caixa de correio que parece vazia em vez de quebrada.

O endereço configurado é o que o produto usa. Depois que um email de identidade é definido, o painel Inbox em uma sessão interativa lê essa caixa de correio em vez da descartável e retira seus próprios botões Replace/Release: eles gerariam um endereço em que o agente não responde. A remoção da caixa de correio de identidade é feita aqui, onde ela foi definida.

Um callsign do Apuchat, não dois. O @handle para o qual as pessoas ligam agora é também o callsign que o agente apresenta ao entrar em canais de coordenação e chamadas de vídeo, então quem ligou para @your-agent encontra @your-agentna sala, e não um nome gerado por máquina. Se o handle parar de funcionar, o agente recorre a um callsign descartável e continua entrando, e você repara o handle publicado nesta aba: Renew o reativa no mesmo lugar, e somente um handle que o Apuchat realmente descartou é substituído — a aba informa isso explicitamente quando o endereço muda, porque quem tem o antigo precisa ser avisado.

O cartão Callable & DM handle é o mesmo cartão em todo lugar em que aparece. Ele tem uma entrada própria no menu Agent da barra do projeto, que é para onde ir quando o objetivo é gerenciar quem pode ligar, e não ler um canal; ele ainda aparece em Coordination, onde sempre esteve; é uma seção de Settings → Agents, ao lado da máquina que ele aciona; e está incorporado à linha do Apuchat em Agent Identity, para que quem veio perguntar como falar com o agente não seja enviado a outra aba para agir sobre a resposta. Um único componente montado quatro vezes, nunca quatro cópias, para que não se desencontrem. Um handle gratuito expira após 24h e é renovado a partir de qualquer um deles. Se você prefere que ele nunca expire, compre um em apuchat.com/account (5 USDC) e anexe-o aqui com a chave de identidade dele: a chave é verificada no Apuchat antes de ser salva, então uma colagem errada falha na hora, em vez de aparecer como um handle que silenciosamente nunca toca. Um handle anexado recebe push como um gratuito: o Orquesta registra um webhook nele com a própria chave de identidade, então uma ligação chega ao agente em cerca de um segundo. Girar a chave em apuchat.com desativa esse webhook; o cron de poll então atende o handle até que você anexe a nova chave.

Uma mensagem para o handle é um prompt, e a resposta volta como uma resposta. O handle nasceu como uma campainha: interpretava um convite de chamada e levava o agente a uma chamada de vídeo, e uma mensagem simples que não fosse um convite era lida, considerada sem interesse e descartada — inclusive o cursor, então depois ela ficava invisível. Visto de fora, isso é indistinguível de um agente que ignora você. Agora, qualquer coisa escrita para @your-agent passa pelo mesmo filtro de chamadores de uma ligação, vira um prompt na sua própria máquina com os escopos do chamador anexados, e a resposta é enviada de volta ao remetente como mensagem de chat. A seção Messagesdo cartão é a conversa: threads por chamador, as respostas do agente marcadas como dele, uma caixa para responder manualmente como o handle, e as mensagens que foram recusadas exibidas no próprio lugar com o mesmo allow to talk de um clique — uma recusa que você consegue ver vale mais do que um silêncio que você não consegue. As respostas têm limite de tamanho e as longas apontam para o dashboard; um chamador pode ter no máximo três mensagens em processamento ao mesmo tempo, para que um handle sem supervisão não possa enfileirar trabalho ilimitado na máquina de alguém. Duas regras de unicidade no banco de dados fazem o resto: um registro por mensagem recebida, para que o webhook e o poll por minuto não ajam os dois sobre ela, e uma resposta por prompt, para que o hook de conclusão e o cron de reserva não respondam os dois.

Quem pode ligar. O handle é público, e uma ligação executa um prompt na sua própria máquina — então a assinatura que o Apuchat envia prova que a mensagem foi entregue, nunca quem ligou. Por isso, um novo handle é criado como restrito: é uma lista de permitidos, e você indica os @handles de chamadores que passam e marca, por chamador, o que cada um pode pedir — talk, read code, run commands, deploy / spend. Um terceiro pode ter permissão para conversar sem ter permissão para executar nada, e nada dito durante a chamada amplia essa lista. Para alguém cujo handle você não pode saber de antemão, gere um passcode compartilhado — nós o geramos, você nunca o escolhe, e ele é exibido uma vez na geração porque guardamos apenas uma cópia criptografada. A pessoa escreve passcode: the-code na mensagem da ligação e recebe os escopos que você deu ao passcode.

Open to anyone é a outra configuração, e é deliberada: ao escolhê-la, aparece um aviso e todo desconhecido fica limitado à menor concessão que existe, talk apenas, sem como ampliá-la. Uma concessão ampla dada a “qualquer um” é exatamente o que essa configuração não pode significar, então os seletores de escopo ficam bloqueados e não apenas com um valor padrão. Handles que existiam antes das permissões de chamadores contam como abertos, e o mesmo limite agora vale para eles. Toda ligação é registrada de qualquer forma, então um chamador recusado aparece com um atalho allow to talk em vez de sumir em um log do servidor.

O @mention do chat e a lista de canais continuam somente leitura aqui e apontam para a tela que é dona deles — um segundo controle para o mesmo campo é um segundo controle que pode discordar do primeiro.

Comentários em prompts

Todo prompt tem uma thread de comentários para a discussão de code review. Você pode mencionar membros da equipe com @mentions, dar feedback sobre o código gerado por IA e discutir mudanças antes do merge.

Planejamento e specs

O sistema de Planning permite criar planos estruturados com itens que podem ser convertidos em prompts ou tickets. A IA pode gerar detalhamentos de plano a partir de descrições de alto nível. As Specs estruturadas (relatos de bug, solicitações de funcionalidade, melhorias) incluem critérios de aceitação que orientam a IA durante a execução.

Executando um item. Clique em ▶ em qualquer item do plano para enviá-lo ao agente como um prompt. O item então mostra o status ao vivo desse prompt e leva direto a ele, de modo que um plano acompanha a própria execução em vez de apenas descrevê-la. Um item que já está em execução não pode ser despachado duas vezes; quando o prompt termina, ▶ o executa de novo — útil quando uma execução falhou.

Visualização em quadro. Tanto Planning quanto Tickets têm um alternador lista/quadro no cabeçalho. Os planos são organizados em quadro pelo status do item; os Tickets, pelos estados reais do workflow do Linear da sua equipe — as colunas são as que sua equipe configurou, na ordem e nas cores do próprio Linear. Arrastar um ticket entre colunas grava o estado de volta no Linear, e o cartão volta ao lugar se o Linear rejeitar a mudança. O quadro sempre mostra todos os tickets, então as abas de status ficam de lado enquanto ele está aberto.

Editando um ticket local. Tickets criados no Orquesta podem ser editados, atribuídos e arquivados depois — o caso para o qual isso serve é uma passada de QA que registra um ticket e descobre no meio da sessão que o título estava errado, o tipo estava errado ou que ele precisa de mais detalhes. ✎ abre o título, o tipo e o corpo em markdown do ticket, que é exatamente o que o agente recebe quando você o executa. Assigno entrega a qualquer membro do projeto. Archive o tira da lista de tickets e da timeline sem apagar nada — seus logs, comentários e custo permanecem intactos, e Archived no cabeçalho traz os tickets arquivados de volta à vista para restaurá-los. Um ticket que o agente está executando no momento só pode ser reatribuído; editar e arquivar esperam a execução terminar.

Tickets locais, com ou sem Linear. Um projeto conectado também registra tickets locais — o widget de feedback os grava ali — então o cabeçalho de Tickets traz um alternador Linear / Local. As duas listas são mantidas separadas de propósito: somente issues do Linear podem ser arrastadas entre os estados do workflow da sua equipe, e uma lista combinada ofereceria ações que funcionam em metade das linhas.

Quadro local, sprints e milestones. Os tickets locais têm seu próprio quadro — Backlog, To Do, In Progress, In Review, Done — e ele não precisa do Linear. Um cartão carrega dois estados separados: a execução (draft → pending → running → done) e a coluna para a qual alguém o arrastou. Um cartão que ninguém tocou pega sua coluna da execução, então um ticket que termina no agente vai para Done sozinho; depois que você o arrasta, a sua coluna prevalece e a próxima execução não o puxa de volta. Agrupe tickets em um sprint ou em um milestone (a mesma coisa — um sprint é simplesmente um com datas) e o chip acima da lista mostra concluídos/total e os dias restantes, em vermelho quando a data final já passou e ainda há trabalho em aberto.

Executando tickets. Marque as caixas de um a dez tickets locais e a barra oferece duas formas de executá-los. Um único ticket é executado como ele mesmo — o próprio corpo é o prompt, e a execução, seus logs e seu resultado permanecem anexados a esse ticket, o que permite que o ticket se feche sozinho quando a execução termina. Run together compõe um único prompt — primeiro a lista numerada, para que o agente possa planejar o conjunto todo, depois o corpo de cada ticket sob o próprio título — despacha-o para o agente e move esses cartões para In Progress. Send to session monta o mesmo prompt, mas o entrega ao terminal interativo, onde ele espera em um banner para você revisar antes de qualquer envio. Nenhuma das duas executa um ticket que já está em execução.

Detalhe do ticket. Clicar no título de um ticket local — na lista ou no quadro — o abre. A coluna da esquerda é o ticket como o agente o vê: o corpo em markdown, o resultado ou erro da execução e a thread de comentários. A coluna da direita é tudo sobre ele que não é o texto: status, responsável e sprint são editáveis no próprio lugar, e abaixo deles ficam quem o criou e quando, quando foi tocado pela última vez, suas tags e de onde veio. Quando o ticket já foi executado, o bloco da execução informa o engine e o modelo, o branch e o commit em que ele pousou e quanto custou. Run, Send to session, Edit e Archive ficam no rodapé, então o painel basta por si só — você não precisa voltar à lista para agir sobre o ticket.

Um ticket se fecha sozinho. Quando uma execução chega a running, o ticket vai para In Progress, e quando ela termina vai para Done — inclusive a partir de In Review, já que uma execução concluída é avanço. O que ele nunca fará é desfazer uma decisão humana: um cartão já em Done ou Canceled nunca é reaberto, um cartão estacionado em In Review não é puxado de volta enquanto roda, e uma execução com falha não grava nada, de modo que uma nova tentativa começa de onde você deixou.

Datas do sprint. Um sprint novo começa hoje e termina uma semana depois, com presets de 1w / 2w / 1m e uma contagem de dias ao lado, então o caso comum é um clique. A data final não pode ser anterior à inicial — Create fica desabilitado enquanto o intervalo estiver invertido, em vez de salvar um sprint que já terminou.

Assisted Mode — o QA envia um documento, você revisa um diff

O Assisted Mode é para o momento em que um colega de QA termina uma passada e tem uma página de achados. Cole o documento inteiro em Assisted na página do projeto. O Orquesta o lê como um único documento — os achados são desduplicados e ordenados entre si, não tratados um prompt por vez — e classifica cada achado em um de quatro veredictos.

A linha que ele traça é defeito óbvio vs. decisão de produto, nunca dificuldade. "O botão Salvar não faz nada" contradiz o próprio rótulo, então é executado sem supervisão mesmo que a correção seja difícil. "Devemos enviar um email ao cliente quando uma execução terminar" é um comportamento novo que ninguém aprovou, então espera por um humano — mesmo sendo trivial de construir.

Executar primeiro, revisar depois. Esta é a diferença em relação à avaliação automática, que bloqueia um prompt antes de ele rodar. Aqui o revisor abre um diff que já existe: arquivos reais, contagens de linhas reais, um commit real. Aprovar uma intenção e aprovar uma mudança não são a mesma revisão, e só uma delas pode ser feita direito.

Uma execução, um branch, um PR. Todos os itens de uma execução compartilham um branch assisted/YYYYMMDD-xxxxxxxx e são executados estritamente um por vez. O auto-deploy é recusado para a execução inteira, no lado do servidor — um branch assistido nunca chega à produção por conta própria, independentemente das configurações de deploy do projeto.

O gate de diff. Todo diff que o agente produz é inspecionado antes de o próximo item começar. Migrations, arquivos com formato de credencial, exclusões, uma mudança grande demais ou uma correção declarada que não mudou nada interrompem a execução — o item N+1 nunca é empilhado sobre um diff que ninguém leu. Mudanças em dependências, CI, auth e binários são sinalizadas para o revisor sem parar a fila. Cada sinalização é exibida no cartão com o motivo que a acionou.

Quem faz o quê. Qualquer membro do projeto pode iniciar uma execução — o QA tem autoridade de disparo, e esse é o ponto. A revisão é separada: pertence aos owners e admins do projeto, além de qualquer pessoa marcada como Assisted reviewer em Team → member permissions. Os revisores recebem uma notificação por execução e são os únicos que podem aprovar, rejeitar ou enfileirar um achado escalado. A procedência é registrada a partir da sessão, não do corpo da requisição.

“Eu faço” — assumindo um item você mesmo. Um achado que precisa de uma decisão de produto costuma ser mais rápido de resolver em um terminal do que de descrever. Cada cartão em Needs your call tem um botão I'll do it: ele assume o item, abre uma sessão interativa já no branch da execução e avisa você no cabeçalho da sessão. A regra serial vale também para pessoas — enquanto você está com um item, o agente não despacha nada, então suas edições e as dele nunca caem no mesmo diff. Quando você encerra a sessão, seu trabalho é commitado, enviado por push e reportado, e o item chega à revisão com um diff stat real e as mesmas sinalizações do gate que um item produzido por agente receberia. Mudou de ideia? Release o devolve a Needs your call e libera a fila.

Endpoints da API do Assisted:

Orquestrador de IA Batuta

O Batuta é o cérebro de IA do Orquesta — um orquestrador inteligente que analisa tarefas e as encaminha para o melhor método de execução. Disponível no plano Max (US$ 12/usuário/mês).

Batuta LLM — Roteamento inteligente

batuta-auto é um id de modelo sintético. Envie seu prompt a ele e o Batuta escolhe o modelo mais barato que ainda deve dar conta da tarefa — Haiku para perguntas e respostas simples, Sonnet para código do dia a dia, Opus para refatorações, arquitetura e raciocínio com contexto longo. Você paga apenas pelos tokens upstream efetivamente usados, mais a assinatura fixa. Se o modelo para o qual um nível roteia estiver indisponível (limite de cota, problema de autenticação, queda do provedor), a requisição passa automaticamente para o próximo modelo da cadeia de fallback — sem interromper o seu fluxo de trabalho.

Por que batuta-auto em vez de escolher um modelo você mesmo: os usuários típicos do Orquesta enviam uma mistura de prompts triviais ("corrigir typo") e difíceis ("refatorar este fluxo de auth"). Rotear os triviais para o Haiku e só os difíceis para o Opus reduz o gasto em 30–60% sem perder qualidade nos prompts que importam. A decisão de roteamento é determinística dado o prompt e é exposta nos cabeçalhos de resposta (X-Batuta-Tier, X-Batuta-Routed-To).

Use-o a partir de qualquer cliente compatível com OpenAI (o orquesta-cli configura isso automaticamente na primeira execução):

curl https://getorquesta.com/api/v1/chat/completions \
  -H "Authorization: Bearer oclt_YOUR_CLI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "batuta-auto",
    "messages": [{"role": "user", "content": "Refactor this React component to use hooks: ..."}]
  }'

Ou fixe um modelo específico: claude-opus-4-7, claude-sonnet-4-6, gpt-4o, deepseek-reasoner, grok-4, e GET /api/v1/models para a lista completa.

Modos de execução

Rotinas

Rotinas são modelos de prompt salvos que podem ser reexecutados com um clique. Crie rotinas para tarefas comuns como fazer deploy, rodar testes, verificar logs ou executar varreduras de segurança. As rotinas podem ser disparadas manualmente ou agendadas.

Prompts agendados (Loop)

Agende prompts para rodar automaticamente de forma recorrente por meio do seu agente local. Inspirado no comando /loop do Claude — defina um agendamento cron e o Orquesta despacha os prompts ao seu agente quando chegar a hora.

Como funciona:

1. Vá ao seu projeto → Configuration → Scheduled (aba Loop)
2. Crie um prompt agendado com um nome, o conteúdo do prompt e um agendamento cron
3. A plataforma verifica os prompts vencidos a cada 2 minutos por meio de um endpoint de cron
4. Quando um prompt vence, ele é despachado ao seu agente local via broadcast do Supabase Realtime
5. O agente executa o prompt usando o Claude CLI e reporta os resultados

Presets de cron:

Requisitos:

• Seu agent local precisa estar em execução quando o agendamento disparar
• Máximo de 20 prompts agendados por projeto
• Máximo de 10 iterações por execução, com timeout limitado a 1 hora
• Expressões cron personalizadas são aceitas junto com os presets

VMs na nuvem

O Orquesta pode provisionar e gerenciar VMs na nuvem para os seus projetos, na DigitalOcean ou na AWS EC2. As VMs já vêm configuradas com hardening de segurança, suporte a Docker e acesso SSH.

Provedores & tamanhos

Escolha um tamanho e o provedor é definido a partir dele — os droplets da DigitalOcean (s-1vcpu-1gb, s-1vcpu-2gb, s-2vcpu-4gb) rodam em qualquer região da DigitalOcean, e as instâncias da AWS (t3.micro, t3.small, t3.medium) rodam na VPC própria do Orquesta em us-east-1. O mesmo bootstrap cloud-init, a mesma instalação do agent e o mesmo hardening se aplicam aos dois. A AWS cobra separadamente computação, armazenamento e o endereço IPv4 público, então uma instância da AWS com a mesma RAM custa mais: os droplets custam de $12 a $34/mês e as instâncias da AWS de $17 a $49/mês, cobrados mensalmente via Stripe.

Templates de workspace & suspensão por inatividade

Configure uma VM da AWS uma única vez — toolchain, repositórios clonados, navegadores logados nas contas que seu agent usa — e depois clique em Salvar como template. O Orquesta captura o disco como uma imagem de máquina privada e criptografada (a VM reinicia uma vez, em cerca de um minuto), e qualquer projeto da mesma organização poderá então iniciar uma nova VM a partir dela em Iniciar a partir de. Cada clone recebe seu próprio token de agent e sua própria chave SSH; todo o resto é copiado, incluindo as sessões logadas, e é por isso que um template nunca pode ser iniciado fora da sua organização (as organizações filhas de um parceiro, que pertencem ao parceiro, são a única exceção). O agent de toda nova VM da AWS se recusa a iniciar em qualquer máquina que não seja a sua, de modo que um clone nunca consegue executar os prompts do projeto de origem.

A suspensão por inatividade para uma VM após um período de 1 hora a 30 dias sem prompts; uma VM suspensa cobra apenas o disco e o próximo prompt enviado ao projeto a inicia novamente. Os templates cobram apenas o armazenamento do snapshot — até 10 por organização.

Acesso SSH

As chaves SSH são criptografadas com AES-256 e armazenadas no Supabase. A plataforma cuida do gerenciamento de chaves, da configuração da conexão e da execução de comandos de forma transparente.

# VM access is managed through the dashboard
# SSH keys are auto-generated and encrypted
# Direct SSH (for debugging):
ssh -i /tmp/orquesta-vm-key -o StrictHostKeyChecking=no user@vm-ip

Hardening de segurança

Toda VM provisionada inclui:

• Firewall UFW (somente as portas 22, 80 e 443)
• Regras de iptables compatíveis com Docker (cadeia DOCKER-USER) — o Docker ignora o UFW por padrão
• Limitação de taxa de saída contra DDoS (SYN 50/s, UDP 100/s, ICMP 10/s)
• Cron de detecção de malware (a cada 5 minutos)
• Sudo restrito para o usuário orquesta (somente comandos da lista de permissões)
• Aplicação automática de patches de segurança

microVM sob demanda

Um projeto pode funcionar sem uma máquina própria: o Orquesta inicia uma microVM isolada quando um prompt chega, executa dentro dela o agent padrão com orquesta-cli e a deixa expirar cerca de 15 minutos após a última atividade. As chamadas ao modelo vão para os endpoints de LLM da sua própria organização (página do Orquesta CLI) ou para o seu add-on Batuta — o Orquesta não coloca nenhuma credencial de modelo própria na microVM. A cobrança é por minuto de vida da microVM, exibida como “Uso (30d)” em Configurações → Agents → Runner sob demanda. Nada persiste entre sessões, então o agent precisa enviar o seu trabalho (git, um registry, uma API) antes de a VM ser encerrada.

• Projeto inteiro — marque Iniciar em uma microVM do Orquesta ao criar o projeto, escolha microVM como opção de hospedagem durante a configuração ou ative o runner em Configurações. Todo prompt passa a rodar ali. Ela nunca inicia enquanto outro agent do projeto estiver online, então os prompts não podem rodar duas vezes.
• Fluxo de trabalho individual — em um projeto que já roda em uma VM local ou na nuvem, marque Executar em uma microVM ao criar o fluxo de trabalho, ou clique em Executar na microVM no card dele (ou envie run_on_microvm para a API de workstreams). Somente os prompts direcionados a esse fluxo de trabalho iniciam a microVM; os demais continuam indo para o agent do próprio projeto. Na microVM o devolve ao agent que ele tinha antes.
• Copiar uma máquina — para um projeto que vive em um PC que fica ligado o dia todo, Copiar para microVM na mesma seção de Configurações (agent ≥ 0.2.272) faz o agent online enviar sua árvore de trabalho, incluindo alterações não commitadas, para uma branch orquesta/microvm-* e enviar seus arquivos .env, que o Orquesta armazena criptografados e nunca commita. Arquivos não rastreados acima de 5 MB e arquivos que parecem chaves (*.pem, id_rsa, .npmrc, credenciais) ficam de fora, e apenas as duas branches de snapshot mais recentes são mantidas. Revise a branch, os arquivos env e o comando de instalação e depois clique em Converter para microVM; cada inicialização os restaura e executa a instalação. Depois, pare o agent no PC. Os serviços que o PC executa 24/7 não são movidos.

Integrações

Conecte suas ferramentas existentes ao Orquesta para um fluxo de trabalho unificado.

Fluxo de branch + PR

Por padrão, o agent faz commit e push na branch de trabalho do projeto. Se sua equipe revisa as alterações antes de elas entrarem, abra o botão de pull request no card do GitHub conectado (Configuração → Integrações → GitHub) e ative Nova branch + pull request.

• Nova branch + pull request — o agent cria uma branch a partir da branch base, faz push nela e abre um PR. Ele nunca faz commit na branch base e nunca faz o merge do PR por conta própria.
• Prefixo da branch — feature/ por padrão, então as branches ficam como feature/add-auth.
• PR em rascunho — abre todo pull request como rascunho.
• Branch base — as branches são criadas a partir dela e os pull requests apontam para ela. Com a opção desativada, é simplesmente a branch em que o agent faz commit.
• Regras adicionais — texto livre acrescentado às instruções de git do agent: convenções de commit, revisores a marcar, arquivos que devem ser deixados em paz.

Corrija CI com falha & reviews em PRs

Um pull request aberto por um prompt do Orquesta não para no primeiro check vermelho. Quando o CI falha, o agent do projeto recebe os logs com falha, corrige o código na mesma branch, faz push e comenta no PR o que alterou — até o CI ficar verde ou o limite de tentativas ser atingido.

• Ative em Configurações do projeto → Integrações → Corrigir CI com falha em PRs. Isso instala um webhook no repositório conectado, então o token do GitHub precisa de direitos de admin no repositório. Somente owners e admins.
• Somente PRs abertos pelo Orquesta são tocados: um PR cuja URL aparece na saída de um prompt, ou cuja branch foi criada por uma execução do Auto Agent. Um PR escrito à mão por alguém nunca é alvo de ação.
• Há suporte tanto a falhas do GitHub Actions (com o final do log de cada job com falha) quanto a falhas de outros CIs que usam a Checks API, cada uma com seu próprio interruptor.
• Falhas que chegam enquanto uma correção ainda está em andamento são reunidas em um único follow-up, em vez de iniciar um prompt para cada uma, e uma falha em um commit que já foi substituído por um push mais novo é ignorada.
• Após o número configurado de tentativas por PR (padrão 3), ele para e avisa isso no PR; o card tem um botão de nova tentativa para dar a esse PR um novo limite.
• A correção nunca faz force-push, nunca faz push em outra branch e nunca abre um novo PR. Se sua árvore de trabalho tiver alterações não commitadas, a correção roda em um git worktree separado e as deixa intactas.
• Os prompts de correção aparecem no dashboard com a tag github.

Reviews e menções a @orquesta. O feedback de review passa pelo mesmo ciclo:

• Os reviews podem ser Desativados, Somente quando @orquesta é mencionado (padrão) ou Todo review em PRs acompanhados. O corpo do review e seus comentários inline (com arquivo e linha) são enviados ao agent, que os trata na mesma branch e responde no PR — ou explica por que discorda.
• Mencionar @orquesta em um review ou comentário de PR também funciona em PRs que o Orquesta não abriu, e rearma um PR que esgotou as tentativas.
• Somente pessoas com acesso de escrita (owner, membro ou colaborador) são atendidas. Bots de review como coderabbitai[bot] são ignorados, a menos que você os liste em Bots de review. PRs de forks são ignorados.
• Issues (opt-in): um comentário @orquesta em uma issue abre um novo prompt que trabalha em uma branch orquesta/issue-N, abre um PR que fecha a issue e responde na issue com o resultado. No máximo 10 prompts de issue por hora por projeto.
• Os comentários são publicados com a conta do GitHub conectada e levam um marcador oculto, então o Orquesta nunca reage aos próprios comentários. Depois de alterar as configurações de review ou de issues em um webhook existente, use Reparar webhook se o card avisar que o GitHub recusou a atualização.

Vercel

Linear

Bot do Telegram

/auth ott_xxxxx    # Authenticate with one-time token\n/prompt Add dark mode  # Submit a prompt\n/status            # Check current execution\n/deploy            # Trigger deployment

Slack

Um canal do Slack pode ser apontado para um projeto. O que sua equipe digita ali vira um prompt no agent próprio daquele projeto, e a resposta volta como uma resposta em thread no mesmo canal — assim a conversa fica onde a equipe já está, e todos veem tanto o pedido quanto o que o agent fez a respeito.

Conectando um canal

1. Instale o app — Configurações da organização → Slack → Adicionar ao Slack, ou em Configurações → Integrações → Slack de um projeto. Uma instalação cobre todo o workspace.
2. Gere um código de vínculo no mesmo card. Ele é válido por uma hora e pode ser usado uma única vez.
3. Resgate-o no canal que você quer vincular: /orquesta link ABCD2345.

As duas metades são exigidas de propósito. Uma sessão do Orquesta prova quem você é, mas não que você pertence àquele canal; um slash command prova que você está no canal, mas não quem você é no Orquesta. Somente quem tem acesso ao projeto pode gerar um código, e somente quem está dentro do canal pode usá-lo.

Ou deixe o Orquesta criar o canal

O card do Slack também cria um canal público para o projeto, e esse dispensa o código por completo: um canal criado pelo app já tem o app dentro dele, então não há mais nada a provar e o canal é vinculado no instante em que existe. Digite um nome, veja exatamente como o Slack vai chamá-lo e crie. Somente owners e admins — isso escreve no seu workspace, não no Orquesta. A pessoa que o cria e os membros do projeto são convidados para ele na hora, identificados pelo e-mail que usam no Orquesta (requer o escopo users:read.email); quem não tem conta no Slack naquele workspace é ignorado.

Isso requer o escopo channels:manage, que o Slack concede no momento da instalação. Um workspace que instalou o app antes de isso existir precisa instalá-lo novamente — até lá, o botão informa exatamente isso. Canais privados não são criados daqui, porque isso exigiria um escopo mais amplo do que o app solicita.

Como usar

/orquesta Add a rate limit to the login endpoint   # run a prompt
@Orquesta what changed in the last deploy?        # same thing, as a mention
/orquesta status                                  # which project this channel runs, and what is in flight
/orquesta link CODE                               # link this channel to a project
/orquesta unlink                                  # stop this channel reaching the agent
/orquesta help

• Um comando digitado no canal abre a sua própria thread e a resposta cai ali, de modo que saídas longas nunca inundam o canal.
• Mencionar o app dentro de uma thread existente mantém essa thread, e os últimos turnos são entregues ao agent como contexto.
• Os prompts vindos do Slack aparecem no dashboard com a tag slack, com o log completo, o diff e o custo — a resposta no Slack é um resumo, o dashboard é o registro.
• No máximo três prompts rodam ao mesmo tempo por canal; além disso, o app avisa em vez de enfileirar em silêncio.
• Toda mensagem enviada e recebida é guardada junto ao projeto, então o card do Slack mostra a conversa recente mesmo para quem não está no workspace.

Chat da equipe, espelhado com o Slack

Uma equipe que já vive no Slack não quer uma segunda caixa de entrada, lida pela metade, dentro do dashboard. Por isso, escolher o Slack une os dois em vez de escolher um: uma mensagem escrita no painel de Chat é publicada no canal vinculado, uma mensagem escrita no canal aparece no painel, e os dois lados leem uma única conversa. O painel mantém o seu campo de escrita — uma versão anterior o transformou em um atalho para o Slack, o que deixou de fora todos que trabalham no dashboard e dividiu o histórico ao meio.

• Configurações da organização → Slack define isso para a org, para todos os projetos ou para alguns escolhidos, e pode fixar a política para que nenhum projeto a substitua. Somente owners.
• Configurações do projeto → Integrações → Slack define isso para um projeto: seguir a organização ou divergir dela em qualquer direção.
• Escolher o Slack antes de um canal ser vinculado não espelha nada — o painel continua funcionando e mostra um lembrete, e os dois se unem assim que um canal é vinculado.
• O espelhamento é livre de loops por construção: cada linha guarda o timestamp do Slack da sua cópia, então a nossa própria publicação voltando como evento, e as até três retentativas de uma mesma entrega do Slack, caem no mesmo índice único e não fazem nada. Mensagens de apps e bots nunca são espelhadas para dentro.
• Um remetente do Slack que não tem conta no Orquesta é exibido pelo nome sem se tornar membro: como o agent, ele é um tipo de autor, não um perfil, então ninguém consome uma vaga ao digitar em um canal.
• Uma thread continua sendo uma thread através da ponte — uma resposta na thread do Orquesta responde na thread do Slack, e vice-versa.
• Slack → Orquesta requer o escopo channels:history e uma assinatura do evento message.channels. Um workspace conectado antes dessa versão continua funcionando em uma só direção, e o card do Slack do projeto avisa isso, com o botão para reconectar.
• A barra lateral indica qual é o caso: Integrado ao lado de Chat da equipe quando o chat está espelhado com o Slack, Integrar quando não está.
• A página de Chat marca cada projeto vinculado com a marca do Slack e lista o seu canal acima dos nativos, e o card do Slack do projeto aponta para todos os canais conectados — um canal criado pelo Orquesta tem o app dentro dele, não você, e um canal público em que você não entrou fica fora da sua barra lateral do Slack até você abri-lo e entrar.
• Um projeto que a política da org alcança mas que ainda não tem canal aparece nas Configurações da organização como sem canal · adicionar um, que leva direto à aba Integrações daquele projeto — criar ou vincular o canal acontece ali, não no nível da org.

As requisições são rejeitadas, a menos que a assinatura do próprio Slack sobre o corpo bruto seja verificada e o timestamp esteja dentro de cinco minutos, e cada evento recebido é registrado uma única vez — o Slack tenta uma entrega até três vezes, e uma nova tentativa não pode virar uma segunda execução da mesma tarefa. Os botões de aprovação na thread são o próximo passo e não fazem parte desta versão.

Derplins

O chip Contrate um especialista em prompts no final da fileira de abas de um projeto abre uma breve explicação sobre o Derplins — um marketplace de especialistas em prompts que você pode contratar para trabalhar no projeto — e vincula o projeto com um clique (owners e admins). A partir daí, ele aparece listado em Seus projetos do Orquesta no dashboard do Derplins de cada membro do projeto, com um botão para publicar um requisito sobre ele, e é oferecido primeiro quando um pedido do Derplins escolhe um workspace. O trabalho contratado ali roda no agent deste projeto, então cada prompt fica aqui com o seu log completo para auditoria. O menu do chip abre o Derplins ou desvincula o projeto.

7ots

• Rosto & voz — Configurações → Identidade lista os seus ots do 7ots; escolha um e o agent residente do projeto assume sua imagem, seu visual em meets e sua voz. O cérebro continua sendo o agent do Orquesta. Em videochamadas do meet, o agent aparece como o próprio ot, em 3D, e fala com a voz dele (agent 0.2.262+). A voz funciona quando o ot está ativo e sua conta do 7ots está conectada ao Orquesta — sem domínio para adicionar.
• Ots conectados — aba Equipe, abaixo de Tokens de AI Agent: deixe um ot externo entrar no projeto para fazer perguntas ao agent residente ou passar trabalho a ele, com escopos por ot. Cada ot mostra o seu próprio rosto (o personagem que o 7ots renderiza, ou a imagem que ele enviou), e não apenas o nome. Somente owners e admins.
• Ícone do projeto — a barra lateral, o cabeçalho do projeto e o app mobile mostram o favicon do site do projeto, ou o avatar do owner no GitHub, atualizado quando a URL do site ou do repositório muda.

Orquesta CLI

Assistente de programação com IA que roda localmente com endpoints de LLM configuráveis. Disponível no plano Max.

npm install -g orquesta-cli

# Interactive mode
orquesta

# Connect to dashboard
orquesta --token oclt_xxx

# Execute a prompt directly
orquesta -p "Add user authentication"

Configuração de LLM

Configure vários endpoints de LLM pelo dashboard ou localmente. Suporta:

• OpenAI (GPT-4, GPT-4o etc.)
• Anthropic (Claude Opus, Sonnet, Haiku)
• Ollama (modelos locais)
• vLLM (auto-hospedado)
• OpenRouter (marketplace de modelos)
• Qualquer endpoint compatível com OpenAI

Sincronização com o dashboard

As configurações de LLM são sincronizadas nos dois sentidos entre o CLI e o dashboard. Configure os endpoints de forma centralizada e distribua para sua equipe. O histórico de prompts é registrado no dashboard independentemente de o prompt ter sido enviado pelo CLI ou pela interface web.

Extensão para IDE

Conecte o Cursor, o VS Code ou o Windsurf diretamente ao Orquesta. Receba prompts do dashboard da sua equipe e execute-os dentro da sua IDE — a extensão vive no seu editor, executa cada prompt por meio de um CLI de programação local no seu workspace e devolve os resultados ao dashboard em tempo real.

Instalação

Baixe o arquivo .vsix e depois instale-o no seu editor:

# Option 1 — Command palette
# Cursor / VS Code / Windsurf:
# Press Cmd+Shift+P → "Extensions: Install from VSIX..."
# Select the downloaded orquesta-vscode-0.2.12.vsix

# Option 2 — CLI
code --install-extension orquesta-vscode-0.2.12.vsix
cursor --install-extension orquesta-vscode-0.2.12.vsix

Configuração & token

Após a instalação, conecte a extensão ao seu projeto usando um token de agent:

1. Abra seu projeto no Orquesta → Projeto → Agents
2. Clique em Criar token de agent → copie o token oat_xxx
3. Na sua IDE, pressione Cmd+Shift+P → Orquesta: Set Agent Token
4. Cole o token — a extensão se conecta e abre a barra lateral automaticamente

O token é armazenado nas configurações globais do VS Code. A extensão se conecta automaticamente a cada inicialização depois que um token é salvo. Para desativar a conexão automática, defina orquesta.autoConnect: false nas configurações.

Modos de execução

Controle como os prompts são executados por meio da configuração orquesta.executionMode:

Comandos

{
  "orquesta.agentToken": "oat_xxx",       // Your agent token
  "orquesta.autoConnect": true,           // Connect on startup
  "orquesta.workingDirectory": "",        // Defaults to workspace folder
  "orquesta.executionMode": "auto"        // "auto" | "cli" | "ide-ai"
}

Embed SDK

Incorpore o widget de feedback do Orquesta nas suas aplicações em produção. Os usuários podem reportar bugs com inspeção de elementos, screenshots e logs de console — tudo fluindo de volta para o seu projeto no Orquesta.

Configuração via CDN

O embed SDK é distribuído exclusivamente via CDN — coloque duas tags em qualquer página HTML e pronto. Sem etapa de build, sem npm install, sempre na versão mais recente.

<link rel="stylesheet" href="https://getorquesta.com/embed/v1/orquesta.css" />
<script src="https://getorquesta.com/embed/v1/orquesta.min.js"></script>
<script>
  Orquesta.init({
    token: 'YOUR_EMBED_TOKEN',
    position: 'bottom-right'
  });
</script>

Novo no embed? Abra Project → Embed no dashboard: uma checklist guiada leva você por executar o agente, definir a URL de destino, criar um token e instalar o snippet — e uma demo ao vivo integrada (widget real, dados fictícios) mostra o que ele faz antes de você configurar qualquer coisa. Você também pode passar demo: true to Orquesta.init() to para renderizar o widget com dados fictícios e sem backend.

Modo Builder

O modo Builder renderiza uma interface em tela cheia no estilo de IDE (semelhante ao Bolt ou Lovable) com três painéis: chat à esquerda, preview ao vivo à direita e um terminal recolhível na parte inferior.

<div id="builder-root"></div>
<script src="https://getorquesta.com/embed/v1/orquesta.min.js"></script>
<script>
  Orquesta.init({
    token: 'YOUR_EMBED_TOKEN',
    mode: 'builder',
    container: '#builder-root',
    previewUrl: 'https://your-app.com'
  });
</script>

Painéis do Builder:

• Chat — Envie prompts, veja as respostas da IA e as atualizações de status
• Preview — iframe ao vivo com barra de URL e botão de atualizar, recarrega automaticamente quando o prompt termina
• Terminal — Logs de execução em tempo real, recolhível, com saída colorida

Os painéis são redimensionáveis por alças de arrastar. O terminal pode ser recolhido/expandido. Totalmente responsivo, com layout empilhado no celular.

Os prompts enviados pelo embed vão para produção por padrão. Como quem envia está olhando o site publicado, todo prompt do embed pede ao agente que faça commit, push, deploy e informe o SHA do commit quando a alteração de código terminar — depois o preview recarrega com um parâmetro anti-cache para que a nova versão seja realmente carregada. Defina auto_deploy: false nas configurações do token de embed para excluir um token desse comportamento.

Recursos

• Inspetor de elementos — Clique em qualquer elemento para marcá-lo em um relatório de bug
• Captura de console — Captura automaticamente a saída do console do navegador
• Captura de rede — Registra requisições de API com falha
• Sistema de comentários — Feedback inline em elementos específicos
• Linha do tempo — Linha do tempo das ações do usuário para reprodução

Extensão de navegador

O embed precisa de uma tag <script> na página, então só alcança sites que você controla. A extensão de navegador do Orquesta faz o mesmo trabalho pelo lado do navegador: ela injeta o widget em qualquer página sem alterar o HTML e permite que o Orquesta CLI controle o navegador em que você já está logado.

• Injete o embed em qualquer lugar — no site de um cliente, em um ambiente de staging atrás de SSO, em produção. Os prompts chegam ao projeto ao qual o token de embed pertence.
• Seu navegador real — as ferramentas browser_ext_* usam seu perfil e suas sessões reais, ao contrário de browser_*, que abre um Chrome limpo e sem login.
• Captura de console e rede — leia o que a página registrou e o que ela requisitou, pela CLI.
• Chat no painel lateral (0.3.0) — clique no ícone da barra de ferramentas, entre com o Orquesta e converse com um agente que lê e opera a aba atual (clicar, preencher, navegar, ler console/rede). Roda no Batuta; sem CLI nem bridge.
• Enviar ao projeto (0.3.0) — selecione texto em qualquer página, clique com o botão direito em Send to Orquesta project, escolha o projeto e ele roda como um prompt no agente desse projeto. O painel transmite o log e tem um botão Parar (POST /api/v1/prompts/{id}/cancel).

Chrome e Edge. O Firefox não é compatível (a extensão usa o Chrome DevTools Protocol).

Instalar & Parear

A extensão ainda não está na Chrome Web Store, por isso é carregada sem empacotar a partir do repositório orquesta-extension . São três etapas, todas locais:

# 1. build the extension
git clone https://github.com/Getorquesta/orquesta-extension
cd orquesta-extension
npm install
npm run build

# 2. load packages/extension/build unpacked from chrome://extensions
#    (enable Developer mode first)

# 3. in orquesta-cli: /tool -> Browser Extension (your own browser)

Ativar o grupo de ferramentas inicia o bridge local para você — um pequeno daemon em 127.0.0.1 com o qual a extensão se comunica. Clique em Pair no popup da extensão, peça o código à CLI (browser_ext_status o informa) e o navegador fica conectado.

O pareamento sobrevive a reinicializações, então isso acontece uma vez por navegador, não uma vez por sessão. O bridge sobrevive à CLI de propósito: execuções curtas de orquesta -p e várias sessões compartilham um mesmo navegador sem parear de novo. Execute-o você mesmo com npx orquesta-bridge se preferir ver o log dele.

Ferramentas da CLI

No Orquesta CLI, execute /tool e ative Browser Extension (your own browser). Isso registra:

• browser_ext_status — o bridge está ativo, há um navegador pareado
• browser_ext_tabs / _open / _reload — listar abas, abrir uma URL, recarregar
• browser_ext_click / _fill / _press / _select — interagir com a página
• browser_ext_text / _html / _eval — ler a página, executar JS nela
• browser_ext_screenshot — capturar a aba visível
• browser_ext_console / _network — mensagens do console e requisições
• browser_ext_wait — aguardar um seletor ou uma navegação
• browser_ext_embed — injetar o widget do Orquesta na página

Segurança

• Nada sai da máquina. A CLI fala com o bridge via loopback e o bridge fala com a extensão por um WebSocket local pareado. Não há nenhum servidor do Orquesta no caminho.
• O pareamento é explícito e expira. O bridge exibe um código válido por dois minutos; a extensão só se conecta depois que você o digita.
• O token de controle é um arquivo, não um argumento. Ele é gravado com 0600 em ~/.orquesta-cli/, então nunca aparece em ps.
• O bridge escuta apenas em 127.0.0.1 e rejeita requisições originadas do navegador, então uma página web não consegue alcançá-lo por DNS rebinding.

Desktop remoto

Além de controlar um navegador, o agente pode operar o desktop inteiro da máquina em que roda — mover o mouse, digitar e tirar screenshots — e você pode assumir o controle ao vivo pelo dashboard. Isso serve para automatizar fluxos em apps nativos, não apenas páginas web. Atualmente Linux/X11; Windows e macOS estão a caminho.

Ativar & modos

Desativado por padrão. Ative por projeto em Settings → Agent → Remote Desktop. Três modos:

• Automação — o agente controla o desktop programaticamente (nenhum servidor VNC é iniciado).
• Ao vivo (VNC) — uma pessoa assume o controle pelo visualizador do dashboard.
• Ambos — automação mais controle ao vivo.

Usando o visualizador

Abra a aba Remote Desktop em um projeto. A tela aparece assim que o agente começa a transmitir; assistir não exige nada além de acesso ao projeto.

• Assumir controle entrega seu mouse e teclado à máquina remota. Movimentos, cliques, arrastos, roda de rolagem e clique do meio/direito são todos transmitidos; o que você digitar vai para o que estiver em foco lá.
• Destacar abre o desktop em uma janela própria, para que ele fique em um segundo monitor enquanto você continua trabalhando na aba do projeto.
• Desconectar encerra a sessão. O agente para de capturar a tela por completo quando ninguém está assistindo, que é também o que o contador de espectadores ao lado do status indica.
• Histórico de sessões lista todas as vezes em que alguém abriu este desktop, por quanto tempo e se assumiu o controle.

PIN de pareamento

Um owner ou admin pode definir um PIN em Settings → Agent → Remote Desktop. Ele protege o assumir o controle, não o assistir: ver uma tela à qual você já tem acesso pelo dashboard não é a capacidade perigosa — controlar a máquina é. O PIN é armazenado com hash e verificado pelo relay, então nem o navegador nem o agente podem ser convencidos a contorná-lo.

Segurança

• Opt-in, desativado por padrão. O controle total do desktop é de alto risco, então nada roda até você ativá-lo para um projeto.
• Assistir e controlar são permissões separadas. O controle é concedido por sessão e termina com ela — ao reconectar, ele é solicitado de novo, e o PIN (se definido) também.
• O servidor VNC escuta apenas em localhost. O único caminho de entrada é o túnel WebSocket autenticado do agente — nunca exposto à rede.
• Desativado com sandbox Strict. O isolamento Strict do sistema de arquivos e o controle total do desktop são mutuamente exclusivos; o agente se recusa a ativá-lo.
• Sessões ociosas são encerradas para que um controle abandonado não deixe o desktop acessível.

Servidor MCP

O Orquesta fala o Model Context Protocol em um único endpoint, para que um assistente rodando em qualquer lugar — Lovable, ChatGPT, Claude Code, Cursor, VS Code — possa ler o histórico de um projeto e gravar de volta nele o próprio trabalho. Nada para instalar: os hooks acima precisam de um processo na sua máquina, enquanto o MCP alcança ferramentas que rodam na nuvem.

https://getorquesta.com/api/mcp

O transporte é stateless: cada chamada é uma requisição HTTPS, não há sessão para manter viva e nenhum stream de eventos para manter aberto.

Conectando um cliente

Cole a URL. Um cliente hospedado descobre o servidor OAuth a partir do 401, se registra e envia você a uma tela de consentimento do Orquesta onde você escolhe a organização a expor — nenhuma API key é criada, exibida ou copiada. No Lovable: Dashboard → Connectors → pesquise mcp → New MCP server, cole a URL, deixe Authentication em OAuth e depois Add server. O ChatGPT e o Claude pedem apenas a URL.

Cada colega autoriza com a própria conta, e o token alcança exatamente os projetos que essa pessoa já pode ver. Cada ferramenta conectada aparece em Settings → Connections com quantas sessões ela registrou, quando fez algo pela última vez e quantas pessoas a autorizaram — um botão ali a desconecta para a organização inteira.

Pelo terminal, o orquesta-cli também é um cliente MCP e agora faz OAuth: orquesta mcp login <name> abre o navegador uma vez e mantém um token com renovação automática nessa máquina, que é o único jeito de alcançar um servidor que não emite API key. orquesta mcp list marca um servidor autorizado, e orquesta mcp logout <name> o esquece.

Clientes sem suporte a OAuth usam um bearer token — uma API key da organização (oak_) em Settings → API Keys, mantendo o escopo prompts:write se o cliente precisar poder registrar o próprio trabalho:

claude mcp add --transport http orquesta https://getorquesta.com/api/mcp \
  --header "Authorization: Bearer oak_abc123..."

{
  "mcpServers": {
    "orquesta": {
      "url": "https://getorquesta.com/api/mcp",
      "headers": { "Authorization": "Bearer oak_abc123..." }
    }
  }
}

Ferramentas

API de agentes externos

API REST que permite que agentes de IA de terceiros (GPT, LangChain, CrewAI, agentes personalizados) se conectem ao seu projeto do Orquesta. O agente externo traz o cérebro; o Orquesta fornece execução + coordenação.

Como funciona:

1. Gere um token oxa_ no dashboard (Project → Team → External Agents)
2. Registre seu agente pela API
3. Leia o contexto do projeto para entender a base de código
4. Envie prompts — o orquesta-agent local os executa
5. Consulte os resultados periodicamente e itere

Autenticação

Todas as requisições à API exigem um Bearer token com os escopos apropriados:

Authorization: Bearer oxa_abc123...

Limites de taxa: 30 requisições/minuto, 300 requisições/hora (configurável por token).

Os dois escopos *:write vêm desativados por padrão quando um token é criado e precisam ser marcados explicitamente. Eles permitem que um agente de deploy forneça a um projeto suas variáveis e arquivos sem possuir um token oclt_ de toda a organização que age como o usuário inteiro. São estritamente somente escrita: o mesmo token recebe 403 em GET/DELETE nessas rotas, e toda escrita é registrada no log de atividade do token (apenas chaves e nomes de arquivo, nunca valores).

Referência da API

URL base: https://getorquesta.com/api/external-agent

Exemplos

import requests

API = "https://getorquesta.com/api/external-agent"
TOKEN = "oxa_your_token_here"
HEADERS = {"Authorization": f"Bearer {TOKEN}"}

# 1. Register your agent
requests.post(f"{API}/register", headers=HEADERS, json={
    "name": "my-gpt-agent",
    "model": "gpt-4o",
    "provider": "openai",
    "version": "1.0.0",
    "capabilities": ["code-review", "testing"]
})

# 2. Read project context
ctx = requests.get(f"{API}/context", headers=HEADERS).json()
print(ctx["memory"])  # Project knowledge

# 3. Submit a prompt
resp = requests.post(f"{API}/prompts", headers=HEADERS, json={
    "content": "Add input validation to the signup form",
    "tags": ["feature"]
})
prompt_id = resp.json()["promptId"]

# 4. Poll for completion
import time
while True:
    status = requests.get(
        f"{API}/prompts/{prompt_id}", headers=HEADERS
    ).json()
    if status["status"] in ("completed", "failed"):
        print(f"Result: {status['result']}")
        break
    time.sleep(5)

curl -X POST https://getorquesta.com/api/external-agent/prompts \
  -H "Authorization: Bearer oxa_xxx" \
  -H "Content-Type: application/json" \
  -d '{"content": "Fix the login bug", "tags": ["bug"]}'

Bot de agente autônomo

O Orquesta vem com um bot autônomo integrado que usa o Claude CLI como cérebro para planejar estrategicamente e enviar tarefas pela API de agentes externos. O agente local executa cada tarefa.

Nenhuma API key necessária — o bot usa sua assinatura web do Claude via claude login.

Como funciona:

1. Registra-se como agente autônomo pela API
2. Reúne o contexto do projeto, os prompts recentes e o status da fila
3. Executa claude -p com o contexto completo para decidir a próxima tarefa
4. Envia o prompt, faz polling até a conclusão e registra o resultado
5. Repete — cada iteração se baseia nos resultados anteriores

# Run with token (default 5 iterations)
npx tsx scripts/autonomous-agent/run.ts oxa_your_token

# Or use env var with custom iterations
MAX_ITERATIONS=10 ORQUESTA_AGENT_TOKEN=oxa_xxx npx tsx scripts/autonomous-agent/run.ts

Configurável: MAX_ITERATIONS (padrão 5), ITERATION_DELAY (padrão 30s entre iterações).

Segurança

A segurança é fundamental no Orquesta. Seu código roda na sua máquina, as credenciais são criptografadas e todo acesso a dados é controlado por políticas de segurança em nível de linha.

Segurança em nível de linha

Toda tabela do Supabase tem políticas de RLS que impõem isolamento em nível de organização. Os usuários só podem acessar dados dentro da própria organização. Operações administrativas usam uma service role key com permissões elevadas, nunca exposta ao cliente.

Gerenciamento de tokens

Todos os tokens passam por hash SHA-256 antes do armazenamento. Apenas o hash é armazenado — o token em texto puro é exibido uma vez na criação e não pode ser recuperado. Os tokens podem ser revogados instantaneamente pelo dashboard.

Variáveis de Ambiente & Arquivos Secretos

Os segredos do projeto ficam em Settings → Environment Variables e são injetados em cada prompt que o agente executa. Há dois tipos: variáveis chave/valor e arquivos secretos — uma chave de assinatura, keystore, JSON de service account ou.p8 que precisa existir em disco. O agente grava cada arquivo no caminho de destino (relativo ao projeto, absoluto ou ~/…; modo 0600) logo antes da execução e exporta ORQUESTA_FILE_<NAME> com o caminho resolvido.

• Colar .env — tanto o assistente de configuração quanto as Settings aceitam um .env colado (comentários, aspas e prefixos export são tratados; chaves existentes são atualizadas no lugar).
• Acesso à API com um token da CLI — /api/projects/{id}/env, /credentials e /secret-files aceitam Authorization: Bearer oclt_… além da sessão do painel, para que scripts e agentes possam carregar segredos sem um navegador. Excluir exige a permissão credentials:manage.
• Acesso somente de escrita com um token de agente externo — um token oxa_ emitido com os escopos opcionais env:write / secret-files:write (desmarcados por padrão) pode fazer POST em /env e /secret-files apenas no seu próprio projeto. Ele não pode lê-los nem excluí-los, e cada escrita fica registrada no feed de atividade do token. Prefira isso a um oclt_ para um agente cuja única função é carregar segredos — veja Escopos de agentes externos.
• Saúde do token — orquesta --status agora verifica o token da CLI armazenado junto ao servidor e avisa quando ele foi revogado, expirou ou é um token antigo sem usuário associado (esses são recusados com 403 em toda escrita). orquesta --login emite um novo.
• Até 32 arquivos, 512 KB cada, 4 MB no total por projeto. Armazenados criptografados como qualquer outra credencial.

# Merge variables from a .env file (existing keys are updated, others kept)
curl -s -X POST https://getorquesta.com/api/projects/$PROJECT_ID/env \
  -H "Authorization: Bearer $ORQUESTA_CLI_TOKEN" -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile dotenv .env.production '{dotenv: $dotenv, merge: true}')"

# Upload a signing key as a secret file
curl -s -X POST https://getorquesta.com/api/projects/$PROJECT_ID/secret-files \
  -H "Authorization: Bearer $ORQUESTA_CLI_TOKEN" -H "Content-Type: application/json" \
  -d "$(jq -n --arg b64 "$(base64 -w0 AuthKey.p8)" \
        '{files:[{name:"APPLE_AUTH_KEY", path:"~/.private_keys/AuthKey.p8", contentBase64:$b64}]}')"

# In the prompt the agent runs, the file is already on disk:
#   eas build --non-interactive   # reads $ORQUESTA_FILE_APPLE_AUTH_KEY via your eas.json / env

Verificação de Identidade (Passkey / OTP)

Uma organização ou projeto pode exigir uma segunda verificação de identidade, além do login normal, antes que qualquer pessoa faça seu agente agir: enviar ou executar prompts, sessões interativas, controle do navegador, controle de área de trabalho remota, execuções agendadas e autonomia do auto-agent. Os membros se verificam com uma passkey (Touch ID, Windows Hello, uma chave de segurança) ou com um código de app autenticador.

• Ative em Organization Settings → Identity verification for agents (owner), ou por projeto em Settings → Agent (owners e admins). Um projeto só pode tornar a política mais rígida.
• Ela expira após o tempo configurado (15 min a 24 h, padrão 8 h; vale o menor entre organização e projeto), quando você sai da conta ou quando pressiona Lock now no seu perfil.
• Cadastre-se em Profile → Identity verification, ou diretamente pelo prompt na primeira vez que for necessário. Adicionar ou remover um método depois do primeiro pede que você se verifique de novo, e cada mudança é enviada por e-mail a você.
• Flexibilizar a política (desativá-la ou aumentar a expiração) exige uma verificação feita nos últimos 15 minutos, para que uma sessão roubada não consiga desativá-la.
• Escopo: a verificação se aplica às sessões do painel. Os caminhos autenticados por token (API pública, CLI, Slack, Telegram, agentes externos) são regidos por seus tokens.

Varredura de Segurança

A varredura de segurança integrada analisa prompts e código gerado em busca de vulnerabilidades. As varreduras detectam problemas comuns como SQL injection, XSS, command injection e credenciais expostas. Os resultados aparecem no painel Security com níveis de severidade e orientações de correção.

GuardRails

O GuardRails é uma camada de proteção de prompts por projeto que intercepta cada prompt antes de chegar ao agente. Ele procura tentativas de prompt injection, jailbreaks, sobrescrita de papel e exfiltração de dados usando mais de 30 regras regex integradas, além de uma etapa opcional de revisão por IA com GPT-4o-mini.

Como funciona:

1. Cada prompt recebe uma pontuação em 6 categorias de regras antes da execução
2. Pontuação ≥ 70 → bloqueado, 30–69 → com aviso, < 30 → aprovado
3. O resultado é armazenado no prompt (guardrail_status, guardrail_flags)
4. No modo block o prompt é cancelado e um 403 é retornado; no modo warn ele é executado, mas é sinalizado

Modos de Ação:

• Block — o prompt é cancelado; quem o enviou recebe um erro com a regra correspondente
• Warn — o prompt é executado normalmente, mas é sinalizado no log de violações
• Log Only — o prompt é executado e as violações são registradas silenciosamente para auditoria

Configuração: Vá em Agent → GuardRails no painel do projeto para ativar, definir o modo, alternar a revisão por IA e adicionar padrões regex personalizados. Os admins do projeto também podem ativar/desativar o GuardRails diretamente na barra de ferramentas Send Prompt usando o botão GuardRails — sem precisar sair da tela.

Endpoints da API do GuardRail:

Quality Gates

Os Quality Gates permitem que admins exijam uma etapa de Simulate antes de Submit para membros específicos da equipe. Quando ativados, o botão Execute do membro passa a ser Simulate — ao clicar, uma IA mostra uma prévia do que o agente faria (arquivos tocados, comandos executados, riscos). Em seguida o membro escolhe Sign & Submit para prosseguir ou Cancel.

Como ativar:

1. Vá em Team no painel do projeto
2. Clique no selo Sign-off ao lado do nome do membro (somente admins)
3. O selo fica âmbar quando ativo — esse membro verá "Simulate" em vez de "Execute"
4. A simulação é rastreada por meio de quality_gate_signed no registro do prompt

CLAUDE.md Sync

Edite o CLAUDE.md do seu projeto diretamente no painel e mantenha-o sincronizado com o diretório de trabalho do agente. O Claude Code lê o CLAUDE.md da raiz do projeto a cada sessão — chega de SSH manual para atualizá-lo.

Editor no Painel

Abra Configuration → Settings → aba CLAUDE.md. Edite o conteúdo e salve. Ele é armazenado em projects.settings.claude_md. Na próxima conexão do agente, o arquivo é gravado em <workingDirectory>/CLAUDE.md.

Sincronização pelo Agente

Na primeira conexão, o agente envia o CLAUDE.md local ao painel (somente se não houver conteúdo de usuário salvo):

1. O agente lê o CLAUDE.md do seu diretório de trabalho
2. Faz POST do conteúdo para /api/agent/claude-md
3. O servidor o armazena somente se settings.claude_md ainda não estiver definido (edições do usuário nunca são sobrescritas)
4. Nas conexões seguintes, se settings.claude_md estiver definido, ele é gravado de volta em disco

Contexto do Agente da Organização

O CLAUDE.md é por projeto. As regras que valem para todos os projetos da organização ficam em Settings → Agent context (/dashboard/settings, somente owners) — políticas que você nunca deveria precisar repetir: “trabalhe sempre em uma branch e abra um PR”, “pergunte antes de adicionar uma dependência”, “escreva as mensagens de commit em inglês”.

Ele é entregue depois das instruções do projeto e das skills de integração, sob um cabeçalho que declara que ele as sobrepõe — a precedência de prompt é posicional, então o último bloco rotulado vence. Os agentes em execução o recarregam em poucos segundos após o salvamento.

Code Browser

A aba Code Browser oferece uma visualização somente leitura do código-fonte do seu projeto diretamente no painel. Os arquivos são obtidos do GitHub ou via SSH — sem precisar de clone local.

Recursos:

• Realce de sintaxe para mais de 20 linguagens (TypeScript, Python, Go, Rust, SQL, HTML, CSS e outras)
• Explorador de arquivos com filtro de busca e navegação por diretórios
• Busca dentro do arquivo com navegação entre ocorrências (Ctrl+F ou botão de busca)
• Navegação por breadcrumb e metadados do arquivo (tamanho, número de linhas, linguagem)
• Copiar todo o conteúdo do arquivo para a área de transferência
• Ask AI — abra um painel lateral para fazer perguntas sobre o arquivo que você está vendo. Respostas em streaming com Claude Haiku ou GPT-4o-mini

Esta é uma experiência somente de visualização — os arquivos não podem ser modificados, criados nem excluídos no Code Browser. Use-a para revisões de código, integração de novos membros da equipe ou para explorar partes desconhecidas da base de código.

Ask AI

Clique no botão Ask na barra de ferramentas do arquivo para abrir o painel de IA. A IA recebe o conteúdo do arquivo como contexto e pode responder perguntas sobre o código, explicar padrões, identificar possíveis problemas e descrever o que as funções fazem. Prompts sugeridos são oferecidos para você começar.

Painel de Desempenho

A aba Performance (Configuration → Performance) mostra dados agregados de uso de tokens e custo do projeto, divididos por modelo e por dia. Os dados vêm dos campos tokens_used e cost_cents preenchidos pelo executor da Claude CLI.

O que você vê:

• Cards de estatísticas: Custo total ($), Total de tokens, Quantidade de prompts
• Gráfico de barras diário: custo por dia no período selecionado
• Tabela por modelo: modelo, provedor, prompts, tokens, custo — ordenada por custo
• Gasto por membro: gasto de tokens + custo por usuário, ordenado por uso, com um alerta de High-spend quando um membro concentra mais de 40% dos tokens da equipe
• Limite de tokens por usuário: owners/admins da organização podem definir um teto mensal de tokens Batuta por membro para toda a organização, no modo somente alerta (membros e admins recebem e-mail em 80% / 95%) ou no modo bloqueio (os prompts são rejeitados após o teto até o próximo mês)
• Seletor de período: 7 dias / 30 dias / Todo o período

API de Desempenho

Quick Prompts

Os Quick Prompts permitem salvar prompts usados com frequência como templates reutilizáveis. Em vez de digitar as mesmas instruções de novo, salve-as uma vez e execute com um único clique.

Criar e Usar Quick Prompts

Criando:

• Abra o campo de prompt em qualquer projeto
• Digite seu prompt e clique no botão Save as Quick Prompt
• Dê um nome e, opcionalmente, uma descrição
• Os quick prompts são salvos por projeto na tabela quick_prompts

Usando:

• Clique no menu suspenso Quick Prompts na área de entrada do prompt
• Selecione um prompt salvo para preencher o campo automaticamente
• Edite se necessário e envie normalmente

Casos de uso:

• Prompts padrão de revisão de código
• Checklists de deploy
• Templates de relatório de bug
• Tarefas recorrentes de manutenção

Building in Public

Torne a atividade de IA do seu projeto visível publicamente — sem necessidade de login. Ative a opção "Build in Public" e seu projeto aparece no Live Feed em getorquesta.com/feed, permitindo que qualquer pessoa acompanhe seu agente de IA entregando código em tempo real. Uma ótima forma de gerar FOMO e mostrar como é o desenvolvimento com IA.

Ativar e Configurar

Vá em Project → Settings → aba Permissions. Em "Build in Public", ative a opção.

• Slug personalizado — Defina uma URL curta como my-project para que a página do seu feed fique em getorquesta.com/feed/my-project em vez de um UUID. Deve conter letras minúsculas, números e hifens (3–50 caracteres). Deve ser único.
• URL do site ao vivo — Informe a URL do seu app em produção (p. ex. https://myapp.com). Os visitantes da página do seu feed verão uma prévia em iframe do produto em execução abaixo da linha do tempo de prompts.

Live Feed

O feed global em /feed lista todos os projetos públicos, ordenados pela pontuação de votos da comunidade. Cada card mostra:

• Status online/offline do agente (ponto verde = visto nos últimos 3 minutos)
• Pulso âmbar "Running now" quando um prompt está sendo executado
• Os 3 últimos trechos de prompts com ícones de status e selos de origem (Web / Telegram / Auto / etc.)
• Botões de voto positivo/negativo — a pontuação é votos positivos menos negativos, armazenada por UUID anônimo do navegador
• Link para a linha do tempo completa do projeto em /feed/[slug]

A página de detalhes do projeto (/feed/[slug]) mostra:

• Prévia em iframe do site ao vivo (se uma URL do site estiver configurada)
• Linha do tempo completa de prompts (últimos 50, somente leitura)
• Conteúdo do prompt expansível, tags, origem, duração
• Botão de compartilhar no X e botão de copiar link
• Terminal de logs ao vivo para qualquer prompt em execução

Logs em Tempo Real

Quando um prompt está em execução, um painel de terminal aparece abaixo dele na página pública do projeto e transmite os logs do agente a cada 2 segundos. Os logs são filtrados — as entradas internas de thinkingficam ocultas e só a saída acionável é exibida:

Os logs são limitados às últimas 80 entradas por consulta e truncados em 500 caracteres por linha. A rolagem é automática até a entrada mais recente.

API Pública

Estes endpoints não exigem autenticação — são totalmente públicos:

Chaves de API

As chaves de API (oak_) dão a integrações externas acesso aos dados do Orquesta. Gere-as em Settings > API Keys, onde cada chave tem duas restrições independentes: quais escopos ela possui (somente leitura por padrão) e quais projetos ela pode acessar (todos ou alguns escolhidos). Ambas podem ser editadas depois, sem reemitir o token.

Autenticação

Inclua sua chave de API em todas as requisições:

# Option 1: Authorization header
curl -H "Authorization: Bearer oak_xxx" https://getorquesta.com/api/v1/projects

# Option 2: X-API-Key header
curl -H "X-API-Key: oak_xxx" https://getorquesta.com/api/v1/projects

Endpoints

Projetos & VMs

Chaves de organização (oak_ apenas — tokens de CLI, agent e MCP são recusados) podem criar projetos e gerenciar a VM na nuvem de cada projeto. As operações de escrita exigem que o usuário que criou a chave ainda seja proprietário ou administrador da organização. Limite: 30 requisições/minuto, 300/hora por chave. As respostas de VM nunca incluem a chave privada SSH nem o token do agent.

Organizações parceiras (habilitadas pela Orquesta) podem criar uma organização filha por cliente final e atuar nela enviando X-Orquesta-Org: <child id> para qualquer endpoint acima. Uma organização filha com cobrança Stripe deve pagar primeiro pelo checkout; até lá, a criação de uma VM responde 402 with code: billing_required.

Escopos

Uma chave possui apenas os escopos que você marcar. Uma requisição fora deles responde 403 indicando o escopo ausente.

Dois presets cobrem a maioria dos casos: Somente leitura (todos os escopos :read, exceto o opcional vms:read) e Leitura + envio de prompts. Criar uma chave sem indicar nenhum escopo gera uma chave somente leitura. Os escopos de infraestrutura nunca estão em um preset: marque-os explicitamente.

Restrição por projeto

Uma chave vale para toda a organização, a menos que você a restrinja. Ao escolher projetos, todos os endpoints — REST e MCP — são filtrados por eles: as listagens retornam apenas os registros desses projetos, e pedir qualquer outra coisa responde 404, a mesma resposta de um projeto que não existe, de modo que uma chave não consegue sondar quais ids de projeto são reais. As chaves existentes continuam valendo para toda a organização até você editá-las.

# A key restricted to one project
curl -H "Authorization: Bearer oak_xxx" \
  "https://getorquesta.com/api/v1/prompts?projectId=<allowed>"   # 200

curl -H "Authorization: Bearer oak_xxx" \
  "https://getorquesta.com/api/v1/prompts?projectId=<other>"     # 404

OSS Community

Orquesta OSS é uma versão open source e auto-hospedada da plataforma. As instâncias OSS podem, opcionalmente, se publicar no feed da comunidade getorquesta.com/feed, tornando sua instância descobrível por outros desenvolvedores.

Auto-hospedagem

Comece com a versão OSS:

# Clone the repository
git clone https://github.com/Orquesta-live/orquesta-oss.git
cd orquesta-oss

# Install dependencies
npm install

# Set up the database
npx prisma db push

# Start the development server
npm run dev

Stack OSS:

• Next.js 15 + Prisma + SQLite (não precisa de banco de dados externo)
• Better Auth para autenticação
• Socket.io para comunicação em tempo real com os agents
• Agent Grid completo, tokens de agent e sessões interativas

Publicar no feed da comunidade

Os proprietários de instâncias OSS podem publicar sua instância no feed da comunidade em getorquesta.com/feed. Isso torna sua instância visível para a comunidade.

Como publicar:

• Abra o dashboard da sua instância OSS
• Clique no botão Publish to Community no cabeçalho do projeto (somente o proprietário)
• Os dados da sua instância são enviados para POST /api/oss/publish
• Sua instância aparece na seção Comunidade de /feed

API:

Cobrança & Planos

Matriz de recursos

Batuta LLM Add-on

Batuta LLM é um proxy de LLM gerenciado que dá à sua equipe acesso aos principais modelos de IA (GPT-4o, Claude, Gemini, DeepSeek, Mistral, Grok) sem precisar gerenciar chaves de API. Use-o pelo chat do dashboard ou pelo Orquesta CLI.

O Batuta Standard está incluído no plano Max — as organizações Max recebem automaticamente a cota de 5M tokens/mês e não precisam do add-on. Os níveis Plus, Pro e Team abaixo permitem escalar ainda mais.

Enterprise

O Orquesta Enterprise foi projetado para organizações que precisam de segurança, conformidade e controle avançados sobre fluxos de desenvolvimento com IA. De SSO e permissões granulares a implantação on-premise e conformidade SOC 2, o Enterprise dá às suas equipes de segurança e de compras tudo o que precisam para aprovar o Orquesta em produção.

SSO & Gerenciamento de identidade

O Orquesta se integra ao seu provedor de identidade existente para que sua equipe faça login com as credenciais corporativas. Sem senhas separadas, sem provisionamento manual de usuários.

Provisionamento SCIM

Automatize o gerenciamento do ciclo de vida dos usuários com SCIM 2.0. Quando funcionários entram ou saem da sua organização, o acesso ao Orquesta é provisionado ou revogado automaticamente pelo seu provedor de identidade.

• Criação automática de usuário ao ser adicionado a um grupo do IdP
• Desativação automática ao ser removido do IdP
• Mapeamento de grupos para funções (os grupos do IdP correspondem às funções do Orquesta)
• Provisionamento just-in-time (JIT) no primeiro login

Autenticação multifator (MFA)

Exija MFA no nível da organização. O Orquesta oferece suporte a TOTP (aplicativos autenticadores), WebAuthn (chaves físicas como YubiKey) e SMS como alternativa. Os administradores podem exigir MFA de todos os membros ou de funções específicas.

Verificação de domínio

Reivindique seu domínio de e-mail (por exemplo, @yourcompany.com) para que qualquer funcionário que se cadastre com esse domínio seja adicionado automaticamente à sua organização. Evita contas paralelas e garante o gerenciamento centralizado.

Funções e permissões avançadas

O RBAC Enterprise vai além das funções padrão Admin / Developer / Viewer. Crie funções personalizadas com permissões granulares restritas a projetos, ambientes e ações específicos.

Funções Enterprise integradas

Funções personalizadas

Crie funções personalizadas com conjuntos de permissões detalhados. Cada permissão é uma combinação de recurso + ação:

{
  "name": "Senior Developer",
  "permissions": [
    "prompts:submit",
    "prompts:execute",
    "prompts:approve",
    "logs:read",
    "git:commit",
    "git:push",
    "agents:connect",
    "agents:interactive_session",
    "vm:ssh",
    "settings:claude_md:edit"
  ],
  "restrictions": {
    "environments": ["development", "staging"],
    "max_tokens_per_prompt": 50000,
    "blocked_commands": ["rm -rf /", "DROP DATABASE", "format"]
  }
}

Acesso por ambiente

Restrinja quais ambientes cada função pode acessar. Um desenvolvedor pode ter acesso total a development e staging, mas precisar de aprovação para production. Os ambientes são definidos por projeto e aplicados no nível do agent.

• Development — acesso aberto, sem necessidade de aprovações
• Staging — acesso de desenvolvedor, revisão opcional
• Production — exige aprovação de quality gate por um Reviewer ou Project Admin
• Restricted — somente Org Admins e Security Officers, com auditoria completa de cada ação

Allowlists e blocklists de comandos

Defina quais comandos de shell e padrões são permitidos ou bloqueados por função e ambiente. O agent aplica essas regras antes da execução, impedindo operações destrutivas ou não autorizadas.

{
  "production": {
    "blocked_patterns": [
      "rm -rf",
      "DROP TABLE",
      "DROP DATABASE",
      "truncate",
      "format",
      "mkfs",
      "dd if=",
      "> /dev/sd"
    ],
    "require_approval": [
      "git push",
      "npm publish",
      "docker build",
      "kubectl apply",
      "terraform apply"
    ]
  }
}

Allowlist de IPs

Restrinja o acesso ao dashboard e à API a faixas de IP específicas. Somente requisições da sua rede corporativa, VPN ou blocos CIDR aprovados podem acessar o Orquesta. Configurado no nível da organização.

{
  "ip_allowlist": {
    "enabled": true,
    "ranges": [
      "203.0.113.0/24",
      "198.51.100.0/24",
      "10.0.0.0/8"
    ],
    "bypass_for_sso": false,
    "enforce_on_api": true,
    "enforce_on_agents": true
  }
}

Opções de implantação

Escolha o modelo de implantação que atende aos seus requisitos de segurança e conformidade. O Orquesta oferece suporte desde a nuvem totalmente gerenciada até instalações on-premise isoladas, do tipo air-gapped.

Residência de dados

Escolha onde seus dados são armazenados para cumprir as regulamentações regionais. Regiões disponíveis para implantações em nuvem gerenciada e VPC:

• US East (Virgínia) — padrão
• US West (Oregon)
• EU West (Frankfurt) — em conformidade com o GDPR
• EU North (Estocolmo)
• LATAM (São Paulo)
• APAC (Sydney, Tóquio)

Arquitetura de alta disponibilidade

As implantações Enterprise rodam em configuração de alta disponibilidade com failover automático:

• Replicação de banco de dados multi-AZ com failover automático
• Servidores de API com balanceamento de carga entre zonas de disponibilidade
• Relay WebSocket com sticky sessions e tratamento de reconexão
• Cluster Redis para estado em tempo real e cache
• Backups diários automatizados com retenção de 30 dias (configurável)
• Recuperação de desastres com RPO < 1 hora, RTO < 4 horas

Auditoria & Governança

Toda ação no Orquesta é registrada com contexto completo. A auditoria Enterprise vai além do registro padrão, com trilhas de auditoria imutáveis, integração com SIEM e políticas de retenção configuráveis.

Log de Auditoria Imutável

Todo evento é gravado em um log de auditoria somente de anexação, que não pode ser modificado nem excluído, nem mesmo pelos Org Owners. Os eventos são encadeados criptograficamente para detectar adulteração.

Integração com SIEM

Envie eventos de auditoria em tempo real para o seu SIEM ou plataforma de gerenciamento de logs. Destinos compatíveis:

• Splunk — via HEC (HTTP Event Collector)
• Datadog — via Log Forwarding API
• Elastic / ELK — via bulk API do Elasticsearch
• AWS CloudWatch — para implantações em VPC
• Azure Monitor — via workspace do Log Analytics
• Custom Webhook — qualquer endpoint HTTPS, payload JSON, assinado com HMAC

Fluxos de Aprovação

Os quality gates Enterprise oferecem cadeias de aprovação em vários níveis. Configure os requisitos de aprovação por ambiente e tipo de ação:

{
  "approval_policy": {
    "production": {
      "prompt_execution": {
        "required_approvals": 2,
        "approver_roles": ["Reviewer", "Project Admin"],
        "auto_reject_after_hours": 48,
        "require_diff_review": true
      },
      "git_push": {
        "required_approvals": 1,
        "approver_roles": ["Project Admin", "Org Admin"]
      },
      "destructive_commands": {
        "required_approvals": 2,
        "approver_roles": ["Org Admin", "Security Officer"],
        "notify": ["#security-alerts"]
      }
    },
    "staging": {
      "prompt_execution": {
        "required_approvals": 1,
        "approver_roles": ["Reviewer", "Developer"],
        "auto_approve_after_hours": 24
      }
    }
  }
}

Políticas de Retenção de Dados

Configure por quanto tempo cada tipo de dado é retido. Atenda aos requisitos regulatórios e controle os custos de armazenamento:

• Logs de auditoria — mínimo de 1 ano, configurável até 7 anos (exigido para SOC 2, HIPAA)
• Logs de execução — 90 dias por padrão, configurável
• Histórico de prompts — 1 ano por padrão, configurável
• Diffs do Git — retidos indefinidamente (vinculados aos commits)
• Gravações de sessão — 30 dias por padrão, configurável
• Limpeza automática — os dados são excluídos com segurança após o fim do período de retenção

Gestão de Custos e Orçamentos

A gestão de custos Enterprise dá a líderes de finanças e engenharia visibilidade e controle totais sobre os gastos com IA em toda a organização.

Controles de Orçamento

Dashboard de Uso

Um dashboard de analytics Enterprise dedicado oferece:

• Uso de tokens em tempo real em todos os projetos e equipes
• Detalhamento de custos por projeto, usuário, equipe e ambiente
• Análise histórica de tendências com relatórios mensais/trimestrais
• Exportação para CSV/PDF para relatórios financeiros
• Atribuição de custos de API (qual provedor de LLM, modelo e plano)
• Previsões com base nas tendências de uso

Integrações Enterprise

Conecte o Orquesta às ferramentas que sua equipe já usa. As integrações Enterprise vão além dos webhooks padrão, com integrações profundas e bidirecionais.

Sistema de Webhooks

O sistema de webhooks Enterprise é compatível com qualquer endpoint HTTPS, com eventos configuráveis, políticas de retry e verificação de assinatura HMAC:

{
  "url": "https://your-service.com/webhooks/orquesta",
  "secret": "whsec_...",
  "events": [
    "prompt.submitted",
    "prompt.approved",
    "prompt.executed",
    "prompt.failed",
    "agent.connected",
    "agent.disconnected",
    "security.alert",
    "budget.threshold"
  ],
  "retry_policy": {
    "max_retries": 5,
    "backoff": "exponential",
    "timeout_ms": 30000
  },
  "headers": {
    "X-Custom-Header": "value"
  }
}

SLA e Níveis de Suporte

Clientes Enterprise recebem suporte premium com tempos de resposta garantidos e uma equipe dedicada de customer success.

Slack Connect

Clientes Enterprise têm um canal compartilhado do Slack Connect com a engenharia do Orquesta. Tenha acesso direto à equipe que constrói o produto para resolver problemas rapidamente, solicitar funcionalidades e receber orientação de arquitetura.

Conformidade e Certificações

O Orquesta se compromete a cumprir os mais altos padrões de segurança e conformidade. Abaixo estão nossa postura atual de conformidade e o roadmap de certificações.

Conformidade Atual

Roadmap de Certificações

As certificações a seguir estão planejadas ou em andamento como parte do nosso roadmap de conformidade Enterprise:

Práticas de Segurança

• Testes de Intrusão — Pentest anual por terceiros. Resultados disponíveis sob NDA.
• Programa de Bug Bounty — Programa de divulgação responsável para pesquisadores de segurança.
• Varredura de Dependências — Varredura automatizada de CVEs em cada build via Snyk/Dependabot.
• Análise Estática — Ferramentas de SAST integradas ao pipeline de CI/CD.
• Detecção de Segredos — Hooks de pre-commit e verificações de CI evitam o vazamento de segredos.
• Segurança dos Funcionários — Verificação de antecedentes, treinamento de segurança, acesso com privilégio mínimo e chaves de hardware para a infraestrutura.
• Resposta a Incidentes — Plano de resposta documentado, com confirmação em 1 hora para incidentes P1. Postmortem em até 72 horas.
• Gestão de Fornecedores — Todos os subprocessadores são avaliados quanto à postura de segurança. DPAs firmados com todos os fornecedores.

Trust Center

Acesse getorquesta.com/trust para ver nosso Trust Center público, que inclui:

• Status do sistema em tempo real e histórico de uptime
• Whitepaper de segurança (PDF para download)
• Formulário de solicitação do relatório SOC 2
• Modelo de DPA (Data Processing Agreement)
• Lista de subprocessadores
• Resumo dos testes de intrusão
• Política de divulgação responsável / bug bounty

Onboarding Enterprise

Todo cliente Enterprise recebe um onboarding estruturado para garantir um time-to-value rápido e uma adoção bem-sucedida entre as equipes.

Cronograma de Onboarding

Avaliação Enterprise

Oferecemos um piloto Enterprise de 30 dias com acesso completo aos recursos. O piloto inclui:

• Conjunto completo de recursos Enterprise (SSO, RBAC, auditoria, integrações)
• Até 25 usuários durante o período do piloto
• Canal dedicado do Slack Connect com a equipe do Orquesta
• Duas sessões de onboarding de 1 hora
• Questionário de segurança pré-preenchido
• Prova de conceito personalizada para o seu fluxo de trabalho específico