Epilogue

Epilogue carries the paperwork after a loss: organizing accounts, drafting letters, and following up, so grieving families return only for decisions that need them. Built with Strands Agents.

Comment

Inspiration

When someone dies, their subscriptions keep renewing. Their bank still needs documents. Their family still has to find the insurance policy, keep the house powered, and decide what happens to the photographs.

Each task sounds small until you are the person carrying all of them while grieving.

The Agents for Humans brief made me think about where an agent could give someone back more than time. Epilogue grew from a simple question: what if a family could explain what happened once, hand over the paperwork, and only come back when a decision genuinely needed them?

I built Epilogue for surviving family members and executors facing the administration after a loss. Its name reflects the work: helping close the practical chapters of a life with care, while leaving the personal choices with the people who knew that person.

What it does

Epilogue turns a narrative and a “shoebox” of statements, mail, and notes into an ongoing case. It identifies accounts and obligations, creates a plan, drafts correspondence, processes replies, follows up when an institution goes quiet, and keeps a record of what happened.

The working demo follows the fictional Mitchell family. The agent deals with simulated banks, subscriptions, utilities, insurance, benefits, and identity alerts. These institutions push back: a bank demands a certified document; a gym ignores a cancellation channel; an insurer needs a signature. The agent has to respond to those conditions and keep work moving.

The family sees a calm dashboard with active matters, correspondence, weekly notes, and decision cards. Choices involving memories, irreversible actions, or amounts above the family's financial threshold pass through an explicit approval gate. A “hold” or “no” remains a refusal.

The model and agent work are real; the institutions and transactions are simulated. The demo sends no real letters and moves no real money. Its case clock lets a reviewer advance days to observe follow-ups and replies that would otherwise take weeks.

How we built it

Epilogue uses Python and the Strands Agents SDK for the agent system:

  • An Intake Reader, Archivist, and Planner convert narrative and documents into typed Pydantic objects: a case profile, account inventory, and task plan.
  • A Steward works individual matters and calls specialist Strands agents through Agent.as_tool(): a Scribe for correspondence, an Advocate for potential refunds and benefits, and a Sentinel for identity signals.
  • A Triage agent classifies incoming replies into structured results so the workflow can route them.
  • Custom tools handle the case ledger, document vault, institutional playbooks, correspondence, and requests for human decisions. Strands hooks record tool activity for the audit trail.

The Decision Gate lives in Python, at the tool boundary. It checks the family's autonomy settings and recorded choices before allowing an outward action. Financial actions above the threshold require authorization for the amount; permission for a different action cannot silently authorize a payment.

FastAPI serves a responsive web interface. The live deployment uses Firebase Hosting, Cloud Run, Google sign-in, and private Firestore case records. SQLite supports local development. The hosted model is GPT-4.1 mini, with the API key held server-side in Secret Manager. The repository also supports Bedrock and includes an AgentCore adapter; the submitted live demo runs on Google Cloud.

Challenges we ran into

Making persistence work. A convincing first response was only the beginning. Cases needed to survive failed requests, interrupted sessions, sign-out, and deployments. We added intake checkpoints, durable storage, and worker leases so saved work could resume without competing workers acting on the same case.

Turning careful language into enforceable behavior. Testing revealed that asking a simulated institution for payment instructions could be mistaken for making a payment. We tightened the simulator and required explicit amounts and the appropriate approvals. We also preserved certified document copies for institutions that actually need them.

Catching what the model missed or repeated. Structured output still omitted some obligations. Coverage checks now repair missing inventory-backed matters. A real-model test also exposed simultaneous tool calls creating duplicate follow-ups; an atomic ledger check and a concurrency regression test addressed it.

Making the public demo welcoming. The original access-code flow and generic browser prompts were a poor first experience. We replaced them with Google sign-in, clear in-app errors, styled accessible dialogs, recovery controls, and a responsive interface that explains what the agent is doing.

Accomplishments that we're proud of

  • A deployed, model-driven workflow that goes from fictional intake through correspondence, follow-ups, human decisions, and recorded outcomes.
  • A non-trivial Strands implementation combining agents as tools, typed outputs, custom tools, and audit hooks.
  • Approval rules enforced by code, with tests for refusals, financial thresholds, and duplicate decisions.
  • Persistent private cases and complete exports of correspondence and audit history.
  • 61 passing automated tests, with CI across Python 3.10, 3.11, and 3.12, plus real-model evaluations spanning 12 simulated days and a targeted concurrency regression.
  • Verified Google sign-in, mobile layout, export, session recovery, and persistence across a hosted deployment change.

Most of all, I am proud that the product's personality and its architecture share the same aim: reduce what the family has to carry.

What we learned

An agent's useful memory belongs in a durable record. The model can reason about the next step, but the ledger must retain what was sent, what was promised, what the family decided, and what happens next.

We also learned that structured output guarantees a shape, not completeness. Validation needs to check the meaning of the result against the inventory and the workflow's rules.

Finally, autonomy includes knowing when to wait. A pending reply is not a reason to invent progress, and an unanswered decision is not consent. The important measure for Epilogue is whether the work moves forward with fewer demands on the person using it.

What's next for Epilogue

The next milestone is a supervised pilot with people who understand this work: executors, bereavement support organizations, and estate professionals. Their feedback should shape both the institutional playbooks and the language families see.

From there, I want to add verified communication adapters, document intake with extraction, jurisdiction-specific workflows, and shared review for a family member or professional. Real payments would require verified payment rails and stronger identity and authorization controls before any live use.

On the infrastructure side, the next step is to validate the existing AgentCore adapter and connect a scheduler so cases can wake on real dates. The demo currently advances time on request. The goal is for Epilogue to keep following through between visits, and surface only when someone's judgment matters.

Built With

Share this project:

Updates

Submission history