---
title: "A business for agents to practice in"
description: "Simulated business scenarios give agents realistic situations to work through, and can do it thousands of times, to get it right."
canonical: "https://www.rickblalock.dev/scratch-notes/a-business-for-agents-to-practice-in/"
date: "2026-10-20"
updated: "2026-10-20"
author: "Rick Blalock"
---

# A business for agents to practice in

> Simulated business scenarios give agents realistic situations to work through, and can do it thousands of times, to get it right.

Published: 2026-10-20

Catalog: SN-023

An agent dropped into a business inherits decisions made before it arrived. Someone approved an estimate, promised a date, ordered a part, or made an exception for a customer. The next task depends on that history.

Synthetic data can mean asking a model to manufacture examples for another model to learn from. [Yuhan Luo’s piece on synthetic data](https://x.com/i/article/2111490981208203264) is about the system that produces those examples. Simulate the events first, then generate the records those events would leave behind. The emails, invoices, and support tickets would share one history instead of being invented separately and checked for contradictions afterward. Luo puts the agent at the end of that process:

> “The agent’s starting world is the end state of this simulated history.”

I’ve [written about models for small-business work](https://rickblalock.dev/scratch-notes/a-model-for-small-business-work/). Luo’s approach gives me something more concrete to consider: a small, simulated business where an agent could practice handling the consequences of a decision.

Imagine a repair company. A customer accepts an estimate, a technician is booked, and the required part is ordered. Then the supplier pushes delivery back. The customer has already taken time off for the visit. Another job occupies the technician’s next available afternoon.

Now give the agent a short request: sort out the delay and prepare a revised plan for the owner.

The simulator would know when the part can arrive, which commitments already exist, and which changes require approval. We could check whether the agent’s plan is possible, whether it creates another scheduling problem, and whether it promises something the owner has not approved.

The records wouldn’t all agree, either. An old email might still promise the original appointment. A spreadsheet might not have been updated. Each disagreement should have a cause in the history, and working out which information to trust is part of the task.

Obviously a language model could help write the messages and documents but also a lot of the other ancillary data to generate the various scenarios. Someone who knows the work would still need to judge whether the situations and rules resemble an actual business. A simulation can hang together perfectly and still be wrong about how the work goes.

[AppWorld](https://arxiv.org/html/2407.18901v1) builds simulated histories this way, through application APIs, so an order produces related changes to inventory, the cart, and confirmation emails. It demonstrates a way to construct and test these environments. It doesn’t establish that training in them makes an agent better at running a real business.

I may try a small version of this next week. Generate and give the same agent, unchanged, a few situations in clean records, then versions with old messages, inconsistent formatting, and stale information. Keep the underlying business problem the same and see where its decisions change.

That would be an evaluation, not evidence that the agent had learned from practice. With several changes made at once, it also wouldn’t show which one moved a decision. It could still answer a useful first question: does the agent still prepare a workable plan when the business history takes some effort to reconstruct?

---

[All Scratch Notes](https://www.rickblalock.dev/scratch-notes/)