Community Edition completa bajo Apache 2.0. Sin telemetría.Ver el código
Agents City

Cómo aislar el trabajo de agentes de IA entre clientes

Da una ciudad distinta a cada cliente y abre una carretera sólo cuando dos asientos tengan un motivo legítimo para intercambiar información.

Revisado con Agents City 0.3.0-beta.22 · commit c985198 ↗
01

El problema real

Una consultora trabaja en una plataforma retail y un portal sanitario desde el mismo portátil. Reutilizar un único workspace persistente arriesga contaminación de contexto, objetivos confusos y coordinación accidental entre clientes.

02

Resultado buscado

Cada cliente recibe identidad, configuración, repositorios, conocimiento, deliberaciones, sesión y allowlist propias. El trabajo común cruza únicamente una ruta explícita entre asientos.

cliente-retail · cliente-salud · plataforma-comun

Dominio
una ciudad autónoma por responsabilidad
Objetivo
Aislar el trabajo de clientes y permitir sólo una dependencia acotada de plataforma común.
Asiento principal
un asiento independiente por ciudad
Unidades y evidencia
cliente-retailciudad cliente

Repositorios, objetivo, conocimiento y deliberaciones retail

cliente-saludciudad cliente

Repositorios sanitarios y contexto de compliance separado

plataforma-comunciudad interna

Sólo la dependencia que puede afectar a ambos clientes

04

Antes de empezar

  1. 01

    Una lista clara de qué repositorios y conocimiento pertenecen a cada cliente.

  2. 02

    Carpetas locales y permisos de proveedor apropiados para cada proyecto.

  3. 03

    Una regla explícita sobre qué información puede cruzar por la ciudad interna compartida.

05

Cómo hacerlo

  1. Paso 01

    Crea una ciudad por cliente

    Crea ciudades gestionadas en vez de copiar carpetas o reutilizar identidades. Configura asiento, objetivo, repositorios, roles y motores de forma independiente.

    TERMINAL
    agents-city cities create cliente-retailagents-city cities create cliente-saludagents-city cities list
  2. Paso 02

    Configura e inspecciona cada límite

    Abre cada ciudad por separado. Confirma que su ficha contiene sólo los repositorios previstos y que no ha aparecido ninguna carretera implícita.

    TERMINAL
    agents-city seat --city cliente-retail --reposagents-city seat --city cliente-salud --reposagents-city road list cliente-retail
  3. Paso 03

    Modela el trabajo común como otra ciudad

    Si ambos clientes dependen de una plataforma interna, dale objetivo y asiento propios en vez de conectar directamente las ciudades cliente.

    TERMINAL
    agents-city cities create plataforma-comunagents-city seat --city plataforma-comun
  4. Paso 04

    Abre únicamente las carreteras necesarias

    Conecta cada asiento cliente con plataforma-comun. Comprueba el roster antes de enviar evidencia. La carretera no expone los repositorios cliente.

    TERMINAL
    agents-city road connect cliente-retail plataforma-comunagents-city road connect cliente-salud plataforma-comunagents-city bus roster
06

Qué deberías obtener

  • Cambiar de ciudad no mezcla objetivos, repos, conocimiento, comités ni sesiones tmux.
  • Los clientes no pueden dirigirse entre sí salvo que añadas deliberadamente una carretera.
  • La plataforma común recibe sólo mensajes admitidos por su propio asiento.
07

Qué no resuelve

  • El aislamiento de ciudad es un límite de aplicación, no otra cuenta del sistema operativo ni una VM.
  • Cada runtime sigue ejecutándose como el usuario local salvo que añadas aislamiento externo.
  • No envíes texto confidencial por una carretera sólo porque la ruta exista.