Resumen de la plataforma

Orquesta es una plataforma colaborativa de orquestación de prompts que convierte prompts en lenguaje natural en código de producción. Tu equipo escribe lo que quiere construir y los agentes de IA se encargan del código, los PRs y el despliegue.

La plataforma admite múltiples vías de ejecución: un agente local conectado por WebSocket con todas las capacidades de Claude CLI, VMs en la nube con ejecución directa por SSH, Batuta AI para el enrutamiento autónomo de tareas y una API de agentes externos para integrar IA de terceros.

Inicio rápido

Empieza a trabajar en menos de 5 minutos:

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

Recorrido de bienvenida

Los usuarios nuevos reciben un recorrido guiado interactivo en su primera visita al panel. El recorrido crea un proyecto de demostración con datos de ejemplo y repasa 9 áreas clave de la plataforma.

Conceptos clave

Agente local

El paquete orquesta-agent conecta tu máquina local con el panel de Orquesta mediante WebSocket. Recibe prompts, los ejecuta con Claude CLI y devuelve los registros en tiempo 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

Conexión a un proyecto

Genera un token desde el panel (Proyecto → Agente → Configuración) y luego:

orquesta-agent --token oat_abc123...

Varios agentes por proyecto

Conecta varios agentes al mismo proyecto: uno en tu laptop de desarrollo, otro en staging y otro en producción. Cada agente recibe su propio token y se ejecuta de forma independiente.

# 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"

Al enviar un prompt, puedes elegir qué agente lo ejecuta mediante el selector desplegable de agentes. Características:

• Estado en línea/fuera de línea por agente con indicadores verdes
• Selector desplegable de agentes cuando hay varios en línea
• Ejecución en paralelo: cada agente ejecuta los prompts de forma independiente
• Nombres de agente personalizados con la opción --name

El agente:

• Valida el token con la API de Orquesta
• Establece una conexión WebSocket mediante Supabase Realtime
• Envía heartbeats cada 30 segundos
• Escucha comandos EXECUTE en el canal del proyecto
• Informa su versión y capacidades al panel

Flujo de ejecución de prompts

Cuando se envía un prompt:

1. El panel transmite un comando EXECUTE por el canal Realtime
2. El agente lo recibe y lo pone en cola (solo ejecución secuencial)
3. El agente lanza un proceso de la CLI claude con el prompt
4. La salida se envía como entradas de registro a Supabase
5. Al terminar, el agente informa el estado, los commits de git y el uso de tokens

Motor de código: qué CLI ejecuta tus prompts

El agente no incluye ningún modelo. Lanza una CLI de código que ya está instalada y con la sesión iniciada en la máquina, así que cada prompt se ejecuta con tu suscripción. Elige el motor por proyecto en Ajustes → Agente, desde el chip del encabezado del proyecto o en el asistente de configuración mientras conectas el agente: el asistente muestra el mismo selector y las mismas marcas, de modo que el motor se elige antes del primer prompt y no después de que falle.

# 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

La elección llega a un agente en ejecución con su siguiente heartbeat, sin reiniciar. El agente informa qué motor está ejecutando realmente, así que si el que elegiste no está instalado, el panel muestra el de respaldo en lugar de fingir en silencio. Cada prompt completado se etiqueta con su cli_type y muestra una insignia en la línea de tiempo.

Dos problemas distintos reciben dos marcas distintas en Ajustes → Agente. ✗ significa que el motor no está instalado: el agente recurre al siguiente que tenga. ! significa que sí está instalado pero no tiene la sesión iniciada: no hay respaldo, porque el binario existe, así que los prompts se ejecutan y fallan en la autenticación propia del motor hasta que inicies sesión en esa máquina (cursor-agent login, claude login, kiro-cli login). Cada motor es dueño de su credencial: Orquesta nunca la ve y no puede iniciar sesión por ti.

Hooks de IDE — refleja sesiones de Claude Code y Cursor

El flujo anterior es el de despacho: Orquesta envía trabajo al agente. Los hooks van en la dirección opuesta — tú sigues trabajando en tu propio IDE y Orquesta refleja lo que ocurrió. Nunca se ejecuta nada de vuelta en tu editor y no necesitas tener ningún daemon en ejecución.

Ejecútalo una vez por repositorio. Sin --client configura ambas herramientas:

# 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

Escribe .orquesta.json (vínculo con el proyecto — mantenlo en gitignore, ya que contiene el token en bruto) además de .claude/settings.json y/o .cursor/hooks.json. Los hooks existentes se conservan; al volver a ejecutar init se actualizan las entradas de Orquesta en lugar de apilar duplicados.

Los prompts reflejados llegan con source: terminal y una insignia Local CLI; la columna cli_type (claude-code o cursor-cli) determina la insignia de herramienta junto a ella. Se excluyen del despacho al agente, por lo que una sesión con hooks nunca se vuelve a ejecutar.

Solución de problemas

Dashboard

El dashboard es el centro desde el cual gestionas proyectos, envías prompts, monitoreas la ejecución y colaboras con tu equipo.

Home (/dashboard/home) es una vista centrada en el chat: elige un proyecto en el selector y conversa con su agente. El panel izquierdo lista tu historial agrupado por día — chats de Home, sesiones de terminal interactivas, sesiones locales con hooks y prompts individuales — y una cuenta nueva llega aquí con un primer proyecto ya creado y una lista de configuración de cuatro pasos (máquina lista, elige tu modelo, primer prompt, invita a alguien — GitHub, Supabase y el resto están en el modo Advanced). Cada proyecto tiene su propia dirección, /dashboard/home/<projectId>. Al cambiar desde Advanced se mantiene el proyecto en el que estabas. Cuando un proyecto ya tiene historial, sus sugerencias salen de él — primero las propuestas abiertas del Auto Agent, luego continuaciones del trabajo reciente. El panel derecho se puede ocultar y trae un panel de Actividad (las herramientas que está ejecutando el agente, como en las sesiones interactivas) y uno de Artefactos (archivos que cambió la IA y enlaces que generó). El interruptor Operator / Advanced de la barra lateral alterna entre Home y el dashboard completo; Home solo muestra dónde se ejecuta el agente, y reconfigurarlo se hace en el modo Advanced. Cada chat de Home funciona como un chat: en Claude CLI (agente 0.2.267+) cada chat es una sesión real de Claude que se reanuda con cada mensaje nuevo, de modo que Claude conserva toda la conversación — lo que leyó, ejecutó y respondió — y "sí, hazlo" se refiere a lo que se acaba de discutir. En otras CLI, agentes más antiguos o una máquina que nunca ha visto el chat, el mensaje lleva en su lugar los turnos anteriores del chat (los últimos 8, recortados para que quepan). Los logs de un agente se abren en el mismo lugar, debajo de su respuesta, en vivo mientras trabaja, sin salir del chat. Los mismos chats están en Orquesta Terminal: su botón Operator los abre a pantalla completa sobre tus paneles, de modo que puedes descargar Terminal, iniciar sesión y conversar con el agente de cualquier proyecto sin abrir el dashboard. Home está disponible en inglés, español y portugués. La pestaña Settings → Integrations de un proyecto agrupa todo aquello a lo que está conectado — Code (GitHub, con el repositorio vinculado y el ciclo de retroalimentación de PR), Ship (Vercel, Supabase), Work intake (Linear, Slack, Telegram) y Talent (Derplins) — cada uno con su estado, a qué está vinculado y un botón para desconectar; las skills y las configuraciones personalizadas están en Advanced. El antiguo asistente de configuración fue retirado: los enlaces con ?setup=true llevan a esa pestaña, o a la vista de VM para el hosting.

Máquina Orquesta gratuita. Las cuentas que inician sesión con Google pueden obtener una máquina en la nube gratuita, desde Home o al crear un proyecto, con el agente y orquesta-cli preinstalados y el proyecto configurado para ejecutarse en Batuta. Se suspende tras 48 horas sin prompts y se reactiva automáticamente cuando envías uno; el prompt espera en la cola mientras arranca. Las máquinas adicionales son de pago, desde la pestaña Agent del proyecto.

Prompts y ejecución

La pestaña Prompts es donde envías trabajo al agente de IA. Cada prompt puede incluir:

• Contenido — Descripción en lenguaje natural de lo que se debe construir
• Etiquetas — Categoriza como bug, feature, refactor, urgent, docs
• Asignación — Asígnalo a un miembro específico del equipo
• Prioridad — Marca con una estrella los prompts importantes
• Especificaciones estructuradas — Usa plantillas de reporte de bug, especificación de feature o mejora con criterios de aceptación

Los prompts pueden provenir de múltiples fuentes:

Gestión

La sección de Gestión incluye:

• Tickets — Da seguimiento a elementos de trabajo de la integración con Linear o creados manualmente
• Requisitos — Define y da seguimiento a los requisitos del proyecto con análisis asistido por IA
• QA — Instrucciones de control de calidad y seguimiento de pruebas
• Planificación — Crea planes con elementos, hitos y desgloses generados por IA

Señales sonoras

El dashboard reproduce breves señales sintetizadas para los resultados — una ejecución que termina o falla, un agente que se conecta o se cae, y cualquier cosa que esté esperando tu respuesta. La interfaz es silenciosa: abrir un modal, activar un interruptor o cambiar de pestaña nunca emite un sonido. Las señales del agente y del chat solo suenan mientras la pestaña está en segundo plano.

Desactívalas, ajusta el volumen o escucha cada señal en Profile → Sound. La preferencia se guarda por dispositivo, y todo el conjunto se silencia automáticamente si tu sistema solicita reducir el movimiento.

Logs e historial

La transmisión de logs en tiempo real muestra cada paso de la ejecución del agente — comandos ejecutados, archivos modificados, operaciones de git y más. Los logs se clasifican por nivel (info, warning, error) y tipo (command, output, status, git). La página History muestra una línea de tiempo cronológica de toda la actividad del proyecto.

Actividad en vivo

La pestaña Activity del panel lateral — el primer ícono del panel plegable junto a la terminal y junto a la línea de tiempo de prompts — muestra en lenguaje sencillo lo que el agente está haciendo ahora mismo: “Edited public-queries.ts”, “Running the test suite”. El paso actual queda fijado en la parte superior; debajo está cada paso hasta ahora con las líneas agregadas y eliminadas en cada archivo, y un resumen de archivos modificadosal final.

Sigue una sesión interactiva en vivo a partir del flujo de la sesión, por lo que funciona con todas las CLI, incluida orquesta-cli, y en la pestaña Prompts sigue el prompt en ejecución. Es el mismo flujo que la pestaña Logs, leído para quienes no quieren leer la salida de las herramientas: las lecturas repetidas de archivos se colapsan en una sola línea, los pasos de gestión interna se ocultan y un paso fallido muestra el error en lugar de la carga útil en bruto. No se registra nada nuevo para producirlo.

Cada paso también lleva una etiqueta de área de color que indica qué cambia en lugar de qué archivo tocó — Database, API, Interface,Dependencies, Deploy / CI, Config, Tests, Docs, o unaDestructive roja para eliminaciones, drops y hard resets. Una franja de resumen en la parte superior del panel las suma, de modo que “esta ejecución tocó la base de datos tres veces” se entiende sin abrir un solo archivo. Los pasos que solo leen algo no llevan etiqueta, porque leer no cambia nada.

Artifacts — archivos que hizo el agente

Cuando una ejecución produce algo que vale la pena abrir — un reporte HTML, un gráfico, un PDF, un CSV, un sitio compilado — el agente puede publicarlo: orquesta-cli tiene la herramienta publish_artifact, y cualquier CLI puede simplemente escribir el archivo en .orquesta/artifacts/. Al terminar el prompt, el agente (≥ 0.2.273) sube esos archivos y aparecen primero en la tarjeta Artifacts del Operator con un enlace de descarga, guardados 30 días (máx. 25 MB por archivo, 50 archivos / 100 MB por prompt; nunca se envían .env ni archivos con pinta de llave). En la microVM bajo demanda está siempre activo, porque su disco muere con la sesión. En tus propias máquinas es opcional: Configuración → Agente → Artifacts.

Cada artefacto, y cada archivo del panel Context files de una sesión interactiva, tiene dos botones: Abrir lo muestra en una pestaña nueva (HTML, imágenes, PDF y texto se ven en vez de descargarse; el resto se descarga) y Compartir copia un enlace público getorquesta.com/share/… que cualquiera puede abrir sin cuenta. El renderizado ocurre en un origen de almacenamiento separado, nunca en getorquesta.com, así que una página hecha por IA no puede tocar tu sesión. El enlace se revoca desde la misma fila y el de un artefacto deja de funcionar cuando el artefacto expira.

Claude Code no tiene herramienta de publicación, así que cuando responde con un bloque <antArtifact> (una página HTML, un SVG, un documento Markdown) el bloque se guarda como artefacto de ese prompt unos segundos después de terminar — sin configurar nada. Los proyectos nuevos empiezan con un paso Uso en la tarjeta de configuración (chat, sesión interactiva, prompts sueltos, embed o hook) que decide dónde abre el proyecto; su paso de hosting incluye la microVM de Orquesta, con las primeras 10 ejecuciones por organización gratis (luego $0.25/h).

Tareas en el panel lateral

La pestaña Tasks del panel es un único feed de todo lo que está esperando trabajo en este proyecto — tickets locales, elementos de planes, issues de Linear, prompts programados y prompts asignados a ti — cada uno etiquetado con su origen y filtrable por fuente.

