How does your Hand learn who you know?

There is a simple reason instructions such as “email Sophie” or “move my meeting with Alex” sometimes require more explanation than they should: a name is not yet an identity. Gmail can send a message and Calendar can change an event, but neither instruction tells your Hand which Sophie or which Alex you mean.

Names need an identity source

When Google Contacts is connected to a Hand, it gives that Hand a dedicated source to search before another Google tool acts. That changes the shape of a useful instruction.

The second instruction is shorter, but it is not less precise if your contact data supplies the missing identity. Your Hand can search the contacts it is allowed to use, select a clear match, and then use Gmail or Calendar for the actual task.

What to clean up in Google Contacts

You do not need to turn your address book into a CRM. Start with the people you actually ask your Hand to work with. For each important contact, make the record easy to distinguish from every other person with a similar name.

• Use the person's real, recognizable name. Avoid records called only “Accountant”, “Supplier” or an email address unless that is genuinely how you identify the person.
• Keep the primary email address current. The best name match is still useless if the action is sent to an obsolete address.
• Add company or role when it helps disambiguate. “Sophie Jansen · Northstar” is more useful than two records called simply “Sophie”.
• Remove or merge duplicates in Google Contacts. Hands does not expose contact merging, so the contact system itself remains the right place to clean duplicate identities.
• Keep important people in Google Contacts itself. Do not assume an address that appeared somewhere else in your Google account is automatically a clean contact your Hand should treat as authoritative.

You can improve this gradually. The ten or twenty people involved in your recurring work will usually deliver more value than spending an afternoon polishing hundreds of dormant contacts.

What if there are two people with the same name?

Good source data reduces ambiguity; it should not hide it. If a search produces one clearly relevant person, the Hand has useful identity context. If two plausible people remain, the safe behavior is to ask which one you mean rather than guess.

That is a feature, not friction. A short clarification at the identity boundary is much cheaper than sending an email or changing a meeting for the wrong person.

A 10-minute setup that pays off repeatedly

1. Open Google Contacts and fix the people you work with most. Check name, primary email and a useful company or role.
2. Clean obvious duplicates. Do the merge in Google Contacts, where the source record belongs.
3. Connect Google Contacts to the Hand that needs these people. A Hand only needs this connector when resolving or maintaining contacts is part of its job.
4. Connect the action tool as well. Contacts identifies the person; Gmail sends mail and Calendar handles events. Identity and action are separate jobs.
5. Test with ordinary language. Try a real request using only a person's name. If the name is ambiguous, check whether the Hand asks you to choose instead of silently guessing.

What Hands can and cannot do with Google Contacts

The current Google Contacts connection is deliberately bounded. Hands can search and read contacts, and it can create or partially update a contact through the Hands action layer. Creating or updating a contact remains subject to the connector permission and review settings you choose for that Hand.

Hands does not expose permanent contact deletion, contact merging, Workspace Directory administration, delegates or account-level Google administration. If your address book needs a duplicate merged, do that in Google Contacts itself and let the cleaner source data improve future requests.

Better source data beats longer prompts

The broader lesson goes beyond contacts. A Hand works best when durable facts live in the tools designed to hold them: people in contacts, meetings in calendars, documents in file systems, customer facts in a CRM. Then your instructions can describe the outcome instead of re-supplying the database every time.