Prompts help, systems scale

Most companies met AI through an empty box and a blinking cursor. What came out depended on what went in, so people learnt to write prompts. Some became very good at it. Their colleagues asked for the magic words, the words were pasted into documents and chats, and a new kind of folklore was born.

Prompting matters, and it is worth doing well. But a company cannot run on folklore. Here is what makes a prompt good, what the labs themselves recommend, and why the companies that get the most out of AI stop relying on clever prompts.

A bad prompt and a good one

Take a request every marketing team makes. The bad version reads: write a LinkedIn post about our new service.

The model has nothing to work with, so it writes the average LinkedIn post about the average service, with an opening question, a row of emojis and a call to action. It is not wrong. It is nobody's.

The good version says who is writing and for whom, what the service is and what it costs, what the reader should do next, how long the post may be, and which words the company never uses. It includes two earlier posts that worked, marked as examples. And it says why: the post goes to finance leads who are sceptical of AI, so it should open with a fact, not a promise.

The second prompt is far longer, and far more likely to produce a draft someone can use. The difference is not cleverness. It is context.

What the labs recommend

The official guides from the three large labs say much the same thing.

Anthropic's guide for Claude asks you to “think of Claude as a brilliant but new employee who lacks context on your norms and workflows.” Its golden rule: “Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.” It also shows why reasons beat orders. Instead of writing never use ellipses in capitals, explain that the answer will be read aloud by a text to speech engine that cannot pronounce them. The model generalises from the reason.

OpenAI's guide recommends giving the model the context it needs and examples of possible inputs with the desired outputs, across a diverse range. It calls prompting “a mix of art and science.”

Google's guide for Gemini recommends always including a few examples and warns that prompts without them are likely to be less effective. For complex tasks it suggests making each step its own prompt and chaining them together. And it is honest about the process: “Prompt engineering is iterative.”

Why prompts do not scale

Read those guides again and notice what they assume: someone who knows the company's norms, has the right examples at hand and has time to iterate. In most teams, that describes a few people, on a good day.

Everyone else copies a prompt from a chat, changes a word and gets a different result. The prompt that worked in spring behaves differently after a model update. Two teams keep two versions, with rules that contradict each other. One of OpenAI's own prompting guides warns that contradictory or vague instructions can do more damage to a reasoning model, because it spends effort trying to reconcile them. Its example is a healthcare assistant told both never to book an appointment without the patient's recorded consent and to book the earliest slot without contacting the patient first.

OpenAI treats prompts as software for that reason. Its guide tells developers to keep production prompts in their application code, to pin applications to specific model snapshots, and to build tests and evaluation suites that measure how prompts behave. That is the opposite of a prompt library in a shared document.

The cost shows up in results. MIT's NANDA initiative reported last year that only about 5 percent of the AI pilots it studied achieved rapid revenue acceleration. Fortune summarised the cause as a learning gap: generic tools stall inside companies because they do not learn from or adapt to the way the work is done.

From prompts to systems

The labs have drawn the conclusion themselves. Anthropic now speaks of context engineering rather than prompt engineering: curating everything the model sees, not only the instruction, and finding the smallest possible set of high signal tokens that makes the right result likely. Its engineers warn against two failure modes, brittle logic hardcoded into prompts on one side and vague guidance that gives the model nothing concrete on the other.

The practical answer is skills. Anthropic describes them as “organized folders of instructions, scripts, and resources” that an agent loads when it needs them, and compares writing one to “putting together an onboarding guide for a new hire.” In a post on design, the same company wrote that skills make effective prompts reusable and contextual, so nobody has to repeat the same guidance in every request. Since December 2025 the format has been an open standard.

A skill is a good prompt that has been written once, given its reasons, its examples and its checks, tested, and put where every assistant in the company can find it. Add the company's knowledge, its rules and its connections to real systems, and you have a company brain. Then the quality no longer depends on who typed.

How we help

This is the work behind Twin. We find out how a company actually works, improve the process where it needs it, and then build its brain: knowledge with the source on every answer, skills for every role written in the company's conventions, integrations to its systems, and rules and rights by role. It runs in the assistant the team already uses, Claude, ChatGPT or Codex, and the company receives the source code.

Without Twin, every prompt starts from zero and the quality depends on who asks. With Twin, every answer starts from the company, with one standard on every desk.

We run crue the same way: more than 80 skills and a brain for each of our products, in Claude and ChatGPT and on our own hardware with our own model. When the data is too sensitive to leave the building, there is Eigna, built by our partner Eigna Labs: a private model trained on the company's own files, rules and language, running in its own cloud or on its own servers, and retrained in steps that go live only when they test better.

What a company can do

Keep prompting well, and learn the basics from the guides above. Then collect the ten prompts your best people actually use, and ask what each one knows that the model does not. Write that down once: the context, the reasons, the examples, the rules and the check at the end. Give each one an owner and a test, and put it where every assistant can reach it. That is a skill.

We want the machine to take the routine, the first drafts and the lookups, and to do them faster and more consistently than any of us. The judgement, the personal contact with clients and the responsibility for what is sent stay with people, and a good system gives them more time for exactly that.

A clever prompt makes one person faster. A system makes the whole company better, and keeps working after the clever person has gone home.