Home Page
Agent Descriptions
Example Intake Form Question
Example Answer Choices
Update Answer
Care plan given by agents
More Care plan recommendations
Save Plan Options
Agent Collaboration

ParkCare

One form. Three AI agents. One coordinated care plan for Parkinson's.

Inspiration

Parkinson's affects everyone differently. One person has an occasional tremor. Another falls often, lives alone, and needs help every day. Yet finding support means searching three separate worlds: medical directories for specialists, product sites for mobility aids and home modifications, and agency listings for in-home care. Nobody connects them, so patients and families are left to work out how the pieces fit together, often while managing fatigue, stiffness, and a tight budget. This challenge became deeply personal when one of our teammates’ grandparents was diagnosed with Parkinson’s and later passed away. Their experience reminded us that behind every diagnosis is a family navigating uncertainty, and that finding the right support should not be another burden they have to carry.

We wanted to build something that listens to a person's situation in their own words, then helps them see how medical care, equipment, and caregiving work together.

What it does

ParkCare is a multi-agent website that helps people with Parkinson's disease and their caregivers explore personalized care resources.

One accessible intake. The user answers a few open-ended questions in plain language, by voice or by typing. One question per screen, large tap targets, autosave, and every question skippable.
A shared patient profile. The app turns those answers into a structured profile. The user reviews and corrects it on a "Here's what we understood" screen before anything else happens.
Three specialized AI agents analyze the profile:
- Medical Agent: relevant specialists, clinics, and medical resources
- Equipment Agent: mobility aids and home-safety options
- Caregiver Agent: home-care and support services that match needs and preferences
Agent collaboration. The agents exchange findings. For example, the Equipment Agent flags frequent falls, and the Medical and Caregiver Agents adjust their recommendations in response.
One coordinated care plan. The result is a prioritized list of next steps with explanations, resource cards, and a visible record of what the agents said to each other.

How we built it

Frontend: Next.js (App Router), React, TypeScript, Tailwind CSS, and accessible components designed around WCAG 2.2 AA, with large touch targets, text-size controls, high-contrast themes, and voice dictation.
Database: PostgreSQL for anonymous sessions, intake answers, patient profiles, the three resource datasets, agent messages, and care plans.
AI: an existing LLM API (no custom training). It extracts a structured profile from open-ended answers, and each agent uses its own instructions and its own resource dataset.
Agent communication: a Python service hosts the three agents as A2A servers that talk over an AGNTCY SLIM node. An orchestrator runs two rounds (independent analysis, then an exchange of findings), and a synthesizer builds the final plan. Every message is saved so the UI can show the collaboration.
Data: small curated datasets for medical resources, equipment, and caregiver services, informed by sources like the CMS Provider Data catalog and Parkinson's Foundation guidance. Anything simulated is clearly labeled.
Process: we planned the product in a spec first, then built in phases with Cursor: intake, profile extraction, datasets, individual agents, agent messaging, and the results page.

Challenges we ran into

Designing specifically for Parkinson's Tremor, slowness, fatigue, and soft speech changed our decisions: no drag-and-drop, 56px targets, no timeouts, voice input with an editable transcript, and autosave for "off" periods.
Open-ended answers vs. structured data. Free text is friendlier for users, but agents need structure. We added an extraction step that returns "unknown" instead of guessing, plus a confirmation screen so users can correct mistakes.
Fast-moving agent infrastructure. SLIM and A2A packages change quickly, so we pinned versions, started from a hello-world agent, and kept a fallback.
Keeping the AI honest. We built guardrails so agents can only cite resources that exist in our datasets and must state uncertainty instead of filling gaps.

What we learned

Accessibility is a design constraint from the first sketch, not a checklist at the end.
Multi-agent systems get interesting at the handoffs. The value is how one agent's finding changes another's.
Trust matters most in health-adjacent tools. Labeling what's verified and what's uncertain is a feature.
Letting people describe their situation in their own words surfaces details that checkboxes miss, as long as the user can review what the system understood.
Keeping scope small (one form, three agents, three small datasets) is what made an end-to-end demo possible.