Run hace lo que significa ejecutar en la pantalla en la que estás. En una sesión interactiva envía la tarea a la terminal en vivo de inmediato. En la pestaña Prompts la despacha al agente: una tarea que ya es una fila de prompt — un ticket local, un prompt asignado a ti — se ejecuta en el mismo lugar, de modo que la ejecución queda asociada a ella y el ticket se cierra solo cuando termina; cualquier otra cosa se convierte en un nuevo prompt. Junto a él, Start carga la tarea en el cuadro de prompt para revisarla en lugar de enviarla, y Prompt primero convierte la historia en un prompt de implementación concreto.

Memoria y contexto

El panel Memory almacena contexto persistente del proyecto que se incluye en cada ejecución de prompt. Esto incluye decisiones de arquitectura, convenciones de código, problemas conocidos y conocimiento específico del proyecto. La memoria se resume automáticamente y se inyecta en el contexto de Claude CLI.

Contexto automático

Los prompts cortos como "sí", "despliega" o "hazlo" reciben automáticamente contexto de las últimas tareas completadas. No necesitas activar Include Context — el agente siempre sabe lo que ocurrió antes. Para prompts más largos, usa el interruptor Include Context para un control explícito.

El agente también puede obtener contexto detallado durante la ejecución si necesita más información:

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

Auto Agent

El Auto Agent analiza tu proyecto — planes, trabajo reciente, memoria, tickets abiertos — y decide qué construir a continuación. Funciona en dos modos, ambos desde la pestaña Auto Agent del proyecto.

Modo en segundo plano (proponer y aprobar). Activa el interruptor y elige una programación. En cada ciclo el agente escribe propuestas — título, por qué importa, el prompt exacto a ejecutar y una calificación de riesgo — en una bandeja de entrada. No escribe código ni ejecuta nada. Revisas la bandeja una vez al día, editas cualquier prompt si quieres y apruebas los que valga la pena hacer; solo entonces el agente trabaja. Las propuestas rechazadas se recuerdan, así que deja de sugerir lo mismo.

Los ciclos son baratos porque la mayoría nunca se ejecuta: un ciclo se omite cuando tu agente local está desconectado, cuando la bandeja ya tiene propuestas esperando (vaciarla es tu tarea — acumular más es solo ruido) y cuando nada ha cambiado desde el último ciclo (mismo commit, sin prompts nuevos). Las tres cosas se deciden con lecturas de la base de datos, por lo que un nominal "cada 6 horas" en un proyecto inactivo no cuesta ningún token.

Run now (en primer plano). El ciclo original, bajo "Run now": el agente elige tareas y las ejecuta de inmediato mientras tú observas, hasta el límite de iteraciones que definas. El ciclo se ejecuta en el servidor, así que sobrevive a cambios de pestaña, congelamientos del navegador y despliegues.

Autonomía (ejecutar sin hacer clic). En Settings, "Run approved work automatically" permite que las propuestas dentro de los límites que definas se ejecuten sin que nadie haga clic en Approve. Está desactivado por defecto y no se activará sin un comando de verificación — el comando que prueba que tu proyecto sigue funcionando (npm test, pytest -q, make check). Un trabajo que nadie revisa y nada verifica no es automatización, así que Orquesta se niega a hacerlo.

Cada ejecución autónoma trabaja en su propia rama auto/… a partir de tu commit actual, hace la tarea y luego ejecuta tu comando de verificación. Con código de salida 0 se resuelve según indica el flujo de git de tu proyecto — fast-forward y push, o abrir un pull request y dejar intacta la rama base. Con cualquier otro código de salida revierte la rama, devuelve el repositorio al commit del que partió y regresa la propuesta a la bandeja con las últimas 100 líneas del fallo adjuntas. Nunca reintenta: un intento de máquina por propuesta, y luego decide una persona.

Cuatro límites lo acotan. Un techo de riesgo y un techo de tamaño — lo que los supere sigue esperándote, y una propuesta que nunca indicó su riesgo se trata como medio, por lo que queda bloqueada con el valor por defecto. Dos presupuestos móviles de 24 horas, un número de tareas y una cifra en dólares, el que se agote primero (los planes de modelo de tarifa fija realmente no cuestan nada por ejecución y reportan $0, así que ahí lo que limita es el número de tareas). Y un cortacircuitos que pausa el proyecto tras N fallos consecutivos y no le manda a nadie un correo sorpresa — la pestaña explica el motivo y lo reanudas desde ahí.

Cada ejecución desatendida aparece en "Autonomous runs" con su rama, el commit del que partió, el código de salida de la verificación, si el árbol se restauró y la salida del fallo. Una ejecución que falló y no pudo revertirse se destaca en rojo — es el único caso en el que vale la pena revisar la máquina.

Workstreams (varias preguntas permanentes, un proyecto). Un proyecto rara vez tiene un único propósito. "Clasificar los bugs", "leer el feedback de los clientes y decidir qué construir" y "revisar el marketing y la acción comercial" son tres preguntas distintas, y plantearlas como una sola colapsa en la que el modelo encuentre más legible. Crea workstreams en el panel Workstreams del proyecto y la pestaña Auto Agent incorpora un selector: cada stream tiene su propia programación, su propia bandeja, sus propios límites y su propio presupuesto de 24 horas, y a cada cerebro se le dice para qué sirve su stream y se le pide que no proponga nada antes que meterse en el de otro.

Un workstream puede apuntar a un directorio, pero no es obligatorio. El stream es lo que define el trabajo; el directorio solo decide si dos streams pueden ejecutarse al mismo tiempo. Los streams en directorios distintos se ejecutan en paralelo. Los streams que comparten un directorio — y cualquier stream en un proyecto que es una sola carpeta — se turnan, porque dos ramas autónomas en un mismo árbol de trabajo son una carrera que nadie gana. Un stream apuntado a la raíz del proyecto es exclusivo frente a todos los demás, ya que los contiene.

Ese directorio puede estar por debajo de la raíz del repositorio — un stream que posee repo/server aun así puede crear ramas, hacer commits y revertir. Con aislamiento del sistema de archivos, el sandbox solo permite escribir en el directorio de trabajo, así que el agente también abre el directorio git del repositorio que lo contiene (y, en el caso de un worktree, el repositorio principal en el que escribe objetos). Sin esto, un stream así podría editar código y nunca crear una rama, y el error parecería un disco que falla en lugar de un ajuste.

Cada stream tiene un tipo, porque no toda pregunta termina en un commit. Un stream Code modifica el repositorio: trabaja en su propia rama, debe pasar un comando de verificación y se revierte si no lo hace. Un stream Analysis lee y reporta — feedback de clientes, logs de errores, el estado del mercado — y no necesita comando de verificación, porque no hay nada que deshacer. Un stream Action hace algo fuera del repositorio, como enviar un correo o crear un ticket, y nunca se ejecuta sin supervisión: siempre espera a una persona, sin importar la configuración de autonomía. Cambiar un stream a Action desactiva también su autonomía.

La vista de enjambre. Cuando un proyecto tiene dos o más workstreams, la pestaña Auto Agent los dibuja como un grafo: el agente raíz arriba, un nodo por stream debajo, con el tipo, el directorio, la bandeja y el conteo de 24 horas en cada uno. Una arista verde significa que ese stream se está ejecutando ahora mismo; una ámbar significa que está armado y detenido porque otra ejecución ocupa su directorio — la regla de cola descrita arriba, mostrada en lugar de explicada. Puedes fijar la vista en cualquiera de los dos sentidos desde los ajustes del proyecto o al crearlo, para un proyecto que será un enjambre antes de que exista su primer stream.

Haz clic en un nodo y un panel a la derecha muestra qué es ese stream, qué hizo por última vez y sus ejecuciones recientes; renómbralo desde ahí haciendo clic en su nombre. Arrastra las tarjetas para ordenar el grafo como realmente ves el proyecto en tu cabeza — la disposición se recuerda en tu navegador, por proyecto, y es solo tuya: mover una tarjeta no la mueve para nadie más. El control de restablecer lo devuelve todo a su lugar.

Tu valor predeterminado de terminal. El mismo panel tiene Use as my terminal default: las sesiones interactivas de ese proyecto se abren entonces con ese workstream ya seleccionado (también se puede configurar con la estrella junto a Run in en la terminal). Es una preferencia tuya, guardada en tu navegador, que el resto del equipo no hereda. El encabezado de la terminal siempre nombra el workstream en el que estás (recargar la página lo conserva), y una sesión iniciada en un workstream se abre con la descripción de ese workstream cargada como su misión, de modo que el agente parte de ella en lugar de preguntar qué hacer (agente 0.2.265 o posterior).

Unirte a una sesión en curso conserva su pasado. Cuando te unes a una sesión que ya está activa, o recargas la página mientras una se ejecuta, la conversación hasta ese momento se carga en el scrollback de la terminal (y en el panel History) antes de dibujar la pantalla en vivo, de modo que al desplazarte hacia arriba ves los turnos anteriores y no solo la última pantalla. Solo sesiones de Claude, agente 0.2.266 o posterior.

Bajo el grafo, Lo que ha hecho el enjambre fusiona todos los streams en una sola cronología de los últimos catorce días — propuestas y ejecuciones intercaladas, porque una propuesta y la ejecución que surgió de ella son una sola historia — con los totales de la ventana: ejecuciones, verificadas, revertidas y rollback fallido contado aparte del resto, ya que este último significa que quedó una rama olvidada en la máquina. Haz clic en cualquier fila para saltar al stream del que proviene.

Un correo de resumen diario lista lo que está esperando revisión, y solo se envía cuando llegó algo nuevo — una propuesta ignorada nunca se convierte en una molestia diaria.

Meet — una videollamada con el agente

Meet, en el menú Agent del proyecto, es una videollamada con tu agente a un clic. Pulsa "Start meet": el dashboard abre una llamada en meet.apuchat.com dentro de la misma página y envía al agente a unirse. Habla en voz alta — tu voz se transcribe en tu navegador y llega al agente como texto; sus respuestas se dicen en voz alta y también aparecen en la transcripción junto a la llamada, así que nada de lo dicho se pierde cuando termina la llamada.

Cada proyecto tiene su propia sala de meet persistente, separada del chat del equipo y de los canales de coordinación, de modo que el agente solo se despierta para una llamada que tú iniciaste. "Invite" muestra un enlace protegido y una contraseña para incorporar a otra persona; "Open in a new tab" ejecuta la misma llamada fuera del dashboard si tu navegador bloquea el micrófono en una página incrustada. El agente debe estar en línea para responder.

Meets anteriores. Cada meet realizado desde el dashboard se registra como texto — quién dijo qué y cuándo — y se lista bajo la tarjeta "Start meet" con su fecha, duración y número de líneas; ábrelo para leer la transcripción completa. El registro es solo la transcripción (no se almacena audio ni video), y lo escribe la pestaña del dashboard que está en la llamada, así que un meet al que solo se entró desde una pestaña de navegador normal no se conserva.

En el móvil. Meet también está en la app de Orquesta: abre un proyecto, toca "Meet with the agent" y la llamada se ejecuta dentro de la app de la misma manera, con la transcripción en vivo y tus meets anteriores. Si el agente ejecuta el despacho pero no permanece en la sala, la vista de la llamada dice "agent didn't join" en lugar de esperar en silencio — algunos proyectos rechazan una llamada por sus propias reglas, y eso se muestra con honestidad.

Cómo responde el agente. Cada cosa que dices la responde un modelo rápido del lado de Orquesta que lee lo que Orquesta ya sabe del proyecto — sus notas, prompts recientes y sus resultados — por lo que las preguntas se responden en uno o dos segundos sin tocar tu máquina. Cuando pides trabajo real (mirar el código, ejecutar las pruebas, revisar un log, cambiar algo), dice "un momento" y entrega un prompt normal al agente del proyecto; mientras eso se ejecuta escuchas una breve actualización cada treinta segundos, y el resultado se lee en voz alta cuando llega. El agente permanece en la llamada mientras hablas o mientras hay trabajo en curso, y se va tras unos tres minutos de silencio (30 minutos como máximo). Si vuelves a hablar, lo vuelve a despertar.

Hey Orquesta — voz manos libres en todos tus proyectos

Hey Orquesta (en la barra lateral) es un compañero de voz que se sitúa por encima de todos los proyectos a los que tienes acceso — para cuando caminas o conduces y no puedes leer una pantalla. Activa el modo manos libres y escucha, responde en voz alta y vuelve a escuchar.

• "¿Cómo va ehive-dev?" — se lee desde Orquesta: si el agente está en línea, qué se está ejecutando y sus últimas líneas de log, y qué terminó recientemente. No se despierta ningún agente para esto.
• "Dile al agente de ehive-dev que ejecute las pruebas" — se convierte en un prompt normal en ese proyecto, atribuido a ti, y el agente se despierta de inmediato. Requiere permiso para ejecutar prompts en el proyecto.
• "Envíame un correo cuando ehive-dev termine" — Orquesta te envía un correo cuando el trabajo en curso (o la tarea que acabas de pedir) se completa o falla, con un breve resumen del resultado.

El reconocimiento de voz y la voz se ejecutan en tu navegador (Chrome, Edge o Safari). Los proyectos se identifican por nombre, así que basta con uno suficientemente parecido; si dos proyectos coinciden, pregunta cuál. El mismo endpoint, POST /api/companion/turn, acepta una sesión del dashboard o un token de CLI oclt_, que es lo que usa la app móvil.

Hey Orquesta está incluido en los planes Pro y Max — lo tienes cuando cualquier organización a la que perteneces tiene uno. En otros planes la pantalla muestra una tarjeta de mejora de plan y el endpoint responde 402.

