StareBrain

Building StareBrain — say a command, see exactly what it's about to do, confirm before it fires.

A thread today gave me the sentence I've been missing for a state I already believed in but hadn't written down cleanly: for actions where the only evidence of success comes from the system I'm trying to verify, the honest final record isn't "success" or "failure." It's authorized, dispatched, outcome not independently knowable.

That state can't just be a status displayed and forgotten. It needs an owner — someone or something whose job it is to look at it. An expiry — a point past which it either resolves or explicitly escalates. And a compensation path — what actually happens when it doesn't resolve, which I haven't designed yet. Resend and risk a duplicate action? Surface it and let the user decide? Different answers for different actions, probably, not one universal rule.

Without those three things, an honest "unresolved" quietly becomes the same silent-success problem I built the state to avoid in the first place.

Building in public as I go — waitlist link in profile.

Building StareBrain — say a command, see exactly what it's about to do, confirm before it fires.

Read something today that isn't about my app at all, but hit the same nerve. A well-sourced post on llms.txt: 97% of published files never get fetched by anything, and most of the small fraction that do get hit are coding tools, not the search assistants people built the file for in the first place.

The part worth borrowing isn't the headline number — it's the layer underneath it. Even a successful fetch doesn't tell you the content did anything. That's the exact shape of the problem I keep finding in StareBrain's own execution pipeline: a request going out isn't evidence that anything downstream happened because of it. "Sent" and "seen" are different claims, and it's easy to quietly let the first one stand in for the second.

Building the confirm→execute→verify chain to actually catch that gap instead of assuming past it.

Building in public as I go — waitlist link in profile.

Building StareBrain — say a command in plain English, see exactly what it's about to do, confirm before it executes, then it happens on your phone.

Today's build-log entry came from someone else's product, not mine. Reading through how another founder added MCP support so their SaaS could be driven from a ChatGPT or Claude chat window, one line stuck: their consent screen tells the user plainly that the connected assistant can only do what the user themselves is allowed to do. Not what it's about to do in this one request — what it's capable of, full stop.

That's a distinction StareBrain's confirmation screen doesn't currently make. Right now, every screen is built around a single action: "send this text," "book this slot," shown, explained, confirmed. What it's never shown is the ceiling those actions sit under — what the app is actually authorized to touch in general. A user confirming one text message has no way to see, in that moment, everything else that authority quietly covers.

So the next addition isn't a new action type, it's a new screen: a persistent "here's everything this app can currently do" view, shown before the first action confirmation ever happens, not buried three taps deep in settings. Confirming an action and understanding your authority are two different questions. StareBrain has only been asking one of them.

Building in public as I go. Join the waitlist today!

Building an app that confirms before it executes taught me a harder problem hiding underneath: proving what happened after it executes.

Say StareBrain sends a text on your behalf. It shows you the plan, you confirm, it fires. Good. But the only evidence that it actually reached anyone comes from the same provider whose job is to send it — which means "confirmed" and "self-reported" can look identical from the outside.

Today's build-log insight: don't let an app grade its own homework. Separate producing evidence from judging it. StareBrain's job should be to expose exactly what it knows and doesn't — not to quietly promise more certainty than it has.

Still pre-launch, still figuring this out in public, one honest gap at a time.

Waitlist: starebrain.vercel.app/waitlist

Building StareBrain — natural language commands for Android, confirm before anything executes. Been building toward a three-proof model for confirmed execution: plan integrity, execution-time validity, post-dispatch evidence. Today someone asked a question that broke the third one cleanly.

The question: if the only evidence that something executed comes from the same system you're trying to verify, is that actually evidence, or just the system's own claim about itself?

My planned post-dispatch check was going to be an SMS provider's delivery webhook, a calendar API's confirmation response. Then it hit me: that's not independent evidence. That's the system I'm verifying, reporting on itself. I don't have a second phone confirming a text arrived, or a separate account reading the calendar from outside. For a solo build, true independent verification of a third-party API might not be achievable at all — only degrees of how much I trust a given provider's own word.

