Wisteria

• 

• 

• 

• 

• 

Inspiration

Some days, a full sentence is too much.

Wisteria started with a simple problem: most cycle and wellness trackers ask for the most effort on the days when a person may have the least energy to give.

The original focus was people living with PMDD who are entering perimenopause. When cycles become less predictable, the familiar calendar can stop being useful—but the difficult days still matter, and remembering them later can be hard.

That raised a bigger question: what if tracking did not depend on knowing exactly where you are in a cycle at all?

Wisteria is built around ordinary language instead. A person can say “I feel off,” tap an emoji, enter a number, or give a very short check-in. They do not need to identify a phase, understand terminology, or explain why they feel the way they do.

Feedback from other people reinforced that idea. Someone asked whether Wisteria could also be useful for PCOS, where cycles may also be irregular or difficult to predict. That helped clarify the broader design principle: Wisteria is not trying to diagnose PMDD, perimenopause, PCOS, or any other condition. It is designed for people whose lives do not always fit neatly into a predictable calendar.

What it does

Wisteria is a low-effort Android companion for recording how a day feels and gradually turning those tiny signals into useful context.

A check-in can be as simple as a tap, a number, or a phrase such as “I feel off.” Wisteria translates those inputs into intentionally plain everyday textures: bright, steady, heavy, and off.

The experience does not end after the check-in. Wisteria can continue the conversation through voice or text while keeping the interaction tied to the same session. A follow-up like “yes, give me one idea” stays a follow-up instead of accidentally creating another daily record.

Over time, Wisteria's user-triggered Night Shift feature can look across saved history for recurring heavy-to-off patterns. It shows the sample size, confidence, and evidence behind what it notices rather than presenting a pattern as certainty.

Wisteria also includes:

• Optional Health Connect context for individually granted signals such as sleep and steps.
• Google Sign-In for optional cloud features.
• Explicit, button-triggered Firestore synchronization.
• Conversational memory built from bounded, filtered notes rather than a permanent raw transcript.
• A daily Check-In Alarm with snooze, dismiss, reboot recovery, and notification fallbacks.
• Visible receipts showing when an action was actually authorized and completed.
• A deterministic local companion fallback if cloud services are unavailable.

Most importantly, Wisteria never assigns a body phase, diagnoses a condition, invents a cause, contacts someone automatically, or silently changes settings.

How we built it

Wisteria is a native Android application built with Kotlin and Jetpack Compose.

The agent experience uses Google ADK Kotlin to maintain conversational sessions. An ADK LlmAgent reaches Gemini 3.5 Flash through Firebase AI Logic, allowing Gemini to handle natural companion wording while the application maintains control over what actions are allowed.

That separation became one of the most important architectural decisions in the project:

Gemini decides how Wisteria says something. Small local rules decide what Wisteria is allowed to do.

Before any tool can run, a deterministic local router identifies whether the person's message is a new check-in, a conversational follow-up, an idea request, a pattern question, a reminder request, or an ending.

Writes are controlled by a separate local policy. An AI response cannot silently create another check-in, change an alarm, contact someone, or synchronize data.

Daily history is stored locally with Room. Night Shift runs on-device and only when the person requests it.

For connected features, Wisteria uses:

• Firebase Authentication with Google Sign-In.
• Cloud Firestore for explicit synchronization.
• Firebase AI Logic for Gemini access.
• Firebase App Check for request protection.
• Health Connect for optional private context.
• Vertex AI Memory Bank through an authenticated server-side bridge for optional bounded conversational memory.

Raw Health Connect records are not placed into the model prompt. Instead, granted signals are reduced on-device to limited contextual hints.

The project is continuously tested through GitHub Actions, including Android unit tests, APK builds, memory-service tests, and verification that the Firebase OAuth configuration matches the certificate actually signing the Android build.

Challenges we ran into

One of the biggest challenges was deciding how much authority an AI companion should actually have.

It would have been easy to allow the model to decide when something sounded important enough to save. Instead, we built a much stricter separation between conversation and action. That required creating deterministic routing, duplicate-turn protection, explicit tool policies, and visible receipts.

