I don't have an address for all my contacts. But many of them have phone numbers. In many cases, I can rely on the country code to at least know which country someone lives in. For US people, the area code tells me a lot. Of course, in many cases the area code won't match where they live since people often keep their numbers when they move, but it's good enough.

The number of GPT functions is growing. I can probably get smarter about composing functions together into "meta-functions". For example, I like how querying contacts by location, birthdays, and facts are three separate classes. Each class is nicely focused on one thing.

But as a GPT function, it would make sense to have this be a single function with a QuestionType field that could be Location, Birthday, or Other. Then I could dispatch to the class based on the type.

It might be fine to just do this all in a new function class and not worry about composing smaller functions into bigger functions. That may be my next step. But it's worth thinking about whether composing smaller functions into meta functions is worth it or not.

If I specify a new address for a contact, it'd be nice if that data were written to the database and back to the contact.

My OAuth token used to access the People API expires after some time. I then have to log out and log back in to get a new one. I should be handling the refresh token to get a new token automatically so I don't have to log out and log back in.

On a periodic basis, update existing contacts and create new contacts from the Google API. If data has been changed locally, we'll need to have a way to resolve conflicts.

Google people API supports storing key value metadata for contacts. We could use this as the source of truth for contact "facts" and sync between database and the API.