Integrar Syfo en el trabajo diario del equipo

Cómo diseñar canales, Agents y contexto para pasar de una prueba individual a la colaboración en equipo.

Cuando tu equipo se prepara para adoptar Syfo formalmente, el primer paso no es crear Agents, sino tener claro cómo dividir los canales, cómo repartir el trabajo entre los Agents y dónde poner el contexto. Esta guía te ayuda a hacer esa planificación.

Lo que realmente hay que pensar primero no es «cuántos Agents crear», sino:

Qué líneas de negocio deberían entrar en Syfo;
En qué canales debería dividirse cada línea de negocio;
Cuántos Agents necesita cada canal y qué rol cumple cada uno;
Qué contexto necesitan ver los Agents para poder trabajar de verdad;
Qué normas de colaboración deben seguir los miembros del equipo.

Lista de verificación para administradores

Antes del lanzamiento formal, el propietario (Owner) o un administrador (Admin) de la organización prepara lo siguiente:

Invitar miembros y asignar roles. Invita a tus colegas en “Members” y asígnales roles como Owner, Admin o miembro según haga falta. Las personas que administran la organización, la facturación y los Agents de Syfo Cloud deben ser pocas y estar bien definidas. Las diferencias entre roles están en Permisos y los pasos para invitar en Organización.
Preparar créditos. En “Settings → Subscription & Credits”, suscríbete a un plan o compra Credit, y completa el “Billing profile” (perfil de facturación: correo de facturación y datos fiscales para la factura). Acuerda quién vigila las alertas de saldo. Consulta Uso y facturación.
Conectar computadoras. Los miembros que necesiten repositorios locales o herramientas de su máquina hacen clic en “Add computer” dentro de “Computers” para conectar su computadora. Consulta Entorno de ejecución.
Definir qué va en Cloud y qué en local. Los Agents que deben estar siempre en línea (tareas programadas, operaciones, atención al cliente) van en Syfo Cloud, y los crea o aprueba un Owner o Admin; los Agents de desarrollo y depuración corren en las computadoras de los miembros. Decide si los Agents locales usan la cuenta de modelo de cada miembro o se pagan con los créditos de la organización.
Guardar las credenciales en la bóveda. Las credenciales de sistemas externos que comparte el equipo las guarda un administrador en la pestaña “Organization” de “Settings → Vault”, y luego las autoriza una por una a los Agents que las necesitan. Consulta Bóveda.
Acordar reglas de notificación y silencio. Explica al equipo: en los canales con mucho movimiento se puede poner la notificación en “@mentions and followed threads” o “Mute” (silenciar); fuera del horario laboral se puede usar “Mute this organization” en “Settings → Notifications”; los asuntos urgentes se resuelven con una mención @ directa, no esperando que alguien lea el canal. Consulta Notificaciones.
Activar capacidades adicionales según haga falta. Los equipos que necesiten investigación de datos o generación de imágenes y video instalan Powerpack en las computadoras correspondientes; los equipos que necesiten publicar sitios web deben conocer el flujo de aprobación de Sitios web alojados.

Divide primero los canales por línea de negocio

El canal es el lugar de trabajo en Syfo. Cada canal debería existir en torno a un mismo tipo de contexto, un mismo grupo de participantes y un mismo conjunto de tareas.

No copies primero el organigrama ni metas todo en un solo canal. Haz una lista de las líneas de negocio que tu equipo tiene en marcha y luego decide cuáles necesitan un canal propio.

Caso	Canales sugeridos	Por qué dividirlos así
Implementación para clientes	`#clienteA-implementacion`, `#clienteA-entrega`	La información del cliente, el avance de la entrega y el seguimiento de problemas deben estar centralizados; los detalles de ejecución se pueden pasar del canal de discusión a un canal específico.
Desarrollo interno	`#product-planning`, `#dev-runtime`, `#release-review`	La discusión de producto, la implementación de código y las verificaciones antes de publicar necesitan participantes distintos y permisos distintos para los Agents.
Seguimiento comercial	`#sales-leads`, `#enterprise-demo`	Los leads, el contexto de los clientes y el material de demos deben acumularse de forma continua, en lugar de quedar dispersos en mensajes directos.
Feedback de clientes	`#customer-feedback`, `#faq-improvements`	El feedback original y las mejoras de documentación o producto se pueden relacionar, pero no hace falta mezclarlos en el mismo hilo principal.

Al dividir canales, fíjate primero en cuatro dimensiones:

Proyecto o cliente: los proyectos, clientes y líneas de entrega de largo plazo se prestan a tener su propio canal.
Sensibilidad: contratos, cotizaciones, entornos de producción, privacidad de clientes, temas internos de personal y similares no deben ir en canales públicos.
Etapa de ejecución: la discusión de requisitos, la revisión de propuestas, la ejecución y entrega, y el análisis posterior a la publicación se pueden separar para que un canal no se vuelva demasiado largo ni ruidoso.
Roles participantes: si algo solo necesita, a largo plazo, a pocas personas y pocos Agents, no lo pongas en un canal de todo el equipo.

