Inspiration
Most connected intimate-wellness devices already have an app. I tried several while researching this project, and the same issue kept surfacing: the phone demanded too much attention.
The user has to browse preset patterns, adjust sliders, reconnect the device, and remember which combination worked last time. That felt backwards. The software was controlling the device, but doing almost nothing to help the user carry a good experience forward.
I also found people wiring devices to Claude, ChatGPT, Gemini, and local models through scripts and developer tools. The experiments were interesting, but they raised a problem I could not ignore:
If an AI suggested ten seconds and the device disconnected after three, what should the AI remember?
That question became IntoMate.
What IntoMate does
IntoMate connects an AI companion to a compatible interactive device and keeps a clear record of what happened during the session.
It separates:
- what the companion proposed;
- what the user allowed;
- what command was sent;
- what the device actually completed;
- what the user later confirmed.
Those details matter because a command can be accepted without the intended experience ever happening.
For example:
Ari proposed: 10 seconds
Device completed: 3 seconds
Connection lost
User confirmation: missing
IntoMate rejects that session as preference evidence.
During a session the user needs only a few direct actions: Stay here, Gentler, Slower, Pause, Stop.
Afterward Ari offers a short interpretation. The user can confirm it, correct it, skip it, or say the experience did not physically happen.
A confirmed session creates two things: a relationship memory for Ari, and a plain-language body insight for the user. The next session starts from that confirmed memory and changes one variable.
How I built it
IntoMate is a React and Vite frontend talking to a local Python host.
The host owns session state, safety rules, device capabilities, and local records. The frontend owns the experience: choosing Ari's style, reviewing a proposal, running Live, reflecting afterward, and seeing what was kept.
The companion never sends raw values to the device. It can suggest a high-level action, such as holding steadily for slightly longer. A deterministic safety state machine decides whether that action is allowed and how it becomes device behavior.
One internal command format covers several device paths:
- a deterministic presentation device;
- a gated remote-device adapter;
- a future Bluetooth adapter.
That let me build and test the whole product flow before treating the physical-device path as finished.
The evidence model is a sequence of separate events. Proposal, authorization, command, execution, reflection, and confirmation are stored independently, and memories are computed from those records. Correcting or deleting evidence recomputes the conclusion that depended on it.
The language layer is provider-agnostic and returns text only. It imports nothing from the device or engine layers, so no model can issue a device command, and Stop never depends on model output. In this repository the OpenAI provider is registered but deliberately left unimplemented until it is validated against a real key, so the demo runs the local path. I did not want to ship a runtime claim I had not verified, in a product whose whole argument is that unverified things should not be believed.
I used Codex heavily during development. I had it inspect the repository before changing anything, trace the existing session and adapter architecture, and find where the safety and evidence boundaries were weak. It then helped me implement across the frontend, Python host, state machine, adapters, and test harnesses. It was most useful when a problem crossed several files and layers at once, like disconnect handling, or carrying a corrected reflection all the way through to the final memory. I reviewed the product decisions myself, especially every case where the system had to refuse to learn.
GPT-5.6 in ChatGPT was the thinking partner rather than a runtime dependency. I used it to work out the truthful-learning model, reason through provenance and recomputation, pressure-test the safety boundaries, shape the companion's voice and the English product language, and rewrite the parts of this submission that had drifted away from what the code actually does.
The current repository passes 433 host tests and 206 frontend tests, plus the production TypeScript and Vite build.
The public Hackathon demo runs on isolated deterministic state, so judges can walk the complete flow without a simulated session ever being presented as physical evidence.
What I learned
I thought the hard part would be connecting the AI to a device.
The hard part was deciding what the AI had the right to remember.
A server response does not prove a device completed an action. A device command does not prove what the user experienced. A positive comment does not prove which part of the session caused it.
Once that landed, the architecture changed. I stopped treating a session as one continuous event and started recording each stage separately. I narrowed the learning model so one recommendation moves one variable, which makes the result easier to understand and makes wrong learning easier to catch.
Stop became a hard boundary. It cannot depend on model output, a generated response, or a remote provider. The language layer is allowed to fail; the session still has to stay controllable.
Privacy got the same treatment. The session record stays local by default, and the user can inspect, correct, export, or delete it.
Challenges
The hardest engineering work has been device interoperability.
Many Bluetooth devices use undocumented protocols. Two devices with similar features can expose completely different command formats. A dual-channel device may behave as one combined channel in one app and two independent channels in another.
I am currently targeting one Bluetooth device that is normally driven through device app. I started with passive BLE discovery, because I did not want the first real-device experiment to be an uncontrolled write.
The validation order matters:
- identify the service and characteristics;
- confirm the Stop path;
- test the lowest possible output;
- verify execution;
- only then let a session count toward physical learning.
The other challenge is separating product value from novelty. Someone may enjoy the AI voice once and never come back. Someone else may value the memory and prefer direct control. I built it so I can measure those separately instead of calling every repeat session "AI retention."
What's next
The next milestone is one complete physical-device path.
I need to measure connection reliability, physical Stop latency, what happens when the connection disappears, whether execution can be attributed to the right action, and whether corrected or deleted evidence actually changes the resulting memory.
After that, an eight-week invitation-only test with 30 to 50 adults who already use both an AI companion and a connected device. Each participant completes four verified sessions. I would track activation, second-session return, week-four and week-eight retention, willingness to pay, and any false relationship memories.
The scope stays deliberately small: one companion, one device, one learning variable, and no false relationship memories.
Built With
- anthropic
- api
- bluetooth
- claude
- energy
- fastapi
- keychain
- low
- openai-compatible
- os
- pydantic
- pytest
- python
- react
- rest
- sqlite
- typescript
- vite
- websockets
Log in or sign up for Devpost to join the conversation.