Prompt Engineering

Receipts are not glamorous. That is precisely why they are useful. A receipt-item categoriser is not a benchmark leaderboard, a launch demo, or a dramatic agentic workflow with a glowing dashboard. It is the kind of small, repetitive business decision that quietly determines whether an AI system becomes a product or remains an expensive toy. A bottle of iced coffee needs a category. A supermarket item needs to land in the right expense bucket. The output must be parseable. The cost must be low enough to repeat thousands or millions of times. Nobody wants a philosophical essay from the model. They want a JSON array. ...

Tone is an attractive business lever because it feels cheap. No new model. No new data pipeline. No procurement meeting in which someone says “governance layer” with a straight face. Just add a more emotional sentence before the prompt and hope the model becomes sharper. This is exactly the kind of idea that spreads because it is easy to try and hard to interpret. One team finds that urgency helps. Another finds that politeness helps. A third discovers that telling the model you are scared improves one benchmark and damages another. Soon the organization has a secret prompt cookbook, which is always a classy substitute for measurement. ...

Prompt failures rarely announce themselves with a dramatic explosion. More often, they arrive as a polite, plausible answer that quietly ignores the one word that mattered. A compliance assistant misses “not.” A summarizer preserves the general topic but drops the exception. A customer-support bot treats “refund denied” and “refund approved” as neighbors because the surrounding sentence looks familiar enough. Nobody panics at first. The output is fluent. The dashboard is green. The meeting is calm. Then someone asks the inconvenient question: which part of the prompt actually controlled the answer? ...

Prompts are now office furniture. Everyone has them. Everyone complains about them. Nobody is quite sure who owns the standard version. One team keeps a Notion page of “best prompts.” Another hides theirs in a spreadsheet. A third tells new staff to “just ask clearly,” which is not a method, but it does have the administrative elegance of doing nothing. ...

Roles are convenient. They let managers believe a system is legible before it becomes messy. One agent is the compliance reviewer. Another is the customer-support representative. A third is the skeptical analyst. Add a prompt, assign a tone, define a boundary, and the organization can pretend it has converted social behavior into configuration. ...

Agents are easy to create. That is now the boring part. Give one LLM a persona, give another LLM a conflicting persona, add a shared task, let them talk, and suddenly the demo looks like a little society. A farmer argues with a conservationist. A rural teacher argues with an urban parent. A policy maker tries to sound balanced, because apparently even simulated bureaucracy has survival instincts. ...

Trading teams rarely fail because nobody had a title. They fail because the signal gets lost somewhere between the analyst, the sector specialist, the portfolio manager, and the final trade list. Someone sees momentum. Someone else sees valuation. A news analyst notices a red flag. A macro analyst says the regime is awkward. Then the PM receives a pile of half-compatible opinions and performs the ancient institutional ritual known as “synthesis,” which is often just a polite word for discretionary compression. ...

Car wash. That is not usually where enterprise AI strategy goes to become interesting. Yet a small question about whether one should walk or drive to a nearby car wash exposes a very real failure mode in LLM systems: the model optimizes the visible variable and misses the actual task. The question is simple: ...

Poetry is a useful place to test the limits of AI, partly because the task is so easy to misunderstand. A bad poem can be fluent. A decent poem can be vague. A machine can produce both before breakfast, along with a motivational LinkedIn post and three flavors of executive summary. That is not the interesting part. ...

Tokens are small. That is why they are dangerous. A developer asks an assistant to generate a function, explain a repository, or reason through a failing test. The screen fills with text. Some of it is useful. Some of it is decoration. Some of it is a polite little parade of examples, test cases, alternative implementations, or whitespace that will be thrown away by the next parser in the pipeline. ...