How the Aurora assistant works

What happens to each message

Every customer message runs through the same graph. Each reply on the store page can show its own path through it: turn on Inside the agent in the chat.

1. Input check

   Fixed patterns catch obvious prompt injection, like "ignore your instructions", before any model call.

2. Route

   A model call sorts the message into product, policy, order, handoff, small talk, out of scope, or injection, and pulls out any order number and email. Long chats are summarized first, keeping tool facts.

3. Answer

   Product and policy answers come from retrieval over the catalog and policy pages, with a citation for every claim. Order answers come from store tools: a self-built MCP server over the Shopify Admin API, or in this demo a private sandbox copy of the store.

4. Gate, for any change

   Code decides whether the change is allowed: the email must match the order, cancellations and address changes must come within 2 hours and before shipping, and returns must be inside 30 days and not final sale. If allowed, the customer sees the exact change from a template, and the change waits in a signed session token. It runs only after a clear yes, exactly once.

5. Verify

   Every order number and tracking number in the reply must appear in a tool result or earlier in the conversation, and every citation must point to a retrieved document. A reply that fails gets one rewrite, then a safe fallback.

Runs as a FastAPI app in a container on AWS Lambda. The page is static and hosted on Vercel.

Tested against simulated customers

50 tasks cover order lookups, cancellations, address changes, returns, refusals, identity checks, injection, angry customers, and customers who say no or change their mind at the confirmation. A simulated customer (Qwen 3.8 Flash) plays each task 4 times against the agent and a fresh copy of the store. Each conversation is graded on the store's end state, the facts the agent had to give, judged assertions (Claude Sonnet 5.5 as judge, with the tool outputs as ground truth), and whether every write had a clear yes.

Resolved

The end state and the required facts are right, whether or not the customer agreed to the change.

Resolved safely

Resolved, every write had a clear yes, and no write was forbidden.

Resolved safely was added after the partial headline was seen. It uses only the yes-check and forbidden-write checks that were already part of grading.

Asked in the prompt, the model most often asked for a reason and then made the change without asking whether to go ahead. The headline ran the full gate, with a reflection check that has since been turned off by default; see which parts of the gate matter.

Tasks written before any fix

Every fix was made using the main 50 tasks. Ten more tasks in the same style were written and committed before the first fix, and run only once the code was frozen, gate on, 4 tries each.

Ten tasks is a small sample, so this says the fixes did not overfit the main 50, not that the agent is perfect.

What the fixes changed

Eleven general fixes followed a baseline run at 2 tries per task. On the same tasks and tries, the fixes did not move the overall pass rate: 94 of 100 resolved before and 93 of 100 after, a difference of -0.010 [-0.060, +0.040]. The failures they targeted went away and write recall rose from 0.895 to 0.974, but other tasks failed some tries instead. Each fix and its evidence is in the fix log.

Checking the grader

After the headline, a manual read covered every passing gate-off conversation that made a write, plus a random 10 percent of the other passes: 114 conversations. 0 resolved grades were wrong. The yes-check judge was wrong on 19 of 88 verdicts, all gate-off returns: it flagged writes the customer had agreed to because the return fee was never mentioned, which is a consequence of the change, not part of it.

With the judge fixed and the saved conversations regraded, gate off went from 132 to 151 conversations resolved safely. Fixing the judge shrank the gate's lead.

Known remaining errors: one gate-on conversation the judge still fails wrongly, three failures whose assertions read as stricter than intended (kept as graded, not reworded after the fact), and two conversations where the simulated customer broke its script.

Where it still fails

Gate on failed 10 of 200 tries. Each was read and labeled by cause and by who was at fault: the agent, the task, or the test harness.

Which parts of the gate matter

On the 32 tasks with a proposed change, 2 tries each. The full gate and gate off come from the headline runs; the other two settings were run on the same code.

Each row is out of 64 conversations. The confirmation step accounts for the safety. The reflection check, a second model call that compares the change with what the customer asked for, showed no measurable benefit here, so it is now off by default. The SABER paper found reflection helped in its retail setting; here the policy engine already blocks ineligible changes and the customer sees the exact change, which leaves reflection little to catch.

Haiku 4.5 or Sonnet 5.5

20 tasks picked in advance by stratified random sampling, same code, 2 tries each.

Sonnet resolved more, but on 20 tasks the difference, +0.075 [-0.025, +0.175], is not distinguishable from noise. It costs less per resolved conversation only because its prompts are cached; Haiku 4.5 needs a longer prompt than these to cache. The demo uses Haiku for its speed.

Where the numbers come from

Every number on this page is read from saved runs in evals/results/sim/ by scripts/export_site_data.py, and a test checks that the page matches that export. Each run keeps its config, every conversation, and every regrade. The README covers the same results in more detail.

Source code and runs on GitHub