Crear contacto Android con IA y comprobar duplicados antes de guardar

Crear un contacto revisado sin duplicarlo

Para crear contacto Android con IA y comprobar duplicados, el flujo correcto tiene cinco pasos: aportar la fuente, convertirla en campos estructurados, buscar coincidencias, revisar la cuenta destino y aprobar la escritura. En FoneClaw lo diseñamos así porque guardar un contacto parece una acción pequeña, pero una agenda duplicada se vuelve difícil de usar cuando el teléfono tiene varias cuentas, nombres parecidos y números reutilizados.

Imagina que recibes este mensaje: “Soy Laura Medina, de Nova Dental. Mi móvil es +34 612 345 678 y mi correo laura@novadental.example”. Una petición útil sería: “Crea este contacto si no está duplicado, guárdalo en mi cuenta personal y muéstrame los datos antes de aprobar”. FoneClaw extrae nombre, organización, teléfono, correo y nota de origen; después comprueba si ya existe una coincidencia exacta o una posible coincidencia que merezca revisión.

La frontera importante está antes de escribir. La IA puede preparar la propuesta, pero el usuario conserva la decisión: crear un contacto nuevo, cancelar, editar campos, elegir otra cuenta o convertir la acción en una actualización manual. FoneClaw admite creación directa aprobada sin abrir otra app, pero esa comodidad no significa escritura silenciosa. El contacto se guarda cuando el usuario revisa la propuesta y confirma la acción.

Este enfoque nos permite avanzar rápido sin tratar la detección de duplicados como una verdad absoluta. Un número repetido puede pertenecer a una recepción compartida; dos nombres iguales pueden ser personas distintas; y un contacto en otra cuenta puede no fusionarse automáticamente. Por eso la comprobación sirve para decidir mejor, no para eliminar criterio humano.

Convertir una firma o nota en campos de contacto

El primer trabajo de la IA no es guardar, sino ordenar. Android organiza los contactos mediante registros y filas de datos: nombre, teléfono, correo, organización, cargo, dirección, nota y otros campos viven como piezas estructuradas. La documentación de Android sobre Contacts Provider describe esa estructura con contactos agregados, registros asociados a cuentas y datos tipados. En términos prácticos, una firma o un mensaje no debe copiarse como bloque plano si contiene campos claros.

FoneClaw convierte el texto de origen en una propuesta legible. El nombre debe separarse del cargo; el teléfono debe conservar su prefijo cuando aparece; el correo debe mantenerse tal como fue proporcionado; la empresa no debe confundirse con el apellido; y la nota debe explicar de dónde salió el dato cuando sea útil para el usuario. Si la fuente es una pantalla, una imagen o un SMS, el mismo principio se mantiene: extraer lo que está presente y marcar lo que no está claro.

Hemos aprendido que la normalización ayuda, pero inventar datos destruye confianza. Si una firma dice “Laura, ventas”, FoneClaw puede proponer nombre Laura y nota “ventas”, pero no debe crear un apellido, una empresa ni una dirección que no aparezcan. Si un número no incluye país, el usuario puede confirmarlo según su contexto. Si un correo parece tener un error tipográfico, conviene mostrarlo como posible revisión, no corregirlo sin permiso.

La fuente también importa. Un contacto obtenido de un mensaje reciente tiene más contexto que una frase suelta dictada deprisa, pero sigue necesitando revisión. Para flujos donde los mensajes proporcionan datos de seguimiento, Resumir mensajes de texto Android con IA por fechas y respuestas pendientes muestra cómo un SMS puede alimentar una acción posterior sin perder la relación entre conversación, dato y decisión.

Comprobar coincidencias exactas y posibles

La comprobación de duplicados debe empezar por identificadores fuertes. Un teléfono normalizado o un correo idéntico suelen ser señales más fiables que un nombre parecido. Si FoneClaw encuentra el mismo número o el mismo correo en la agenda visible y accesible, lo presenta como coincidencia exacta para revisión. La acción adecuada puede ser cancelar la creación, actualizar el contacto existente o guardar un registro nuevo solo si hay una razón clara.