Las respuestas se dicen con la voz de Grok (con la voz del navegador como alternativa) y toman el idioma del interruptor ES/EN de la pantalla. Cada conversación se conserva: el botón de historial lista las anteriores y, dentro de una, muestra lo que hizo cada agente con el trabajo que le encargaste (estado en vivo y resultado). Cuando preguntas cómo le fue a ese trabajo, el compañero lee el resultado actual en lugar de adivinar. El orbe del encabezado de la página lo abre desde cualquier lugar. En el modo manos libres el micrófono permanece abierto mientras habla, así que puedes interrumpirlo con una nueva solicitud en cualquier momento; mientras piensa dice un breve "un momento" en lugar de quedarse en silencio.

Colaboración en equipo

Orquesta admite cuatro roles con permisos granulares:

Chat del proyecto

Cada proyecto tiene un chat integrado en tiempo real con tecnología de Supabase Realtime. Incluye conversaciones en hilos, archivos adjuntos, confirmaciones de lectura e indicadores de escritura. El chat es ideal para discutir prompts, revisar resultados y coordinar el trabajo.

Pregunta al agente del proyecto. Escribe @agent en el chat de un proyecto y responderá a partir del historial de ese mismo proyecto: qué se ejecutó por última vez, cómo le fue y qué sigue pendiente. Solo informa; nunca ejecuta nada, y solo conoce el proyecto en el que vive. El identificador es propio de cada proyecto: ponle nombre en Configuración → Agente → Identificador del chat (p. ej. @elclaudio) y responde dentro del hilo donde preguntaste. Las respuestas vienen del servidor, así que funcionan incluso cuando la máquina del agente está desconectada.

Convierte un mensaje en una tarea. Pasa el cursor sobre cualquier mensaje del chat y pulsa el ícono de tarea para abrirlo como un elemento del plan: el título y la descripción se rellenan con el mensaje, y tú eliges el plan y la persona asignada. La tarea conserva una insignia Desde el chat para que puedas distinguir lo que surgió en la conversación.

Inicia una reunión. El botón Meet del encabezado del chat abre la sala de video del proyecto y publica una tarjeta para unirse en la conversación, de modo que cualquiera que la lea pueda entrar con un clic. El video y el audio van de navegador a navegador: la sala solo transporta la señalización y nada de lo que se diga en ella se graba. Cada persona recibe su propio enlace al pulsar Unirse, por eso la tarjeta es un botón y no una URL para pegar.

Agentes que consultan a agentes

El agente de un proyecto puede preguntarle al de otro. Dentro de una organización, un agente lista a sus pares con GET /api/agent/directory y envía una solicitud con POST /api/agent/requests: una consulta (pregunta, corre en solo lectura del otro lado y se aprueba sola) o un encargo (orden de trabajo, espera que una persona la apruebe en la pestaña Callable del proyecto). La solicitud es un prompt normal en el proyecto destino, así que queda en su historial; al terminar, la respuesta vuelve al proyecto que preguntó como un prompt de seguimiento, o este consulta GET /api/agent/requests/{id}, que además entrega enlaces de descarga de los archivos que produjo el destino (hasta 256 MB cada uno). Las cadenas se limitan a dos saltos, los ciclos se rechazan y cada proyecto tiene un tope diario. Solo aparecen y pueden preguntarse entre sí los proyectos con coordinación habilitada (settings.coordination.enabled); una solicitud acepta un timeout_min opcional (30 por defecto para una consulta, 240 para un encargo, máximo 720) tras el cual se cancela, y el token de un agente puede quedar atado a IPs de origen.

Handles permanentes y DMs al dueño. Cada agente de proyecto puede tener un handle permanente @<proyecto>-agent que no expira, con el dueño en su lista de permitidos. Un agente bloqueado en una decisión le escribe a una persona permitida con POST /api/agent/dm; la respuesta, durante hasta 24 horas, se convierte en un prompt que le muestra al agente su propia pregunta y la tarea que la originó.

Identidad del agente

Configuración → Identidad del agente es el único lugar que responde “quién es este agente y cómo lo contacto”. Antes, cada dirección en la que responde el agente vivía en una pantalla distinta — el identificador del chat en Configuración, el @handle de Apuchat en Coordinación, el correo en el panel de Bandeja de entrada — así que nadie podía ver la identidad completa de una vez. Esta pestaña reúne todo. La identidad es por proyecto, y la pestaña es solo para propietarios y administradores.

Dale al agente su propio correo. De forma predeterminada, el correo de un agente es un buzón desechable de apumail, lo cual sirve para darle una dirección a un agente externo para un solo intercambio y no sirve para nada que quieras seguir recibiendo — apumail lo libera tras 24 h de inactividad. Define aquí una dirección (cualquier buzón que sirva apumail, más su token de bandeja) y esa pasa a ser el correo del agente; el buzón desechable se queda donde está y deja de ser la respuesta. El token se verifica contra apumail antes de guardarse, se almacena cifrado y no se vuelve a mostrar — un token que solo se guarda falla más tarde como un buzón que parece vacío en lugar de roto.

La dirección configurada es la que usa el producto. Una vez definido un correo de identidad, el panel Bandeja de entrada de una sesión interactiva lee ese buzón en lugar del desechable y retira sus propios botones Reemplazar/Liberar: producirían una dirección en la que el agente no responde. El buzón de identidad se elimina aquí, donde se definió.

Un solo indicativo de Apuchat, no dos. El @handle al que llama la gente ahora es también el indicativo que presenta el agente cuando se une a canales de coordinación y videollamadas, de modo que quien llamó a @your-agent se encuentra con @your-agenten la sala y no con un nombre generado por una máquina. Si el handle deja de funcionar, el agente recurre a un indicativo temporal y sigue uniéndose, y tú reparas el publicado desde esta pestaña: Renovar lo revive en el mismo lugar, y solo un handle que Apuchat realmente eliminó se reemplaza — la pestaña lo indica de forma explícita cuando cambia la dirección, porque quien tenga la anterior debe ser avisado.

La tarjeta de handle para llamadas y mensajes directos es la misma en todos los lugares donde aparece. Tiene su propia entrada en el menú Agente de la barra del proyecto, que es adonde ir cuando la tarea es gestionar a quienes llaman y no leer un canal; sigue apareciendo en Coordinación, donde siempre ha vivido; es una sección de Configuración → Agentes, junto a la máquina a la que llama; y está integrada en la fila de Apuchat de Identidad del agente, de modo que quien llegó a preguntar cómo contactar al agente no tenga que ir a otra pestaña para actuar sobre la respuesta. Un solo componente montado cuatro veces, nunca cuatro copias, así que no pueden desincronizarse. Un handle gratuito caduca a las 24 h y se renueva desde cualquiera de ellos. Si prefieres que nunca caduque, compra uno en apuchat.com/account (5 USDC) y adjúntalo aquí con su clave de identidad: la clave se comprueba contra Apuchat antes de guardarse, así que un pegado incorrecto falla de inmediato en lugar de presentarse como un handle que nunca suena sin avisar. Un handle adjunto recibe notificaciones push como uno gratuito: Orquesta registra un webhook en él con su propia clave de identidad, de modo que una llamada llega al agente en aproximadamente un segundo. Rotar la clave en apuchat.com retira ese webhook; entonces el cron de sondeo atiende el handle hasta que adjuntes la nueva clave.

Un mensaje al handle es un prompt, y la respuesta vuelve como una respuesta. El handle nació como un timbre: analizaba una invitación de llamada y llevaba al agente a una videollamada, y un mensaje simple que no era una invitación se leía, se consideraba poco interesante y se descartaba — con todo y cursor, de modo que después era invisible. Desde fuera eso es indistinguible de un agente que te ignora. Ahora todo lo que se escribe a @your-agent pasa por el mismo filtro de quien llama que una llamada, se convierte en un prompt en tu propia máquina con los permisos de quien llama adjuntos, y su respuesta se devuelve al remitente como un mensaje de chat. La sección Mensajesde la tarjeta es la conversación: hilos por quien llama, las respuestas del agente marcadas como propias, un cuadro para responder a mano como el handle, y los mensajes que fueron rechazados se muestran en su lugar con el mismo botón de un clic permitir hablar — un rechazo que puedes ver vale más que un silencio que no puedes ver. Las respuestas tienen un límite de longitud y las largas apuntan al panel; una misma persona puede tener como máximo tres mensajes en proceso a la vez, de modo que un handle desatendido no pueda encolar trabajo ilimitado en la máquina de alguien. Dos reglas de unicidad de la base de datos hacen el resto: un registro por mensaje entrante, para que el webhook y el sondeo por minuto no actúen ambos sobre él, y una respuesta por prompt, para que el hook de finalización y el cron de respaldo no respondan ambos.

Quién puede llamar. El handle es público, y una llamada ejecuta un prompt en tu propia máquina — por eso la firma que envía Apuchat demuestra que el mensaje fue entregado, nunca quién llamó. Por lo tanto, un handle nuevo se crea restringido: es una lista de permitidos, y tú nombras los @handles de quienes pueden pasar y marcas, por cada uno, qué pueden pedir — talk, read code, run commands, deploy / spend. Se puede permitir a un tercero hablar sin permitirle ejecutar nada, y nada de lo dicho durante la llamada amplía esa lista. Para alguien cuyo handle no puedes conocer de antemano, genera un código de acceso compartido — nosotros lo generamos, tú nunca lo eliges, y se muestra una sola vez al generarlo porque solo guardamos una copia cifrada. La persona escribe passcode: the-code en el mensaje de la llamada y obtiene los permisos que le diste al código de acceso.

Abierto a cualquiera es la otra opción, y es deliberada: elegirla muestra una advertencia y limita a cada desconocido al permiso más reducido que existe, talk únicamente, sin forma de ampliarlo. Un permiso amplio entregado a “cualquiera” es exactamente lo que esa opción no puede llegar a significar, por eso los selectores de permisos están bloqueados y no solo con un valor predeterminado. Los handles que existían antes de los permisos por quien llama se leen como abiertos, y el mismo límite se les aplica ahora. Toda llamada queda registrada en ambos casos, así que quien fue rechazado aparece con un atajo de permitir hablar en lugar de desaparecer en un registro del servidor.

La @mention del chat y la lista de canales siguen siendo de solo lectura aquí y apuntan a la pantalla que es dueña de cada una — un segundo control para el mismo campo es un segundo control que puede contradecir al primero.

Comentarios en prompts

Cada prompt tiene un hilo de comentarios para la discusión de revisión de código. Puedes mencionar a miembros del equipo con @menciones, dar comentarios sobre el código generado por IA y discutir los cambios antes de fusionarlos.

Planificación y especificaciones

El sistema de Planificación te permite crear planes estructurados con elementos que se pueden convertir en prompts o tickets. La IA puede generar desgloses de planes a partir de descripciones de alto nivel. Las especificaciones estructuradas (reportes de errores, solicitudes de funciones, mejoras) incluyen criterios de aceptación que guían a la IA durante la ejecución.

Ejecutar un elemento. Pulsa ▶ en cualquier elemento del plan para enviarlo al agente como un prompt. El elemento muestra entonces el estado en vivo de ese prompt y enlaza directamente a él, de modo que un plan registra su propia ejecución en lugar de solo describirla. Un elemento que ya se está ejecutando no se puede despachar dos veces; cuando el prompt termina, ▶ lo vuelve a ejecutar, útil cuando una ejecución falló.

Vista de tablero. Tanto Planificación como Tickets tienen un selector de lista/tablero en su encabezado. Los planes se organizan por estado del elemento; los Tickets, por los estados reales del flujo de trabajo de Linear de tu equipo: las columnas son las que tu equipo haya configurado, en el orden y los colores propios de Linear. Arrastrar un ticket entre columnas escribe el estado de vuelta en Linear, y la tarjeta se revierte si Linear rechaza el movimiento. El tablero siempre muestra todos los tickets, así que las pestañas de estado se apartan mientras está abierto.

Editar un ticket local. Los tickets creados en Orquesta se pueden editar, asignar y archivar después; el caso para el que sirve esto es una pasada de QA que registra un ticket y luego descubre a mitad de sesión que el título era incorrecto, el tipo era incorrecto o que necesita más detalle. ✎ abre el título, el tipo y el cuerpo en markdown del ticket, que es exactamente lo que recibe el agente cuando lo ejecutas. Asignarlo entrega a cualquier miembro del proyecto. Archivar lo saca de la lista de tickets y de la línea de tiempo sin eliminar nada: sus registros, comentarios y costo permanecen intactos, y Archivados en el encabezado vuelve a mostrar los tickets archivados para restaurarlos. Un ticket que el agente está ejecutando en ese momento solo se puede reasignar; editar y archivar esperan a que termine la ejecución.

Tickets locales, con o sin Linear. Un proyecto conectado también registra tickets locales — el widget de comentarios los escribe ahí — por lo que el encabezado de Tickets incluye un selector Linear / Local. Las dos listas se mantienen separadas a propósito: solo las incidencias de Linear se pueden arrastrar entre los estados del flujo de trabajo de tu equipo, y una lista combinada ofrecería acciones que funcionan en la mitad de las filas.

