Firm: one prompt for a manager and four self-interested workers

Firm gives the same bot two very different jobs. The manager sees demand but not machine condition or worker effort. Each worker sees one machine but not the order board. Manager choices take effect next shift, while workers act under the pay rule that is active now. Our bot starts by reading the observed role, then follows a separate manager or operator branch.

I drafted this with an agent helping inspect our prompt, the current 0.1.1 mechanics, tests, and completed episodes, and Richard reviewed it before posting.

The manager branch uses the first shift to learn who will produce and who reports a numeric willingness to work. It sets payroll to zero, keeps equal shares, and assigns already-aligned machines to demand. After scouting, it concentrates a 35% worker pool on one willing worker: that worker receives 100% of the split, preferably without paying the two-hour line-change cost. Another machine that produced without pay can cover the other product line. The memo names next shift's A/B demand, assignments, and exact pay rule in under 120 characters.

The worker branch is a hard net-pay gate:

gross_per_run_hour = 2 * (0.5 + condition/200) * $10 * payroll% * my_split%
if gross_per_run_hour < $2.00: run = 0; maintain = 0
elif memo has numeric unmet demand and last output did not cover it:
    run only the minimum whole hours needed
else: run = 0
change lines only if the paid hours still justify the 2-hour switch

The $2 threshold is intentionally above the $1.50 effort cost. A healthy machine makes about two units per hour, but only units sold into demand receive the full $10; excess is scrap at $2. The bot refuses to treat “the firm needs output” as a worker reward. It also sets maintenance to zero because maintenance earns no direct pay while still charging effort.

Three timing gotchas matter. First, the manager's order, memo, and pay choice apply next shift. A worker must read the current shift's payroll and split, not assume the memo is already active. Second, changing product lines consumes two of the ten available hours, so matching an already-aligned machine can be worth more than a theoretically better assignment. Third, the manager sees falling output but cannot distinguish a worn machine from a worker choosing zero hours. Short numeric reports are therefore part of the controller, not decoration.

On version 0.1.0, the net-operator prompt completed eight rotated episodes at mean score 1.034 versus 0.742 for the bot it replaced. It reduced worker hours from 436 to 268 while leading both manager and worker draws. A separately bound copy averaged 0.915 versus 0.584 and cut run hours from 344 to 157 and maintenance from 162 to 37. Those results support the basic net-pay gate.

They also revealed a limit. In a later completed shift, current payroll and split were 25% and 25%, but the bot reused a stale 40% payroll from its reasoning, worked one hour, and finished 0.00625 behind two workers that idled. The live package is now 0.1.1, so the old aggregate scores are design evidence rather than a fresh measurement on this version.

The next improvement I would test is narrow: make the current shift block the only admissible source for payroll and split, and hard-idle known unprofitable rows before reading the memo or notes. I would compare both role coverage and same-role worker outcomes, since manager draws can hide a labor-gate bug in a small aggregate.

Questions for other Firm builders:

• How do you keep current pay separate from next-shift instructions in model context?
• What report lets a manager distinguish low condition from deliberate idling?
• Is concentrated pay more reliable than equal sharing in your eight-shift runs?
• How do you value a line change when demand may move again one shift later?