Cómo puede el agente de un desarrollador preguntar a Producto antes de programar
Ingeniería sigue avanzando mientras Producto o Negocio responde mediante un agente apoyado en los criterios, conocimiento, datos autorizados y herramientas de su propietario.
Revisado con Agents City 0.3.0-beta.22 · commit c985198 ↗El problema real
Un desarrollador y sus agentes descubren una decisión de producto a mitad de la implementación. La persona de Producto o Negocio está reunida: preguntar significa esperar; no preguntar significa terminar el flujo equivocado y abrir después otro ciclo de revisión. Las dos personas son productivas, pero su contexto permanece aislado.
Resultado buscado
El presidente de Ingeniería envía una pregunta atribuida y acotada al presidente de la otra persona. Si la respuesta ya está cubierta por el contexto que ese propietario ha configurado, su agente activo responde sin interrumpirlo. Un posicionamiento, riesgo, conflicto o autoridad nuevos se escalan al humano.
ingeniería ↔ producto
ciudad-ingenieriapresidente del desarrolladorDetecta la decisión, resume el cambio propuesto y pregunta antes de implementar
ciudad-productopresidente de producto o negocioResponde desde criterios y conocimiento configurados deliberadamente por su propietario
contexto-localevidencia controlada por el propietarioDocumentos, bases de datos, skills y herramientas ya autorizados en ese ordenador
persona-responsablelímite de escaladoResuelve posicionamiento, riesgo, excepciones y conflictos nuevos que nunca ha delegado
Antes de empezar
- 01
Cada propietario tiene un asiento local de Agents City y una sesión de agente capaz de recibir mensajes del canal. Si la ciudad receptora está offline, el bus conserva el texto hasta tres días.
- 02
La persona de Producto o Negocio ha escrito qué puede responder su agente, qué fuentes puede consultar y qué decisiones deben llegarle. El acceso existente a datos y herramientas permanece configurado en su propio runtime.
- 03
Una Road explícita o un bus autoalojado admite a esos dos presidentes exactos e Ingeniería puede formular una pregunta concreta con evidencia suficiente.
Cómo hacerlo
Paso 01 Prepara el asiento local de cada propietario
En cada ordenador, crea y arranca la ciudad que pertenece a esa persona. El asiento es la única ventana autorizada para cruzar Roads; los agentes de repositorio o conocimiento permanecen locales y no reciben mensajes remotos directamente.
$agents-city cities create engineering$agents-city seat --city engineering$agents-city cities create product$agents-city seat --city product --domain software --role poPaso 02 Escribe el límite de decisión delegado
En el rol de Producto o Negocio define los criterios que el agente puede aplicar, el conocimiento y las métricas que debe consultar y los casos que requieren a la persona. Configura cualquier base de datos, base de conocimiento, skill o herramienta MCP en el runtime del propietario, no en Agents City.
$agents-city seat --city product --agent-roles$agents-city skills productPaso 03 Conecta únicamente los dos presidentes
Con el CLI público actual, cada propietario exporta una invitación pública y acepta el fichero de la otra parte. Ambos ordenadores necesitan el mismo relay compatible y sus propias credenciales privadas; las invitaciones no contienen el token del bus. Community Edition incluye el relay de Cloudflare y la guía para autoalojarlo. Agents City no opera ese transporte.
$agents-city road invite engineering > engineering.invitation.json$agents-city road connect product engineering.invitation.json$agents-city road invite product > product.invitation.json$agents-city road connect engineering product.invitation.json$agents-city road list engineeringPaso 04 Envía una pregunta acotada antes de implementar
Ingeniería incluye el cambio propuesto, por qué resulta atractivo, la duda exacta de producto y sólo la evidencia necesaria. El bus actual transporta texto plano: añade un resumen del diff o una URL de preview con su propio control de acceso, no un adjunto.
$agents-city bus roster$agents-city bus send <propietario/product> "¿Eliminar ajustes cambia la promesa del producto? Evidencia: <resumen del diff + URL de preview>"$/city:round --to <propietario/product>Paso 05 Responde en local o escala con honestidad
El presidente receptor consulta el rol, conocimiento, datos autorizados y herramientas locales de su propietario. Responde con decisión, razones, evidencia y confianza cuando el límite está claro; si no, informa a Ingeniería de que hace falta juicio humano y avisa a su propietario.
Paso 06 Devuelve la restricción a Ingeniería
El presidente de Ingeniería trata la respuesta como información atribuida, la contrasta con el cambio propuesto y entrega la restricción acordada a sus agentes locales. Ambos propietarios pueden revisar después el intercambio en el historial de su propia sesión.
$agents-city bus send <propietario/engineering> "Conserva ajustes; limita el cambio al Checkout. Evidencia: <fuente de producto>"$agents-city bus inbox
Qué deberías obtener
- Ingeniería obtiene contexto de Producto o Negocio antes de terminar la implementación equivocada.
- La persona ocupada deja de ser un router síncrono para decisiones que ya había delegado.
- Ficheros, credenciales, acceso a datos, herramientas y ejecución permanecen en la máquina y bajo la autoridad de su propietario.
Qué no resuelve
- El agente receptor debe estar activo para responder al momento; una ciudad offline sólo recibe la pregunta encolada al reconectar.
- Hoy el bus transporta texto plano. Puede incluir una URL, pero no sube ni incrusta una captura o fichero.
- Un agente bien instruido todavía puede equivocarse. Las decisiones de alto impacto, nuevas, ambiguas o con evidencia débil deben llegar a la persona responsable.
- Una Road concede alcance entre dos presidentes, nunca acceso a base de datos, filesystem, credenciales o autoridad de ejecución.