Tablero local, sprints e hitos. Los tickets locales tienen su propio tablero — Backlog, Por hacer, En curso, En revisión, Hecho — y no necesita Linear en absoluto. Una tarjeta lleva dos estados separados: la ejecución (borrador → pendiente → en ejecución → hecho) y la columna a la que alguien la arrastró. Una tarjeta que nadie ha tocado toma su columna de la ejecución, así que un ticket que el agente termina pasa a Hecho por sí solo; una vez que la arrastras, tu columna manda y la siguiente ejecución no la devolverá. Agrupa tickets bajo un sprint o un hito (es lo mismo: un sprint es simplemente uno con fechas) y el chip sobre la lista muestra hechos/total y los días restantes, en rojo una vez pasada su fecha de fin con trabajo aún abierto.

Ejecutar tickets. Marca las casillas de uno a diez tickets locales y la barra ofrece dos formas de ejecutarlos. Un solo ticket se ejecuta como sí mismo: su propio cuerpo es el prompt, y la ejecución, sus registros y su resultado quedan asociados a ese ticket, lo que permite que el ticket se cierre solo cuando termina la ejecución. Ejecutar juntos compone un solo prompt — primero la lista numerada para que el agente pueda planificar sobre todo el conjunto, luego el cuerpo de cada ticket bajo su propio encabezado — lo despacha al agente y mueve esas tarjetas a En curso. Enviar a la sesión construye el mismo prompt pero lo entrega a la terminal interactiva, donde espera en un banner a que lo revises antes de enviar nada. Ninguna de las dos ejecuta un ticket que ya se está ejecutando.

Detalle del ticket. Al hacer clic en el título de un ticket local, en la lista o en el tablero, se abre. La columna izquierda es el ticket tal como lo ve el agente: el cuerpo en markdown, el resultado o error de la ejecución y el hilo de comentarios. La columna derecha es todo lo que no es el texto: estado, responsable y sprint se editan en el mismo lugar, y debajo aparecen quién lo creó y cuándo, cuándo se tocó por última vez, sus etiquetas y de dónde vino. Cuando el ticket se ha ejecutado, el bloque de ejecución indica el motor y el modelo, la rama y el commit en el que aterrizó, y lo que costó. Ejecutar, Enviar a la sesión, Editar y Archivar están en el pie, así que el panel basta por sí solo: no tienes que volver a la lista para actuar sobre él.

Un ticket se cierra solo. Cuando una ejecución llega a en ejecución, el ticket pasa a En curso, y cuando se completa pasa a Hecho, incluso desde En revisión, ya que una ejecución terminada es avance. Lo que nunca hará es deshacer lo que hizo una persona: una tarjeta que ya está en Hecho o Cancelado nunca se reabre, una tarjeta aparcada en En revisión no se arrastra de vuelta mientras se ejecuta, y una ejecución fallida no escribe nada en absoluto, de modo que un reintento parte desde donde lo dejaste.

Fechas del sprint. Un sprint nuevo empieza hoy y termina una semana después, con atajos de 1 sem / 2 sem / 1 mes y un conteo de días a su lado, de modo que el caso común es un solo clic. La fecha de fin no puede ser anterior al inicio: Crear permanece deshabilitado mientras el rango esté invertido, en lugar de guardar un sprint que ya terminó.

Modo asistido: QA envía un documento, tú revisas un diff

El Modo asistido es para el momento en que un compañero de QA termina una pasada y tiene una página de hallazgos. Pega el documento completo en Asistido en la página del proyecto. Orquesta lo lee como un solo documento — los hallazgos se deduplican y se ordenan entre sí, no se tratan un prompt a la vez — y clasifica cada hallazgo en uno de cuatro veredictos.

La línea que traza es defecto evidente vs. decisión de producto, nunca la dificultad. "El botón Guardar no hace nada" contradice su propia etiqueta, así que se ejecuta sin supervisión aunque la corrección sea difícil. "Deberíamos enviar un correo al cliente cuando termine una ejecución" es un comportamiento nuevo que nadie acordó, así que espera a una persona, aunque sea trivial de construir.

Ejecutar primero, revisar después. Esta es la diferencia con la autoevaluación, que bloquea un prompt antes de que se ejecute. Aquí el revisor abre un diff que ya existe: archivos reales, conteos de líneas reales, un commit real. Aprobar una intención y aprobar un cambio no son la misma revisión, y solo una de ellas se puede hacer correctamente.

Una ejecución, una rama, un PR. Todos los elementos de una ejecución comparten una rama assisted/YYYYMMDD-xxxxxxxx y se ejecutan estrictamente de uno en uno. El despliegue automático se rechaza para toda la ejecución, desde el servidor: una rama asistida nunca llega a producción por sí sola, sin importar la configuración de despliegue del proyecto.

La compuerta del diff. Cada diff que produce el agente se inspecciona antes de que empiece el siguiente elemento. Migraciones, archivos con forma de credenciales, eliminaciones, un cambio desmesurado o una corrección declarada que no cambió nada detienen la ejecución: el elemento N+1 nunca se apila sobre un diff que nadie ha leído. Los cambios en dependencias, CI, autenticación y binarios se marcan para el revisor sin detener la cola. Cada marca se muestra en la tarjeta con el motivo por el que se activó.

Quién hace qué. Cualquier miembro del proyecto puede iniciar una ejecución: QA tiene autoridad para dispararla, y ese es el punto. Revisar es aparte: corresponde a los propietarios y administradores del proyecto, además de quien tenga la marca Revisor asistido en Equipo → permisos de miembros. Los revisores reciben una notificación por ejecución y son los únicos que pueden aprobar, rechazar o poner en cola un hallazgo escalado. La procedencia se registra a partir de la sesión, no del cuerpo de la solicitud.

“Yo me encargo”: tomar un elemento tú mismo. Un hallazgo que necesita una decisión de producto suele resolverse más rápido en una terminal que describiéndolo. Cada tarjeta en Necesita tu decisión tiene un botón Yo me encargo: toma el elemento, abre una sesión interactiva ya en la rama de la ejecución y te lo indica en el encabezado de la sesión. La regla serial también aplica a las personas: mientras tienes un elemento, el agente no despacha nada, así que tus ediciones y las suyas nunca caen en el mismo diff. Cuando terminas la sesión, tu trabajo se confirma, se sube y se reporta, y el elemento llega a revisión con un resumen de diff real y las mismas marcas de la compuerta que recibiría uno producido por el agente. ¿Cambiaste de opinión? Liberar lo devuelve a Necesita tu decisión y libera la cola.

Endpoints de la API asistida:

Orquestador de IA Batuta

Batuta es el cerebro de IA de Orquesta: un orquestador inteligente que analiza tareas y las dirige al mejor método de ejecución. Disponible en el nivel Max ($12/user/mo).

Batuta LLM: enrutamiento inteligente

batuta-auto es un id de modelo sintético. Envíale tu prompt y Batuta elige el modelo más económico que aún debería resolver la tarea: Haiku para preguntas y respuestas simples, Sonnet para el código del día a día, Opus para refactorizaciones, arquitectura y razonamiento de contexto largo. Pagas solo por los tokens del proveedor realmente usados, más la suscripción fija. Si el modelo al que se dirige un nivel no está disponible (tope de cuota, problema de autenticación, caída del proveedor), la solicitud pasa automáticamente al siguiente modelo de la cadena de respaldo, sin interrumpir tu flujo de trabajo.

Por qué batuta-auto en lugar de elegir un modelo tú mismo: los usuarios típicos de Orquesta envían una mezcla de prompts triviales ("corrige un typo") y difíciles ("refactoriza este flujo de autenticación"). Enrutar los triviales a Haiku y solo los difíciles a Opus reduce el gasto entre un 30 y un 60 % sin perder calidad en los prompts que importan. La decisión de enrutamiento es determinista dado el prompt y se expone en los encabezados de respuesta (X-Batuta-Tier, X-Batuta-Routed-To).

Úsalo desde cualquier cliente compatible con OpenAI (orquesta-cli lo configura automáticamente en la primera ejecución):

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: ..."}]
  }'

O fija un modelo específico: claude-opus-4-7, claude-sonnet-4-6, gpt-4o, deepseek-reasoner, grok-4, y GET /api/v1/models para la lista completa.

Modos de ejecución

Rutinas

Las rutinas son plantillas de prompts guardadas que se pueden volver a ejecutar con un clic. Crea rutinas para tareas comunes como desplegar, ejecutar pruebas, revisar registros o realizar escaneos de seguridad. Las rutinas se pueden activar manualmente o programar.

Prompts programados (Loop)

Programa prompts para que se ejecuten automáticamente de forma recurrente a través de tu agente local. Inspirado en el comando /loop de Claude: define un cronograma cron y Orquesta despacha los prompts a tu agente cuando les toca.

Cómo funciona:

1. Ve a tu proyecto → Configuración → Programados (pestaña Loop)
2. Crea un prompt programado con un nombre, el contenido del prompt y un cronograma cron
3. La plataforma busca prompts pendientes cada 2 minutos mediante un endpoint cron
4. Cuando un prompt está pendiente, se despacha a tu agente local mediante un broadcast de Supabase Realtime
5. El agente ejecuta el prompt usando Claude CLI y reporta los resultados

Preajustes de cron:

Requisitos:

• Tu agente local debe estar en ejecución cuando se dispare la programación
• Máximo 20 prompts programados por proyecto
• Máximo 10 iteraciones por ejecución, con un tiempo límite de hasta 1 hora
• Se admiten expresiones cron personalizadas además de los preajustes

VMs en la nube

Orquesta puede aprovisionar y administrar VMs en la nube para tus proyectos, en DigitalOcean o AWS EC2. Las VMs vienen preconfiguradas con refuerzo de seguridad, soporte para Docker y acceso SSH.

Proveedores y tamaños

Elige un tamaño y el proveedor se deduce de él: los droplets de DigitalOcean (s-1vcpu-1gb, s-1vcpu-2gb, s-2vcpu-4gb) funcionan en cualquier región de DigitalOcean, y las instancias de AWS (t3.micro, t3.small, t3.medium) funcionan en la VPC propia de Orquesta en us-east-1. El mismo bootstrap de cloud-init, la instalación del agente y el refuerzo de seguridad se aplican en ambos. AWS factura por separado el cómputo, el almacenamiento y la dirección IPv4 pública, por lo que una instancia de AWS con la misma RAM cuesta más: los droplets cuestan $12–$34/mes y las instancias de AWS $17–$49/mes, facturados mensualmente a través de Stripe.

Plantillas de espacio de trabajo y suspensión por inactividad

Configura una VM de AWS una sola vez — toolchain, repositorios clonados, navegadores con sesión iniciada en las cuentas que usa tu agente — y luego haz clic en Guardar como plantilla. Orquesta captura el disco como una imagen de máquina privada y cifrada (la VM se reinicia una vez, durante aproximadamente un minuto), y cualquier proyecto de la misma organización podrá iniciar una VM nueva a partir de ella en Iniciar desde. Cada clon recibe su propio token de agente y su propia clave SSH; todo lo demás se copia, incluidas las sesiones iniciadas, y por eso una plantilla nunca puede lanzarse fuera de su organización (la única excepción son las organizaciones hijas de un socio, que pertenecen al socio). El agente de cada VM nueva de AWS se niega a iniciar en cualquier máquina que no sea la suya, de modo que un clon nunca puede ejecutar los prompts del proyecto de origen.

La suspensión por inactividad detiene una VM tras un período de 1 hora a 30 días sin prompts; una VM suspendida factura solo su disco y el siguiente prompt al proyecto la inicia de nuevo. Las plantillas facturan solo el almacenamiento de su snapshot, hasta 10 por organización.

Acceso SSH

Las claves SSH se cifran con AES-256 y se almacenan en Supabase. La plataforma se encarga de la gestión de claves, la configuración de la conexión y la ejecución 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

Refuerzo de seguridad

Cada VM aprovisionada incluye:

• Firewall UFW (solo puertos 22, 80 y 443)
• Reglas de iptables compatibles con Docker (cadena DOCKER-USER): Docker omite UFW por defecto
• Limitación de tasa de DDoS saliente (SYN 50/s, UDP 100/s, ICMP 10/s)
• Cron de detección de malware (cada 5 minutos)
• sudo restringido para el usuario orquesta (solo comandos de una lista permitida)
• Parches de seguridad automáticos

microVM bajo demanda

Un proyecto puede funcionar sin una máquina propia: Orquesta inicia una microVM aislada cuando llega un prompt, ejecuta dentro de ella el agente estándar con orquesta-cli y la deja expirar unos 15 minutos después de la última actividad. Las llamadas al modelo van a los endpoints de LLM propios de tu organización (página de Orquesta CLI) o a tu complemento Batuta — Orquesta no coloca ninguna credencial de modelo propia en la microVM. La facturación es por minuto de vida de la microVM y se muestra como “Uso (30d)” en Ajustes → Agentes → Ejecutor bajo demanda. Nada persiste entre sesiones, por lo que el agente debe subir su trabajo (git, un registro, una API) antes de que la VM sea eliminada.

