AWS Builder Center
LifeGuard AI: An Integrated Multi-Agent Framework for Longitudinal Health Record Management and Explainable Risk Assessment in Dependent Care

LifeGuard AI: An Integrated Multi-Agent Framework for Longitudinal Health Record Management and Explainable Risk Assessment in Dependent Care

LifeGuard AI, an integrated framework combining two complementary subsystems: Mediforever, a longitudinal digital health record platform providing a lifelong, unified medical data layer; and AHRA (Agentic Health Risk Assessment), a multiagent orchestration system that analyzes physiological inputs, produces explainable risk scores, and safely coordinates real-world escalation workflows with explicit user consent.

AWS SBG Leader at RIT Kottayam

When your patient can’t tell you they’re sick, a multi-agent system can. Here’s how I designed LifeGuard AI to fill the most overlooked gap in health monitoring.


Almost every AI health tool assumes the same thing: the patient can talk.
Think about how most health apps work. You log symptoms. You describe pain. You rate your sleep. The AI uses your description as the primary signal. This works fine — when you’re the patient and you’re conscious and coherent.
Now think about a three-month-old infant. Or a labrador with a fever. Or a bedridden elderly parent with dementia.
These individuals cannot describe their distress. Caregivers are left watching a smartwatch or baby monitor screen, looking at raw numbers — heart rate 182, sleep 3 hours, activity very low — with no reliable way to answer the only question that matters: should I be worried right now?
The gap: Existing health monitoring platforms either display raw data without interpretation, or use opaque single-model AI that gives you a risk score with zero explanation. Neither is useful under pressure at 2am.
This is why I built LifeGuard AI — a multi-agent system that takes fragmented physiological signals, reasons through them in context, produces a fully explainable risk assessment, and only takes action when you say so.

Why a single AI model isn’t enough

My first instinct was to train a single classification model. Feed in heart rate, temperature, sleep, activity — get a risk label out. Simple.
The problem is that a single model has no natural boundaries. It can’t tell you why it thinks the risk is high. It can’t be held accountable for a specific reasoning step. And critically, it has no way to handle the enormous biological diversity between a human newborn, an adult dog, and an exotic reptile.
A resting heart rate of 38 bpm is alarming in a human adult. In a ball python, it’s perfectly normal. A single model either needs impossibly diverse training data, or it collapses into population-level averages that are wrong for everyone.
“Instead of one model that knows everything poorly, I wanted seven agents that each know one thing well.”
That’s the core architectural insight behind AHRA (Agentic Health Risk Assessment): decompose the problem into specialist agents, each with a formally bounded knowledge domain, coordinated by a central orchestrator. I built the system on IBM watsonx Orchestrate, which gave me native multi-agent workflow management and explicit tool-gating for the consent layer.

The seven-agent architecture

Here’s how the pipeline works from input to output:
Agent 1 — Context & Normalization Agent Sets the biological reference frame for everything that follows. Species, age category, dependency type, and historical context from the Mediforever health record layer. Without this, every downstream reading is meaningless. A heart rate of 120 bpm is normal for a 3-month-old human infant and concerning for a resting adult. The normalization agent makes this distinction before any specialist agent sees the data.
Agent 2 — Vital Signs Analysis Agent Analyzes heart rate and body temperature against age- and species-specific reference ranges stored in its knowledge base. Outputs a four-point severity indicator (Normal / Mildly Abnormal / Significantly Abnormal / Critical) with a written natural-language rationale citing the specific reference range it applied.
Agent 3 — Sleep Cycle Evaluation Agent Evaluates sleep duration and quality against expected biological norms for the given species and age. Chronic sleep disruption is a high-sensitivity indicator of physiological distress across both human infants and companion animals. The agent flags deviations beyond one standard deviation from the expected norm.
Agent 4 — Activity & Mobility Assessment Agent Assesses movement behavior relative to expected baselines. Crucially, it distinguishes between expected low-activity periods (neonatal sleep) and pathological hypoactivity — a cross-species distress signal associated with pain, fever, infection, or organ dysfunction.
Agent 5 — Risk Aggregation Agent Combines severity indicators from all three specialist agents into a unified, explainable risk score (0–100). The aggregation uses weighted scoring that prioritizes vital sign anomalies (45%), activity anomalies (35%), and sleep anomalies (20%), reflecting clinical evidence on the relative predictive value of these signals in dependent populations.
Agent 6 — Threat Classification Agent Maps the aggregated numerical score to one of four threat levels:
Level, Score, Indicative Response
🟢 Normal, 0–25, Routine monitoring
🔵 Monitor, 26–50, Increase observation frequency
🟠 Warning, 51–75, Caregiver review; consider consultation
🔴 Critical, 76–100, Immediate action; consent-gated escalation
Agent 7 — Decision Orchestrator Agent The central coordinator. Dispatches inputs, validates all agent outputs, assembles the final explainable risk report, manages the user consent workflow, and — only when consent is given — triggers the Appointment Booking workflow. This is the only agent that talks directly to the caregiver.
What makes this genuinely different from a black-box classifier is that every output is traceable. The caregiver sees not just “Warning” but why: which agent flagged which reading, against which reference range. That traceability is what makes a 2am alert actionable rather than panic-inducing.

Mediforever: the memory layer

