Kinloop

An autonomous agent that runs a family's caregiving coordination — medications, appointments, paperwork — and only interrupts you when there's a real decision to make.

Comment

Inspiration

About 1 in 5 adults in the US is an unpaid family caregiver — usually coordinating with siblings or a spouse, across different households. It's never just one task. It's medications on one schedule, appointments split across different specialists, and insurance paperwork with its own deadlines — three separate systems, tracked by three separate people, with nobody holding the full picture. Every existing tool in this space — shared calendars, caregiving apps like CareZone — is a tracker: a human still has to open it, read it, and reconcile what's happening. None of them actually act. We wanted to build the thing that does the reconciling itself, and only interrupts a human for a genuine decision — which is also the literal design brief of this hackathon's Everyday Agents track.

What it does

Kinloop runs once a day, unattended, for a family sharing caregiving duties. It checks every tracked medication for refill status and drafts a refill request for anything overdue. It scans the family's shared appointment calendar for conflicts — a family member double-booked as a driver, or an appointment with nobody assigned — and proposes a fix using who else is free. It tracks recurring paperwork deadlines (insurance recertification, benefit renewals) and flags what's missing before it's too late. And it makes exactly one more decision on top of all that: which of the day's findings are routine (log only) versus a genuine decision that needs a human — and only notifies someone for the latter.

How we built it

Kinloop is built with the Strands Agents SDK using the Agents-as-Tools pattern: a Supervisor agent delegates to four specialists — MedAgent, ApptAgent, PaperworkAgent, and NotifierAgent — each with its own system prompt and tools, called as tools themselves from the Supervisor. NotifierAgent is deliberately a separate agent rather than folding escalation into each specialist, so the "should a human be interrupted" decision gets made once, consistently, by comparing findings across all three domains together.

The deterministic parts — is a refill overdue, do two appointments conflict, is a deadline urgent — are plain, unit-tested Python functions that the @tool decorator exposes to the agent loop. The LLM reasons about what to do with that information (drafting a message, phrasing a notification, deciding who to escalate to), not about arithmetic on dates. That split made the system both cheaper to run and possible to test thoroughly without needing a model in the loop for the parts that don't need one.

Runtime is AWS Lambda, triggered once daily by EventBridge Scheduler, backed by DynamoDB and Amazon Bedrock (Nova Lite, on-demand — no provisioned throughput). A Strands hook (BeforeToolCallEvent) enforces a hard ceiling on how many sub-agent calls the Supervisor can make per run, as a cost safety measure independent of prompting. We deliberately kept Bedrock AgentCore Runtime out of the always-on path — its Memory, Gateway, and Observability components bill independently with no meaningful free tier, and Observability specifically has documented uncapped-cost risk from idle-session accrual. Lambda + EventBridge gets the same job done inside the near-permanent AWS free tier, since the whole system only runs for a few seconds a day. AgentCore is still demonstrated as an optional, deliberately-torn-down deployment path.

Challenges we ran into

The biggest one had nothing to do with the agent design: this AWS account is new, and AWS's new-account identity/billing verification hold ended up blocking Bedrock access for an extended period, even with an active Support case and live chat contact. That blocks every real LLM call, on Lambda or locally, regardless of deployment target.

Rather than stall, we split Kinloop's logic on purpose along a line that turned out to matter a lot here: every deterministic decision (refill status, conflict detection, deadline urgency, and the escalation thresholds themselves) lives in plain Python functions, fully covered by unit tests, with zero AWS dependency. That let us build a --dry-run mode that exercises the real decision logic end-to-end with no Bedrock call, clearly labeled as such at every line of output — so development, testing, and even demo rehearsal never had to stop waiting on an account review queue. It's not a substitute for the real multi-agent reasoning, and we say so explicitly (see docs/dry_run.md) — but it meant a platform-level account restriction didn't become a project-level blocker.

Accomplishments that we're proud of

  • A genuine multi-agent architecture (Agents-as-Tools, 5 agents) instead of a single prompt doing everything
  • 10/10 unit tests on the real decision logic behind every tool, with zero AWS cost to run them
  • A cost model we can actually defend: on-demand-only Bedrock calls, a hard per-run call ceiling enforced in code (not just prompted for), and a CloudFormation-managed budget alarm that deploys before anything else does
  • Turning an infrastructure setback (the AWS verification delay) into a design decision (the dry-run mode) instead of a stalled project

What we learned

That separating "what does the LLM need to reason about" from "what's actually just arithmetic on structured data" pays off twice — once in Bedrock cost, and once in resilience, since it turned out to be the exact line that let us keep building through an infrastructure problem we didn't see coming. We also came away with a much sharper sense of where Bedrock AgentCore's pricing model creates real bill-shock risk for a background agent that runs briefly once a day, versus where it's the right call.

What's next for Kinloop

Real integrations in place of the structured sample data — pharmacy refill APIs, calendar sync (Google/Apple) instead of a shared JSON file, and document upload with real OCR/field-extraction via Amazon Textract for the paperwork side. We'd also like to let NotifierAgent learn a family's actual escalation preferences over time (some families want to be pinged for anything paperwork-related; others only for hard deadlines) rather than using one fixed policy for everyone.

Built With

Share this project:

Updates

Submission history