PERSONAL AGENT
Tenon
I designed and built Tenon to keep delegated plans coherent when prices change, flights slip, or a person needs to take over.
When the terms change, Tenon asks you to review them again before booking.
The hotel added a $36 fee.
$640$676, was $640, now $676
- Budget
- Within your $700 hotel budget
- Stay
- The Wren on Pine, 2 nights
- Status
- Waiting for your review
Seven intents
the model reads from what you say.
Fixed rules
work out what can actually happen.
One OK
before any booking changes.
Loading Tenon
The opportunity
Delegating is the easy part. The plan changing afterwards is where it gets hard.
Personal agents now handle real errands. The hard part comes after you hand one over: a fee posts, a flight slips, a business refuses to deal with an assistant, you step in to do one part yourself, or you pick the task up again on your phone. I designed for that part.
Independent product exploration informed by current personal-agent workflows.
The baseline is strong. Meta's Muse already ships purchase approvals, goals and activity views, editable memory and generated documents. Meta, Sept 2026
Businesses set their own boundaries. Amazon blocked Muse from shopping on its site. GeekWire, Sept 20
Useful, and a little too close. A hands-on reviewer found everyday tasks genuinely useful and the access uncomfortable. TechRadar, Sept 14
Decisions
Four decisions define how Tenon behaves.
Each one is a rule in the engine, visible in the product, with the cost I accepted for it.
Tenon acts alone only where a mistake is cheap to undo.
The brief carries three standing permissions a person can read in one glance. Tenon researches and books a table with no deposit on its own, then says so. Anything that charges a card or changes a booking comes to you. Messages to other people are drafted and left for you to send. These are the three questions the Judgment instrument used to ask with sliders (can it be undone, what does an error cost, who else is affected), now answered by what the product does.
Stripe describes the Muse checkout as a purchase the person approves, paid with a single-use card scoped to that one purchase.
Every card charge is a tap you make yourself. In exchange, nothing that costs money happens while you aren't looking.
An approval belongs to the version you saw.
Every review carries a version and a hold time. When the hotel adds a fee while you're reading, the first review is withdrawn and a new one shows the struck $640 beside $676, with the terms that did not change listed underneath. An old button, a view that hasn't refreshed, or a second device can't push the earlier version through: the engine refuses it and says what already happened. Approvals made offline wait and are checked again on reconnect.
Human-in-the-loop workflows suspend on a decision, resume only on that decision, and time out rather than wait forever.
A fee posting mid-review costs you a second look. It never costs you a charge you didn't see.
When a business won't take an assistant, the work moves to you, prepared.
Stewart Street Inn only takes bookings directly, and a hotel can refuse assistants mid-booking. Tenon doesn't work around that. It pauses on the stay, hands you the guest names, dates, quoted rate and arrival note ready to copy, and marks the item as yours in a band nobody can miss. When you hand it back, it shows exactly what you changed, records it as done by you, and rechecks the budget.
Amazon blocked Meta's Muse from shopping on its site, citing disclosure and how the agent identifies itself.
You do the provider's step yourself. The comparison, the details and the rest of the trip carry on without restarting.
A timeout is not a yes, and not a no.
If the hotel doesn't answer within 30 seconds, the stay moves to Checking, the booking button stays gone, and Tenon asks for the booking status before anything else. If the reservation exists, it's confirmed once. If it doesn't, you get a fresh review, and nothing was charged.
Payment APIs treat a retry after an unknown result as a repeat of the same request, not a new one, so it can't charge twice.
The rare slow reply takes longer to resolve. A double booking can't happen.
Handoff and return
The stay changes hands twice and nothing is lost.
Four steps from the takeover path, and who can act at each one. Try it below: book the inn, pick a king room, hand it back.
Confirmation SSI-20931.
One task, three layouts
A desk for comparing, a phone for deciding.
Desktop adds an overview across every task, grouped by what needs you. The tablet keeps the plan and the current decision side by side. The phone leads with the decision and keeps its action in reach of a thumb. All three read the same task state.
- The phone keeps the decision, what changed, what stayed the same, the terms, and one action within reach of your thumb.
- The phone drops the side-by-side comparison and the overview across tasks. The plan sits one scroll below.
- Nothing is retold. Each layout reads the same task at the same version, so a decision made on one shows as made on the other.
How it works
The model reads what you mean. The code decides what happens.
You say
We now land at 8:30 pm.
The model hears
- Intent
- New arrival
- Time
- 8:30 pm from your message
- Day
- Fri Nov 6 from the itinerary
One of seven intents. It never sees prices, bookings or permissions.
The code works it out
- Lands8:30 pm
- Transfer55 min
- Hotel arrival9:25 pm
- Earliest dinner9:40 pm
Available table9:45 pmSorrel & Salt's reply, sample data
Arithmetic and fixed rules, not the model. The 8:00 table is too early.
You decide
Dinner at Sorrel & Salt
8:00 pm 9:45 pm
Confirmed Waiting for your OK
Changing a booking waits for your OK. Table held until 4:12 pm.
- Progress saved Across tabs and a handoff link
- 41 automated checks Approvals, expiry, timeouts, takeover and cancellation
- Sample data only Nothing books, charges or messages anyone
- Try every scenario, full screen
More work