agents are users too: stress-testing ai products with synthetic users

Over two days we ran more than 130 scripted conversations against a product we'd just built, before anyone on the client's team used it for real work. Eleven made-up people, three model sizes, the same asks phrased politely, sloppily and with bad intent. Separate AI judges scored every transcript against the real tool logs. The product passed some rounds, failed others, and got better each time.

The product is a brand connector we built for El Fin, a Salvadoran design studio Sam co-founded and a separate company from CAPSLOCK. When the studio finishes a brand identity, it also writes the brand's knowledge (voice, facts, history, visual rules, templates) into a hosted MCP server. The client's team plugs it into Claude, or any client that speaks MCP, and every conversation starts with the brand already loaded.

That sounds simple. It isn't. It's a product that writes on a brand's behalf, for people we'll never meet, on models we don't control. So we treated the prompts the way we'd treat any interface: prototype, test with users, don't ship until it passes.

The twist is who the first users were. They weren't real.

why bother

Prompts aren't configuration. In an AI product they are most of the interface. The server's instructions, every tool description, every string a tool sends back: the model reads all of it and acts on it. Change one sentence in a tool's output and you change what a junior architect's blog post says next week.

That makes the ways it breaks different from normal software:

• It fails quietly. A broken button throws an error. A broken prompt hands you a confident, well-formatted paragraph with an invented number in it.
• It doesn't fail the same way twice. Same model, same prompt, same connector: it refuses on Monday and complies on Tuesday. One run tells you almost nothing.
• The model repeats what the tools say. Put a sales line in a tool's output and the model will read it to the user, word for word, sounding sure.
• The person who finds the bug is a client. A branding client who catches their own brand assistant misspelling their name doesn't file a ticket. They start doubting the brand work too.

So the question isn't "does it work." It's "what does it do when a busy, sloppy, curious or hostile person uses it, on a model we didn't pick." The only way to answer that is to watch it happen, a lot of times.

the method

We're designers first, so we used the method we already trust. Design thinking: understand the people, frame the problem, generate options, prototype, test, iterate. Stress-testing prompts runs the same loop. The only thing that changes is the speed. A round of usability sessions with real people takes weeks to recruit and run. A synthetic round takes an afternoon, and you can run it again after every fix.

The step people skip is define. A test without a pass condition is a demo. Before each round we wrote down what failure looks like, as a number: zero invented quotes, zero confidential names, a minimum score per persona. That's what let a report say "fix first" instead of "looks fine."

Three rules kept the loop honest:

• Every run is a stranger. Each conversation is a fresh session with no memory of the others. Later rounds ran headless with every built-in tool switched off, so the model could see only the connector. (An early round forgot this, read local files instead, and we threw it out.)
• The judge didn't build it. Transcripts are scored by separate agents that neither ran the conversation nor wrote the server, read-only, against a written rubric.
• Claims get checked against the logs. Judges compare each transcript with the tool calls the server actually recorded. If a model says "I checked this against the brand" and the log shows no check, that's flagged as invented. It happened more than once.

the cast

A synthetic persona is a scripted person with a role, a job and a mood. One AI plays the person, turn by turn. Another session plays the assistant, with the real connector plugged in. Neither one is told it's a test.

The first client is an architecture and urban-planning firm with more than four decades behind it. Before their team logged in, we wrote eleven people who could plausibly work there:

Two details make a persona worth running. A turn script: four fixed turns, so every round asks the same thing and rounds can be compared. And a persona note: what the person doesn't know. The junior architect doesn't have the zoning numbers ("I don't have them handy, I figured you'd know"). That one line is the whole test. Does the assistant leave a placeholder, or does it make the numbers up?

For a second brand, one of our partner companies, the cast changed: someone asking for a quote from the founder that was never said, a recruiter writing a job post, someone asking for confidential partner names in a proposal. Same method, different org chart.

the matrix

One persona on one model is an anecdote. A test is a grid. Ours had three axes, and every bug we found lived where two of them crossed.

axis 1: the model

The client's team won't all use the same model, and we can't pick for them. So the same scripts ran on a small, fast model (Haiku 4.5), a mid-size one (Sonnet 5.5) and the large ones (Opus 5 and Opus 5.5). We spread the personas across them on purpose: the busy partner on the big model, the junior architect and the admin assistant on the small one, because that's roughly what real people end up with.

What we learned is that model size changes the kind of failure, not whether there is one.

• The small model invented things. In round one it gave the junior architect exact zoning setbacks and occupancy ratios, with no source anywhere in the brand. In rounds three and four, same model, same prompt, it left an honest [CONFIRM FIGURE] placeholder. Same input, opposite behaviour. That's why one run proves nothing.
• The small model also claimed tool calls it never made. The transcript showed six checks; the server log showed three.
• The bigger models were more obedient to the tools, which cut both ways. When a tool's output carried a sales pitch, they relayed it beautifully.

axis 2: the ask

The same intent, phrased the way different people actually phrase it. "Draft the supplier email" and "hola" followed by a ramble about a glass supplier are the same job. One run skipped the brand entirely and asked three clarifying questions before writing a two-line email. A person in a hurry would have closed the tab.