Las posibles coincidencias requieren más criterio. Un nombre parecido, una misma organización, un apodo o una coincidencia parcial pueden indicar duplicado, pero también pueden describir personas distintas. “Carlos Ruiz” y “Carlos R.” en la misma empresa merecen revisión; “Recepción Clínica Norte” y “Dra. Marta Norte” no deben fusionarse solo porque comparten una palabra. FoneClaw debe mostrar por qué una coincidencia aparece y permitir que el usuario decida.

Android puede agregar registros que parecen pertenecer a la misma persona, y los cambios en nombre, teléfono, correo u organización pueden activar una nueva agregación según los datos y la cuenta. La referencia de Android sobre RawContacts ayuda a entender por qué un contacto puede tener varias partes bajo la superficie. Para el usuario, la traducción es sencilla: una coincidencia técnica no prueba por sí sola identidad humana.

Google Contacts también ofrece sugerencias de fusión revisadas por el usuario. Su ayuda sobre fusionar contactos duplicados mantiene la decisión en manos de la persona y marca una frontera práctica: los contactos guardados en distintas cuentas de Google no siempre pueden fusionarse mediante ese flujo. Por eso FoneClaw trata la cuenta como parte de la decisión, no como un detalle secundario.

La regla que aplicamos en FoneClaw es directa: las coincidencias exactas detienen la escritura hasta revisión, y las coincidencias posibles se explican con señales concretas. La IA reduce búsqueda y comparación; el usuario conserva la autoridad sobre crear, actualizar, fusionar fuera del flujo o cancelar.

Revisar cuenta, campos y acción antes de aprobar

La cuenta destino define dónde vive el contacto y cómo se sincroniza. En Android, un contacto puede estar asociado a una cuenta de Google, una cuenta corporativa, una cuenta del fabricante, el almacenamiento local del dispositivo u otra libreta compatible. Guardar en la cuenta equivocada puede hacer que el contacto aparezca en un móvil pero no en otro, que se mezcle con una agenda de trabajo o que quede fuera de una copia esperada.

Antes de aprobar, el usuario debe ver tres cosas: la cuenta donde se guardará, los campos que se escribirán y la acción propuesta. “Crear contacto nuevo” no es lo mismo que “actualizar contacto existente” ni que “abrir la app de Contactos para editar”. La comprobación de duplicados informa la decisión, pero no autoriza la escritura por sí sola. La aprobación debe responder a una propuesta concreta.

En FoneClaw diseñamos la pantalla de aprobación para que el usuario pueda detectar errores de impacto real: contacto parecido, número con prefijo incorrecto, correo mal leído, cuenta de empresa en lugar de cuenta personal o nota demasiado amplia. Una confirmación útil no pregunta “¿seguro?” de forma genérica; muestra qué cambiará. Para profundizar en esta capa de diseño, UX de aprobación de agentes de IA: decisiones claras en el teléfono explica cómo presentar motivo, impacto y confianza cuando una acción modifica el teléfono.

El permiso de contactos pertenece a Android, no al modelo. FoneClaw puede preparar una propuesta y solicitar la acción, pero el acceso al proveedor de contactos depende de permisos y políticas del dispositivo. Si falta acceso, el flujo debe detenerse y guiar al usuario. La guía Sandbox de agentes de IA y permisos del teléfono: por qué aún hacen falta límites desarrolla esta frontera entre razonamiento del agente y autoridad real sobre datos del móvil.

Crear contactos directamente con FoneClaw

FoneClaw admite creación directa aprobada de contactos en Android sin abrir otra app. Lo importante de esta capacidad no es saltarse la interfaz del sistema, sino reducir pasos cuando el usuario ya revisó la propuesta. El flujo sigue siendo visible: fuente, campos, duplicados, cuenta, aprobación, escritura y verificación.

Un ejemplo completo puede empezar con voz: “Guarda a Diego Salas, proveedor de catering, con el número +52 55 1234 5678, correo diego@mesa.example, en mi cuenta de trabajo, pero comprueba duplicados antes”. FoneClaw convierte la frase en campos, busca contactos accesibles con teléfono o correo coincidente, muestra posibles coincidencias por nombre u organización y prepara una tarjeta de aprobación. Si el usuario ve que “Diego S.” ya existe con el mismo correo, puede cancelar la creación y actualizar manualmente. Si no hay coincidencia relevante, aprueba el contacto nuevo.