• Proyecto completo — marca Iniciar en una microVM de Orquesta al crear el proyecto, elige microVM como opción de alojamiento durante la configuración, o activa el ejecutor en Ajustes. Desde entonces cada prompt se ejecuta allí. Nunca se inicia mientras otro agente del proyecto esté en línea, de modo que los prompts no pueden ejecutarse dos veces.
• Un solo flujo de trabajo — en un proyecto que ya se ejecuta en una VM local o en la nube, marca Ejecutar en una microVM al crear el flujo de trabajo, o pulsa Ejecutar en microVM en su tarjeta (o envía run_on_microvm a la API de workstreams). Solo los prompts dirigidos a ese flujo de trabajo inician la microVM; el resto sigue yendo al agente propio del proyecto. En microVM lo devuelve al agente que tenía antes.
• Copiar una máquina — para un proyecto que vive en un PC que permanece encendido todo el día, Copiar a microVM en la misma sección de Ajustes (agente ≥ 0.2.272) hace que el agente en línea suba su árbol de trabajo, incluidos los cambios sin confirmar, a una rama orquesta/microvm-* y envíe sus archivos .env, que Orquesta almacena cifrados y nunca confirma en el repositorio. Los archivos sin seguimiento de más de 5 MB y los archivos que parecen claves (*.pem, id_rsa, .npmrc, credenciales) se excluyen, y solo se conservan las dos ramas de snapshot más recientes. Revisa la rama, los archivos env y el comando de instalación, y luego pulsa Convertir a microVM; cada arranque los restaura y ejecuta la instalación. Después, detén el agente en el PC. Los servicios que el PC ejecuta 24/7 no se mueven.

Integraciones

Conecta tus herramientas existentes a Orquesta para tener un flujo de trabajo unificado.

Flujo de rama + PR

Por defecto, el agente hace commit y push en la rama de trabajo del proyecto. Si tu equipo revisa los cambios antes de integrarlos, abre el botón de pull request en la tarjeta de GitHub conectada (Configuración → Integraciones → GitHub) y activa Nueva rama + pull request.

• Nueva rama + pull request — el agente crea una rama a partir de la rama base, hace push allí y abre un PR. Nunca hace commit en la rama base y nunca fusiona el PR por sí mismo.
• Prefijo de rama — feature/ por defecto, de modo que las ramas se ven como feature/add-auth.
• PR en borrador — abre cada pull request como borrador.
• Rama base — las ramas se crean a partir de ella y los pull requests la tienen como destino. Con el interruptor desactivado, es simplemente la rama en la que el agente hace commit.
• Reglas adicionales — texto libre que se añade a las instrucciones de git del agente: convenciones de commits, revisores a etiquetar, archivos que no se deben tocar.

Corrige CI fallido y revisiones en PRs

Un pull request abierto por un prompt de Orquesta no se detiene en el primer check en rojo. Cuando su CI falla, el agente del proyecto recibe los logs del fallo, corrige el código en la misma rama, hace push y comenta en el PR lo que cambió — hasta que el CI esté en verde o se alcance el límite de intentos.

• Actívalo desde Ajustes del proyecto → Integraciones → Corregir CI fallido en PRs. Instala un webhook en el repositorio conectado, por lo que el token de GitHub necesita derechos de administrador en el repositorio. Solo propietarios y administradores.
• Solo se tocan los PRs que abrió Orquesta: un PR cuya URL aparece en la salida de un prompt, o cuya rama creó una ejecución de Auto Agent. Un PR escrito a mano por alguien nunca se toca.
• Se admiten tanto los fallos de GitHub Actions (con el final del log de cada job fallido) como los fallos de otros CI que usan la Checks API, cada uno con su propio interruptor.
• Los fallos que llegan mientras una corrección sigue en curso se agrupan en un único seguimiento en lugar de iniciar un prompt por cada uno, y se ignora un fallo en un commit que ya fue reemplazado por un push más reciente.
• Tras el número de intentos configurado por PR (3 por defecto) se detiene y lo indica en el PR; la tarjeta tiene un botón de reintento para darle a ese PR un presupuesto nuevo.
• La corrección nunca hace force-push, nunca hace push a otra rama y nunca abre un PR nuevo. Si tu árbol de trabajo tiene cambios sin confirmar, la corrección se ejecuta en un git worktree separado y no los toca.
• Los prompts de corrección aparecen en el dashboard con la etiqueta github.

Revisiones y menciones a @orquesta. Los comentarios de revisión siguen el mismo ciclo:

• Las revisiones pueden estar en Desactivado, Solo cuando se menciona a @orquesta (por defecto) o Todas las revisiones en PRs con seguimiento. El cuerpo de la revisión y sus comentarios en línea (con archivo y línea) se envían al agente, que los atiende en la misma rama y responde en el PR — o explica por qué no está de acuerdo.
• Mencionar a @orquesta en una revisión o en un comentario del PR también funciona en PRs que Orquesta no abrió, y reactiva un PR que agotó sus intentos.
• Solo se actúa sobre personas con acceso de escritura (propietario, miembro o colaborador). Los bots de revisión como coderabbitai[bot] se ignoran a menos que los incluyas en Bots de revisión. Los PRs de forks se ignoran.
• Issues (opcional): un comentario @orquesta en un issue abre un nuevo prompt que trabaja en una rama orquesta/issue-N, abre un PR que cierra el issue y responde en el issue con el resultado. Como máximo 10 prompts de issues por hora por proyecto.
• Los comentarios se publican con la cuenta de GitHub conectada y llevan una marca oculta, por lo que Orquesta nunca reacciona a sus propios comentarios. Después de cambiar la configuración de revisiones o issues en un webhook existente, usa Reparar webhook si la tarjeta avisa de que GitHub rechazó la actualización.

Vercel

Linear

Bot de 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

Un canal de Slack puede apuntar a un proyecto. Lo que tu equipo escribe allí se convierte en un prompt para el agente propio de ese proyecto, y la respuesta vuelve como una respuesta en hilo en el mismo canal, de modo que la conversación se queda donde el equipo ya está y todos ven tanto la solicitud como lo que el agente hizo al respecto.

Conectar un canal

1. Instala la app — Ajustes de la organización → Slack → Añadir a Slack, o desde Ajustes → Integraciones → Slack de un proyecto. Una sola instalación cubre todo el workspace.
2. Genera un código de vinculación en la misma tarjeta. Es válido durante una hora y se puede canjear una sola vez.
3. Canjéalo en el canal que quieres vincular: /orquesta link ABCD2345.

Ambas mitades son necesarias a propósito. Una sesión de Orquesta demuestra quién eres, pero no que perteneces a ese canal; un comando slash demuestra que estás en el canal, pero no quién eres en Orquesta. Solo alguien con acceso al proyecto puede generar un código, y solo alguien dentro del canal puede usarlo.

O deja que Orquesta cree el canal

La tarjeta de Slack también crea un canal público para el proyecto, y ese se salta el código por completo: un canal que crea la app ya tiene la app dentro, así que no queda nada por demostrar y el canal queda vinculado en el instante en que existe. Escribe un nombre, mira exactamente cómo lo llamará Slack y crea. Solo propietarios y administradores: escribe en tu workspace, no en Orquesta. La persona que lo crea y los miembros del proyecto son invitados al canal en el acto, según su correo de Orquesta (requiere el scope users:read.email); quien no tenga una cuenta de Slack en ese workspace se omite.

Esto requiere el scope channels:manage, que Slack otorga en el momento de la instalación. Un workspace que instaló la app antes de que esto existiera tiene que instalarla de nuevo; hasta entonces el botón informa exactamente eso. Los canales privados no se crean desde aquí, porque eso requeriría un scope más amplio que el que pide la app.

Uso

/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

• Un comando escrito en el canal abre su propio hilo y la respuesta llega allí, de modo que una salida larga nunca inunda el canal.
• Mencionar la app dentro de un hilo existente mantiene ese hilo, y los turnos previos más recientes se entregan al agente como contexto.
• Los prompts desde Slack aparecen en el dashboard con la etiqueta slack, con el log completo, el diff y el costo: la respuesta en Slack es un resumen, el dashboard es el registro.
• Como máximo se ejecutan tres prompts a la vez por canal; más allá de eso la app lo avisa en lugar de encolar en silencio.
• Cada mensaje de entrada y de salida se conserva asociado al proyecto, así que la tarjeta de Slack muestra la conversación reciente incluso a quienes no están en el workspace.

Chat de equipo, reflejado con Slack

Un equipo que ya vive en Slack no quiere una segunda bandeja de entrada a medio leer dentro del dashboard. Por eso elegir Slack fusiona ambos en lugar de escoger uno: un mensaje escrito en el panel de Chat se publica en el canal vinculado, un mensaje escrito en el canal aparece en el panel, y ambos lados leen una sola conversación. El panel conserva su editor: una versión anterior lo convirtió en un puntero a Slack, lo que dejó fuera a todos los que trabajan en el dashboard y partió el historial en dos.

• Ajustes de la organización → Slack lo define para la organización, ya sea para todos los proyectos o para algunos elegidos, y puede fijar la política para que ningún proyecto la anule. Solo propietarios.
• Ajustes del proyecto → Integraciones → Slack lo define para un proyecto: seguir a la organización, o discrepar de ella en cualquier dirección.
• Elegir Slack antes de vincular un canal no refleja nada: el panel sigue funcionando y muestra un recordatorio, y ambos se unen en el momento en que se vincula un canal.
• El espejo está libre de bucles por construcción: cada fila almacena la marca de tiempo de Slack de su copia, así que nuestra propia publicación que regresa como evento, y los hasta tres reintentos de Slack de una misma entrega, caen en el mismo índice único y no hacen nada. Los mensajes de apps y bots nunca se reflejan hacia dentro.
• Un remitente de Slack que no tiene cuenta de Orquesta se muestra por nombre sin convertirse en miembro: como el agente, es un tipo de autor, no un perfil, así que nadie consume un asiento por escribir en un canal.
• Un hilo sigue siendo un hilo a través del puente: una respuesta en el hilo de Orquesta responde en el hilo de Slack, y viceversa.
• Slack → Orquesta requiere el scope channels:history y una suscripción al evento message.channels. Un workspace conectado antes de esa versión sigue funcionando en un solo sentido y la tarjeta de Slack del proyecto lo indica, con el botón para reconectar.
• La barra lateral indica cuál es: Integrado junto a Chat de equipo cuando el chat está reflejado con Slack, Integrar cuando no lo está.
• La página de Chat marca cada proyecto vinculado con el símbolo de Slack y lista su canal por encima de los integrados, y la tarjeta de Slack del proyecto enlaza cada canal conectado: un canal creado por Orquesta tiene dentro a la app, no a ti, y un canal público al que no te has unido queda fuera de tu barra lateral de Slack hasta que lo abras y te unas.
• Un proyecto al que llega la política de la organización pero que aún no tiene canal aparece en los Ajustes de la organización como sin canal · añade uno, que lleva directamente a la pestaña Integraciones de ese proyecto: crear o vincular el canal se hace allí, no a nivel de organización.

Las solicitudes se rechazan a menos que se verifique la firma propia de Slack sobre el cuerpo sin procesar y que la marca de tiempo esté dentro de cinco minutos, y cada evento entrante se registra una sola vez: Slack reintenta una entrega hasta tres veces, y un reintento no debe convertirse en una segunda ejecución de la misma tarea. Los botones de aprobación en el hilo son el siguiente paso y no están en esta versión.

Derplins

El chip Contrata a un especialista en prompts al final de la fila de pestañas de un proyecto abre una breve explicación de Derplins — un marketplace de especialistas en prompts a los que puedes contratar para trabajar en el proyecto — y vincula el proyecto con un clic (propietarios y administradores). Desde entonces aparece en la lista Tus proyectos de Orquesta del dashboard de Derplins de cada miembro del proyecto, con un botón para publicar un requisito sobre él, y se ofrece primero cuando un pedido de Derplins elige un workspace. El trabajo contratado allí se ejecuta en el agente de este proyecto, así que cada prompt permanece aquí con su log completo para auditoría. El menú del chip abre Derplins o desvincula el proyecto.

7ots

• Rostro y voz — Ajustes → Identidad lista tus ots de 7ots; elige uno y el agente residente del proyecto adopta su imagen, su aspecto en meet y su voz. El cerebro sigue siendo el agente de Orquesta. En las videollamadas de meet el agente aparece como el propio ot, en 3D, y habla con su propia voz (agente 0.2.262+). La voz funciona cuando el ot está activo y su cuenta de 7ots está conectada a Orquesta; no hay que añadir ningún dominio.
• Ots conectados — pestaña Equipo, debajo de Tokens de agentes de IA: permite que un ot externo entre al proyecto para hacerle preguntas al agente residente o encargarle trabajo, con scopes por ot. Cada ot muestra su propio rostro (el personaje que renderiza 7ots, o su imagen subida), no solo su nombre. Solo propietarios y administradores.
• Icono del proyecto — la barra lateral, el encabezado del proyecto y la app móvil muestran el favicon del sitio del proyecto, o el avatar del propietario en GitHub, y se actualizan cuando cambia la URL del sitio o del repositorio.

Orquesta CLI

Asistente de programación con IA que se ejecuta localmente con endpoints de LLM configurables. Disponible en el plan 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"

Configuración de LLM

Configura varios endpoints de LLM desde el dashboard o localmente. Compatible con:

• OpenAI (GPT-4, GPT-4o, etc.)
• Anthropic (Claude Opus, Sonnet, Haiku)
• Ollama (modelos locales)
• vLLM (autoalojado)
• OpenRouter (marketplace de modelos)
• Cualquier endpoint compatible con OpenAI

Sincronización con el dashboard

Las configuraciones de LLM se sincronizan de forma bidireccional entre la CLI y el dashboard. Configura los endpoints de forma centralizada y distribúyelos a tu equipo. El historial de prompts se registra en el dashboard sin importar si el prompt se envió desde la CLI o desde la interfaz web.

Extensión para IDE

Conecta Cursor, VS Code o Windsurf directamente a Orquesta. Recibe prompts del dashboard de tu equipo y ejecútalos dentro de tu IDE: la extensión vive en tu editor, ejecuta cada prompt a través de una CLI de programación local en tu workspace y envía los resultados de vuelta al dashboard en tiempo real.

