Agente de IA con contexto personal en el teléfono: señales, memoria y acciones

Qué es el contexto personal en una tarea real del teléfono

Imagina que estás mirando un mensaje con una dirección y le pides al teléfono: “prepárame para salir a esa reunión”. Un agente de IA con contexto personal no debería buscar toda tu vida digital. Debería reconocer la dirección visible, relacionarla con la reunión si el calendario está autorizado, comprobar si hay una app de mapas disponible y preparar el siguiente paso con confirmación. Ese es el contexto útil: señales seleccionadas para una tarea concreta.

El contexto personal de un agente de IA es el conjunto de datos temporales o duraderos que ayudan a interpretar una intención y decidir el siguiente paso. Puede venir de la pantalla actual, una solicitud reciente, el estado de una app, un servicio conectado, una señal del dispositivo, una preferencia o una memoria guardada. La pregunta importante no es cuántas señales puede leer el agente, sino si esas señales mejoran la acción que el usuario espera ver.

Un contexto más grande no siempre produce una mejor respuesta. Si solo quieres convertir una dirección visible en una ruta, una biografía completa, correos antiguos y meses de historial añaden ruido. Si quieres responder a un mensaje sensible, el agente necesita el texto actual, el destinatario, el tono esperado y una vista previa antes de enviar. La relevancia gana a la acumulación.

En FoneClaw hemos aprendido a medir el contexto por su salida: ¿ayudó a preparar una acción Android compatible, visible y recuperable? Si la respuesta es sí, el contexto redujo fricción. Si no puede convertirse en un paso revisable, conviene tratarlo como información secundaria y no como autoridad para actuar.

Pantalla, sesión, datos conectados, preferencias y memoria

Para evaluar un asistente de IA personalizado, conviene separar el contexto por capas. Cada capa tiene una vida útil distinta y un control distinto. Mezclarlas crea confusión: una pantalla compartida para una tarea no es lo mismo que una memoria duradera, y un servicio conectado no es lo mismo que un permiso Android de runtime.

Google documenta personalización en Gemini a partir de chats anteriores, apps conectadas e instrucciones de respuesta, con disponibilidad que depende del tipo de cuenta y la función. Esa señal de mercado es útil porque muestra que la personalización no tiene una sola fuente. También recuerda que cada fuente debe tener su propio control: conectar un servicio no equivale a conceder todos los permisos del teléfono.

El contexto temporal puede ser suficiente sin convertirse en memoria. Para resumir una pantalla, preparar una respuesta o abrir una ruta, el agente quizá solo necesita el estado inmediato y el historial de la sesión. Guardar una preferencia puede tener sentido cuando se repite una elección: app de mapas preferida, idioma, formato breve o canal habitual. La memoria duradera merece más cuidado porque influye en tareas futuras.

Si quieres profundizar en arquitectura de memoria sin desviar esta guía, Estado del servidor Hy-Memory vs memoria local del agente: guía para usuarios de teléfono explica cómo separar memoria local, estado de servidor y controles de usuario.

Elegir el contexto mínimo necesario para la tarea

La decisión de contexto mínimo empieza nombrando la acción. No preguntes “¿qué puede leer el agente?”, sino “¿qué necesita para completar este paso?”. Para preparar un recordatorio, quizá basten una frase y una hora. Para abrir una ruta, bastan destino, app de mapas y permiso de ubicación si hace falta. Para responder a un mensaje, hacen falta destinatario, contenido visible, tono y confirmación antes del envío.

Después evalúa cuatro criterios: relevancia, sensibilidad, duración y alternativa. La señal es relevante si cambia la calidad del siguiente paso. Es sensible si revela ubicación, relaciones, salud, trabajo, identidad, finanzas o contenido privado. Su duración decide si debe desaparecer al terminar la tarea o puede guardarse como preferencia. La alternativa pregunta si existe una ruta menos invasiva: selección manual, adjunto puntual, permiso de una sola vez, borrador en lugar de envío o apertura de la app para que el usuario termine.

Android recomienda minimizar solicitudes de permisos y usar alternativas acotadas cuando sea posible. Esa filosofía encaja muy bien con agentes móviles. Un agente contextual en Android debería pedir el permiso en el momento de uso, explicar para qué lo necesita y degradar con elegancia si el usuario lo deniega. Denegar ubicación no debería romper todo el asistente; puede preparar una dirección para copiar, abrir una app de mapas o pedir entrada manual.