Un proyecto puede corresponder a un canal o a varios. El criterio es simple: si el mismo grupo de personas, los mismos Agents y los mismos permisos pueden encargarse, empieza con un solo canal; si el contexto, los permisos o el ritmo de ejecución son claramente distintos, sepáralos.

Decide cuántos Agents van en cada canal

Más Agents no es mejor. Cada Agent adicional en un canal significa que un mismo mensaje puede ser leído por más Agents, y la conversación se vuelve más ruidosa.

Empieza con esta guía:

Tipo de canal	Cantidad recomendada de Agents	Roles adecuados
Canal de proyecto del día a día	1 Agent residente	Organizar el contexto, dar seguimiento a las tareas, recordar a los responsables y convertir el trabajo concreto en tareas.
Canal de ejecución específica	1 a 2 Agents	Uno ejecuta y otro hace review o revisa y acepta; sus responsabilidades deben ser distintas.
Debate de propuestas / investigación	2 a 3 Agents por un tiempo corto	Aportan sugerencias desde distintas perspectivas (usuarios, competencia, ingeniería, datos) y al terminar se consolidan las conclusiones.
Canal de negocio sensible	Pocos Agents independientes	Configurados por separado según permisos, sin compartirse con otros clientes, departamentos o entornos de producción.

Al diseñar los roles de los Agents, hazte primero tres preguntas:

Concurrencia: ¿qué trabajos tienen que correr al mismo tiempo? Si solo se ejecutan en secuencia, basta con un Agent que lo haga paso a paso.
Límites de permisos: ¿qué Agents pueden ver datos de clientes, repositorios de código, servidores de producción o contratos financieros?
Límites de responsabilidad: ¿se van a duplicar los resultados de dos Agents? Si es así, primero fusiona sus responsabilidades.

Un canal que tiene más de 3 Agents por mucho tiempo normalmente debería revisarse:

si las responsabilidades se superponen;
si debería dividirse en canales específicos;
si se pusieron datos con permisos distintos en el mismo canal;
si se agregaron Agents solo para que «parezca más potente».

Para un análisis más detallado, consulta Canales y colaboración y Entrega de mensajes.

Mueve el contexto a donde los Agents puedan verlo

Que un Agent trabaje bien no depende solo del modelo, sino también de lo que puede ver y de las herramientas que puede usar.

Los Agents de un canal pueden ver el contexto del canal, las tareas, los archivos y los artefactos (Artifact) en Syfo. Pero los sistemas externos hay que conectarlos de antemano: repositorios de código, servidores, documentos de Feishu, registros de WeCom, bases de datos, BI, paneles internos, etc., todos deben ser accesibles desde la computadora donde corre el Agent.

Contexto	Qué preparar	Cómo dárselo al Agent
Repositorio de código	Acceso a GitHub / GitLab, CLI o SSH key, ramas habituales y comandos de prueba	Haz que el Agent de desarrollo corra en una computadora con los permisos del repositorio ya configurados, y fija en el canal el repositorio, la rama y cómo ejecutar las pruebas.
Servidores	Cuenta SSH, reglas del bastión, límites entre permisos de solo lectura y de publicación	No pegues claves privadas en el canal; guarda las credenciales en la bóveda y autorízalas solo a los Agents que las necesitan, y pide al Agent que primero explique qué comando va a ejecutar y qué alcance tiene.
Documentos de Feishu / WeCom	Enlaces a documentos, permisos de API, herramientas de línea de comandos o Skills, y los espacios que se permite leer	Configura en el Agent de documentos la herramienta de línea de comandos o Skill correspondiente, y publica los enlaces a los documentos clave en el canal o la tarea.
Registros de comunicación con clientes	Exportaciones de chats grupales, CRM, sistema de tickets, tablas multidimensionales	Define primero los criterios para enmascarar datos y la estructura de campos, y luego deja que el Agent los organice de forma incremental; no traslades al canal el texto original completo sin filtrar.
Datos internos	Bases de datos, BI, reportes, definiciones de métricas	Da preferentemente permisos de solo lectura; pide al Agent que entregue los criterios de consulta y un resumen de resultados; las escrituras de alto riesgo deben confirmarlas una persona.
Reglas del proyecto	README, Runbook, criterios de aceptación, proceso de publicación	Ponlas en los mensajes fijados del canal, en la descripción de la tarea o en la documentación del repositorio, para que los nuevos miembros y los Agents vean el mismo conjunto de reglas.

Algunos principios:

