CompassionateConnect AI
A multi-agent mental-health intake system with ethical guardrails built in from the start
Built for the Google Cloud Multi-Agent (Agent Development Kit) Hackathon, archived, demo only
What was the problem?
Intake paperwork at mental health clinics is repetitive for patients and time-consuming for staff, and it’s easy for a crisis-relevant detail to get lost inside a long, unstructured intake response if nothing is specifically watching for it.
What did I make?
I built a system of six small AI agents that each handle one part of intake (asking questions, watching for crisis indicators, writing a therapist-friendly summary, suggesting possible directions for a session) instead of one agent trying to do everything. Every insight is explicitly labeled as a suggestion for a therapist to evaluate, never a diagnosis.
Why is that useful?
Splitting the work into agents with clear boundaries makes it possible to give safety rules (like flagging a crisis or refusing to diagnose) to one specific agent as its explicit, narrowly scoped job, rather than hoping a single system behaves correctly across every kind of conversation. That’s the intended design boundary, not a tested guarantee it can’t be circumvented; see below.
What is still unproven?
This was tested only with simulated patient data, demoed live but never used with a real patient or clinic, and its own retrospective is explicit that there’s no evaluation harness yet, meaning nobody has systematically measured whether its summaries or crisis detection are actually good, only whether the system runs.
The problem
- Intake paperwork at mental health clinics is repetitive and impersonal: patients re-explain the same concerns to multiple people, and clinicians often don’t get a usable summary before the first session.
- Crisis-relevant details can go unnoticed inside long, unstructured intake responses if nothing is specifically watching for them.
The approach
- Built as six independent agents with defined input/output contracts, sequenced by a coordinator: an onboarding coordinator, an intake-questionnaire agent (asks, validates, and clarifies responses in real time), a crisis-response agent (detects crisis indicators and logs high-priority cases), a summary-generator agent (therapist-friendly briefs), an insight agent (suggests possible therapy directions), and a data-persistence agent (Firestore plus local JSON).
- Ethical design was a stated constraint from the start, not an afterthought: no diagnoses, only directions for a therapist to evaluate, disclaimers embedded in every AI insight, simulated patient data only with no real PHI at any stage, and an explicit goal of augmenting clinicians rather than replacing them.
- Deliberately kept deployable from a terminal: a CLI-first design so a clinic without web developers or complex infrastructure could still run it.
What broke (and how it got fixed)
- Refactoring toward Google’s Agent Development Kit hit a persistent TypeError initializing FunctionTool on google-adk==1.2.1. The issue report documented argument-parsing behavior involving functions with mixed required and optional parameters, reproduced on Python 3.13 and 3.11. After recording the environment and diagnostic evidence, I filed google/adk-docs issue #826 and continued development with a workaround. This is the same issue tracked in this site’s Manual Bugs Log.
- The CrisisResponseAgent and SummaryGeneratorAgent ended up sharing state in ways that created ordering dependencies between agents meant to be independent, recorded directly in the project’s own retrospective as a design lesson: a production version would need stricter input/output contracts and a message bus instead of direct agent-to-agent calls.
- The project’s GitHub history didn’t survive the hackathon intact: an account issue mid-build deleted the original repository, requiring a full re-upload to a new one before judging.
Outcome
- A working end-to-end flow was demoed live rather than just described: a deployed intake form (Render) feeding Firestore, plus a separate CLI therapist dashboard.
- Informal demo feedback was collected directly from practicing therapists and used to inform possible next steps, rather than guessing at clinical needs in isolation.
- The project’s own retrospective is unusually candid about what’s not yet proven: "No eval harness; I tracked whether the system ran, not whether the outputs were actually good," naming structured evaluation of summary quality and crisis-detection accuracy as required before any clinical use.
Stack
- LLM
- Gemini 1.5 Flash (google.generativeai / Vertex AI)
- Backend
- FastAPI + Uvicorn, Python multi-agent architecture
- Storage
- Firestore (real-time) + local JSON (offline demo + backup)
- Deploy
- Render (intake form) + a separate CLI therapist dashboard
Honest scope
A hackathon submission the project’s own README marks "Archived / Demo Only." It ran on simulated patient data exclusively (no real PHI at any stage) and was never used with real patients or in a clinical setting. It is not a validated mental-health tool, and its own creator names the missing evaluation harness as a blocker to any clinical use.
Have a technical problem, AI or otherwise, that needs a second pair of eyes?
Let's talk.