¿Qué es una agencia AI-native?

• Agencia AI-native es un término útil para un modelo operativo, no una categoría legal ni una promesa de autonomía total.
• Los Agents asumen roles acotados con instrucciones, conocimiento, tools y una persona reconocible. La personalidad define la comunicación, nunca el acceso ni la autoridad.
• Las reglas deterministas, state machines y workflows controlan los pasos que deben ser previsibles. El modelo interviene solo donde el lenguaje o el juicio aportan valor.
• Las personas conservan la responsabilidad sobre clientes, dinero, empleo, asesoramiento regulado, acciones irreversibles y toda aprobación que el sistema no pueda asumir de forma segura.

Cada capa resuelve un trabajo diferente. Combinarlas es lo que convierte una demo de IA en un sistema operativo gestionado.

• docAgents y personalidadesUn rol con nombre, instrucciones, conocimiento, tools, modelo, acceso y canales. La persona controla voz y comportamiento, no permisos.
• docSkillsMétodos, checklists, referencias y scripts reutilizables que se empaquetan una vez y se conectan donde se repite el mismo estándar de calidad.
• linkMCPLa capa de conexión que permite a clientes de IA aprobados descubrir tools, resources y prompts permitidos mediante un endpoint autenticado.
• dataKnowledge y User MemoryAgent Knowledge es compartido y controlado por el autor. User Memory es contexto personal deliberado, limitado a un usuario autenticado y un Agent.
• codeWorkflows y state machinesLos workflows de Microsoft Agent Framework orquestan pasos del Agent; estados y triggers explícitos controlan el siguiente paso; un Flow independiente posee la automatización general.
• dataOrleans y digital twinsLos actores virtuales poseen identidad y estado duraderos para Agents, sesiones, runs, Tasks y otras entidades. Aquí digital twin es un modelo mental de entidad de software, no una afirmación sobre Azure Digital Twins.
• docTeams, Goals y TasksUn límite privado de colaboración para miembros, Goals y KPI medibles, Tasks tipadas, archivos, conocimiento, procesos, aprobaciones, coste, tiempo y Agents conectados.
• dataStores y pagosUn propietario de comercio separado para catálogo, carrito, checkout, pedidos y obligaciones del vendedor, con un Agent existente y autorizado como asistente del comprador.

1. 01
   Goal y Task

   Define resultado, propietario, KPI, fecha, datos permitidos y el punto exacto donde una persona debe decidir.

2. 02
   Agent y Skill

   Da al rol una persona, conocimiento aprobado, método reutilizable, tools y reglas de rechazo.

3. 03
   MCP y acceso

   Conecta solo los sistemas necesarios mediante OAuth o un grant explícito y limitado; conectividad no significa permiso.

4. 04
   Workflow y estado

   Usa una state machine, un workflow del Agent o un Flow para pasos previsibles, reintentos y aprobaciones.

5. 05
   Propietario duradero

   Un grain de Orleans conserva el estado exacto del Agent, sesión, run, Team Task u operación de Store sin depender de la memoria de un proceso.

6. 06
   Evidencia y siguiente acción

   Registra resultado, actor, revisión, coste, tiempo e historial de aprobaciones; después actualiza el Goal o entrega la excepción a una persona.

Un mapa práctico de las capas de Agent, MCP, memoria, workflow, Team, Task, Store y estado duradero necesarias para automatizar trabajo real sin fingir que la empresa funciona sin personas.

• Onboarding de clientes: un Agent reúne información permitida, una state machine valida etapas obligatorias y una Team Task envía excepciones a la persona adecuada.
• Operaciones de contenido: persona de marca, fuentes aprobadas, Skills reutilizables, artefactos versionados y Tasks de revisión sustituyen copias dispersas de prompts.
• Soporte y ventas: User Memory conserva preferencias permitidas por Agent, mientras un asistente de Store solo lee el catálogo y las commerce tools de ese Store.
• Operaciones recurrentes: un Flow coordina handoffs deterministas, horarios, tools externos y runs observables; los Agents resuelven trabajo lingüístico acotado.
• Dirección: Goals y KPI ponderados vinculan el trabajo con Tasks y ejecuciones de Agents en vez de contar mensajes de chat como progreso empresarial.
• Entrega multicanal: el mismo Agent publicado puede servir una web, canales compatibles, un ChatGPT Plugin o un connector de Claude cuando lo permiten el cliente y la política de acceso.

• Las rutas de Agent, Skill, hosted MCP, Knowledge, canales compatibles, User Memory y state machines existen bajo las reglas de producto, acceso, proveedor y release correspondientes.
• El producto Flow está en Preview; sus gates pendientes de fiabilidad, recovery, programación y carga no deben presentarse como ya demostrados.
• Las capas avanzadas del sistema operativo Team están implementadas para validación focalizada de early access, pero el release completo aún tiene gates de evidencia live, carga, concurrencia y fallos.
• Stores y conectores de comercio externos siguen en Preview y limitados al vendedor. El vendedor conserva responsabilidad sobre dinero, impuestos, fulfillment, reembolsos, disputas y clientes.

No empieces con una lista de agentes. Empieza con un resultado repetitivo que tenga propietario, evidencia y un punto de parada seguro.

1. 01
   Nombra el trabajo repetitivo.

   Describe trigger, resultado esperado, frecuencia, propietario actual, coste del fallo y decisión humana.

2. 02
   Separa lenguaje y reglas.

   Usa un Agent donde ayuden lenguaje y juicio; usa estados, triggers, validaciones y Flow donde la ruta deba ser explícita.

3. 03
   Elige el propietario de producto.

   Elige Agent, Skill, Flow, Team o Store según quién posea identidad, trabajo, colaboración o comercio.

4. 04
   Conecta la autoridad mínima.

   Expón solo las MCP tools y datos necesarios, limita la memoria, prueba OAuth y exige aprobación antes de escrituras relevantes.

5. 05
   Mide antes de ampliar.

   Revisa calidad, excepciones, tiempo, coste, impacto en clientes y progreso del Goal antes de añadir otro proceso o Agent.