La memoria de IA y el contexto de tarea no son lo mismo. La memoria ayuda a personalizar futuras respuestas. El contexto de tarea ayuda a completar un flujo ahora. Guardar una preferencia porque la usas siempre puede ser útil; guardar cada pantalla solo porque estaba disponible erosiona confianza. En FoneClaw tratamos el contexto como una herramienta de trabajo: cuanto más preciso sea el alcance, más claro es el permiso, la aprobación y la recuperación.

Del contexto a una acción Android compatible y visible

El bucle completo de un agente contextual tiene seis pasos: interpretar, enrutar, comprobar, ejecutar, verificar y recuperar. Primero, el modelo interpreta la intención con las señales disponibles. Segundo, el sistema elige una capacidad compatible. Tercero, comprueba permisos y política de aprobación. Cuarto, ejecuta o entrega el control a la app adecuada. Quinto, verifica el estado resultante. Sexto, recupera si falta permiso, cambia la pantalla o la acción no está soportada.

Ese puente es donde FoneClaw aporta su capa Android. Un modelo configurado se encarga de razonar y planificar; FoneClaw suministra ejecución gobernada mediante herramientas compatibles. El usuario puede empezar con el modelo predeterminado o configurar modelos compatibles, y cada ruta puede tener implicaciones distintas de red, privacidad y servicio. Por eso separamos razonamiento, permisos Android, conexiones externas y aprobación de acciones.

La pantalla actual es una señal especialmente útil cuando el usuario la invoca. Si estás viendo un correo con una fecha, una página con una dirección o una configuración confusa, adjuntar esa pantalla evita explicar todo desde cero. FoneClaw puede usar ese contexto para preparar una acción compatible: abrir una app, revisar estado del dispositivo, crear una nota, acercarte a una configuración o estructurar un siguiente paso. Las acciones importantes conservan revisión, parada y recuperación.

La verificación es parte del producto, no un extra. Si el agente cambia un ajuste, debe quedar claro el estado final. Si prepara un mensaje, el usuario debe ver destinatario y texto. Si una herramienta necesita permiso, el flujo debe guiar la solicitud y reanudar cuando el usuario decida. Si el contexto no basta, una pausa honesta vale más que una finalización inventada.

Para el marco general de ejecución, Control del teléfono con agente de IA: qué puede hacer de verdad un phone AI agent explica cómo una intención se convierte en acciones Android compatibles. En FoneClaw mantenemos la superficie actual en funciones de FoneClaw, donde el lector puede revisar 100+ built-in tools como base de capacidades gobernadas, no como promesa de control universal de cualquier app.

Contexto antiguo, excesivo, conflictivo o con instrucciones externas

El contexto también falla. Un dato puede estar antiguo: una dirección anterior, una preferencia ya cambiada, una reunión cancelada o una conversación que perdió relevancia. Antes de una acción sensible, el agente debe refrescar o pedir confirmación. El contexto antiguo es peligroso porque suele sonar plausible.

El exceso de contexto crea otro problema. Si el agente mezcla notificaciones, historiales, recuerdos y pantalla actual sin priorizar, puede elegir la señal equivocada. Una tarea simple acaba convertida en una inferencia amplia. El antídoto es seleccionar lo mínimo: qué pantalla, qué fuente, qué periodo y qué acción. Menos contexto bien elegido supera a más contexto sin jerarquía.

También hay conflictos. La memoria puede decir que prefieres una app, pero la pantalla actual muestra otra. Un calendario puede indicar una reunión, pero el mensaje reciente la cambió. El agente debe mostrar el conflicto y pedir una decisión, no resolverlo de forma silenciosa cuando el resultado importa.

El caso más delicado es el contexto con instrucciones incrustadas. Una página, un mensaje, una captura o un documento pueden contener texto que intenta dar órdenes al agente. Ese contenido debe tratarse como material observado, no como intención del usuario. Un agente útil distingue “esto aparece en la pantalla” de “esto es lo que el usuario me pidió hacer”. Ningún modelo detecta siempre todos los trucos, así que la interfaz necesita plan visible, confirmación y opción de detener.