Instalación

Descarga el archivo .vsix y luego instálalo en tu 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

Configuración y token

Después de la instalación, conecta la extensión a tu proyecto usando un token de agente:

1. Abre tu proyecto en Orquesta → Proyecto → Agentes
2. Haz clic en Crear token de agente → copia el token oat_xxx
3. En tu IDE, pulsa Cmd+Shift+P → Orquesta: Set Agent Token
4. Pega el token: la extensión se conecta y abre la barra lateral automáticamente

El token se almacena en los ajustes globales de VS Code. La extensión se conecta automáticamente en cada inicio una vez que se guarda un token. Para desactivar la conexión automática, establece orquesta.autoConnect: false en los ajustes.

Modos de ejecución

Controla cómo se ejecutan los prompts mediante el ajuste 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

Incorpora el widget de comentarios de Orquesta en tus aplicaciones en producción. Los usuarios pueden reportar errores con inspección de elementos, capturas de pantalla y logs de consola, todo fluyendo de vuelta a tu proyecto de Orquesta.

Configuración por CDN

El embed SDK se distribuye exclusivamente por CDN: añade dos etiquetas a cualquier página HTML y listo. Sin paso de compilación, sin npm install, siempre la última versión.

<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>

¿Es tu primera vez con el embed? Abre Project → Embed en el dashboard: una lista de verificación guiada te lleva paso a paso por ejecutar el agente, definir tu URL de destino, crear un token e instalar el snippet — y una demo en vivo integrada (widget real, datos de ejemplo) muestra lo que hace antes de configurar nada. También puedes pasar demo: true a Orquesta.init() para renderizar el widget con datos de ejemplo y sin backend.

Modo Builder

El modo Builder muestra una interfaz estilo IDE a pantalla completa (similar a Bolt o Lovable) con tres paneles: chat a la izquierda, vista previa en vivo a la derecha y una terminal plegable en la 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>

Paneles del Builder:

• Chat — Envía prompts, consulta las respuestas de la IA y las actualizaciones de estado
• Vista previa — iframe en vivo con barra de URL y botón de recarga, se recarga automáticamente al completarse un prompt
• Terminal — Logs de ejecución en tiempo real, plegable, con salida codificada por colores

Los paneles se pueden redimensionar arrastrando los controladores. La terminal se puede contraer y expandir. Totalmente responsivo, con un diseño apilado en móvil.

Los prompts enviados desde el embed se publican por defecto. Como quien envía está viendo el sitio desplegado, cada prompt del embed le pide al agente que haga commit, push, deploy y reporte el SHA del commit una vez terminado el cambio de código — luego la vista previa se recarga con un parámetro anticaché para que la nueva versión se obtenga de verdad. Define auto_deploy: false en la configuración del token del embed para excluir un token.

Funciones

• Inspector de elementos — Haz clic en cualquier elemento para marcarlo en un reporte de error
• Captura de consola — Captura automáticamente la salida de la consola del navegador
• Captura de red — Registra las solicitudes de API fallidas
• Sistema de comentarios — Comentarios en línea sobre elementos específicos
• Línea de tiempo — Línea de tiempo de acciones del usuario para reproducir el problema

Extensión de navegador

El embed necesita una etiqueta <script> en la página, así que solo llega a los sitios que controlas. La extensión de navegador de Orquesta hace el mismo trabajo desde el lado del navegador: inyecta el widget en cualquier página sin cambiar el HTML, y permite que Orquesta CLI controle el navegador en el que ya iniciaste sesión.

• Inyecta el embed donde quieras — el sitio de un cliente, un entorno de staging detrás de SSO, producción. Los prompts llegan al proyecto al que pertenece el token del embed.
• Tu navegador real — las herramientas browser_ext_* usan tu perfil y tus sesiones reales, a diferencia de browser_*, que lanza un Chrome limpio y sin sesión iniciada.
• Captura de consola y red — lee desde la CLI lo que la página registró y lo que solicitó.
• Chat en el panel lateral (0.3.0) — haz clic en el icono de la barra de herramientas, inicia sesión con Orquesta y chatea con un agente que lee y opera la pestaña actual (clic, rellenar, navegar, leer consola/red). Se ejecuta en Batuta; no necesita CLI ni bridge.
• Enviar al proyecto (0.3.0) — selecciona texto en cualquier página, haz clic derecho en Send to Orquesta project, elige el proyecto y se ejecuta como un prompt en el agente de ese proyecto. El panel muestra su log en streaming y tiene un botón Detener (POST /api/v1/prompts/{id}/cancel).

Chrome y Edge. Firefox no es compatible (la extensión usa el Chrome DevTools Protocol).

Instalar y vincular

La extensión aún no está en la Chrome Web Store, así que se carga sin empaquetar desde el repositorio orquesta-extension . Son tres piezas, todas locales:

# 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)

Al habilitar el grupo de herramientas se inicia el bridge local por ti — un pequeño daemon en 127.0.0.1 con el que habla la extensión. Haz clic en Pair en el popup de la extensión, pídele el código a la CLI (browser_ext_status lo informa) y el navegador queda conectado.

La vinculación sobrevive a los reinicios, así que se hace una vez por navegador, no una vez por sesión. El bridge sigue activo después de la CLI a propósito: las ejecuciones cortas de orquesta -p y varias sesiones comparten un mismo navegador sin volver a vincular. Ejecútalo tú mismo con npx orquesta-bridge si prefieres ver su log.

Herramientas de la CLI

En Orquesta CLI, ejecuta /tool y habilita Browser Extension (your own browser). Eso registra:

• browser_ext_status — indica si el bridge está activo y si hay un navegador vinculado
• browser_ext_tabs / _open / _reload — listar pestañas, abrir una URL, recargar
• browser_ext_click / _fill / _press / _select — interactuar con la página
• browser_ext_text / _html / _eval — leer la página, ejecutar JS en ella
• browser_ext_screenshot — capturar la pestaña visible
• browser_ext_console / _network — mensajes de consola y solicitudes
• browser_ext_wait — esperar un selector o una navegación
• browser_ext_embed — inyectar el widget de Orquesta en la página

Seguridad

• Nada sale de la máquina. La CLI habla con el bridge por loopback y el bridge habla con la extensión mediante un WebSocket local vinculado. No hay ningún servidor de Orquesta en el camino.
• La vinculación es explícita y caduca. El bridge imprime un código válido por dos minutos; la extensión solo se conecta después de que lo escribes.
• El token de control es un archivo, no un argumento. Se escribe con permisos 0600 en ~/.orquesta-cli/, por lo que nunca aparece en ps.
• El bridge solo escucha en 127.0.0.1 y rechaza las solicitudes originadas en el navegador, así que una página web no puede alcanzarlo mediante DNS rebinding.

Escritorio remoto

Además de controlar un navegador, el agente puede operar el escritorio completo de la máquina donde se ejecuta — mover el mouse, escribir y tomar capturas de pantalla — y tú puedes tomar el control en vivo desde el dashboard. Esto sirve para automatizar flujos en aplicaciones nativas, no solo en páginas web. Por ahora Linux/X11; Windows y macOS llegarán pronto.

Habilitar y modos

Desactivado por defecto. Actívalo por proyecto en Settings → Agent → Remote Desktop. Tres modos:

• Automatización — el agente controla el escritorio de forma programática (no se inicia ningún servidor VNC).
• En vivo (VNC) — una persona toma el control desde el visor del dashboard.
• Ambos — automatización más toma de control en vivo.

Usar el visor

Abre la pestaña Remote Desktop de un proyecto. La pantalla aparece apenas el agente empieza a transmitir; para mirar no necesitas nada más que acceso al proyecto.

• Tomar el control entrega tu mouse y tu teclado a la máquina remota. Movimientos, clics, arrastres, rueda de desplazamiento y clic central/derecho se transmiten; lo que escribas va a lo que tenga el foco allá.
• Separar abre el escritorio en su propia ventana, para que pueda estar en un segundo monitor mientras sigues trabajando en la pestaña del proyecto.
• Desconectar abandona la sesión. El agente deja de capturar la pantalla por completo cuando nadie está mirando, que es también lo que te indica el contador de espectadores junto al estado.
• El historial de sesiones lista cada vez que alguien abrió este escritorio, por cuánto tiempo y si tomó el control.

PIN de vinculación

Un owner o admin puede definir un PIN en Settings → Agent → Remote Desktop. Protege tomar el control, no mirar: ver una pantalla a la que ya tienes acceso desde el dashboard no es la capacidad peligrosa — manejar la máquina sí lo es. El PIN se almacena con hash y lo verifica el relay, así que ni el navegador ni el agente pueden ser convencidos de omitirlo.

Seguridad

• Opt-in, desactivado por defecto. El control total del escritorio es de alto riesgo, así que nada se ejecuta hasta que lo habilites para un proyecto.
• Mirar y manejar son permisos separados. El control se concede por sesión y termina con ella — al reconectar se pide de nuevo, y el PIN (si hay uno) también se vuelve a pedir.
• El servidor VNC escucha solo en localhost. El único camino de entrada es el túnel WebSocket autenticado del agente — nunca se expone a la red.
• Deshabilitado bajo sandbox Strict. El aislamiento estricto del sistema de archivos y la toma de control total del escritorio son mutuamente excluyentes; el agente se niega a habilitarlo.
• Las sesiones inactivas se cierran para que una toma de control abandonada no deje el escritorio accesible.

Servidor MCP

Orquesta habla el Model Context Protocol en un único endpoint, de modo que un asistente que se ejecute en cualquier lugar — Lovable, ChatGPT, Claude Code, Cursor, VS Code — pueda leer el historial de un proyecto y escribir de vuelta su propio trabajo en él. Nada que instalar: los hooks de arriba necesitan un proceso en tu máquina, mientras que MCP llega a herramientas que se ejecutan en la nube.

https://getorquesta.com/api/mcp

El transporte es sin estado: cada llamada es una solicitud HTTPS, no hay sesión que mantener viva y ningún flujo de eventos que mantener abierto.

Conectar un cliente

Pega la URL. Un cliente alojado descubre el servidor OAuth a partir del 401, se registra solo y te envía a una pantalla de consentimiento de Orquesta donde eliges la organización a exponer — no se crea, muestra ni copia ninguna API key. En Lovable: Dashboard → Connectors → busca mcp → New MCP server, pega la URL, deja Authentication en OAuth y luego Add server. ChatGPT y Claude piden solo la URL.

Cada integrante del equipo autoriza con su propia cuenta, y el token llega exactamente a los proyectos que esa persona ya puede ver. Cada herramienta conectada aparece en Settings → Connections con cuántas sesiones ha registrado, cuándo hizo algo por última vez y cuántas personas la autorizaron — un botón ahí la desconecta para toda la organización.

Desde la terminal, orquesta-cli también es un cliente MCP, y ahora soporta OAuth: orquesta mcp login <name> abre el navegador una vez y guarda en esa máquina un token que se renueva solo, que es la única forma de llegar a un servidor que no emite API key. orquesta mcp list marca un servidor autorizado, y orquesta mcp logout <name> lo olvida.

Los clientes sin soporte OAuth usan en su lugar un bearer token — una API key de organización (oak_) desde Settings → API Keys, conservando el scope prompts:write si el cliente debe poder registrar su trabajo:

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..." }
    }
  }
}

Herramientas

API de agentes externos

API REST que permite a agentes de IA de terceros (GPT, LangChain, CrewAI, agentes personalizados) conectarse a tu proyecto de Orquesta. El agente externo aporta el cerebro; Orquesta ofrece ejecución + coordinación.

Cómo funciona:

1. Genera un token oxa_ desde el dashboard (Project → Team → External Agents)
2. Registra tu agente mediante la API
3. Lee el contexto del proyecto para entender el código base
4. Envía prompts — el orquesta-agent local los ejecuta
5. Consulta los resultados por polling e itera

Autenticación

Todas las solicitudes a la API requieren un Bearer token con los scopes adecuados:

Authorization: Bearer oxa_abc123...

Límites de tasa: 30 solicitudes/minuto, 300 solicitudes/hora (configurable por token).

Los dos scopes *:write están desactivados por defecto al crear un token y deben marcarse explícitamente. Permiten que un agente de deploy entregue a un proyecto sus variables y archivos sin tener un token oclt_ de toda la organización que actúa como el usuario completo. Son estrictamente de solo escritura: el mismo token recibe 403 en GET/DELETE de esas rutas, y cada escritura queda registrada en el log de actividad del token (solo claves y nombres de archivo, nunca valores).

Referencia de la API

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

Ejemplos

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

Orquesta incluye un bot autónomo integrado que usa Claude CLI como cerebro para planificar estratégicamente y enviar tareas mediante la API de agentes externos. El agente local ejecuta cada tarea.

No necesitas API key — el bot usa tu suscripción web de Claude mediante claude login.

Cómo funciona:

1. Se registra como agente autónomo mediante la API
2. Reúne el contexto del proyecto, los prompts recientes y el estado de la cola
3. Lanza claude -p con todo el contexto para decidir la siguiente tarea
4. Envía el prompt, consulta por polling hasta que termina y registra el resultado
5. Repite — cada iteración se apoya en los 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

Configurable: MAX_ITERATIONS (por defecto 5), ITERATION_DELAY (por defecto 30 s entre iteraciones).

Seguridad

La seguridad es fundamental en Orquesta. Tu código se ejecuta en tu máquina, las credenciales están cifradas y todo acceso a los datos está controlado por políticas de seguridad a nivel de fila.

