AI accountability partner: why vipassana.cool is deliberately not one

No, and the design is explicit about that. When you sign up through /practice-buddy on this site, the person who ends up sitting across from you on a Google Meet call every day is a real human meditator who also signed up, filled in their timezone and preferred time, and accepted a calendar invite. No model, no chatbot, no voice agent, no digital twin. The only AI anywhere on the site is a small page-level question-answerer (the floating widget on guide pages) that reads the public content of these /t/ pages and answers questions about them. It is not your partner and it cannot be. Your partner has a calendar that fills up, a bedroom with a door that closes, and the same 6 AM alarm you do.

Because the thing that makes accountability work is that the other party bears a cost when you do not show up. A chatbot greets you the same on Monday and on Thursday; your absence is not visible in any way that registers as a loss to it. A person who woke up, made tea, opened Meet at 5:58 AM, and sat there alone for a few minutes has a different experience of your absence. The literature on implementation intentions and appointment-based accountability (Gail Matthews at Dominican University, Rogelberg on scheduled commitments, a long line of studies on peer-pressured exercise) all converge on the same finding: the strength of the effect is proportional to the concreteness of the expectation of another human. An AI has no expectation that can be disappointed. A person does. The product optimizes for that asymmetry instead of around it.

No. The auto-matcher lives at src/app/api/auto-match/route.ts, runs every two hours via Vercel cron, and is 476 lines of ordinary TypeScript. It builds a list of session slots from eligible signups, filters pairs where the UTC minute difference is more than 60, scores the remaining pairs on a four-tier plain-old-data sort (ready-status > both-old-student > same-session-duration > smallest time difference), and greedily picks non-overlapping pairs. There is no embedding step, no vector similarity, no prompt, no model call, and no temperature knob. The dependencies imported at the top of the file are Neon (Postgres), Resend (email), and a Google Meet helper; no openai, no anthropic, no langchain. I have grepped the repo for those strings to make sure this statement stays accurate before publishing.

Tier 1, readyScore, counts how many of the two people are already in status='ready' — meaning they had a prior match expire but had confirmed on their end, so they should be fast-tracked. Tier 2, bothOld, is true only when both are Goenka old students (finished at least one 10-day course). Tier 3, sessionMatch, is true when both are sitting for the same duration (20, 30, 45, 60, 90, or 120 minutes). Tier 4, diff, is the number of minutes between the two UTC session times, the smaller the better, up to the 60-minute hard cap. The ordering is intentional: a ready person waiting for a rematch gets priority over someone who signed up 25 hours ago; a pair of seasoned meditators gets priority over a seasoned-plus-new mix; people who want to sit the same length get priority over people with different preferred durations; and finally, when everything else is equal, proximity in clock time breaks the tie. No weights to tune, no learning rate, no reward function to misalign.

One line, src/app/api/auto-match/route.ts:84 — if (c.contact_count >= 10) continue. The waitlist_entries table has a contact_count column that increments every time the person is offered a match. Ten offers without a successful match (with a 7-day cool-off between each retry) and they drop out of the candidate pool for auto-matching. Status 'ready' bypasses the cap. They can still sign up again manually or the operator can re-engage them by hand from the admin UI, but the cron will not keep sending them to new partners. This is the sort of behavior an LLM-based matcher would need a careful policy and a lot of prompt engineering to get right, and one if-statement does it deterministically.

Yes, in exactly one place: the floating 'page assistant' chat panel on the /t/ guide pages, powered by Google's Generative AI SDK. You can see the exact setup at src/components/guide-chat.tsx and src/app/api/guide-chat/route.ts. It answers questions about the content of the site by retrieving the /t/ pages you are currently reading. It has never been marketed as an accountability partner, it does not have access to the matches table, it cannot modify your match state, and it cannot send emails. It is a content assistant, scoped to the public guide corpus. The accountability partner is a human.

Every time either party clicks their personal Meet tracking link, the GET handler at src/app/meet/[token]/route.ts inserts a row into meet_clicks with (token, match_id, person_id, meet_url, ip, user_agent). The row is the receipt. Two rows on the same match_id within a few minutes of each other, at roughly the same wall-clock time, is the daily performance signal. One row without a partner row is the partial-performance signal. No rows for days is the silent-breakup signal that ages the pair out. No streak counter, no XP, no badge. The data is in the database and the operator reads it directly on the /admin dashboard.

There is no chatbot, so no. A match can end by one of three paths. Either side clicks the unsubscribe footer on any email, which runs a single UPDATE matches SET status='ended' across every active row involving that person. Either side declines the Google Calendar invite, which /api/check-rsvp picks up daily and flips the match to status='ended'. Or both stop clicking the Meet link for long enough that the operator notices the silence on the dashboard and closes it manually. In every case the remaining party returns to status='ready' on the waitlist and enters the pool with priority for the next auto-match run. The pair never gets rematched with each other (that is enforced by getPriorMatchedIds in src/lib/db.ts).

Short-term, possibly, for one morning. Long-term, no. The product is calibrated around this risk in three places. First, the serial-ghoster filter above removes people who have been offered two matches without following through. Second, an expired match is not a dead end: it sends you back into the pool with a 'ready' priority flag, so you get paired with someone new within hours of the next matcher run. Third, the product is free and does not advertise its numbers publicly, which means the signups are unusually self-selected toward people who want the real thing. The result is not a chatbot-like 100 percent reliability; it is something closer to the reliability of a gym buddy or a running partner, which is the thing most accountability research actually measures.

No. The matcher scores on meditation-specific attributes (old-student status, session duration on a Goenka-style 30-to-120-minute scale, morning versus evening sit). The intro emails assume both parties are meeting to sit in silence for the same duration. If you want accountability for workouts, writing, studying, or business goals, the architecture pattern on this page is public and copy-able, but the running product is not a general-purpose buddy service. For anything about how to actually sit, how to work with a difficult session, or how to begin the practice at all, the correct place is a residential 10-day course at dhamma.org with an authorized assistant teacher. Nothing on this site will teach you to meditate.