Teaching the agent how our three screens work
A one-day menu exposed a seven-poster assumption. We corrected the artwork and taught the reusable workflow to count the shop's actual screens and confirmed service days.
When we prepared the menu for 4 October, there was only one confirmed service day that week. The agent nevertheless produced seven posters. I looked at the plan and pointed out a basic constraint: our shop has three physical screens. We needed a set that would work on those three screens on that day.
One screen carries a fixed Facebook QR code. That leaves two screens for the day's menu. In a week with three service days, two menu designs per day plus the shared QR design gives us seven files. For one service day, the same rule gives us three. The agent had carried the seven-file pattern into a week where it did not belong.
I explained that distinction and asked for the correction. The revised set had two complementary menu panels and the fixed Facebook panel. The two menu panels covered all seven products for that Sunday, rather than splitting one day's information across six separate designs.
We checked the downloaded files as well as the preview. The final pack contained three 1920 × 1080 JPGs. Names, prices, portions, collection details and the real food photographs were checked, including their watermarks and whether anything had been cut off. The fixed Facebook board stayed unchanged, and the old seven-board version was marked as superseded.
I also wanted the correction to survive the next run. We updated the publish-menu skill, the reusable instructions I described in Part 8. The workflow now derives the required number of designs from the confirmed service days: two menu boards for each day, plus one shared Facebook board. Its validation rejects a set with the wrong count instead of simply expecting seven every week.
The result we can verify is a corrected three-file pack and a changed workflow, with the rule covered by automated checks. That is different from proving what was playing on the shop's televisions. It also does not make the agent incapable of future mistakes; it gives this particular assumption a concrete check.
For another small business, this is a useful way to respond when an agent gets something wrong. Explain the real constraint, check the revised output, and put the correction into the instructions or checks used next time. In our case, the constraint was as ordinary as three screens, one fixed QR code and the days Cindy was actually serving food.
