BasketBrief — Follow through when the report changes

An agent for relief coordinators: chase missing evidence, reconcile corrections, and keep every donor on the approved version.

Comment

BasketBrief — follow through when the report changes

An agent for relief coordinators: chase missing evidence, reconcile corrections, and keep every donor on the approved version.

Try the live story · Watch the film · Source code · Good Neighbor Agents

Inspiration

A small relief team's work does not end when supplies arrive. Its coordinator still has to find receipts, reconcile volunteers' updates, and explain the same figures to different donors. A late correction starts that work again.

BasketBrief tackles that follow-up. Our demonstration follows a fictional coordinator, Amal, and two contributors: Rana has the receipts; Sami has the delivery counts. Two donors need reports. A missing transport receipt is the first gap. Then, after the reports are approved and delivered, Sami corrects the delivery count from 92 kits to 88.

That second moment is the heart of BasketBrief: a correction must reach everyone who received the original, with its evidence and approval history intact.

Who benefits, and what changes for them

Our first intended users are small volunteer relief teams where one coordinator collects spending evidence from a finance volunteer, delivery counts from field volunteers, and prepares updates for several donors. The critical moment is a correction arriving after a report has already been shared.

  • The coordinator gets a named owner for each missing item, its source, and a visible decision to review. The agent follows up; the coordinator retains approval.
  • Contributors answer the question tied to their evidence. In the demonstrated workflow, one receipt reply supports both donor reports.
  • Donors receive the same approved facts in English and Arabic, with the prior version and exact changes preserved. A new draft cannot silently rewrite what they previously received.

The demonstrated benefit is consistency and traceability: USD 60 remains reported but unsupported until its receipt arrives; a change from 92 to 88 delivered triggers reconciliation; kit counts never become an unsupported claim about families helped. In a further public test, changing 88 to 87 triggered another question while both donors retained their earlier approved reports.

We expect this to reduce repeated chasing and inconsistent updates, but have not measured that effect with an organization. Our prepared pilot compares normal tools with BasketBrief on equivalent reporting tasks, counting human review time, unsupported figures and missed correction recipients. A benefit would require fewer errors or less total human effort without weakening review.

What it does

BasketBrief reads incoming evidence, asks the responsible contributor to resolve a gap, and prepares reports for human approval. It delivers the approved version to separate English and Arabic donor inboxes inside the application.

Watch the complete loop in the live demonstration:

  1. Ask the person who knows. The agent finds USD 60 without a receipt and asks Rana. Her answer serves both donor reports.
  2. Keep the source visible. Rana uploads a receipt image. The reader classifies it, transcribes it, compares the transcription with the image, and checks the arithmetic. Amal can inspect the original.
  3. Review before sharing. Amal approves one exact version. Each donor receives a saved snapshot.
  4. Follow a late correction. Sami changes 92 delivered to 88. The old approval cannot authorize the changed report. Four kits now need an explanation, so BasketBrief asks Sami to check the records.
  5. Close the gap without inventing impact. Sami confirms 12 returned. Amal reviews both changes and approves an amendment. Donors keep the original alongside the new version. Unique households remain unknown.

The guided story supplies fictional replies and approvals; Strands inference, tools, evidence storage and donor inbox delivery execute live. Visitors can also perform the steps themselves.

Work with separate accounts

The team workspace supports individual accounts, project invitations, contributor uploads, reviewer access and donor-only approved reports. Persistent in-app notifications tell the responsible person when evidence or a question arrives.

A receipt requested for an existing expense completes that expense without a second charge. Multiple expenses retain their original currencies; a combined reporting total requires reviewed exchange rates with dates and sources. Selected PNG/JPEG files, PDFs and saved-email attachments can be imported. PDF originals remain available; multi-page documents require full human review.

How we built it

Strands Agents SDK and Amazon Bedrock Nova Pro interpret evidence and choose tools for the next follow-up. The guided story uses seven scoped tools; the team workspace uses a separate project-scoped three-tool agent. Neither agent can approve a report.

Amazon Bedrock AgentCore Runtime hosts the image reader. A recorded in-process Bedrock fallback keeps the same reader available if Runtime fails. AgentCore Memory provides advisory vendor history for the fictional demo team; it is not evidence that a vendor is trustworthy or fraudulent.

Deterministic code owns arithmetic, permissions, saved facts, follow-up persistence, versioning and delivery. Each approval binds to a report revision and content hash. Reports use templates over stored facts rather than model-written financial claims.

Architecture · Verification and limits

What we verified

  • 125 automated tests passed, including 30 adversarial boundary cases. These test code boundaries; they are not a live-model attack benchmark.
  • A separate live Strands/Bedrock probe exercised five fixed synthetic challenges twice. The final build passed 10/10 after two defects were found and fixed: choosing an ambiguous count and omitting a valid unsupported claim. All batches, including failures, are published in the evaluation; this is not a broad security benchmark.
  • Live guided runs exercised receipt follow-up, first approval, a late correction, refusal of stale approval and delivery of both amendments.
  • A separate-account browser test exercised contributor upload → reviewer notification → agent follow-up → coordinator approval → donor access. Donors saw no report before approval.
  • An owner-authorized Gmail app-password test imported one selected PDF, retained its original, and blocked duplicate import and access from another account. The test connection was removed afterward; no private mail is published.
  • A private document review exposed incorrect assumptions about statements and utility tables. The reader now rejects statements and transfers as purchase evidence. Unconfirmed readings remain for review.

Challenges and lessons

A number appearing in a document is not enough: its meaning matters. A debit, a meter reading and a purchase total are different facts. We classify before extracting and require source review when the evidence is unclear.

Corrections exposed another boundary: the system must preserve supported information while asking about what remains unresolved. It must also retire approval of an earlier revision. Those behaviors are enforced in code, with regression tests and visible report history.

Current scope and next steps

All demonstration participants and evidence are fictional. We have not run an organization pilot or measured human time saved. Our evidence establishes working software behavior, not independently verified payments or aid outcomes.

OCR can still fail, including on Arabic documents. Gmail app-password import was tested; Google/Microsoft OAuth activation and external SMTP notification delivery are not live-verified. Team notifications and donor delivery currently work inside BasketBrief. Bank statements are outside its purchase-receipt scope.

The next validation is a supervised trial with a relief coordinator, measuring task completion, corrections caught and time spent reviewing. Provider OAuth activation and an independent security review follow before broader use.

Built during this hackathon with AI coding assistance. Persistence/channel patterns were reused from an abandoned entry in the same competition; the domain-specific evidence, reconciliation, vision and approval workflows were implemented here. Public source: MIT license.

Build notes on AWS Builder Center

Three articles trace the implementation and lessons from earlier revisions. Current behavior and verification limits are recorded in the repository's evaluation notes.

Built With

Share this project:

Updates

Submission history