Which means DENIED_UNRESOLVED might not be a temporary state I eventually close for a lot of actions. It might be honestly permanent — not because the verification isn't built yet, but because independent evidence genuinely isn't available at this resource level.

The provider's webhook is still evidence. It's just weaker evidence than true independence, and I think the actual discipline is labeling that difference explicitly instead of letting a provider's self-report quietly earn the same trust an independent check would.

Three weeks into this model and I keep finding the next layer down instead of the bottom.

Building in public as I go — waitlist link in profile if you're working on agent verification too.

Building StareBrain — natural language commands for Android, confirm before anything executes. Posted yesterday about re-verifying authority right before execution — a token bound to exact parameters, checked at the last possible moment. Felt like a real fix. Today it got split into pieces, and only one of those pieces was actually solved.

Turns out there are three separate proofs hiding inside "did this happen correctly," not one:

Plan integrity — did what executed match exactly what was confirmed? My hash-matching fix from yesterday solves this, and only this.
Execution-time validity — were the facts that made the plan valid still true at the moment it fired? A calendar slot can vanish, a contact's info can change, in the gap between confirmation and dispatch — even if the confirmed plan itself is byte-identical. My fix says nothing about this.
Post-dispatch evidence — once something leaves the system for a provider I don't control (an SMS gateway, a calendar API), what do I actually have proof of? Requested, accepted, externally confirmed are three different claims, and conflating them is where DENIED_UNRESOLVED lives.

I'd been treating this as one gap with one fix. It's three gaps, and a clever hash check only ever covered the first. The other two need their own separate mechanisms — re-checking live facts immediately before dispatch, and treating anything past the system's own boundary as unresolved until a receipt says otherwise.

Slightly deflating to find out yesterday's fix was 33% of the actual answer and felt like 100% until someone split it apart. Better to find that out from a comment than from a bug report.

Building in public as I go — waitlist link in profile if you're working on agent safety/authorization too.

Building StareBrain — natural language commands for Android, confirm before anything executes. Here's a scenario most agent builders haven't tested: your agent gets permission to do something. Four minutes later, that permission is revoked — a token expires, a setting changes, someone says no. But the agent already has the technical capability queued up. At minute five, it executes anyway. At minute six, some downstream system records it as done.

The agent had permission. Was it still authorized at the moment it actually mattered? Those are different questions, and almost nobody's system can tell them apart.

Worse: if you try to stop the action after authority changes, and the request already left for an external provider, flipping your own app's state to "blocked" doesn't prove anything happened — or didn't. You're guessing, wearing the costume of a system that checked.

Spent this week in a thread with people independently landing on the same fix from completely different systems — WordPress admin tools, AI ops platforms, and now StareBrain. The fix: never let permission be a thing you check once and trust forever. Every action gets a short-lived, parameter-bound token — re-verified the instant before it fires, not five minutes earlier when it was requested. And once something leaves the system's boundary, "blocked" isn't a real status anymore. Only "confirmed clean" or "unresolved" are honest.

That's the actual engineering behind "say it, it happens" — nothing executes on stale authority, ever. Confirmed before it runs, or it doesn't run.

Building in public as I go — waitlist link in profile if the 9:00-to-9:06 problem is one you've hit too.

Building StareBrain — say a command in plain English, see exactly what it's about to do, confirm before anything runs. Been circling this for three weeks. Deep in confirmation-model design, provenance tags, verified non-execution states — genuinely useful thinking, and also, I realized this week, a very comfortable place to hide from the one thing that actually mattered: putting the product in front of a single real person.

Got asked directly what the smallest possible ask looks like, one that isn't a screen share, isn't me narrating, isn't me in the room at all. Landed on this: send a friend the APK, one line — "trying this out, can you type one thing you'd actually want your phone to do and see what happens? No need to explain anything back unless something's confusing."

No walkthrough. No context-setting call. No "let me show you first." If they need me to explain it before trying, that's data too — it means the first-run experience isn't carrying its own weight yet.

Sent it today. First time in three weeks this was true instead of hypothetical. Whatever happens next is the first real data point I've had.

Building in public as I go — waitlist link in profile if you want to follow along.