A personalized greeting is the visible half. The useful half is spending that knowledge later, where it saves the customer a step.
The bundled view_transactions skill asks which account, every time. We know
Jordan’s usual account. Asking anyway is the same anonymity, one turn later.
Scoped instructions
A scoped instruction is a top-level if: branch in the skill body. The model
is shown only the branch that currently applies:
if: not session.view_transactions.selected_account_id and session.project.default_account_id
The customer has a usual account on file: @memory.project.default_account_label.
Offer that one first by name — for example, "Want your usual
@memory.project.default_account_label, @memory.project.customer_name?" If they
say yes, set `selected_account_id` via `set_fields` to
@memory.project.default_account_id. If they'd rather use a different account, or
they already named one clearly, instead call `fetch_accounts`, present the
accounts, ask which one they want, and set `selected_account_id` to the matching
account id.
if: not session.view_transactions.selected_account_id and not session.project.default_account_id
Call `fetch_accounts` to load the customer's accounts. Present them and ask which
one they want.
if: session.view_transactions.selected_account_id
Call `get_recent_transactions` for the selected account and present the returned
rows briefly (date, merchant, amount).Three states, three sets of instructions, one skill. A customer with a default account is offered it; a customer without one gets the list; once an account is chosen, both converge on the same final branch.
The model never sees the branches that do not apply, which is why this scales better than one long instruction full of caveats.
Two details that are easy to get wrong
The if: must be at the top level of the skill body. Indented inside an
instructions: block it is not parsed as a condition at all — it stays prose,
and the model is asked to evaluate something it cannot. This fails silently:
nothing errors, the branch just never works.
Reference memory as @memory.… in prose. The session.… form is correct in
conditions and structured fields like requires:, but inside instruction text it
is passed to the model as literal characters. Two spellings, two places:
| Where | Form |
|---|---|
if: conditions, requires:, complete_when: | session.project.default_account_id |
| instruction prose | @memory.project.default_account_id |
Check the confirmation boundary
Start a fresh conversation with Jordan’s usual account loaded in
session.project.default_account_id, its label set to Everyday Checking, and
session.view_transactions.selected_account_id unset. Having a usual account
is not the same as having selected it for this request.
The following is an illustrative expected interaction, not a captured test run:
you show my transactions
bot Want your usual Everyday Checking, Jordan?
you yes
bot Here are your most recent transactions for Everyday Checking:
2026-07-28 Blue Harbor Market -$42.18
2026-07-26 Northline Transit -$3.50
2026-07-24 Cedar & Co. -$68.00
2026-07-22 Payroll Deposit +$2,150.00Check the selected account and tool calls as well as the wording. Before the
confirmation, selected_account_id should remain unset and
get_recent_transactions should not run. After “yes”, it should match the loaded
default account ID before transactions are fetched. If the user instead asks
for a different account, check that fetch_accounts supplies the choices and
that the eventual selection matches the user’s choice, not the stored default.
Only a conversation where selected_account_id is already set starts in the
final branch and can fetch transactions without this account question. Clear it
before repeating the first test. Personalization saves the customer a list
selection; it does not remove their confirmation.