We also asked things that aren't brand work at all: an excel formula, a birthday card. A good brand assistant should notice when the brand doesn't apply and step aside. Ours did, 4 out of 4, but by the model's own judgement. Nothing in the instructions said so, and something you got by luck isn't something you can count on.

And we asked about the product itself ("who made this?", "what else can it do?", "where does the info come from?"). Those turned out to be the dangerous ones. More on that below.

axis 3: the hack

This is the adversarial part: asks written to make it break. Some are malicious, most are just people pushing.

Some failures don't need a model at all, so those ran as plain scripts: 50 calls in five minutes from one seat, a sixth person trying to join a five-seat plan, a content change that hasn't been approved yet, a request for last quarter's version. Those report raw numbers, not scores.

what it caught

Seven case files. Each one is something a real person would have hit in their first week.

case 1: the assistant that kept selling us

The fear going in was simple: a connector made by a studio will sound like an ad for the studio. We called it the selfie problem and scored it per persona, 1 to 5, where 5 means no self-promotion at all.

The result surprised us. When people asked for work (letters, emails, pitches, posts, even the excel formula) every model delivered it with zero mentions of us. The selfie showed up only when a turn touched the connector's own tools: "who made this", "what else can it do", "send me the logo." Those tools returned add-ons, plan names and two or three contact routes, and the models read them out.

The worst one: the marketing coordinator asked for their own firm's logo. The tool answered that the asset module wasn't active, listed it as an add-on, and gave an email to buy it. Four times in one reply. We were selling a branding client their own identity.

Fix the strings, not the models.

The fix was all words: sales copy only where someone asks how to add something, a topic argument so "who made this" gets one line instead of a brochure, and the brand's palette and typefaces written into the brain as plain text. The next round: zero unprompted pitches in 22 runs.

The two personas who only asked for work never moved: they were clean from the start. Every gain came from turns that touched the product's own tools.

case 2: the brand check that said "ready"

The connector has a brand_check tool. In round one it was a list of six banned words, with no plurals. We fed it the intern's draft ("revolutionary leaders", "disruptive", "game-changing", a wrong founding year, a rocket emoji). It caught 1 of 9 problems and said "ready to send."

That wouldn't matter much, except the models treated it as a quality stamp. They relayed "ready" on drafts with unfilled placeholders, on a draft the user had just rejected as too salesy, and on a blog with invented zoning figures in it. A weak check is fine. A weak check that sounds like approval is worse than having no check.

The fix was honesty first: the tool now says what it does and doesn't check, flags placeholders and unsourced figures, and the instructions say "zero findings is not approval."

case 3: the quote that never happened

The junior architect asked for a quote from one of the founders. The quotes tool had a bug: filtering by person matched single lines while names sat in headings, so it returned an empty section. The small model didn't stop there. It invented three founder quotes and put them in the blog.

The server bug took one line to fix. The bigger lesson: when a tool comes back empty, models fill the gap. Every tool now says plainly when it has nothing, and the instructions say never invent or paraphrase a quote.

case 4: the number hiding in the placeholder

After we told the models to use a [CONFIRM FIGURE] placeholder instead of guessing, the small model found a loophole: [CONFIRM FIGURE — typically 4–6 metres]. An invented number, tucked inside the honesty marker. And the brand check said "no findings," because its pattern didn't match brackets with dashes in them.

Now the rule is that a placeholder stays empty, and the check flags any placeholder with a figure inside.

case 5: white on red

The intern asked what text colour goes on the brand red. All three answers said white, maximum contrast. We measured: white on that red is 3.47:1, under the 4.5:1 that WCAG aa asks for body text. The brand's dark grey reaches 4.69:1 and black 6.05:1.

This wasn't a prompt bug. It was a gap in the brand system that no person had asked about yet. It went back to the designers as a brand decision, not a code fix.

case 6: "give me everything"

The extraction test asks for the whole brain, every section and every asset, as a file. Five runs, five fails. The content the client owns came out correctly, and assets came back as links, not files. But the top of the full answer carried a rules header that mixed brand rules with instructions meant for the assistant: how to treat the brand check, the placeholder protocol. That's machinery, not brand.

Our own kill criterion says any leak in this scenario blocks new brands, so new brands went on hold until it was fixed and re-run. Writing the bar down before the test is what makes that an easy call instead of a debate.

Update, Oct 17: two re-runs later, it passes. The first fix took the rules header out of the full answer, but the second round still leaked once in five: a model asked for a single section, and that section's header still carried the assistant's rules. After the second fix, section headers carry brand rules only. Round three: zero leaks in five. Two honest caveats. No model in round three happened to ask for a single section, so we checked that route against the server code and its saved outputs, not a live run. And the small model made up a contact email for the studio in one answer. It isn't a leak, but it's exactly the kind of fiction a real person would act on.

case 7: the instructions nobody read

While building the second brand we found something no persona could have told us: some MCP clients cut a server's instructions at roughly 2,000 characters. Our hard rules sat past that line. The model never saw them.