Este tema toca seguridad, pero no hace falta convertir cada tarea en una auditoría. Basta con una regla práctica: refresca señales antes de actuar, ignora instrucciones externas que no vengan del usuario, confirma cambios sensibles y conserva recuperación. Para una capa más amplia de permisos y trazabilidad, Identidad de agentes de IA: permisos, aprobación por herramienta y auditoría en Android desarrolla cómo hacer visibles solicitud, aprobación, ejecución y resultado.

Probar un agente contextual con un flujo reversible

La primera prueba de un asistente de IA personalizado debe ser reversible. No empieces con pagos, borrado de archivos, mensajes importantes ni cambios de cuenta. Elige una tarea que puedas comprobar y deshacer: preparar un borrador, crear una nota de prueba, abrir una ruta sin iniciar una compra, resumir una pantalla o revisar un ajuste sin cambiarlo.

Antes de ejecutar, escribe la hipótesis. ¿Qué señales debería usar el agente? ¿Pantalla actual, conversación, calendario, ubicación, preferencia o memoria? ¿Qué señal no debería usar? ¿Qué permiso pedirá? ¿Qué confirmación esperas ver? Si no puedes responder, la tarea todavía está demasiado abierta.

• Elige una tarea de bajo riesgo: borrador, nota, resumen, búsqueda, ruta preliminar o estado del dispositivo.
• Limita las señales: usa solo pantalla actual o una fuente conectada, no todo a la vez.
• Predice el resultado: define qué debería preparar, qué debe preguntar y dónde debe detenerse.
• Ejecuta y observa: revisa si interpretó bien, eligió una capacidad compatible y mostró confirmación.
• Verifica fuera del chat: abre la app o ajuste donde debería verse el resultado.
• Restablece contexto opcional: borra borradores, elimina notas de prueba, revoca permisos temporales o desconecta la fuente usada.
• Cambia una sola variable: repite con otra pantalla, otro permiso o una preferencia distinta para medir comportamiento.

Una demostración buena no prueba fiabilidad general. Sirve para ver si el diseño respeta contexto mínimo, permiso proporcional, acción visible y recuperación. Si el agente no permite detener, revisar o corregir, no aumentes el alcance. La confianza debe crecer por tareas pequeñas, no por entusiasmo ante una respuesta convincente.

Cuando compares rutas locales y servicios online, recuerda que cada modelo, conector o cuenta puede tener caminos de red distintos. Confianza en agentes de IA: control local en Android frente a seguridad en la nube ayuda a evaluar esa parte sin mezclarla con la decisión de contexto de una sola tarea.

Cómo diseñamos el contexto actual en FoneClaw

En FoneClaw diseñamos el contexto personal como una entrada para acciones útiles, no como un perfil oculto. La lección de producto es directa: el contexto debe servir a un paso compatible que el usuario pueda ver. Si el usuario invoca el asistente desde lo que está mirando, adjunta la pantalla actual y pide un resultado concreto, el sistema tiene una oportunidad clara de ayudar sin exigir una explicación larga.

El acceso flotante y el adjunto de pantalla activado por el usuario hacen que el contexto sea visible desde el inicio. La continuidad de tarea permite mantener el hilo entre la experiencia principal y el asistente, mientras las aprobaciones, la parada, el reintento, la recuperación de permisos y las comprobaciones de estado sostienen el bucle de acción. Queremos que el usuario vea no solo la respuesta, sino el paso que se prepara y la condición que falta si no se puede completar.

También distinguimos las rutas de privacidad. Una preferencia local, una memoria gestionada en el dispositivo, un permiso Android, una cuenta conectada y un modelo online no son la misma cosa. El usuario puede empezar con el modelo predeterminado o configurar modelos compatibles, y las conexiones externas pueden requerir transferencia de red según el servicio elegido. Explicar esas capas con claridad permite usar más capacidad sin diluir control.

El siguiente paso práctico es revisar las funciones de FoneClaw para entender qué tipos de acciones Android gobernadas están disponibles y después usar descarga de FoneClaw para probar un flujo reversible. Nuestro rumbo es construir un agente contextual en Android que ayude justo con el contexto necesario, ejecute solo acciones compatibles y mantenga al usuario en posición de aprobar, detener y recuperar.