Alice
Objective: replace a spreadsheet that held data but not decisions with a system that prioritizes a high-volume relationship problem for me.
A spreadsheet holds data. It doesn't hold decisions. I replaced mine with a system that prioritizes for me instead of asking me to re-derive priority from a wall of rows.
Built for the relationship load of an active executive search: a phone-editable tool backed by a real database, with a scoring engine underneath instead of a sort order.
What the spreadsheet couldn't do
A nightly sweep, then five minutes on the phone
Every night it pulls new Gmail activity, calendar matches, and new Granola meeting summaries, then rescoring runs against the full list. What's left for me is a short review: open the phone, see who moved, act on what matters.
A phone-first review, and one record underneath
Two views of the same system: the nightly review list, ranked and ready, and one contact record showing what the system actually holds. Names and identifying details are redacted for this page.
Five tools, one system
Nothing here is a platform I bought. Each piece does one job well, and the system is the way they're wired together.
Five weighted dimensions, one priority score
Each contact is scored on real signal in the record, not self-reported. The weighted result classifies every contact into one of six states, and a second layer ranks it against the full population. Every number recalculates from current state, so a stale score can't quietly persist after the facts change. Click a row for what it measures.
This is the same layered scoring architecture behind a separate venture I'm building, applied to my own problem as a live test of whether it holds outside its original domain. It did, with no structural change, only a change in what the inputs represent.
Scoring is a decision. The drafted email is a convenience.
It would be easy to let the two blur together. They aren't the same kind of AI, and they don't deserve the same trust.
Deterministic
Five weighted dimensions, computed the same way every time, auditable back to the signal that produced the number. Nothing about it is generated. It's a formula, not a guess, and it doesn't change its mind between runs.
Generative
A starting point, written in my voice from the real thread. Useful, and it saves real time. But it's a suggestion I read, edit, and approve before anything sends, not a decision the system is trusted to make on its own.
The standard company-brain toolkit, refused on three different grounds
Vector embeddings, a knowledge graph, an agent-memory framework: the usual answer to "how do you build a company brain." None are in Alice. Each was refused for its own reason, not dismissed as a group.
Audited against Slite's four-pillar company-brain model. The sharper finding underneath: the sweep was a detector wired to a human, not to the store. It couldn't read what was already recorded, so it re-reported things I'd already logged. It couldn't write, so every finding cost a manual re-entry. That diagnosis, not a feature wish, produced the review-queue design.
I ran the same four-pillar test against an outside package, a CFO chief-of-staff skill built by a vendor, specifically to check whether I was rationalizing. Its ledger was four flat markdown files with no versioning, a downgrade from what Alice already had. Its stated principle, broad read access, narrow write authority, human approval before anything consequential, was already what the review queue enforces. One piece was genuinely better: an explicit ranking rule, attention value as consequence times urgency times decision leverage times confidence, with four escalation bands separating what interrupts now from what waits. Adopted the same day, minus the confidence term, which the schema couldn't support honestly.
Their own demo was worth noting too. It configures a scheduled job to skip all approvals while granting it write and delete access to the user's email. That's the exact failure mode the review queue exists to prevent, shipped as the recommended setup in the material teaching people how to build one.
What makes a brain durable, not just built
Three findings a working group of company-brain builders converged on independently. Each one is a constraint Alice was already built around, not a feature added after reading them.
Four hosting attempts, three dead ends
Each failure produced a specific, falsifiable finding rather than a shrug: does the code run, is the data correct, is the header wrong at the origin or a cache layer. That discipline is what made it possible to recognize the third failure as a deliberate platform decision, not a bug worth fighting, and change approach instead of trying a fourth variation on the same one.
Three real architectural dead ends in one day, each abandoned cleanly once the evidence was conclusive, rather than sunk-cost escalation into a fourth attempt at the same broken approach.
A mistake I caught, and a list put back in order
A schema change moved one table to a more flexible shape. Every server-side function that touched the old structure was checked and updated. The code that loads that table into the browser was not, and every record rendered as undefined on the next real load. I caught it from a screenshot, not from my own review.
The fix took minutes. The useful part was the test: the existing one would have passed with the bug in place, because it fed one function's output straight into the other and skipped the step where the database wraps a record before returning it. Rewritten to simulate that step, so the same class of mistake gets caught automatically going forward.
Less time managing the list, more time on the calls that matter
Check against ground truth before you write, not against the last thing you remember being true.