DayMend

When childcare falls through, DayMend repairs the day—preserving what still works, finding feasible backup care, and only interrupting parents when a real decision needs approval.

Comment

Inspiration

Childcare disruptions can turn a normal workday into a coordination problem very quickly. If a nanny cancels, a parent may suddenly need to check family availability, meetings, transportation, backup care, cost, and approvals all at once.

I built DayMend for working parents who need help recovering from those disruptions without manually rebuilding the entire day.

What it does

DayMend is an agentic childcare recovery system.

When care falls through, it:

  • understands what changed
  • preserves the parts of the day that still work
  • checks known family and caregiver options
  • researches backup care only when needed
  • validates timing, location, transport, trust, and cost
  • creates a revised care plan
  • asks for approval only when family policy requires it
  • executes the approved recovery flow
  • verifies that final childcare coverage is complete

The core idea is:

Agents propose. Deterministic services own truth.

The agents handle reasoning, planning, research, and replanning. Deterministic services own feasibility, exact cost, family policy, approval rules, transport constraints, execution guards, and completion verification.

How I built it

DayMend uses three Strands agents:

  • Recovery Orchestrator — understands disruptions, determines what changed, and coordinates the recovery flow
  • Constraint Planner — selects a feasible childcare plan from authoritative care and transport primitives
  • Backup Care Research — searches synthetic backup-provider inventory when known family options are insufficient

The application is deployed on AWS using:

  • Strands Agents SDK
  • Amazon Bedrock AgentCore
  • Claude Sonnet 4.5
  • FastAPI
  • AWS App Runner
  • Angular
  • Amazon S3
  • Amazon CloudFront
  • Amazon DynamoDB
  • Amazon CloudWatch

A preservation-aware replanning flow allows DayMend to keep unaffected care instead of regenerating the whole day.

For example, if Grandma becomes unavailable after Plan A has already been created, DayMend preserves the childcare segments that still work, invalidates only the Grandma-dependent portion, researches backup care if necessary, and repairs only the broken part of the schedule.

Challenges I ran into

One of the hardest problems was making the system behave like a real recovery agent instead of simply asking an LLM to generate a new schedule.

I had to solve several issues:

  • preventing the model from inventing infeasible transport or caregiver transitions
  • preserving unaffected parts of an existing plan during replanning
  • determining when known family options were actually sufficient
  • rejecting researched providers that could not form a complete connected care plan
  • keeping exact cost and approval policy outside the LLM
  • maintaining one persistent recovery case across multiple disruptions
  • exposing real progress to the UI without showing fake chain-of-thought or fake percentages

I eventually moved important feasibility decisions into deterministic services and allowed the agents to reason only over valid, authoritative choices.

That separation made the system more reliable and also made the agent behavior easier to explain.

Accomplishments I'm proud of

I'm especially proud of the second-disruption recovery flow.

DayMend can:

  1. recover from an initial nanny cancellation
  2. create a valid Plan A
  3. react when Grandma later declines
  4. preserve the care segments that still work
  5. identify the exact broken interval
  6. research backup care only when necessary
  7. reject infeasible candidates
  8. select a feasible replacement
  9. apply the family's approval policy
  10. resume the same persisted recovery after approval
  11. verify final childcare coverage before marking the case resolved

The result feels less like a chatbot and more like an actual recovery system.

What I learned

The biggest lesson I learned was that strong agent systems should not give every responsibility to the model.

I learned to separate:

  • reasoning from truth
  • planning from feasibility
  • recommendation from policy
  • execution from completion verification

The agents are most useful when they reason over a controlled world model, while deterministic services enforce the hard constraints.

I also learned that replanning is more valuable when the system preserves what still works instead of starting over.

Another important lesson was that an agent should not call every capability on every run. Backup Care Research is only used when known family options are insufficient. That makes the system more deliberate and easier to trust.

What's next for DayMend

The current demo uses synthetic backup-provider inventory and simulated booking, messaging, calendar, and payment actions.

Future versions could integrate with:

  • real calendar providers
  • real childcare-provider directories
  • messaging services
  • mapping and travel-time APIs
  • booking systems
  • payment providers

I would also like to expand the agent's tool use so it can work across more real external systems instead of relying on simulated downstream actions.

The long-term goal is for DayMend to become a true background family operations agent that handles coordination quietly and surfaces only the decisions that genuinely require a parent.

Demo disclosure

The following parts are real:

  • Strands agent reasoning
  • Amazon Bedrock AgentCore runtime
  • orchestration
  • replanning
  • backup-care research decision
  • feasibility validation
  • family policy
  • approval boundary
  • persistence
  • completion verification
  • live UI progress

The following parts are synthetic or simulated:

  • backup-provider inventory is synthetic
  • booking actions are simulated
  • calendar actions are simulated
  • messaging actions are simulated
  • payment actions are simulated

Built With

Share this project:

Updates

Submission history