Fable
The messenger learns to hand over a work order, not just write a paragraph of advice
In the warehouse there was a clever messenger who understood people's requests. When a worker wanted to check inventory, he could write a very presentable explanation, but he could not make the system actually check.
The administrator first had messengers write commands in sentences. Engineers then guessed from the sentences which system to call and what the parameters were.
Guessing quickly caused trouble. The customer's "before next Wednesday" was parsed incorrectly, a product model number lost a letter, and cancel order and query order got mixed together.
Some tried to patch it with regex and keywords. Every additional business action added another pile of exception rules, and maintenance costs kept climbing.
The new administrator changed the rules. Executable actions must first be registered as functions, with names, parameters, types, required fields, and meanings clearly written. When the messenger needs to act, they must submit a structured work order.
After receiving the work order, the system first validates the parameters, then the application layer decides whether to execute, whether to approve, whether to ask follow-up questions, and how to return the result to the messenger.
The messenger no longer drives external systems with a single natural language sentence. It is responsible for selecting functions and filling in parameters, while actual execution is still carried out by controlled programs.
Administrators still had to prevent errors. If function design was too broad, descriptions were vague, and permission and idempotency controls were missing, structured calls could also cause real losses. He understood that the key to letting machines request tools was not making them more eloquent, but having them use machine-readable parameters to submit reviewable action requests. Later, an even trickier job came along. On the surface it looked like just an amplified version of an old problem, but in reality it forced out all the gaps hidden in the process: who takes over first, who can make changes, and how to return to the previous step when something goes wrong. Places that used to get by on familiarity and tacit understanding now all had to be made explicit. The person in charge did not urge everyone to be more careful again; instead, he walked through the site once more. He had people record every handoff, every failure, and every remediation—which places were merely slow, which places would harm the results, and which places would be hard to trace back once wrong. After the new rules were rolled out, the first few days were not smooth. Some complained about the extra check, and some felt their old experience was being insulted. But when the next anomaly appeared, for the first time everyone could follow the traces to find where the problem had occurred, instead of gathering around the result and guessing at one another.