-
-
Steward. Decide together. Steward it well.
-
A way through, not a verdict. Two people asked for the same clock. Steward lays out the options and leaves the choosing to the family.
-
What Steward has learned. Every decision the executor records teaches it this family in particular. No two estates learn the same pattern.
-
Built on Gemini 3.5 and Google Cloud. Two Cloud Run services, one trust boundary — the frontend never touches Firestore directly.
-
The whole estate, as a ledger. Counts, never scores. What's settled, what needs a talk, what's still unspoken for.
-
Where things have landed. Roughly what each person has received so far — deliberately not a scoreboard.
-
It says why it's sure. One photograph in. A category, a confidence, and the reasoning — written for a person to read.
-
When it can't tell, it says so. No guessing. The item waits, marked "needs a look," until the family fills in what the photo couldn't.
-
It asks. The family answers. A plain question in the thread — no form, no dropdown. Just what somebody remembers.
-
Unknown becomes Mixing Bowl. The answer gets folded back in and the item re-read, with the reason kept on the record.
-
It writes the listing itself. Platform, price, and a description that mentions the scratches — honest about condition, never dressed up.
-
The executor makes the call. Steward offers the shapes a decision can take. A person chooses.
-
One thread for the whole family. Item questions and general conversation live in a single feed — nothing is split by scope.
-
Putting your name down. Any beneficiary can ask for something and say why. Two claims makes it contested — by design.
-
What still needs a decision. Everything waits on the family, at whatever pace suits. No urgency badges, anywhere in the product.
Inspiration
When someone dies or downsizes, the legal and financial estate process is well served — software handles wills, court forms, tax deadlines. But there's a second burden nobody addresses: deciding what happens to the physical belongings. Existing estate-settlement tools stop at the household's contents. Existing reseller tools are built for repeat power-sellers running an ongoing hustle, not a family doing this once, under grief, with people who disagree about who gets what.
There's even a name for this in the academic literature — the University of Minnesota Extension's "Who Gets Grandma's Yellow Pie Plate?" program has studied exactly this problem for years. It's real, it's common, and it's underserved.
While researching, I found a direct competitor, FairSplit, solving a version of the same problem — and a wave of general-purpose AI dispute-mediation platforms starting to name inheritance disputes as a use case. That didn't kill the idea; it sharpened it. FairSplit resolves conflict through blind-bidding and structured rounds. General AI mediators resolve what you tell them, in free-text conversation, with no memory of the estate itself. Steward's bet is different: mediate what actually happened, in a real claim ledger, and learn a specific family's pattern of decisions over time.
What it does
Steward is a multi-user agent that helps executors and beneficiaries decide together what happens to an estate's belongings.
An executor photographs an item; Gemini 3.5 classifies it — category, condition, era, confidence — and if it can't tell what something is, it says so and asks. Beneficiaries claim items they want. When two people claim the same thing, the item goes contested and the agent proactively posts a mediating suggestion — assign, rotate, or appraise — grounded in who actually claimed it and what they said, not a generic script.
The core differentiator is the adaptive loop: every time an executor's final decision differs from what Steward suggested, that's logged. The next time a similar item comes up, Steward weights its suggestion by this specific estate's own history — "this estate has donated 3 of 4 similar items" — with an honest "no pattern yet" when there's nothing to learn from. That's a real retrieval-and-adapt loop, not a one-shot classifier.
A third agent behavior notices when a family member shares a genuine memory about an item and warmly invites others to add their own — something no competitor in the space attaches to the claim/dispute flow. For items routed to sell, Steward drafts an honest marketplace listing — real condition, flaws included, no hype language.
Beyond the core arc: self-serve estate creation and multi-estate support, real invite emails, an executor review table for fast bulk decisions, a "what Steward has learned" panel and an equalization view showing whether everyone received roughly equal value, real-time notifications, and a full WCAG AA accessibility pass.
How we built it
Gemini 3.5 via Vertex AI for classification, mediation, and marketplace copy. Google ADK orchestrates the two backend-triggered agent behaviors as real tools on an LlmAgent — dispatch happens on a detected state transition rather than a model's own judgment call, a deliberate choice: the family's message content shouldn't be at the mercy of a sampling temperature. Two Cloud Run services (frontend, backend) with Firestore for state, Cloud Storage for photos, Firebase Auth for accounts, and a Veo-generated ambient hero animation on the sign-in screen.
Third-party/pre-existing code: standard open-source dependencies only (React, FastAPI, Google ADK, Firebase SDKs — see requirements.txt/package.json in the repo). One CC BY 2.0-licensed photograph used during design exploration, credited in CREDITS.md. No other pre-existing or third-party code.
Challenges we ran into
The sharpest lesson came from testing production, not just the emulator. Deploying real Firestore Security Rules surfaced a genuine vulnerability: a beneficiary could bypass the UI entirely and write a forged "resolved" status straight into Firestore, settling a contested item against everyone else's wishes. It only existed because the rule checked membership but not role — found, confirmed live, fixed, and covered by new regression tests before it ever reached a demo.
A separate UAT pass found something more basic and more important: the contested-claim flow — the literal center of the product — was unreachable from the frontend. A status list was one value short, so two real people could never trigger a contest through the app itself; every contested item all week had come from test scripts. Fixed, and verified again with two real accounts.
Accomplishments that we're proud of
Finding both of those bugs before a judge could. Building an adaptive-learning loop that's genuinely earned from real decisions, not seeded to look impressive. And a marketplace copy generator that, when asked to describe a chipped, worn item, describes the chip and the wear — because an agent that's honest about flaws is more trustworthy than one that oversells, especially when it's helping a family decide what to do with what's left behind.
What we learned
That competitive research needs to search what a product actually does, in plain language — not just the categories its own problem statement assumes. That a passing test suite proves the paths you tested, not the paths that exist. And that production is the only place that tells the truth.
What's next
An executor-facing bulk listing center, a toggleable high-contrast mode, and continuing to build out the shared-memories behavior — the feature we're most confident nobody else in this space has built yet.
Log in or sign up for Devpost to join the conversation.