Cómo funciona ElevenAgents Architect
Qué sabe ElevenAgents Architect cuando comienza una conversación, cómo investiga y cómo convierte una pregunta en un cambio validado.
Información general
Una conversación con ElevenAgents Architect se ejecuta como una conversación de ElevenAgents en tiempo real, en el mismo motor que impulsa los agentes que creas. Las herramientas de Architect se ejecutan en tu navegador, con tu sesión iniciada. Cada herramienta llama a las mismas API de ElevenAgents que usa el panel, por lo que cada lectura y escritura se comprueba con tus propios permisos. Consulta Permisos, aprobaciones y borradores.
Lo que ElevenAgents Architect sabe de forma predeterminada
Al inicio de cada conversación, Architect recibe:
- Tu cuenta y espacio de trabajo: tu plan, espacio de trabajo y uso.
- Dónde estás: la página y, cuando estás dentro de un agente, ese agente y la rama que tienes abierta. En la barra lateral, Architect también recibe una instantánea de la página y una actualización antes de cada mensaje si la página ha cambiado.
- Un resumen del agente: creado por ElevenLabs cuando estás dentro de un agente. Incluye el nombre y propietario del agente, sus ramas y su reparto de tráfico, el volumen de llamadas de los últimos 7 días, el estado del borrador, los agentes conectados, los procedimientos, si hay pruebas configuradas y qué ramas puedes editar.
- Contexto del agente: el documento
agents.mddel agente, compartido con todas las personas que crean el agente. Consulta Personalizar Architect. - Tus preferencias: tu documento personal
user.md, que se aplica a todos los agentes que creas. - Lo que ha enviado el punto de entrada: por ejemplo, las pruebas que han fallado, el hallazgo de Spotlight o el ticket de triaje. Consulta Iniciar una conversación.
- Los mensajes anteriores de este chat.
Architect no comienza con la configuración completa del agente, sus transcripciones, los resultados de las pruebas, los datos de Spotlight ni tus otros chats con Architect. Lee estos datos con herramientas cuando la tarea los necesita. Así, cada conversación se mantiene centrada y Architect siempre trabaja con datos actuales, en lugar de con una copia desactualizada.
Investigaciones e instrucciones directas
Architect gestiona de forma distinta dos tipos de solicitudes.
Las instrucciones directas indican el cambio, por ejemplo, “Añade una protección que bloquee las conversaciones sobre precios de la competencia” o “Haz que el primer mensaje sea más corto”. Architect lee la configuración pertinente, realiza la edición e informa de lo que ha preparado. En el modo de aprobación predeterminado, las ediciones de la configuración del agente se preparan en un borrador sin preguntarte. Las acciones que afectan al tráfico en directo o a recursos compartidos esperan tu aprobación.
Las investigaciones plantean una pregunta sin indicar una solución, por ejemplo, “¿Por qué se escalan las llamadas sobre reembolsos?” o “¿Cómo mejoro la resolución de reembolsos?”. Architect investiga antes de cambiar nada:
- Escribe una lista de tareas para la investigación, que permanece visible encima del editor a medida que se completan los elementos.
- Empieza por señales poco costosas, como recuentos de conversaciones, temas y resultados de evaluaciones, antes de leer transcripciones individuales.
- Analiza conversaciones en paralelo y agrupa lo que encuentra por causa raíz.
- Su razonamiento es visible. Cada paso de razonamiento se contrae como Pensamiento durante Ns y se puede expandir.
- Informa de lo que ha encontrado, incluido cuántas conversaciones ha leído realmente. No presenta una muestra como si fuera exhaustiva.
Modo Plan
Para cambios más grandes, cambia el editor a Plan (pulsa Shift+Tab para alternar entre modos). En el modo Plan, Architect investiga con herramientas de solo lectura, escribe un plan que puedes ver mientras lo redacta y luego te pide que Apruebes el plan o lo Rechaces. No realiza cambios hasta que lo apruebas. Si rechazas el plan con una nota, Architect lo revisa y vuelve a preguntarte.
En la pestaña de Architect a pantalla completa, el plan aparece en un panel encima del editor. En la barra lateral, aparece como una tarjeta en el chat.
Ejemplo práctico: mejorar la resolución de reembolsos
Este ejemplo sigue una única conversación, desde una pregunta general hasta un cambio listo para revisar. Se muestran los nombres de las herramientas para que puedas relacionar cada paso con lo que aparece en la conversación. Architect elige sus propios pasos, por lo que una conversación real puede diferir en orden y detalle.
La solicitud, enviada desde la pestaña Architect del agente:
¿Cómo mejoro la resolución de reembolsos?
Planificar la investigación
Architect escribe una lista de tareas (write_todos): medir el problema, encontrar conversaciones
fallidas sobre reembolsos, identificar las causas raíz, proponer y probar una solución.
Medir el problema
Architect lee los temas del agente (get_agent_topics, get_topics_summary) para encontrar el tema de
los reembolsos y su tasa de éxito; después cuenta y enumera las conversaciones recientes sobre reembolsos
que no superaron la evaluación (count_conversations, list_conversations).
Leer las conversaciones
Architect busca solicitudes de reembolso en las transcripciones (search_conversation_messages,
semantic_search_conversations) y después analiza en paralelo un lote de conversaciones fallidas
(analyze_conversation_subagent). Cada análisis informa de lo que quería el usuario, dónde se equivocó el agente
y el turno en el que ocurrió.
Encontrar la causa raíz
Architect compara los fallos con la configuración actual (get_agent_config,
list_procedures, get_procedure). Informa de un hallazgo como: “En 31 de las 40 llamadas fallidas
sobre reembolsos, el agente llamó a lookup_order antes de pedir el número de pedido, recibió un error y
escaló la llamada.”
Realizar el cambio en una rama
Architect crea una rama (create_branch) para aislar el cambio del agente en directo. A continuación,
edita el procedimiento de reembolso (update_procedure) para pedir el número de pedido antes de la
consulta. La edición se prepara en tu borrador de esa rama. No ha cambiado nada para quienes llaman en directo.
Escribir pruebas para el cambio
Architect escribe pruebas que recogen el fallo: una simulación de una persona que llama para pedir un reembolso
sin proporcionar un número de pedido (create_simulation_test), una prueba de llamada a herramienta que comprueba que
lookup_order no se llama primero (create_tool_test) y una prueba generada a partir de una de las
conversaciones fallidas reales (generate_test_from_conversation). Architect simula las herramientas que tienen
efectos secundarios en las simulaciones, por lo que no se emiten reembolsos reales.
Ejecutar las pruebas antes y después
Architect ejecuta las pruebas con el agente sin el cambio (run_tests en la rama original,
o run_agent_tests con include_draft: false) y después con el borrador que contiene el
cambio (run_agent_tests), y lee los resultados (get_test_suite_summary,
get_test_suite_failures). El resultado esperado es que las nuevas pruebas fallen sin el cambio
y lo superen con él. Si las pruebas siguen fallando, Architect lee los fallos, ajusta el cambio y
vuelve a ejecutarlas.
Presentar el cambio
Architect resume la causa raíz, el cambio y los resultados de las pruebas, y abre el diálogo de
publicación (request_draft_publish). Revisas el diff y seleccionas Publicar, lo que confirma el
cambio como una nueva versión en la rama. Architect no puede publicar por ti.
Abrir una propuesta
Architect lee el historial de la rama y la vista previa de fusión (get_branch_history,
merge_branch_preview) y abre una propuesta de fusión en main (create_merge_proposal). La
descripción tiene tres secciones, Resumen, Pruebas y Cómo revisar, redactadas a partir de
los commits y ejecuciones de pruebas reales. Architect puede sugerir revisores
(suggest_merge_proposal_reviewers), pero tú los eliges.
La validación se realiza dentro de la conversación, antes de que se te pida publicar o revisar nada. Cuando la propuesta llega a una persona revisora, las pruebas que motivaron el cambio ya están asociadas al agente y se han ejecutado en la rama. Consulta Propuestas y validación para saber qué ve la persona revisora.
Ejecutar las pruebas antes y después es una buena práctica, pero Architect no lo hace automáticamente en cada cambio. Para asegurarte de que lo haga, pídeselo directamente, por ejemplo: “Muéstrame las nuevas pruebas fallando en main y superándose en la rama.”
Comandos de barra
Escribe / en el editor para ver los comandos disponibles en la página actual.
La mayoría de los comandos solo se aplican cuando estás dentro de un agente. /clear y /feedback no están disponibles en la página de inicio de la pestaña Architect.
Paneles en el chat
Architect puede crear un panel en la conversación para responder a una pregunta con datos, por ejemplo: “Desglosa las escaladas de esta semana por motivo y muéstrame la tendencia”. Usa /dashboard o pide uno directamente.
Architect recopila los datos con sus herramientas, les da forma con código y muestra un panel creado con las mismas tarjetas de métricas, gráficos, listas y tarjetas de texto que Spotlight. Un panel puede incluir:
- Tarjetas de métricas con un valor principal, cambio y minigráfico.
- Gráficos: de área, líneas, barras, áreas apiladas, anillos y listas de barras clasificadas para desgloses de los N elementos principales.
- Listas con etiquetas de estado, fechas y enlaces a páginas de ElevenAgents, como conversaciones individuales.
- Tarjetas de texto para hallazgos y recomendaciones.
En la pestaña de Architect a pantalla completa, los paneles se muestran en línea dentro de la conversación. En la barra lateral, se abren en un panel junto al chat.
Los datos del panel solo se conservan en la memoria de la pestaña del navegador donde se creó y nunca se guardan con el chat. Después de recargar la página, abrir el chat en otra pestaña o crear varios paneles grandes, un panel antiguo muestra un mensaje en lugar de sus datos. Pide a Architect que lo vuelva a crear. Los paneles son instantáneas de solo lectura. No tienen filtros ni se actualizan en directo.
Ejecutar código
Architect puede ejecutar programas cortos de Python para contar, agrupar y comparar datos de sus herramientas, por ejemplo, para calcular las tasas de resolución por semana en varios cientos de conversaciones. El código se ejecuta en un entorno aislado de tu navegador y solo cuenta con la biblioteca estándar de Python. No tiene acceso a la red ni a tu cuenta de ElevenLabs, y tiene un límite de tiempo de 20 segundos. La ejecución de código se está implementando gradualmente y puede que no esté disponible en todos los espacios de trabajo.
Respuestas grandes
Cuando una herramienta devuelve más datos de los que caben en la conversación, como una lista larga de conversaciones, Architect conserva la respuesta completa en la memoria de la pestaña de tu navegador y trabaja con un resumen. Puede buscar y leer el resto cuando lo necesite. Un aviso en la llamada a la herramienta muestra cuándo ha ocurrido esto. Estas respuestas nunca se guardan ni se suben.