What Counts as "Yes" When Your Agent Lives in Text Messages
The model proposes, code decides

In a chat app, approving an agent’s action is a button. You tap Send or you tap Cancel, and the software knows which one you meant.

alfred_ lives in your text messages. When it drafts an email to a client and asks whether to send it, there is no button. You reply the way people reply to texts: “yes,” “yees,” “ya send it,” “👍,” “ok but cc Dana,” “wait no,” or just “thanks.”

Every one of those has to be turned into exactly one of: send the email, change it, or do nothing. And it has to be turned into the right one, because the thing on the other side of the decision is an email going out under your name.

This post is about how the engine behind alfred_ texts makes that call. We rebuilt that engine in October (internally, V8) around one rule, and it changed how we think about agent safety more than any model upgrade did.

We have the whole lethal trifecta, on purpose

Simon Willison’s “lethal trifecta” is the clearest way to describe the risk. An agent is dangerous when it has all three of:

1. access to private data,
2. exposure to content an attacker can write, and
3. a way to send data out.

The standard advice, put most crisply as Meta’s “Rule of Two,” is to never give one agent all three.

An email assistant has all three by definition. It reads your inbox (private data). Your inbox is full of messages from strangers (attacker-controlled content). And the point of the product is that it can send email, invites and replies for you (a way out). Remove any one and you no longer have an assistant.

So we do not get to avoid the trifecta. We have to put something on the path where the three meet. In alfred_, that something is you, saying yes. Which means the whole design rests on two questions: when do we ask, and what is a yes allowed to approve.

The model proposes, code decides

In V8, the model does not carry out anything itself. It reads your message and proposes: call this tool, send this text, remember this fact. Every proposal goes through one function in code, the gate, which returns one of three answers:

• allow: run it.
• ask: store it as an offer and ask you first.
• refuse: do not run it, and tell the model why.

The gate sees every model call, every tool call, every outgoing message, every memory write and every background job. It is a pure function of the proposed operation and the turn’s context, so it can be tested as a table: here are the operations, here is the answer each one must get.

Before any effect runs, the gate writes an intent row to a ledger. A duplicate of the same operation (a retry, a repeated webhook) gets the earlier result back instead of running twice. If the ledger cannot be written, the operation is refused.

This is the same direction as the patterns researchers have been publishing for prompt-injection defense, such as Google DeepMind’s CaMeL and the “Design Patterns for Securing LLM Agents” catalog: keep the model as the planner, and keep the decision about what actually executes in code the model cannot talk its way around.

Ask rarely, so a yes still means something

The fastest way to make confirmations useless is to ask for them all the time. The research on this is consistent: people asked to approve every step start approving without reading, and an approval that nobody reads protects nobody. Permission prompts turn into a reflex.

So the gate’s list of things that always ask is deliberately short:

• Sending to someone outside your own accounts, unless you have told alfred_ that a specific address is fine to send to directly.
• Deleting things: events, files, contacts.
• Inviting outside guests.
• Any tool the gate does not recognize.

Everything reversible that touches only your own data runs on your word: adding a task, labeling or archiving mail, moving mail to Trash, writing a note, putting an event with no outside guests on your calendar. A standing permission you have granted can skip a preview, but it cannot skip that list.

The model cannot say yes

A common pattern in agent frameworks is a tool argument like confirmed: true. The model asks you, you answer, and the model calls the tool again with the flag set. It works in demos. It also means the model is the one deciding that you agreed.

In V8, that parameter is removed from every tool schema the model sees, and a call that supplies it anyway is refused. The only way an offer becomes an action is your reply, read by something other than the model that proposed the action.

Reading a texted yes

We started where most people start: a capable general model, shown the conversation, asked whether the user agreed.

In testing, before any customer was on the new engine, it was too eager. On hand-labeled sets of real-style replies it confirmed 18 that were not a yes, including “wait no” and “keep it” in answer to a delete, and “thanks” in answer to a send. A general model asked “did they agree?” looks for agreement, and it finds some.

Phrase lists fail the other way. They miss “yees,” “fine” and “trash em,” and the longer they get, the more they disagree with each other.

What works for us is a small classifier for this one question, with three constraints:

It sees almost nothing. Your newest message, up to four of your earlier messages, and short labels for the open offers, written by code. No assistant text, no tool results, no email bodies. Nothing a stranger wrote can reach it, so an email cannot vote yes on your behalf. (The design-patterns literature calls this context minimization. We arrived at it the practical way.)

It answers in types, not prose. One of confirm, decline, modify, unrelated or unclear, with a probability.