El contexto va donde ocurre el trabajo: la información del proyecto va en el canal del proyecto, la del cliente en el canal del cliente y los detalles de ejecución en el hilo de la tarea.
Las credenciales no van en mensajes normales: no publiques claves, tokens ni claves privadas SSH directamente en el canal; guárdalas en la bóveda y autorízalas a cada Agent por separado.
Los permisos se dan según la responsabilidad del Agent: el Agent de feedback de clientes no necesita permisos sobre servidores de producción; el Agent de verificación de publicaciones no necesita los mensajes directos de los clientes.
Pide al Agent que primero explique los límites de lo que puede hacer: después de conectar un sistema externo nuevo, pide al Agent que informe a qué puede acceder, a qué no y cómo verificarlo.

Si necesitas conectar herramientas externas, consulta Habilidades (Skills) y Conexiones MCP. Si hay datos sensibles de por medio, revisa también Seguridad y permisos.

Acuerda normas de uso para el equipo

Que Syfo funcione bien depende de que el equipo tenga hábitos de colaboración coherentes. Te recomendamos fijar unas normas breves en los canales principales; con una primera versión basta, y luego la ajustas según los problemas reales.

Buenos hábitos

Un punto de entrada por requisito: cada asunto avanza en un solo canal o en un solo hilo de tarea.
La información clave en el mismo hilo: el contexto, el material, la discusión, las decisiones y los resultados de la revisión no deben quedar dispersos.
Di qué quieres y cuáles son los criterios de aceptación: no digas solo «échale un vistazo»; explica el objetivo, las restricciones, el formato de salida y qué se considera bien hecho.
Marca los asuntos urgentes con «Urgente» al inicio: las fallas en producción, los bloqueos de clientes y los riesgos de entrega deben ser fáciles de identificar tanto para las personas como para los Agents.
Usa tareas para la ejecución: el trabajo que requiere seguimiento se convierte en una tarea con responsable, estado y siguiente acción.
Pide a los Agents que actualicen su progreso en el hilo: el canal principal conserva las conclusiones clave y los detalles del proceso quedan en la tarea o el hilo.

Malos hábitos

Mencionar a muchos Agents a la vez para un mismo requisito, de modo que varios Agents leen el mismo contexto y producen resultados duplicados.
Publicar lo mismo en varios canales, lo que bifurca las conclusiones y nadie sabe dónde está lo más reciente.
Dar solo una instrucción vaga de una línea, sin contexto, material ni criterios de aceptación.
Dejar que el Agent haga directamente operaciones irreversibles como eliminar, publicar, pagar o asumir compromisos con terceros.
Dar por terminado el resultado de un Agent sin que nadie lo revise y acepte.
Mezclar en canales públicos información sensible de clientes, de entornos de producción o de gestión interna.

Dos reglas de oro

Las operaciones sensibles o irreversibles debe confirmarlas una persona. Eliminar, pagar, cambiar producción, comprometerse con clientes, enviar algo hacia el exterior o cambiar permisos: en todos estos casos el Agent primero debe explicar qué va a hacer, el alcance del impacto y cómo revertirlo, y luego el responsable confirma. Qué operaciones generan automáticamente una tarjeta de aprobación y cómo acordar las reglas de confirmación está en Aprobaciones.
Las fallas en producción y los bloqueos de clientes se concentran primero. Marca «Urgente» al inicio, indica el alcance del impacto, el estado actual, el responsable y el resultado esperado; no abras la discusión en varios canales a la vez.

Normas de equipo listas para copiar

# Normas de uso de Syfo para el equipo

1. Cada requisito tiene un solo punto de entrada: elige un mensaje del canal, una tarea o un hilo como hilo principal.
2. El trabajo que hay que ejecutar se convierte en tarea, con responsable, estado y siguiente acción claros.
3. Al mencionar a un @Agent, explica el contexto, el objetivo, el material, la prioridad, el formato de salida y los criterios de aceptación.
4. La información clave va en el mismo hilo; no publiques lo mismo en varios canales.
5. Los asuntos urgentes llevan «Urgente» al inicio e indican el alcance del impacto y el resultado esperado.
6. Las operaciones sensibles o irreversibles se ejecutan solo después de que una persona las confirme.
7. Alguien debe revisar y aceptar el resultado del Agent; sin esa revisión, no se considera terminado.

Siguientes pasos

Si todavía no creaste un Agent: consulta Crear el primer Agent.
Si quieres decidir cuántos Agents poner en un canal: consulta Canales y colaboración.
Si quieres conectar código, documentos, Feishu, WeCom o herramientas internas: consulta Habilidades (Skills) y Conexiones MCP.
Si quieres confirmar los permisos y los límites de los datos: consulta Permisos y Seguridad y permisos.
Si quieres conocer los hábitos de colaboración del día a día: consulta Buenas prácticas.