Seguridad a nivel de fila

Cada tabla de Supabase tiene políticas RLS que imponen aislamiento a nivel de organización. Los usuarios solo pueden acceder a los datos dentro de su organización. Las operaciones de administración usan una service role key con permisos elevados, que nunca se expone al cliente.

Gestión de tokens

Todos los tokens se almacenan con hash SHA-256. Solo se guarda el hash — el token en texto plano se muestra una sola vez al crearlo y no se puede recuperar. Los tokens se pueden revocar al instante desde el dashboard.

Variables de entorno y archivos secretos

Los secretos del proyecto viven en Settings → Environment Variables y se inyectan en cada prompt que ejecuta el agente. Hay dos tipos: variables clave/valor y archivos secretos: una clave de firma, un keystore, un JSON de cuenta de servicio o un.p8 que debe existir en disco. El agente escribe cada archivo en su ruta de destino (relativa al proyecto, absoluta o ~/…; modo 0600) justo antes de la ejecución y exporta ORQUESTA_FILE_<NAME> con la ruta resuelta.

• Pegar .env: tanto el asistente de configuración como Settings aceptan un .env pegado (se manejan comentarios, comillas y prefijos export; las claves existentes se actualizan en su lugar).
• Acceso por API con un token de CLI: /api/projects/{id}/env, /credentials and /secret-files aceptan Authorization: Bearer oclt_… además de la sesión del panel, de modo que scripts y agentes pueden cargar secretos sin navegador. Eliminar requiere el permiso credentials:manage.
• Acceso de solo escritura con un token de agente externo: un token oxa_ creado con los scopes opcionales env:write / secret-files:write (desmarcados por defecto) puede hacer POST a /env y /secret-files únicamente de su propio proyecto. No puede leerlos ni eliminarlos, y cada escritura queda registrada en el historial de actividad del token. Prefiérelo sobre un oclt_ para un agente cuya única tarea es cargar secretos; consulta Scopes de agentes externos.
• Estado del token: orquesta --status ahora verifica con el servidor el token de CLI almacenado y avisa cuando está revocado, vencido o es un token antiguo sin usuario asociado (esos se rechazan con 403 en cada escritura). orquesta --login genera uno nuevo.
• Hasta 32 archivos, 512 KB cada uno, 4 MB en total por proyecto. Se almacenan cifrados, como cualquier otra 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

Verificación de identidad (passkey / OTP)

Una organización o un proyecto puede exigir una segunda verificación de identidad, además del inicio de sesión normal, antes de que alguien haga actuar a su agente: enviar o ejecutar prompts, sesiones interactivas, control del navegador, control de escritorio remoto, ejecuciones programadas y autonomía del auto-agente. Los miembros se verifican con una passkey (Touch ID, Windows Hello, una llave de seguridad) o con un código de una app de autenticación.

• Actívala en Organization Settings → Identity verification for agents (propietario), o por proyecto en Settings → Agent (propietarios y administradores). Un proyecto solo puede hacer la política más estricta.
• Caduca tras el tiempo configurado (de 15 min a 24 h, 8 h por defecto; prevalece el más corto entre organización y proyecto), al cerrar sesión o al pulsar Lock now en tu perfil.
• Regístrate en Profile → Identity verification, o directamente desde el prompt la primera vez que se necesite. Agregar o quitar un método después del primero te pide verificar de nuevo, y cada cambio se te notifica por correo.
• Relajar la política (desactivarla o alargar la caducidad) requiere una verificación de los últimos 15 minutos, así que una sesión robada no puede desactivarla.
• Alcance: la verificación se aplica a las sesiones del panel. Las vías autenticadas por token (API pública, CLI, Slack, Telegram, agentes externos) se rigen por sus tokens.

Escaneo de seguridad

El escaneo de seguridad integrado analiza los prompts y el código generado en busca de vulnerabilidades. Los escaneos detectan problemas comunes como inyección SQL, XSS, inyección de comandos y credenciales expuestas. Los resultados aparecen en el panel Security con niveles de severidad y guías de corrección.

GuardRails

GuardRails es una capa de protección de prompts por proyecto que intercepta cada prompt antes de que llegue al agente. Busca intentos de inyección de prompts, jailbreaks, suplantación de rol, and exfiltración de datos mediante más de 30 reglas regex integradas y una revisión opcional con IA de GPT-4o-mini.

Cómo funciona:

1. Cada prompt se puntúa contra 6 categorías de reglas antes de ejecutarse
2. Puntaje ≥ 70 → bloqueado, 30–69 → advertencia, < 30 → aprobado
3. El resultado se guarda en el prompt (guardrail_status, guardrail_flags)
4. En modo block el prompt se cancela y se devuelve un 403; en modo warn se ejecuta pero queda marcado

Modos de acción:

• Block: el prompt se cancela; el remitente recibe un error con la regla coincidente
• Warn: el prompt se ejecuta con normalidad pero queda marcado en el registro de infracciones
• Log Only: el prompt se ejecuta y las infracciones se registran en silencio para auditoría

Configuración: Ve a Agent → GuardRails en el panel del proyecto para activarlo, definir el modo, activar la revisión con IA y agregar patrones regex personalizados. Los administradores del proyecto también pueden activar o desactivar GuardRails directamente desde la barra de herramientas de Send Prompt usando el GuardRails botón, sin necesidad de salir de la página.

Endpoints de la API de GuardRail:

Quality Gates

Los Quality Gates permiten a los administradores exigir un paso de Simulate before Submit a miembros específicos del equipo. Al activarlo, el botón Execute del miembro cambia a Simulate; al hacer clic se llama a una IA que muestra una vista previa de lo que haría el agente (archivos modificados, comandos ejecutados, riesgos). Luego el miembro elige Sign & Submit para continuar o Cancel.

Cómo activarlo:

1. Ve a Team en el panel del proyecto
2. Haz clic en la insignia Sign-off junto al nombre de un miembro (solo administradores)
3. La insignia se vuelve ámbar cuando está activa: ese miembro verá "Simulate" en lugar de "Execute"
4. La simulación se registra mediante quality_gate_signed en el registro del prompt

CLAUDE.md Sync

Edita el CLAUDE.md de tu proyecto directamente desde el panel y mantenlo sincronizado con el directorio de trabajo del agente. Claude Code lee CLAUDE.md desde la raíz del proyecto en cada sesión; se acabó el SSH manual para actualizarlo.

Editor del panel

Abre Configuration → Settings → pestaña CLAUDE.md. Edita el contenido y guarda. Se almacena en projects.settings.claude_md. En la siguiente conexión del agente, el archivo se escribe en <workingDirectory>/CLAUDE.md.

Sincronización del agente

En la primera conexión, el agente sube el CLAUDE.md local al panel (solo si no hay contenido del usuario guardado):

1. El agente lee CLAUDE.md de su directorio de trabajo
2. Envía el contenido por POST a /api/agent/claude-md
3. El servidor lo guarda solo si settings.claude_md aún no está definido (las ediciones del usuario nunca se sobrescriben)
4. En conexiones posteriores, si settings.claude_md está definido, se escribe de vuelta en disco

Contexto del agente de la organización

CLAUDE.md es por proyecto. Las reglas que valen para todos los proyectos de la organización viven en Settings → Agent context (/dashboard/settings, solo propietarios) — políticas que nunca deberías tener que repetir: “trabaja siempre en una rama y abre un PR”, “pregunta antes de agregar una dependencia”, “escribe los mensajes de commit en inglés”.

Se entrega después de las instrucciones del proyecto y de los skills de integración, bajo un encabezado que indica que las reemplaza — la precedencia en el prompt es posicional, así que gana el último bloque etiquetado. Los agentes en ejecución lo recargan a los pocos segundos de guardar.

Code Browser

La pestaña Code Browser ofrece una vista de solo lectura del código fuente de tu proyecto directamente desde el panel. Los archivos se obtienen de GitHub o por SSH, sin necesidad de un clon local.

Funciones:

• Resaltado de sintaxis para más de 20 lenguajes (TypeScript, Python, Go, Rust, SQL, HTML, CSS y más)
• Explorador de archivos con filtro de búsqueda y navegación por directorios
• Búsqueda dentro del archivo con navegación entre coincidencias (Ctrl+F o botón de búsqueda)
• Navegación por ruta (breadcrumb) y metadatos del archivo: tamaño, número de líneas, lenguaje
• Copia el contenido completo del archivo al portapapeles
• Ask AI: abre un panel lateral para hacer preguntas sobre el archivo que estás viendo. Respuestas en streaming con Claude Haiku o GPT-4o-mini

Es una experiencia de solo visualización: no se pueden modificar, crear ni eliminar archivos desde Code Browser. Úsalo para revisiones de código, para incorporar a nuevos miembros del equipo o para explorar partes desconocidas del código.

Ask AI

Haz clic en el botón Ask de la barra de herramientas del archivo para abrir el panel de IA. La IA recibe el contenido del archivo como contexto y puede responder preguntas sobre el código, explicar patrones, identificar posibles problemas y describir lo que hacen las funciones. Se ofrecen prompts sugeridos para empezar.

Panel de rendimiento

La pestaña Performance (Configuration → Performance) muestra datos agregados de uso de tokens y costo del proyecto, desglosados por modelo y día. Los datos provienen de los campos tokens_used y cost_cents, que completa el ejecutor de Claude CLI.

Qué verás:

• Tarjetas de estadísticas: costo total ($), tokens totales, cantidad de prompts
• Gráfico de barras diario: costo por día en el período seleccionado
• Tabla por modelo: modelo, proveedor, prompts, tokens, costo, ordenada por costo
• Gasto por miembro: tokens y costo por usuario, ordenado por uso, con una marca de gasto alto cuando un miembro concentra más del 40% de los tokens del equipo
• Límite de tokens por usuario: los propietarios y administradores de la organización pueden fijar un tope mensual de tokens de Batuta por miembro para toda la organización, ya sea en modo solo alerta (se envía correo a miembros y administradores al 80% / 95%) o en modo bloqueo (los prompts se rechazan al superar el tope hasta el mes siguiente)
• Selector de período: 7 días / 30 días / Todo el tiempo

API de rendimiento

Quick Prompts

Quick Prompts te permiten guardar los prompts de uso frecuente como plantillas reutilizables. En lugar de volver a escribir las mismas instrucciones, guárdalas una vez y ejecútalas con un solo clic.

Crear y usar Quick Prompts

Crear:

• Abre el campo de prompt en cualquier proyecto
• Escribe tu prompt y luego haz clic en el botón Save as Quick Prompt
• Ponle un nombre y, opcionalmente, una descripción
• Los quick prompts se guardan por proyecto en la tabla quick_prompts

Usar:

• Haz clic en el menú desplegable de Quick Prompts en el área del campo de prompt
• Selecciona un prompt guardado para rellenar el campo automáticamente
• Edítalo si es necesario y envíalo como de costumbre

Casos de uso:

• Prompts estándar de revisión de código
• Listas de verificación de despliegue
• Plantillas de reporte de errores
• Tareas de mantenimiento recurrentes

Building in Public

Haz visible públicamente la actividad de IA de tu proyecto, sin necesidad de iniciar sesión. Activa el interruptor "Build in Public" y tu proyecto aparece en el Live Feed en getorquesta.com/feed, para que cualquiera pueda seguir cómo tu agente de IA entrega código en tiempo real. Una excelente forma de generar FOMO y mostrar cómo se ve el desarrollo impulsado por IA.

Activar y configurar

Ve a Project → Settings → pestaña Permissions. En "Build in Public", activa el interruptor.