Real health risk doesn’t exist in a single moment — it exists against a lifetime of context. An infant heart rate of 160 bpm carries entirely different significance depending on whether that infant has a documented congenital cardiac condition or no prior anomalies.
This is why LifeGuard AI integrates Mediforever, a longitudinal digital health record platform I designed to store a person’s complete medical history — diagnoses, medications, allergies, lab results, emergency information — from birth to old age in a single, centralized, patient-owned system.
Within the LifeGuard pipeline, Mediforever feeds historical context into the Context & Normalization Agent before any risk assessment begins. The system reasons against a personal baseline, not just a population average. This is the difference between a risk system that knows health and one that knows this patient’s health.
Most EHR systems are siloed by provider, inaccessible to patients, and designed exclusively for adults capable of self-reporting. Mediforever is designed to be patient-owned, lifelong, and extend to all dependent populations — including companion animals and non-verbal dependents.

Safety and consent gating — the non-negotiable parts

The most important design decision in LifeGuard AI is not in the agents. It’s in what the agents are not allowed to do.
No agent produces a clinical diagnosis. Every output is a caregiver recommendation, not a medical conclusion. The system cannot tell you your infant has tachycardia. It can tell you the heart rate is significantly above the expected range for a 3-month-old and recommend scheduling a pediatric consultation. This constraint is enforced at the knowledge boundary level of each agent.
No automated action fires without consent. When a Critical condition is detected, the Decision Orchestrator presents the recommended escalation action and its full reasoning to the caregiver and waits. If the caregiver confirms, the appointment booking workflow runs. If not, nothing happens. There is no silent autonomous action in this system.
1
2
3
4
5
6
7
8
9
10
11
# Simplified escalation logic in Decision Orchestrator
if threat_level == "Critical":
consent = request_user_consent(
action="book_appointment",
reason=orchestrator_summary,
specialist=recommended_consultant
)
if consent.confirmed:
trigger_appointment_workflow(consent.details)
else:
log_and_monitor() # no silent actions, ever
No agent reasons beyond its knowledge base. Hallucination in a health context isn’t an inconvenience — it’s dangerous. Each agent operates strictly within its predefined knowledge base of biological reference ranges, species-specific norms, and action-to-threat mappings. The Orchestrator validates every agent output before incorporating it into the final report.
These three constraints aren’t features. They’re prerequisites for a health AI system that a caregiver can actually trust.

Evaluation: did it actually work?

I tested AHRA on five synthetic clinical vignettes spanning three dependent populations: human infants, adult dogs, and an exotic reptile (ball python). Each vignette was validated against published pediatric and veterinary clinical reference ranges before testing.
A five-person expert review panel — including biomedical engineering students, a veterinary science student, and a clinical data science researcher — independently rated each AHRA output on classification correctness and explainability quality (1–5 Likert scale).
Results:
Threat classification accuracy: 5/5 (100%)
Mean explainability score: 4.4 / 5.0
Mean response latency: 3.2 seconds
Consent gate precision: 100% (no false triggers, no missed Critical escalations)
The reptile scenario was the most interesting test. A ball python’s resting heart rate of 38 bpm and body temperature of 34.2°C would read as life-threatening for a human. The Context & Normalization Agent correctly identified the subject as an ectotherm, applied species-specific thermoregulation norms, and classified the scenario as Monitor — the correct output. The cross-species generalization worked because the knowledge is in the agent’s bounded reference base, not learned from a mixed-population training set.
Honest limitation: Five synthetic vignettes are not a clinical trial. This is an architectural proof-of-concept. Real-world deployment requires prospective evaluation on actual patient data with clinical partners. I’m explicit about this in the preprint, because a health AI paper that doesn’t acknowledge its limitations is a health AI paper you shouldn’t trust.

What I’d do differently

If I were starting from scratch today, I’d build the orchestration layer on Google ADK rather than IBM watsonx, for two reasons: portability and ecosystem alignment. Google ADK gives you more direct control over inter-agent communication protocols and integrates naturally with Google Cloud infrastructure for production deployment. The IBM platform was excellent for the hackathon context — rapid prototyping, clean workflow UI — but creates platform dependency that matters at scale.
I’d also add a temporal reasoning agent from the start. The current system reasons over a single snapshot of physiological data. A time-series agent capable of detecting gradual deterioration trends — a heart rate creeping up 5 bpm per day over two weeks — would catch deterioration patterns that single-point-in-time assessment misses entirely.

What’s next

The next steps I’m actively working toward:
Direct wearable API integration (Apple HealthKit, Fitbit Health Solutions API, pet IoT sensors)
HL7 FHIR compatibility for Mediforever to connect with clinical EHR systems
Reimplementing the agent pipeline on Google ADK for platform portability
Federated learning for agent knowledge base improvement without centralizing patient data
Prospective evaluation with clinical and veterinary partners
The full architecture, agent knowledge bases, and demo interface are open source at github.com/Argonebee/Lifecycle-Monitoring-System. The technical preprint is available as a research document.
If you’re working in dependent-care AI, clinical decision support, or agentic health systems and want to collaborate or give feedback — reach out at argonebee@gmail.com or connect on LinkedIn https://www.linkedin.com/in/argonebee/ .

I am a Computer Science undergraduate at Rajiv Gandhi Institute of Technology, Kottayam, working on agentic AI systems, LLM integration, and cloud-native health applications.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article