Bander

The OpenClaw I'd actually give my parents.

Comment

Inspiration

I have been running OpenClaw for a while, and I love it. Somewhere in the middle of that, I kept thinking about my mom. She is exactly the person who would benefit from an assistant like this. She juggles appointments and emails from doctors' offices, and she would rather ask a question in one chat than open five apps.

She has told me more than once that she never knows what message these AI tools are going to send. She wishes they would simply show her what they are going to do before doing it. That sentence stuck with me. It is basically the whole product.

The creator of OpenClaw has written that the real goal is an agent even his mum could use, and that getting there requires much more thought about safety. My mom was asking for the same thing in her own words. Build Week felt like the right week to attempt the safety part.

I could not actually give her my setup. I was not comfortable letting the same process hold access to her real accounts, make a change, and then tell her whether it worked.

Build Week therefore became one question. What would an assistant have to look like for me to genuinely hand it to my parents?

What it does

Maya talks naturally with a real OpenClaw assistant in Telegram. It can answer bounded questions about her calendar and inbox without making her approve harmless reads.

OpenClaw never receives her Google Calendar, Gmail, or family messaging credentials. Those live in a separate process called Bander, which also has its own visible Telegram identity.

When something real should happen, such as moving an appointment, replying to the doctor's office, or notifying a family member, Bander shows one Card containing exactly what will happen. That includes the Calendar change, email recipient and reply, or sentence the family member will receive.

Nothing happens until Maya taps yes.

Approval is not a blank check. Bander pins the deal to the state Maya saw. If the Calendar event or email thread changes before execution, Bander refuses rather than acting on stale information. If a provider's response is lost and the outcome cannot be confirmed, Bander says exactly that. It performs no blind retry and never turns uncertainty into a false success.

OpenClaw already has useful approvals, and I did not want to pretend otherwise. The difference is where the keys live. With Bander, the assistant can ask for something, but it cannot hold the Google credentials, rewrite the approved action, or speak as the system that carried it out. The family destination and the text sent to it also belong to Bander, not the model.

The Sol variant of GPT 5.6 solved the language problem. It understood requests such as moving a dentist appointment and letting a son know as one bounded request. Bander still owned every identity, parameter, credential, and decision about whether anything could happen.

How I built it

Codex was my implementation and verification partner throughout Build Week. We worked in a loop I became slightly obsessed with. Write the test for a safety property, observe it fail, implement the smallest correct behavior, and then deliberately break the guard to prove the test could catch the real defect.

That process is recorded in BUILD_WITH_CODEX.md. It includes the failures, live discoveries, deliberate mutations, and the evidence after each fix.

Codex helped me move much faster across the broker, integrations, tests, setup flow, sandbox, and documentation. I still made the calls that shaped the product. Reads would remain easy. Real consequences would require an exact deal. Credentials and outcomes would stay outside the assistant. If an API could not support honest recovery, I would not build that feature.

The stack combines OpenClaw and GPT 5.6 Sol for conversation and bounded tool selection with a TypeScript broker holding separate Google Calendar, Gmail, and Telegram credentials behind five bounded MCP tools.

The hosted browser experience runs the same authority engine against clearly disclosed seeded data. Judges can experience its approval, refusal, replay, and uncertainty behavior without creating accounts.

The complete source, setup guide, evaluator paths, and evidence are in the public repository.

Challenges I ran into

My assumptions kept being wrong, and the test first loop kept catching them.

I originally designed Gmail recovery around caller supplied message identifiers. The first live test showed that Gmail rewrites them. The recovery design was dead on arrival.

We rebuilt it around an opaque Bander header bound into the approved email. Recovery now performs one bounded search of Sent mail. It either finds an exact match or reports the result as unconfirmed.

The first live compound approval also exposed a state lock deadlock after the user approved a Calendar change and family update. The design looked sound in isolation. The continuous real path proved otherwise. We fixed it and added a permanent regression test.

Another review caught Bander about to report that nothing changed in a case where Google might actually have committed the operation. That one scared me. The entire product is supposed to tell the truth about what happened, and it nearly shipped with a lie.

We changed the outcome model so an unconfirmed result stays unconfirmed, including on replay. Bander now tells the parent to check instead of turning missing evidence into a confident answer.

Accomplishments that I am proud of

The Google, Gmail, and Telegram behavior shown in the film is real. The Calendar changes against a dedicated Google account. Gmail places the approved reply in Sent. A second phone shows the exact family update Maya approved.

The changed world refusal also runs against real Calendar state. Bander moves nothing and sends no family message.

The published product matrix contains 535 functional cases plus 26 adversarial cases. The evidence ledger records the critical properties we observed failing before their fixes. It also records deliberate mutations that prove the corresponding regression tests can fail.

There is also a hosted browser experience that runs the shared authority engine against explicitly seeded data. It lets a judge experience all 27 deterministic outcomes, including decline, replay, changed world refusal, and truthful uncertainty, without trusting Bander with an account.

What I learned

The thing I did not expect is that truthfulness decides which features you are allowed to build.

Calendar and Gmail made the cut because their APIs let Bander pin identity and inspect what actually happened. Restaurant reservations, smart home control, calling the clinic, and several other ideas did not.

I wanted all of them, but I cut them because I could not make their recovery stories honest.

Saying no to features became part of the design.

I also learned that writing for my mom is harder than writing code. A technical precondition failure became a plain sentence explaining that her Calendar had changed since she asked, so Bander moved nothing and sent nothing.

That rewrite required as much care as the logic underneath it.

What is next for Bander

Today Bander is a product that a technical family member sets up once for someone they love. Setup takes about 45 minutes, is reversible, and runs through an isolated OpenClaw profile without modifying an existing installation.

Next is reducing that setup friction without weakening the boundary. That means guided onboarding, hosted setup, durable authority for actions already in progress, and additional domains only when their APIs permit honest recovery.

Next I want to put Bander in front of a parent, stay quiet, and watch where they hesitate. If they misunderstand who can act, what approval means, or what the family member sees, I will treat that as a problem with Bander rather than a problem with the person using it.

Built With

Share this project:

Updates