Permisos, aprobaciones y borradores

Cómo se autentica ElevenAgents Architect

Architect no usa una cuenta de servicio independiente ni actúa como una identidad distinta. En el panel de ElevenLabs, sus herramientas se ejecutan en tu navegador, dentro de tu sesión iniciada. Cada lectura o escritura que realiza, desde obtener la configuración de un agente hasta crear una rama, es una solicitud normal realizada como tú y con los permisos de tu espacio de trabajo.

Esto tiene tres consecuencias:

• Architect solo puede hacer lo que tú puedes hacer. Si no puedes editar un agente, Architect puede leerlo, pero no preparar cambios en él. Si tu rol no permite fusionar en una rama protegida, Architect tampoco puede hacerlo.
• Su trabajo queda registrado con tu nombre. Las versiones que publicas, las ramas y las propuestas de fusión que crea Architect te muestran como autor. Nada indica que las haya creado Architect.
• Distintos usuarios obtienen resultados distintos. Dos miembros del equipo que pidan a Architect el mismo cambio pueden obtener resultados diferentes si sus roles son distintos.

Qué permite cada rol

Los roles de acceso al agente se aplican a Architect exactamente igual que se te aplican a ti en el panel.

Los recursos del espacio de trabajo, como las herramientas, los documentos de la base de conocimiento y las pruebas, siguen sus propios permisos de uso compartido. Consulta Lo que Architect puede cambiar para saber qué acciones se aplican al agente y cuáles al espacio de trabajo.

Modos de aprobación

Cada conversación con Architect se ejecuta en uno de tres modos. Cambia de modo desde el selector del editor o pulsa Shift+Tab para alternar entre ellos.

Tu elección de modo se recuerda en tu navegador. No hay ninguna configuración del espacio de trabajo que obligue a todos a usar un modo. Para exigir revisión en cada cambio de un agente en directo, protege su rama main para que los cambios deban pasar por una propuesta de fusión aprobada.

Qué acciones piden confirmación primero

En el modo de Aprobación obligatoria, Architect prepara los cambios en la configuración del agente en tu borrador sin pedir confirmación, porque un borrador nunca afecta a quienes llaman en directo. Pide confirmación antes de:

• Cambios que tienen efecto inmediato para quienes llaman en directo: fusionar una rama y cambiar la división de tráfico.
• Cambios en recursos compartidos del espacio de trabajo: crear, actualizar o eliminar herramientas, actualizar o eliminar pruebas y la mayoría de cambios en la base de conocimiento.
• Acciones destructivas: descartar un borrador, eliminar un procedimiento, archivar un agente o una rama.
• Acciones en el mundo real: realizar una llamada telefónica de prueba.

Las lecturas nunca piden confirmación. La solicitud de aprobación marca con la etiqueta Permanente las eliminaciones que no se pueden deshacer. La lista completa de acciones que piden confirmación primero está en Lo que Architect puede cambiar.

Siempre necesitas intervenir en tres pasos, en todos los modos:

• Publicar un borrador. Architect abre el cuadro de diálogo de publicación y tú seleccionas Publicar.
• Aprobar un plan en el modo Plan.
• Decidir qué hacer con un borrador existente. Si la rama ya tiene un borrador que Architect no creó en este chat, incluidas las ediciones sin guardar en el editor, Architect se detiene y pregunta si quieres conservarlo o descartarlo antes de preparar nada.

Confiar en una herramienta durante la sesión

La solicitud de aprobación tiene una casilla Confiar en estas herramientas durante esta sesión. Al seleccionarla, las llamadas posteriores a las mismas herramientas durante esa sesión se ejecutan sin preguntar. La confianza termina cuando inicias una nueva conversación. Si no respondes a una solicitud de aprobación en unos dos minutos, la solicitud caduca y Architect no ejecuta la acción.

Borradores, versiones y ramas

Architect usa el mismo modelo de versionado que el resto de ElevenAgents.

«Nada se publica sin tu aprobación» tiene un significado preciso:

• Los cambios en la configuración de un agente se preparan en un borrador y solo llegan a quienes llaman en directo después de que publiques, en una rama que recibe tráfico.
• En el modo de Aprobación obligatoria, las acciones que afectan al tráfico en directo o a recursos compartidos esperan tu aprobación.
• En el modo de Aprobación automática, Architect sigue sin poder publicar, pero puede fusionar ramas y cambiar divisiones de tráfico sin preguntar, dentro de tus permisos.

Algunos cambios fuera de la configuración del agente surten efecto en el espacio de trabajo en cuanto se realizan, como crear una herramienta o un documento de la base de conocimiento. No afectan al comportamiento del agente hasta que los usa, lo que ocurre cuando publicas un borrador que los vincula. Los recursos del espacio de trabajo que ya están vinculados a agentes en directo son la excepción: actualizar una herramienta que usa un agente en directo cambia ese agente inmediatamente. Architect pide confirmación antes de actualizar herramientas en el modo de Aprobación obligatoria.

Historial de versiones y reversión

Cada versión publicada registra qué cambió y quién la publicó.

• Ver qué cambió: en Control de versiones > Ramas, abre el Historial de versiones de una rama. Compara cualquier versión con la anterior o con la versión en directo. También puedes preguntarle a Architect, por ejemplo: «¿Qué cambió en main durante la última semana?». Lee el historial de la rama y compara las versiones por ti.
• Ver quién lo cambió: cada versión muestra el usuario que la publicó. Un cambio realizado por Architect muestra el usuario que estaba hablando con él.
• Revertir: selecciona Revertir a esta versión en el historial de versiones. Revertir no elimina el historial. Publica la configuración antigua como una versión nueva. También puedes usar /rollback para que Architect revise los cambios recientes y prepare una reversión para que la publiques.