A deadline can be clear on paper and still be hard to meet.
Imagine opening a disaster-assistance letter while you are also dealing with damage, insurance, repairs, and displacement. The letter may tell you what is missing and start a 60-day appeal window. The records you need may be held by an insurer, a public office, or a contractor. Some may not exist yet.
The clock does not pause while you find them.
That was the starting point for Sixty Days. I wanted to build an agent that could carry the checklist and the deadline across several weeks. I did not want it to impersonate a lawyer, decide eligibility, contact people without permission, or submit anything on an applicant's behalf.
The letter comes before the catalogue
My first design began with a general list of documents someone might need. It was organized and looked helpful. It was also the wrong source of truth.
FEMA's appeals guidance and its tips for appealing a decision kept pointing back to the same thing: the decision letter explains the reason and the relevant supporting documents.
So the workflow now starts there.
Gemini reads a synthetic decision letter after direct identifiers have been removed. The system keeps the stated reason as a quotation, calculates the deadline from the letter date, and routes only the evidence needs supported by that letter.
If the reason cannot be mapped safely, the workflow does not guess. It asks for review.
That one change made the product feel less like a generic checklist and more like a case-specific companion.
You can walk through the live Sixty Days demo or inspect the source on GitHub.
Remembering is the autonomous part
Once the letter is understood, Sixty Days creates a durable series of future checkpoints. Early wakes make sure the evidence plan exists. Later wakes notice missing replies and unfinished items. Near the deadline, the agent assembles whatever is available without pretending the packet is complete.
The public demo uses a clearly labelled simulated clock, because waiting two real months would not make for a useful demonstration. The same deadline logic runs, but a judge can advance the synthetic case in seconds.
What I like about this design is that the autonomy is quiet. The agent does not need to perform a dramatic action. It needs to remember work that a browser session would forget and bring it back at the useful moment.
Preparing is not sending
One design choice kept coming back: should the agent contact an insurer to request a missing record?
It would make the product look more autonomous. It would also cross a line I could not justify.
Instead, Sixty Days prepares a request for the applicant to review. It explains what is being requested, leaves visible blanks where the applicant needs to add or verify information, and tracks whether a response has arrived. There is no send endpoint.
The same boundary applies to the appeal packet. The system can assemble a draft, list the missing items, and keep the deadline visible. It cannot submit the packet.
This is not a technical limitation disguised as a principle. It is a product decision. Preparing useful work is different from acting with someone else's legal and administrative authority.
A photo can show framing, not truth
Evidence photos created another tempting shortcut. A model can observe whether a room is visible, whether an image is too dark, or whether the relevant damage is in frame. That does not mean it can prove authenticity, causation, value, or acceptance by an agency.
The vocabulary in Sixty Days stays narrow. It can ask for a clearer photo or route an image to manual review. It never labels evidence as accepted by FEMA.
That boundary came directly from treating public guidance as a design input. FEMA's page on verifying ownership or occupancy lists several possible records and different date contexts. The insurance guidance distinguishes settlement information, denials, and policy evidence. Neither supports a universal document shortcut, so the interface offers examples without promising sufficiency.
The honest packet is sometimes incomplete
There is an uncomfortable moment near any deadline when polishing the output can hide the real state of the work.
Sixty Days does the opposite. If evidence is missing, the packet remains visibly partial. Each draft says it has not been submitted. Missing records stay on the checklist. The final deadline wake preserves the work already assembled and raises the remaining gap instead of quietly turning partial into complete.
That behavior became the emotional center of the project for me. The goal is not to create a reassuring PDF. It is to help an applicant see exactly what exists, what is still missing, and what they control next.
How it is put together
The application runs on Cloud Run. Firestore keeps structured cases, requirements, requests, wakes, and packet snapshots. Cloud Scheduler invokes due work. Gemini handles bounded letter transcription and observable photo review. Gemma provides a second privacy check after deterministic redaction.
Raw letters, image bytes, transcriptions, and free-form applicant narratives are deliberately not placed in the durable case record.
The source hierarchy and the decisions it changed are documented in the public research ledger. For broader context, GAO-20-503 describes the scale and complexity of the historical assistance process. Those figures provide context, not a prediction that this tool changes an applicant's outcome.
What I learned
I began by thinking the packet was the product.
The real product is continuity. It is the ability to keep the reason, deadline, requests, evidence, missing pieces, and applicant's choices connected over time.
The most helpful agent was not the one that did everything. It was the one that prepared the next safe step and made the boundary unmistakable:
Prepare, track, remind, and assemble. Never decide, contact, or submit.
I created this piece of content for the purposes of entering the All Things Agentic Hackathon.
Where would you want an assistant like this to stop and hand control back to you?
Top comments (0)