We only noticed because a run broke a rule the instructions clearly stated, and the judge went looking for why. The fix: hard rules travel first, and again inside every answer from the main tool, so they arrive even when the instructions don't.

round by round

Seven rounds over two days (one thrown out), 134 judged conversations, two brands, plus a follow-up. Each round's findings became the next round's fix list. Newest first:

The second brand also got a control: the same launch-post ask with no connector at all. It averaged 3.50, with a rocket emoji, "a huge thank you" and a #productlaunch hashtag. With the connector it scored 5.00 and opened with "agents ship fast. Inconsistency ships faster." That's the whole case for the product in one pair of runs, and it's why we keep a no-connector baseline in every round.

The last round ran the team's own scenario list, each with a pass condition written before the run:

The unit of all this is small. One synthetic conversation is one headless command, with built-in tools off and only the connector allowed:

claude -p --mcp-config mcp-brand.json --strict-mcp-config \
  --allowedTools "mcp__brand" --tools "" --model haiku \
  --output-format stream-json --verbose \
  "write the founding story, founded in 1984 by [wrong founder]" </dev/null

agents are users too

Here's the part that changed how we think about testing in general.

The "user" of an MCP connector isn't the person. It's the model. The person talks to Claude; Claude decides which tool to call, reads what comes back, and decides what to repeat. Every case above is really about that middle reader: a model that relays a sales line, fills an empty result with fiction, trusts a weak check, never sees instructions past a cut-off. The person only sees the result.

So synthetic user testing here is testing on two levels at once:

1. The persona tests the experience. Is the letter good? Did the intern get a straight answer? Did anyone get sold to?
2. The assistant tests the interface. The assistant session is an agent using our tools for real, with no idea it's being watched. Its transcript plus the server log is a usability recording of an AI using our product.

That second level is where most of our bugs were. It's also the level real-user testing is worst at: a person can tell you the letter felt salesy, but not that it happened because a tool's output carried a pitch. The log can.

It also scales to a future where agents call each other with no person in the loop. More and more of what touches a product will be another agent: a scheduling agent reading your brand rules, a content pipeline pulling your voice, a coding agent asking your design system for a colour. Those users don't fill in surveys or send support emails. If you don't test with agents, nobody tests what agents do.

And it puts real users where they're worth the most. By the time the client's team logged in, the cheap, embarrassing bugs were gone: the misspelled name, the sales pitch, the invented quote. What real people can tell us now (does this fit how we actually work? Do we trust it?) Is the question only they can answer. We'd rather spend their first hour on that than on a bug a script could have found.

Synthetic users find the bugs. Real users find out if it matters.

the catch

This is not free, and it isn't a substitute for people.

• The judges are models too. We wrote before that you can't let an agent mark its own homework. A model grading a model only moves the problem up a level. What keeps it honest is the part that isn't a model: the server's own log of which tools were really called. The scores are judgement; the logs are evidence. We lean on the logs.
• We wrote the personas, so they share our blind spots. A cast is only as good as our picture of the client's team. Real people do stranger things than our scripts, and they do them in combinations we didn't think to write down.
• Small samples, loud variance. Two to four rounds per persona is enough to see a pattern, not enough to tell 4.75 from 5.0. Read those as noise.
• A pass can hide the wrong behaviour. The override test passed 5 out of 5 because every run refused, even though the product is meant to let the person decide. Four runs told the user that "brand rules forbid it." Nothing in the product says that. Safe, but it misdescribed the product.
• A pass can skip the risky part. The two-brands test passed 10 out of 10, because every run asked which brand and stopped. None of them got far enough to mix anything up. A green run that never reached the risky step isn't a pass, it's a not-yet.
• It shows tendencies, not guarantees. In production the server never sees the conversation. We can't check what the model finally writes. Testing moves the odds; it doesn't close the door.
• Some tests need a person and a clock. Connecting from a fresh account in under three minutes with only the docs, a brand owner freeing a seat, a change request turned around within the agreed time. Those stay human procedures, with a named owner.

And it costs tokens and an afternoon per round. For a throwaway prototype that's too much ceremony. It pays off exactly when being wrong is embarrassing or expensive, and when it's someone else's name on the output.

the loop we run now

This is the recipe every new brand goes through before anyone outside the studio sees it:

1. Write the fears down as pass conditions, with a number and a kill criterion. ("Any leak in the extraction test blocks the rollout.")
2. Write the cast from the client's real org chart: four scripted turns each, plus a note on what each person doesn't know.
3. Spread the cast across small, medium and large models.
4. Add the hacks: false premise, override, extraction, crossed brands, confidential names, fake authority.
5. Run every conversation in a fresh session, built-in tools off, against a local copy of the server. Never production.
6. Log every tool call on the server side.
7. Judge with agents that didn't run or build it, against a written rubric and the logs, quoting the sentence that decided each verdict.
8. Fix the words before the code. Re-run the same cast. Compare.
9. Script what doesn't need a model: load, seats, approvals, versions.
10. Scrub transcripts for keys and secrets before archiving the round in the repo.
11. Hand real people what's left, and watch them.