• Slug personalizado: define una URL corta como my-project para que tu página del feed esté en getorquesta.com/feed/my-project en lugar de un UUID. Debe usar letras minúsculas, números y guiones (3–50 caracteres) y ser único.
• URL del sitio en vivo: ingresa la URL de tu app desplegada (p. ej. https://myapp.com). Los visitantes de tu página del feed verán una vista previa en iframe del producto real en funcionamiento, debajo de la línea de tiempo de prompts.

Live Feed

El feed global en /feed lista todos los proyectos públicos, ordenados por puntaje de votos de la comunidad. Cada tarjeta muestra:

• Estado del agente en línea/fuera de línea (punto verde = visto en los últimos 3 minutos)
• Pulso ámbar "Running now" cuando un prompt se está ejecutando
• Últimos 3 fragmentos de prompts con íconos de estado e insignias de origen (Web / Telegram / Auto / etc.)
• Botones de voto a favor/en contra: el puntaje es votos a favor menos votos en contra, almacenado por UUID anónimo del navegador
• Enlace a la línea de tiempo completa del proyecto en /feed/[slug]

La página de detalle del proyecto (/feed/[slug]) muestra:

• Vista previa en iframe del sitio en vivo (si hay una URL del sitio configurada)
• Línea de tiempo completa de prompts (últimos 50, solo lectura)
• Contenido del prompt expandible, etiquetas, origen, duración
• Botón para compartir en X y botón para copiar el enlace
• Terminal de logs en vivo para cualquier prompt en ejecución

Logs en tiempo real

Cuando un prompt se está ejecutando, aparece un panel de terminal debajo de él en la página pública del proyecto y transmite los logs del agente cada 2 segundos. Los logs se filtran: las entradas internas thinkingse ocultan y solo se muestra la salida accionable:

Los logs se limitan a las últimas 80 entradas por consulta y se truncan a 500 caracteres por línea. Se desplaza automáticamente a la última entrada.

API pública

Estos endpoints no requieren autenticación: son totalmente públicos:

Claves de API

Las claves de API (oak_) dan a integraciones externas acceso a los datos de Orquesta. Genéralas en Settings > API Keys, donde cada clave tiene dos restricciones independientes: qué scopes posee (solo lectura por defecto) y a qué proyectos puede acceder (todos o algunos elegidos). Ambas se pueden editar después sin volver a emitir el token.

Autenticación

Incluye tu clave de API en cada solicitud:

# 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

Proyectos y VMs

Las claves de organización (solo oak_; los tokens de CLI, de agente y de MCP se rechazan) pueden crear proyectos y administrar la VM en la nube de cada proyecto. Las operaciones de escritura requieren que el usuario que creó la clave siga siendo propietario o administrador de la organización. Límite: 30 solicitudes por minuto y 300 por hora por clave. Las respuestas de VM nunca incluyen la clave privada SSH ni el token del agente.

Las organizaciones partner (habilitadas por Orquesta) pueden crear una organización hija por cada cliente final y operar sobre ella enviando X-Orquesta-Org: <child id> a cualquiera de los endpoints anteriores. Una organización hija con facturación de Stripe debe pagar primero a través de su checkout; hasta entonces, crear una VM responde 402 con code: billing_required.

Scopes

Una clave solo tiene los scopes que marques. Una solicitud fuera de ellos responde 403 indicando el scope que falta.

Dos presets cubren la mayoría de los casos: Solo lectura (todos los scopes :read excepto el opcional vms:read) y Lectura + envío de prompts. Crear una clave sin indicar ningún scope produce una clave de solo lectura. Los scopes de infraestructura nunca están en un preset: márcalos explícitamente.

Restricción por proyecto

Una clave abarca toda la organización a menos que la restrinjas. Cuando eliges proyectos, todos los endpoints, tanto REST como MCP, se filtran a ellos: los listados devuelven solo las filas de esos proyectos, y pedir cualquier otra cosa responde 404, la misma respuesta que para un proyecto que no existe, de modo que una clave no puede averiguar qué ids de proyecto son reales. Las claves existentes siguen abarcando toda la organización hasta que las edites.

# 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

Comunidad OSS

Orquesta OSS es una versión autoalojada y de código abierto de la plataforma. Las instancias OSS pueden publicarse opcionalmente en el feed de la comunidad getorquesta.com/feed haciendo que tu instancia sea descubrible por otros desarrolladores.

Autoalojamiento

Empieza con la versión 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 (no se necesita una base de datos externa)
• Better Auth para la autenticación
• Socket.io para la comunicación de agentes en tiempo real
• Agent Grid completo, tokens de agente y sesiones interactivas

Publicar en el feed de la comunidad

Los propietarios de instancias OSS pueden publicar su instancia en el feed de la comunidad en getorquesta.com/feed. Esto hace que tu instancia sea visible para la comunidad.

Cómo publicar:

• Abre el panel de tu instancia OSS
• Haz clic en el botón Publish to Community en el encabezado del proyecto (solo el propietario)
• Los datos de tu instancia se envían a POST /api/oss/publish
• Tu instancia aparece en la sección Comunidad de /feed

API:

Facturación y planes

Matriz de funcionalidades

Batuta LLM Add-on

Batuta LLM es un proxy de LLM administrado que da a tu equipo acceso a los principales modelos de IA (GPT-4o, Claude, Gemini, DeepSeek, Mistral, Grok) sin tener que administrar claves de API. Úsalo desde el chat del panel o mediante Orquesta CLI.

Batuta Standard está incluido en el plan Max: las organizaciones Max reciben automáticamente la cuota de 5M tokens/mes y no necesitan el complemento. Los niveles Plus, Pro y Team que se muestran abajo te permiten escalar aún más.

Enterprise

Orquesta Enterprise está diseñado para organizaciones que necesitan seguridad avanzada, cumplimiento normativo y control sobre los flujos de desarrollo impulsados por IA. Desde SSO y permisos granulares hasta el despliegue on-premise y el cumplimiento de SOC 2, Enterprise ofrece a tus equipos de seguridad y compras todo lo que necesitan para aprobar Orquesta en producción.

SSO y gestión de identidades

Orquesta se integra con tu proveedor de identidad actual para que tu equipo inicie sesión con sus credenciales corporativas. Sin contraseñas adicionales ni aprovisionamiento manual de usuarios.

Aprovisionamiento SCIM

Automatiza la gestión del ciclo de vida de los usuarios con SCIM 2.0. Cuando alguien se une a tu organización o la deja, su acceso a Orquesta se aprovisiona o se revoca automáticamente a través de tu proveedor de identidad.

• Creación automática de usuarios al agregarlos a un grupo del IdP
• Desactivación automática al eliminarlos del IdP
• Mapeo de grupos a roles (los grupos del IdP se asignan a roles de Orquesta)
• Aprovisionamiento just-in-time (JIT) en el primer inicio de sesión

Autenticación multifactor (MFA)

Exige MFA a nivel de organización. Orquesta admite TOTP (apps de autenticación), WebAuthn (llaves físicas como YubiKey) y SMS como alternativa. Los administradores pueden exigir MFA a todos los miembros o a roles específicos.

Verificación de dominio

Reclama tu dominio de correo (p. ej., @yourcompany.com) para que cualquier empleado que se registre con ese dominio se agregue automáticamente a tu organización. Evita cuentas paralelas y garantiza una gestión centralizada.

Roles y permisos avanzados

El RBAC de Enterprise va más allá de los roles estándar Admin / Developer / Viewer. Crea roles personalizados con permisos granulares limitados a proyectos, entornos y acciones específicos.

Roles Enterprise integrados

Roles personalizados

Crea roles personalizados con conjuntos de permisos detallados. Cada permiso es una combinación de recurso + acción:

{
  "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"]
  }
}

Acceso por entorno

Restringe a qué entornos puede dirigirse cada rol. Un desarrollador puede tener acceso total a desarrollo y staging, pero requerir aprobación para producción. Los entornos se definen por proyecto y se aplican a nivel del agente.

• Desarrollo — acceso abierto, sin aprobaciones
• Staging — acceso para desarrolladores, revisión opcional
• Producción — requiere la aprobación del quality gate por parte de un Reviewer o un Project Admin
• Restringido — solo Org Admins y Security Officers, con auditoría completa de cada acción

Listas de comandos permitidos y bloqueados

Define qué comandos de shell y patrones se permiten o se bloquean por rol y entorno. El agente aplica estas reglas antes de ejecutar, evitando operaciones destructivas o no 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"
    ]
  }
}

Lista de IPs permitidas

Restringe el acceso al panel y a la API a rangos de IP específicos. Solo las solicitudes de tu red corporativa, VPN o bloques CIDR aprobados pueden acceder a Orquesta. Se configura a nivel de organización.

{
  "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
  }
}

Opciones de despliegue

Elige el modelo de despliegue que se ajuste a tus requisitos de seguridad y cumplimiento. Orquesta admite desde la nube totalmente administrada hasta instalaciones on-premise aisladas de la red.

Residencia de datos

Elige dónde se almacenan tus datos para cumplir con las regulaciones regionales. Regiones disponibles para despliegues en nube administrada y VPC:

• US East (Virginia) — predeterminada
• US West (Oregon)
• EU West (Fráncfort) — compatible con GDPR
• EU North (Stockholm)
• LATAM (São Paulo)
• APAC (Sídney, Tokio)

Arquitectura de alta disponibilidad

Los despliegues Enterprise se ejecutan en una configuración de alta disponibilidad con conmutación por error automática:

• Replicación de base de datos Multi-AZ con conmutación por error automática
• Servidores de API con balanceo de carga entre zonas de disponibilidad
• Relay de WebSocket con sesiones persistentes y manejo de reconexión
• Clúster de Redis para el estado en tiempo real y el almacenamiento en caché
• Copias de seguridad diarias automáticas con retención de 30 días (configurable)
• Recuperación ante desastres con RPO < 1 hora y RTO < 4 horas

Auditoría y gobernanza

Cada acción en Orquesta se registra con contexto completo. La auditoría Enterprise va más allá del registro estándar con registros de auditoría inmutables, integración con SIEM y políticas de retención configurables.

Registro de auditoría inmutable

Cada evento se escribe en un registro de auditoría de solo anexado que no puede modificarse ni eliminarse, ni siquiera por los Org Owners. Los eventos se encadenan criptográficamente para detectar manipulaciones.

Integración con SIEM

Transmite los eventos de auditoría en tiempo real a tu SIEM o plataforma de gestión de registros. Destinos compatibles:

• Splunk — mediante HEC (HTTP Event Collector)
• Datadog — mediante Log Forwarding API
• Elastic / ELK — mediante la API bulk de Elasticsearch
• AWS CloudWatch — para implementaciones en VPC
• Azure Monitor — mediante workspace de Log Analytics
• Webhook personalizado — cualquier endpoint HTTPS, payload JSON, firmado con HMAC

Flujos de aprobación

Los quality gates Enterprise admiten cadenas de aprobación de varios niveles. Configura los requisitos de aprobación por entorno y tipo de acción:

{
  "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 retención de datos

Configura cuánto tiempo se conserva cada tipo de datos. Cumple los requisitos regulatorios mientras controlas los costos de almacenamiento:

• Registros de auditoría — mínimo 1 año, configurable hasta 7 años (requerido para SOC 2, HIPAA)
• Registros de ejecución — 90 días por defecto, configurable
• Historial de prompts — 1 año por defecto, configurable
• Git diffs — se conservan indefinidamente (vinculados a los commits)
• Grabaciones de sesión — 30 días por defecto, configurable
• Purga automatizada — los datos se eliminan de forma segura al vencer el período de retención

Gestión de costos y presupuestos

La gestión de costos Enterprise da a los líderes de finanzas e ingeniería visibilidad y control totales sobre el gasto en IA de toda la organización.

Controles de presupuesto

Panel de uso

Un panel de análisis Enterprise dedicado ofrece:

• Uso de tokens en tiempo real en todos los proyectos y equipos
• Desglose de costos por proyecto, usuario, equipo y entorno
• Análisis de tendencias históricas con informes mensuales/trimestrales
• Exportación a CSV/PDF para informes financieros
• Atribución de costos de API (qué proveedor de LLM, modelo y nivel)
• Pronósticos basados en tendencias de uso

Integraciones Enterprise

Conecta Orquesta con las herramientas que tu equipo ya utiliza. Las integraciones Enterprise van más allá de los webhooks estándar, con integraciones profundas y bidireccionales.

Sistema de webhooks

El sistema de webhooks Enterprise admite cualquier endpoint HTTPS con eventos configurables, políticas de reintentos y verificación de firma 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 y niveles de soporte

Los clientes Enterprise reciben soporte premium con tiempos de respuesta garantizados y un equipo dedicado de éxito del cliente.

Slack Connect

Los clientes Enterprise obtienen un canal compartido de Slack Connect con el equipo de ingeniería de Orquesta. Accede directamente al equipo que construye el producto para resolver incidencias rápidamente, solicitar funciones y recibir orientación sobre arquitectura.

Cumplimiento y certificaciones

Orquesta se compromete a cumplir los más altos estándares de seguridad y cumplimiento. A continuación se presenta nuestra situación actual de cumplimiento y la hoja de ruta de certificaciones.

Cumplimiento actual

Hoja de ruta de certificaciones

Las siguientes certificaciones están planificadas o en curso como parte de nuestra hoja de ruta de cumplimiento Enterprise:

Prácticas de seguridad

• Pruebas de penetración — Pentest anual por un tercero. Resultados disponibles bajo NDA.
• Programa de bug bounty — Programa de divulgación responsable para investigadores de seguridad.
• Análisis de dependencias — Análisis automatizado de CVE en cada build mediante Snyk/Dependabot.
• Análisis estático — Herramientas SAST integradas en el pipeline de CI/CD.
• Detección de secretos — Hooks de pre-commit y verificaciones de CI evitan la filtración de secretos.
• Seguridad de empleados — Verificación de antecedentes, capacitación en seguridad, acceso de mínimo privilegio, llaves de hardware para la infraestructura.
• Respuesta a incidentes — Plan de IR documentado con acuse de recibo en 1 hora para incidentes P1. Postmortem en un plazo de 72 horas.
• Gestión de proveedores — Todos los subprocesadores se evalúan en cuanto a su postura de seguridad. DPA vigentes con todos los proveedores.

Trust Center

Visita getorquesta.com/trust para acceder a nuestro Trust Center público, que incluye:

• Estado del sistema en tiempo real e historial de disponibilidad
• Whitepaper de seguridad (PDF descargable)
• Formulario de solicitud del informe SOC 2
• Plantilla de DPA (Data Processing Agreement)
• Lista de subprocesadores
• Resumen de pruebas de penetración
• Política de divulgación responsable / bug bounty

Incorporación Enterprise

Cada cliente Enterprise recibe una experiencia de incorporación estructurada para asegurar un tiempo de valor rápido y una adopción exitosa en todos los equipos.

Cronograma de incorporación

Evaluación Enterprise

Ofrecemos un piloto Enterprise de 30 días con acceso a todas las funciones. El piloto incluye:

• Conjunto completo de funciones Enterprise (SSO, RBAC, auditoría, integraciones)
• Hasta 25 usuarios durante el período piloto
• Canal dedicado de Slack Connect con el equipo de Orquesta
• Dos sesiones de incorporación de 1 hora
• Cuestionario de seguridad prellenado
• Prueba de concepto personalizada para tu flujo de trabajo específico