Conversation state was another surprisingly difficult problem. A sentence like “yes, give me one idea” makes perfect sense to a human immediately, but software has to understand that it belongs to the previous check-in rather than treating it as a new one.

Google Sign-In also became one of the more memorable technical battles. The Android CI build used a specific signing certificate, while the matching SHA-1 fingerprint had accidentally been registered to a different Firebase Android package. The configuration looked correct at first glance, but Google authentication continued to fail until we traced the exact certificate, package name, OAuth entry, generated google-services.json, and CI signing key together.

That experience led us to add CI verification that fails before building if the Firebase OAuth configuration does not match the certificate actually signing the APK.

Privacy created another challenge. Health and emotional context can make an assistant more useful, but sending every available piece of information to a model would have been the opposite of Wisteria's design philosophy. We instead reduced Health Connect data locally and kept raw values outside the model prompt.

Accomplishments that we're proud of

We are especially proud that Wisteria can remain conversational without giving the model unrestricted control.

A real voice check-in can travel through Google ADK and Gemini, receive a natural response, create exactly one authorized local record, and then continue naturally into follow-up conversation without duplicating that record.

We are also proud of Night Shift. Instead of claiming that an AI has “figured out” someone's body, it presents patterns with samples, confidence, and uncertainty. The person gets a useful heads-up without Wisteria pretending to know more than the data supports.

Wisteria also now has a working connected Android build with:

• Google Sign-In.
• Firebase Authentication.
• Cloud Firestore synchronization.
• Firebase AI Logic and Gemini.
• Health Connect integration.
• Bounded conversational memory.
• A test-gated CI pipeline that produces a working APK.

Perhaps most importantly, the project kept its original interaction philosophy even as its technical scope grew:

You should not have to understand a system before the system can help you.

What we learned

We learned that reducing friction can be a meaningful technical problem in its own right.

A three-second interaction sounds simple, but making it trustworthy required careful decisions about state, memory, permissions, synchronization, tool authority, fallbacks, and uncertainty.

We also learned that personalization does not require collecting everything. A system can use private context while still deliberately limiting what enters an AI prompt.

The project reinforced another lesson: generative intelligence and operational authority do not need to be the same thing. Giving Gemini responsibility for language while keeping actions behind small deterministic policies made Wisteria easier to test, explain, and trust.

User feedback also broadened our thinking. Wisteria began with PMDD and perimenopause, but questions about experiences such as PCOS highlighted the larger problem underneath: many tracking systems assume predictable cycles. Wisteria can remain useful without making that assumption.

And we learned that sometimes the most important thing an agent can do is not something complicated.

Sometimes it is simply being able to understand:

“I feel off.”

What's next for Wisteria

The immediate next step is testing Wisteria with more people whose cycles and day-to-day experiences do not fit neatly into conventional tracking systems.

We want to learn where its plain-language approach is genuinely useful, where it needs improvement, and which features people actually want before expanding the product further.

That includes exploring its usefulness for people experiencing PMDD through perimenopause, PCOS and other irregular-cycle experiences, while continuing to avoid diagnostic claims or condition-specific assumptions.

We also want to improve Wisteria's long-term pattern tools, conversational memory, accessibility, and privacy controls while preserving the principle that the person—not the model—remains in control of what is stored, shared, or acted upon.

Longer term, Wisteria could become less of a traditional tracker and more of a personal rhythm companion: something that notices the person's own history without demanding that their life conform to a predefined calendar.

Three seconds in.

Something useful back.

Built With

• adk-kotlin
• android
• android-credential-manager
• cloud-firestore
• datastore
• fastapi
• firebase-admin-sdk
• firebase-ai-logic
• firebase-app-check
• firebase-authentication
• gemini-3.5-flash
• github-actions
• google-cloud-vertex-ai
• google-sign-in
• gradle
• health-connect
• jetpack-compose
• junit
• kotlin
• kotlin-coroutines
• python
• robolectric
• roborazzi
• room
• vertex-ai-memory-bank