Cómo diseñar permisos para un agente en gafas que puede ver el entorno, conversar y usar conectores sin convertir cada observación en autorización

Paso 1 — Etiqueta toda señal por origen antes de interpretarla. Cada evento debe indicar contextsource: cámara, micrófono, voz explícita del usuario, memoria, email, sensor o conector. Añade confidence y timestamp cuando corresponda. Una frase dicha directamente al agente tiene una fuerza distinta a texto leído en un cartel o inferido de una conversación ambiental. No necesitas construir una teoría perfecta de intención; solo evitar que fuentes diferentes entren al mismo canal semántico sin identidad. El runtime conserva esa provenance durante la tarea para que cualquier acción pueda explicar qué señales la motivaron y si su origen era apto para ese nivel de consecuencia.

Paso 2 — Clasifica acciones por nivel de consecuencia. Define, por ejemplo, nivel 0 observación; nivel 1 recomendación; nivel 2 preparación reversible; nivel 3 comunicación externa; nivel 4 compra, pago o cambio sensible. Cada capability declara hasta dónde puede avanzar sin confirmación según el contexto. Mirar un producto puede autorizar comparación, quizá preparar un carrito, pero no comprar. Pedir explícitamente “cómpralo” puede habilitar una fase más avanzada, aunque políticas adicionales sigan aplicando. Esta escala evita llenar la experiencia de confirmaciones para acciones inocuas y concentra fricción donde una equivocación tiene costo real.

Paso 3 — Diseña confirmaciones que nombren objeto y efecto. En interfaces de voz, un simple “sí” puede corresponder a varias tareas activas. La solicitud debe resumir la consecuencia: producto, precio, destinatario, fecha o cuenta. Ofrece la confirmación por el canal más apropiado: voz, gesto, display o teléfono. Para pagos o credenciales, un segundo dispositivo puede aumentar seguridad. Registra la autorización con taskid, actionid y snapshot de parámetros. Así el sistema puede demostrar qué se aprobó y evita reutilizar una confirmación antigua para una acción modificada después por nueva información.

Paso 4 — Aplica una política de memory admission. Define qué observaciones pueden almacenarse automáticamente, cuáles necesitan permiso y cuáles nunca persisten. Una preferencia expresada por el usuario puede entrar a memoria con mayor confianza que una inferencia de comportamiento. Guarda provenance y fecha de expiración para datos que cambian. También permite que el usuario inspeccione y corrija recuerdos relevantes. Si una memoria influye en una acción sensible, inclúyela en el explanation record. El objetivo no es recordar todo; es conservar aquello que mejora decisiones sin transformar un wearable en una cámara que acumula indiscriminadamente la vida alrededor de la persona.

Paso 5 — Mantén un task ledger fuera del canal efímero. Cada tarea activa debe tener objetivo, estado, herramientas, permisos usados y siguiente checkpoint. La persona puede preguntar por voz, pero también revisar una vista más completa en otra superficie. Si una conversación cambia de tema, el ledger preserva tareas previas sin confundirlas. Incluye estados waitingconfirmation, running, blocked, completed y cancelled. Un agente ambiental puede trabajar en background, pero nunca debe existir una acción que no pueda localizarse y detenerse. La naturalidad de la interfaz depende de una base estructurada que el usuario no necesita ver todo el tiempo, pero puede auditar.

Paso 6 — Prueba escenarios de ambigüedad antes de producción. Simula conversaciones con varias personas, ruido, correcciones de último segundo, objetos similares, cambios de precio y señales contradictorias. Comprueba que la policy degrada a recomendación o pide confirmación cuando no existe claridad. Evalúa falsos positivos de memoria y acciones iniciadas por contenido del entorno. En Goatify, este protocolo puede convertirse en un adapter común para voz, wearable y navegador. La habilidad conserva permisos y outcome contract; la superficie solo añade context. El éxito es que la experiencia se sienta fluida en el caso normal y deliberadamente prudente cuando el sistema no puede demostrar que una señal representa una decisión real.