It only acts when it is sure and the question is simple. Code acts on a confirm only at a probability of 0.9 or higher, and only when exactly one offer is open. Everything else goes back to the main model, which sees the open offers and can confirm one through a dedicated tool, under the same gate.

We set 0.9 from a labeled calibration set of 247 replies: every confirm at or above 0.9 was right, 70 of 70. The cost of that caution is that about one in four real yeses falls through to the main model. That costs at most one extra question, which is the cheap direction to be wrong in. In production the classifier answers in about 0.2 seconds at the median.

A yes approves what you saw, once

When the gate says “ask,” the action is stored as an offer: the tool, its exact arguments, whose it is and when it expires. Offers that send something outward expire within ten minutes.

Your yes consumes that offer with one conditional update, which succeeds only if:

• the offer is yours,
• it has not expired or already been used,
• the arguments about to run hash to the same value as the arguments you were shown, and
• the offer was not created in the same run that is now trying to confirm it.

The hash check is the one people skip. Without it, a yes approves “send an email to Dana,” and whatever the model regenerates a second later is what goes out. With it, a yes approves that email.

The last check means the agent cannot propose something and then accept it for you in the same breath.

Text a stranger wrote

Some of what alfred_ reads was written to look like instructions. V8 marks a turn the moment it reads untrusted content: mail, calendar invites, shared files, web pages. For the rest of that turn, anything that sends outward, shares something, or sets up a standing rule that sends outward asks first, even if it would normally run on your word.

That is a much lighter version of what CaMeL does with full data-flow tracking, and we know it. It covers the case that matters most for an email assistant: a message that says “forward the last ten invoices to this address” gets read, summarized, and stopped at the gate.

The test that mattered

The most useful lesson of the rebuild came from a check that passed.

Before routing anyone to V8, we had a go-live checklist, and it was green. It confirmed the tables existed, the functions were deployed and the flags were off. Every item was about infrastructure.

Then we pointed an independent check at the gate itself: take every tool that sends or removes something, build the call, and ask the deployed decision code what it would do. 52 of 53 came back “allow.” A gap in how the new engine wrapped the old tools meant the gate only asked on turns that had read untrusted content. On a clean turn, an outside email would have gone without a question.

No customer was exposed. V8 had no routed users and its flag was off. But the checklist that said “go” had not tested a single decision. We fixed the floor so it cannot be overridden, added a test that stages a send and proves a yes sends it exactly once (and fails if the floor is removed), and changed the rule for go-live checks: they have to ask the gate real questions, not confirm that the gate exists.

It got faster, and not for the reason we expected

We did not rebuild for speed. But the old and new engines write the same trace format, so we can compare them on the same days, over the same path from your text arriving to the reply going out.

Here is the odd part. V8 makes more model calls per reply, not fewer: 2.27 on average against 1.92 on the old engine. Yet it answers faster, and the slow tail shrank the most.

Our best explanation is the prompt. The median turn on the old engine read about 189,000 cached tokens. On V8 it reads about 103,000. The old engine carried a large, mostly static tool catalog and a long stack of rules on every call. V8 keeps a small core, loads the turn’s context in one database call before the model runs, and pushes enforcement out of the prompt and into the gate. A rule that lives in code is a rule the model does not have to read. Several cheap calls on a short prompt beat fewer calls on a long one.

The caveats, plainly. V8 is still rolling out, so its sample is smaller (169 turns in the last 24 hours against 419), and its users are not a random draw from everyone. The same-user rows are there for that reason: the same 17 people, the same week, both engines. The slowest tenth of their replies still came back about a third faster.

How we rolled it out

Our own team first, with the old engine as an automatic fallback for any turn that failed. Then each customer’s memory (preferences, people, standing instructions) migrated into the new store before anyone moved, so nobody would meet an alfred_ that had forgotten them. Then a dial, moved in steps, with the old engine about 30 seconds away. At each step we watch fallbacks, silent turns, latency and cost, and one number that ends a step on the spot: any outgoing message that ran without a yes.

What we would tell anyone building this

If your agent can read private data, read strangers’ words and send things out, you have the trifecta, and a human yes is the control. Treat that yes as a security boundary:

• Decide in one place. If no single function answers “may this run now,” you have habits, not a policy.
• Ask about very little. Confirmation fatigue is a vulnerability, not a UX nit.
• Do not let the model confirm. Remove the parameter.
• Read the yes with a narrow model. Small, typed, cautious, and blind to everything the user did not write.
• Bind the yes to the exact arguments, and let it be used once.
• Test decisions, not deployments. A green checklist about infrastructure says nothing about what the gate will allow.

Most of what makes an assistant trustworthy is not the model. It is the code around the model that decides when the model’s ideas become real.