Designing Elysia — a personal AI assistant you talk to

What it is

Elysia is a personal assistant with her own phone number. You can type to her in the app or ring her up, and it’s the same conversation either way. She remembers what you’ve told her, and she can call people for you.

The problem worth solving

An assistant that can dial a phone is one bad decision away from calling the wrong person.

So the first design question had nothing to do with features. It was this: how does she reach people in the real world without ever choosing who gets contacted?

The rule everything hangs off

She decides how and when to reach you. She never decides who to contact.

She can try your second number before ringing your partner. She can’t ring someone you never named. Every other decision in the product sits on top of that one.

How it works

Memory you can actually use

A saved password comes back as a card you copy, not a paragraph you read. Private items are masked on screen, and she won’t say them out loud on a call. The same fact behaves differently depending on which surface could leak it.

Her own number

People ring Elysia directly. She isn’t a second line forwarding to me. When she calls out, she introduces herself by name and says who she’s calling for.

One instruction, a whole sequence

Wake me at 8:45. If I don’t answer, try my other number, then ask Jay.

That’s one instruction. She works down the list and stops the moment something works.

A rule written before the feature

Everything she handled up to this point came from me, or from someone talking to her live. Email is different — anyone can write to it, and it’s aimed at a language model rather than a person.

So the rule went in before the inbox did. Mail can produce a message for me to read. It can’t make her do anything.

What testing changed

The risky parts — who gets called, what gets said, what gets remembered — were tested on real calls to real people who had agreed to it. That surfaced things no amount of internal testing would have.

She read her notes out loud

On a difficult call she recited two paragraphs of her own reasoning to the person she was calling, referred to me in the third person, then quoted the instruction she was following back at them.

A better prompt wouldn’t have fixed that. Deliberation belongs behind the seam; what comes out the other side should be the decision.

A status check that was always red

A pre-flight check flagged a problem on every load, whether or not one existed. Nobody reads a light that’s always on. It now tests the capability by performing it.

A rename that didn’t finish

Renaming the assistant updated most of the app but missed the chat header, the composer placeholder and the avatar initial. A design audit caught it, not a bug report. It’s the one setting about who she is to you, and it was quietly breaking its own promise.

An assumption that expired

The call-in-progress indicator assumed only one call could ever be active. That was true when it was built. A second calling feature shipped later and made two at once normal.

Where it stands

Live, and in daily use. Tested against a real number, real people, and consent that was actually asked for.

Next is an inbox and a calendar of her own, behind the same rule that has held for every channel so far: a stranger’s words can reach her, but they can’t act through her.

---

There’s a companion case study on how the build was run — same project, from the process side.