También puede partir de una pantalla o imagen. Si el usuario adjunta una tarjeta de visita, una firma de correo o un mensaje, FoneClaw extrae los datos con contexto visual y mantiene el contenido incierto como revisión. Un número borroso, una extensión telefónica o una dirección parcial no deben convertirse en certeza. La interfaz debe señalar qué se leyó y qué requiere intervención.

La creación directa forma parte de un conjunto mayor de acciones Android compatibles. En nuestra página de funciones mantenemos el alcance actual de las capacidades y las herramientas integradas de FoneClaw, usando una superficie viva para que el lector confirme qué áreas cubre el producto antes de diseñar un flujo diario. Desde producto seguimos ampliando esta ruta con más claridad de estado, mejores revisiones y recuperación más fluida cuando el teléfono exige atención.

Números compartidos, formatos internacionales y cuentas

La agenda real está llena de casos que una deduplicación agresiva puede estropear. Un mismo número puede ser correcto para varios contactos: una recepción médica, una centralita, un número familiar, una tienda local o un equipo de soporte. Si FoneClaw ve un teléfono repetido, debe mostrar la coincidencia y dejar que el usuario decida si se trata de un duplicado o de un número compartido legítimo.

Los formatos internacionales añaden otra capa. “612 345 678”, “+34 612 345 678” y “0034 612 345 678” pueden apuntar al mismo número según país y contexto, pero no siempre conviene modificar lo dictado sin revisión. Cuando el dato procede de una firma o tarjeta, conservar el prefijo explícito suele ser más seguro. Cuando falta el país, el usuario puede elegir añadirlo antes de guardar.

Las cuentas cruzadas son igual de delicadas. Un contacto personal y un contacto laboral con el mismo correo pueden tener razones para existir separados. Un registro en una cuenta corporativa puede obedecer a políticas de empresa. Un contacto local puede no sincronizarse. FoneClaw debe presentar la cuenta destino y las coincidencias visibles, no asumir que todo registro parecido se puede fusionar.

También hay contactos parciales. A veces basta guardar nombre y teléfono para devolver una llamada; otras veces conviene esperar hasta tener correo, empresa o cargo. Nuestro criterio es permitir crear un contacto útil con campos revisados y dejar la nota como recordatorio del origen: “recibido por SMS”, “firma de correo” o “tarjeta de visita”. Esa nota ayuda a completar después sin confundir una inferencia con un dato confirmado.

Cuando el problema es falta de permiso, estado del teléfono o visibilidad de contactos, Comprobar salud del teléfono Android con IA: batería, permisos y notificaciones ofrece un camino de revisión más amplio para diagnosticar por qué una acción no puede leer o escribir como se esperaba.

Verificar el contacto guardado y recuperarse

El flujo termina cuando el contacto existe de forma visible, no cuando el asistente dice que terminó. Después de aprobar la creación, busca el registro por teléfono normalizado o correo, abre el contacto y confirma cuenta, nombre, número, correo, organización y nota. Si Android o la app de agenda agregan el nuevo registro con otro contacto, revisa el resultado agregado antes de continuar.

Si algo no encaja, corrige una sola cosa cada vez. Cambia la cuenta si el contacto quedó en el lugar equivocado, edita el número si el prefijo era incorrecto o borra una nota demasiado amplia. Si el resultado es incierto, no repitas la creación inmediatamente: primero busca por teléfono y correo para evitar duplicar el error. La prevención de duplicados incluye esta verificación posterior, porque algunos problemas solo aparecen después de que Android procesa el registro.

La recuperación segura también cubre la acción cancelada. Si el usuario rechaza la aprobación, FoneClaw debe conservar la propuesta el tiempo necesario para editarla o descartarla, sin escribir en segundo plano. Si falta permiso de contactos, la tarea puede esperar mientras el usuario decide conceder acceso o terminar manualmente. Esa claridad es la dirección en la que seguimos construyendo FoneClaw: menos pasos repetitivos, más evidencia visible y control humano en cada escritura con consecuencias.