01 · TABLEROS
Tableros con etapas propias
Las columnas llevan el nombre de cómo entrega el equipo. Cada etapa define qué agente trabaja y quién aprueba.
Octopus · by Mister.D
Un pipeline de entrega operado por agentes. Gobernado por tu equipo.
Cada tarea pasa por análisis, desarrollo, testing y revisión con un agente de Claude en cada etapa, un auditor que puede bloquear el trabajo y una persona del equipo que aprueba antes de cada merge.
checkout-squad · tablero en vivo
Backlog 3
RB-1284 A
El checkout falla en Safari
Análisis 1
analista
Desarrollo 1
agente dev
Testing 1
agente QA
Revisión gate
auditor
Aprobado por Ana
Listo 2
log de la corrida
00:14 análisis · 6 casos de prueba desde RB-1284
03:52 dev · push de la rama fix/checkout-safari
07:31 test · 6/6 ok · video anotado adjunto
08:05 auditor · APPROVE → revisión humana
PR #212 mergeado en main
- 1 comando para instalarlo en tu infraestructura: octopus init
- 24h de vida máxima para la API key de cada corrida
- hasta 450% más rápido el QA, con videos anotados como evidencia
Automatización de flujos
El proceso de entrega del equipo, corriendo como pipeline.
Se definen las etapas que el equipo ya usa. Octopus pone un agente especializado en cada una, un auditor en cada traspaso y una persona en las puertas que importan. Entra un ticket; sale un cambio revisado, probado y desplegado.
- 01 · Ingreso
Llega un ticket al tablero
Desde el tablero, la API o una automatización. Entra en la primera etapa de un pipeline configurado a medida, con sus agentes y sus reglas.
- 02 · Análisis
El agente de análisis lee el ticket y el repo
Revisa el código que toca el ticket, escribe criterios de aceptación y los convierte en casos de prueba concretos antes de escribir una línea.
- 03 · Planificación
Un plan que el auditor puede verificar
Archivos a cambiar, subtareas, riesgos. El agente auditor lo aprueba, pide cambios o lo bloquea con el motivo escrito en la tarea.
- 04 · Desarrollo
Código en un sandbox aislado
Cada corrida tiene su propio contenedor o microVM y una API key de vida corta limitada a esa corrida. El agente crea la rama, commitea y abre el pull request.
- 05 · Testing
Los casos de prueba corren en un navegador real
El agente de testing ejecuta cada caso, toma capturas y graba un video anotado con cada paso y su resultado. Todo queda adjunto a la tarea.
- 06 · Revisión y deploy
Auditor, después una persona, después producción
El auditor revisa el PR, una persona aprueba en la puerta de revisión y el merge dispara el deploy con GitHub Actions.
Automatizaciones
Cuando algo pasa, el siguiente paso corre solo.
Los disparadores miran el tablero: tarea nueva, cambio de etapa, comentario, PR mergeado o un horario. Las condiciones los acotan. Las acciones asignan un agente, mueven la etapa, notifican o corren un pipeline.
automation.yaml
QA al entrar
Cuando La tarea pasa a Test
Si Tablero = Web app
Entonces
Correr agente de QAAdjuntar video a la tareaAvisar al revisor
Deploy al mergear
Cuando Se mergea un pull request
Si Rama = main
Entonces
Deploy a staging con GitHub ActionsMover tarea a HechoAvisar al canal
Reporte semanal
Cuando Cada lunes 9:00
Si Workspace = Producto
Entonces
Correr agente de métricasArmar dashboardComentar resumen
- 01
Etapas propias por tablero
Se nombran, se ordenan, se agregan o se quitan. Cada tablero corre su propio proceso.
- 02
Un agente por etapa
Cada etapa tiene su prompt, sus herramientas y sus permisos MCP, hasta lectura o escritura por herramienta.
- 03
Puertas de aprobación humana
Se eligen las etapas donde firma una persona. Nada se mergea sin esa firma.
- 04
Disparadores y horarios
Eventos o cron arrancan el trabajo. Nadie tiene que acordarse de empujar el ticket.
Testing y QA
Cada caso de prueba vuelve como un video anotado.
Octopus lee el ticket y sus criterios de aceptación, escribe los casos de prueba, ejecuta cada uno en un navegador real y adjunta la grabación a la tarea. Cada paso queda marcado en el video: qué se clickeó, qué se escribió, qué se verificó y dónde falló. QA mira, aprueba o comenta.
hasta 450% más rápidas las revisiones de QA 45 min de reproducción manual por ticket pasan a ~10 min mirando el video y aprobando.
- 01 Analizar
Casos de prueba desde el ticket
El agente de testing lee el ticket y los criterios de aceptación y escribe los casos, bordes incluidos, cada uno con prioridad.
CHK-142 · Códigos de descuento + tarjeta rechazada- TC-01 Login con credenciales válidas P1
- TC-02 Agregar producto al carrito P1
- TC-03 Aplicar código de descuento P0
- TC-04 Pagar desde Safari 17 P1
- TC-05 Carrito vacío (caso borde) P2
- TC-06 Mensaje de error con tarjeta rechazada P0
- 02 Ejecutar
Corre en un navegador real
Cada caso corre en un navegador real dentro del sandbox aislado de la corrida. Se graban clicks, tipeo, navegación, consola y red.
Ejecutando 6 casos- TC-01 0:12 ✓
- TC-02 0:21 ✓
- TC-03 0:34 ✓
- TC-04 0:29 ✓
- TC-05 0:09 ✓
- TC-06 0:48 ✗
- 03 Entregar
Video + reporte en la tarea
Un video anotado por caso y un reporte pass/fail quedan en la tarea. Cada falla abre un comentario con el paso exacto que se rompió.
Adjunto en CHK-142tc-06_tarjeta-rechazada.webmreporte-de-pruebas.pdfO TC-06 falló en el paso 4: no aparece el banner “Tarjeta rechazada” después del pago.
CHK-142 · corrida de checkout · anotada REC
verificación OK verificación fallida issue marcado
De dónde sale el 450%
- Leer el ticket
- Preparar datos
- Reproducir
- Capturar pantalla
- Escribir el reporte
- Mirar un video anotado de 2 min
- Aprobar o comentar
4,5× más rápido por ticket
Qué recibe QA en cada corrida
- Video anotado por caso de prueba
- Captura en cada verificación
- Reporte pass/fail
- Errores de consola y red capturados
- Pasos reproducibles, en orden
- Todo adjunto a la tarea
Agendar una demo La corremos sobre un ticket real de tu equipo.
Funcionalidades
Todo lo que el pipeline necesita, en un solo lugar
Dieciséis piezas que llevan una tarea del tablero a producción, con un agente en cada etapa y una persona en cada aprobación.
02 · AGENTES
Un especialista por etapa
Análisis, planificación, desarrollo, testing y revisión: cada uno con su prompt, sus herramientas y sus permisos.
03 · AUDITOR
Un auditor en cada traspaso
Un segundo agente revisa el resultado y responde aprobar, pedir cambios o bloquear.
04 · APROBACIONES
Las personas aprueban
Nada llega a revisión ni a producción hasta que alguien del equipo aprueba.
05 · GITHUB APP
Ramas, commits, PRs y deploys
Los agentes crean la rama, commitean, abren el pull request y disparan el deploy de GitHub Actions con la GitHub App de Octopus.
06 · NAVEGADOR
Un navegador real con cámara
Los agentes recorren la app, sacan capturas y graban video con anotaciones sobre el elemento exacto que falló.
07 · AISLAMIENTO
Un sandbox nuevo por corrida
Cada corrida tiene su propio contenedor o microVM en Kubernetes, y se destruye al terminar.
08 · MCP
Herramientas con permisos por tool
GitHub, navegador, sandbox de código y la API de Octopus por MCP. Lectura o escritura, tool por tool.
09 · AUTOMATIZACIONES
Disparadores que mueven el trabajo
Tarea nueva, cambio de etapa, comentario, PR mergeado o un horario: asignar agente, mover etapa, notificar, correr el pipeline.
10 · CHAT
Conversar con el agente en la tarea
Preguntar por qué, sumar contexto o cambiar el rumbo sin salir del ticket.
11 · EVIDENCIA
Pruebas en cada tarea
Capturas, PDFs, videos anotados y logs quedan en la tarea que los generó.
12 · MÉTRICAS
Métricas y dashboards propios
Definir los números que importan al equipo, como lead time, retrabajo o aprobaciones por etapa, y graficarlos por workspace.
13 · BYOK
Tu propia key de Claude
Los agentes corren sobre Claude con la key de Anthropic del equipo. Consumo, factura y límites propios.
14 · WORKSPACES
Workspaces, roles y keys acotadas
Cada API key pertenece a un workspace con permisos explícitos. Cada corrida recibe una key propia de vida corta.
15 · IDENTIDAD
SSO, passkeys y log de auditoría
SAML y passkeys con MisterD ID. Cada acción sensible queda registrada en el log de auditoría.
16 · DEPLOY
Corre en tus servidores
Se instala en tu infraestructura con Docker Compose o Helm. Funciones de equipo con una license key. Exportar e importar un workspace completo.
Gobierno y seguridad
Los agentes hacen el trabajo.
Las llaves quedan en tus manos.
Cada corrida arranca en un sandbox nuevo, recibe una key limitada a una sola tarea, usa sólo las herramientas permitidas y pasa por un auditor y por una persona antes de salir. Cada paso queda en el log de auditoría.
- 14:02:11 run#8812 key minted scope=task:1284 ttl=24h
- 14:02:12 run#8812 sandbox up microvm=kata-7f3a
- 14:02:19 run#8812 mcp github.branch_create @write ok
- 14:04:37 run#8812 mcp browser.screenshot ok
- 14:06:02 run#8812 mcp octopus.task_get @read ok
- 14:06:03 run#8812 mcp octopus.task_update denied scope=@read
- 14:09:48 run#8812 mcp github.pull_request_open @write ok
- 14:10:05 auditor verdict=approve stage=review
- 14:12:40 human gate approved by reviewer role=admin
- 14:12:41 run#8812 key revoked sandbox destroyed
Seis garantías en cada corrida
-
Aislamiento por corrida
Cada corrida tiene su propio container o microVM en Kubernetes. Nada pasa a la siguiente.
-
Keys cortas y con alcance
Una API key nueva por corrida, limitada a su tarea y workspace, que vence sola.
-
Permisos por herramienta
Se concede escritura en GitHub, navegador, sandbox o lectura de la API de Octopus herramienta por herramienta. Lectura y escritura van por separado.
-
Auditor + gates humanos
Un agente auditor aprueba, pide cambios o bloquea cada etapa. Las personas firman en los gates de revisión.
-
Log de auditoría completo
Keys emitidas, herramientas usadas, veredictos y aprobaciones, con hora y la corrida responsable.
-
SSO (SAML) y passkeys
Ingreso con MisterD ID. Workspaces con roles y API keys por workspace.
Se instala en tus servidores. Se licencia por equipo.
Todo corre en tus servidores
Octopus se instala donde decidas: tu cuenta de nube, tu data center o un solo servidor. El código, los sandboxes, la evidencia y los logs quedan ahí. La única llamada hacia afuera va a Claude, con tu propia key.
$ octopus init✓ imágenes descargadas (daemon, web, postgres)✓ workspace creado, key de admin emitida→ Octopus listo en http://localhost:8585
- Docker Compose con un comando, o Kubernetes con Helm
- Tu key de Claude: el uso del modelo se factura a tu cuenta
- Exportar e importar un workspace completo
Licencia por equipo
Una license key activa las funciones de equipo en tu propia instalación. El precio depende del tamaño del equipo; lo definimos en la demo.
- Varios workspaces con roles
- Proveedores SSO y exportación del log de auditoría (CSV, JSON, SIEM)
- Helm chart para Kubernetes y soporte prioritario
Licencias
Tus servidores. Tu key de Claude.
Una licencia por equipo.
Instalás Octopus en tus propios servidores, cargás una license key para activar las funciones de equipo y conectás tu propia API key de Claude. El código, los sandboxes, la evidencia y los logs quedan de tu lado. La única llamada hacia afuera va a Claude.
- 01
Instalalo en tus servidores
Tu cuenta de nube, tu data center o un solo servidor. Un comando con Docker Compose, o un Helm chart en Kubernetes. El código, los sandboxes, la evidencia y los logs quedan ahí.
- 02
Activá tu licencia de equipo
Cargás la license key en tu propia instalación y se activan las funciones de equipo. La key tiene fecha de vencimiento; para renovar, instalás una key nueva. Sin reinstalar.
- 03
Conectá tu key de Claude
Octopus llama a Claude con tu propia API key. Anthropic factura el uso del modelo directo a tu cuenta. No le sumamos recargo.
Instalación base vs licencia de equipo
| Función | Base corre sin license key | Recomendada para equipos Licencia de equipo license key en tu instalación |
|---|---|---|
| Tablero, proyectos y agentes | ||
| Sandbox Docker por corrida | ||
| Vista del log de auditoría | ||
| Workspaces | Uno | Varios |
| Proveedores SSO | Uno | Ilimitados |
| Usuarios con roles | — | |
| Exportación del log de auditoría (CSV, JSON, SIEM) | — | |
| Helm chart para Kubernetes | — | |
| Soporte prioritario | — |
La licencia de equipo incluye actualizaciones mientras la licencia está activa. Se licencia por equipo; el precio depende del tamaño del equipo.
Qué pagás
Licencia de equipo de Octopus Precio según el tamaño del equipo.
Uso de Claude Anthropic lo factura a tu propia key.
Definimos la licencia con vos en la demo.
Pedir cotización de licenciaReservar demo
Mirá a Octopus trabajar sobre tu propio backlog
Demo de 30 minutos. Traé un ticket real y lo pasamos por el pipeline en vivo.
- 01 El ticket va del análisis al pull request en pantalla
- 02 Evidencia de QA: video anotado, capturas y reporte en la tarea
- 03 Instalado en tus servidores: armamos el setup sobre tu infraestructura y dimensionamos la licencia del equipo
Recibimos el pedido de demo
Respondemos en un día hábil con horarios. Mientras tanto, elegí el ticket.
Preguntas
Antes de la llamada
¿Qué modelo de IA usa?
Claude. Usás tu propia key de Anthropic, así el consumo se factura a tu cuenta y rigen tus límites.
¿Dónde corre mi código?
Cada corrida tiene su propio sandbox aislado y una API key de vida corta limitada a esa corrida. Todo corre en los servidores donde se instala Octopus: los tuyos.
¿Se puede personalizar el pipeline?
Sí, por tablero: etapas, el agente de cada etapa, sus prompts, las herramientas que puede usar (con permisos de lectura o escritura) y las automatizaciones que mueven el trabajo.
¿Cómo recibe QA la evidencia?
El agente de testing adjunta a la tarea videos anotados, capturas y un reporte de pruebas. QA revisa la evidencia en lugar de reproducir cada caso a mano.
¿Cuánto lleva arrancar?
Un comando, octopus init, levanta todo el stack con Docker Compose en tu servidor. Para Kubernetes hay un Helm chart.
¿Cómo se licencia para equipos?
Por equipo, con una license key que se instala en tus propios servidores. Activa varios workspaces, proveedores SSO, exportación del log de auditoría, el Helm chart y soporte prioritario. El uso del modelo va por tu propia key de Claude.