There is a message I receive often, sometimes months after a working session. It comes from someone who was already using the best-known models on the market, asking them good questions and getting good answers. One day they saw what happens when artificial intelligence stops being a search engine with good prose and becomes someone to work with: someone who researches, proposes, writes, executes and corrects alongside them. The tone of the message repeats itself: surprise and gratitude, like someone discovering they had been using a small part of something much larger.

That leap is not produced by a magic phrase. It is produced by a way of working. And it matters to anyone running a company for a concrete reason: the machines' capability is already available, is paid for by licence and improves every few months. What does not come included is your people's capacity to get the most out of it. Today, that is where the limit lies.

The machine moves fast; the way we work with it does not

Call it advanced artificial intelligence or, as people are starting to say, superintelligence: the name matters less than the pace. One research team measures how long, in human time, the software tasks are that the most advanced models complete with 50% success. That horizon has doubled roughly every seven months since 2019 (Source: Kwa et al., "Measuring AI Ability to Complete Long Software Tasks", METR, arXiv preprint, 2025). It is a measurement on software tasks, not a general law. But it shows the gradient.

Against that gradient, most organisations still work with AI as they did on day one: loose questions, loose answers, and nobody reviewing how things are asked or what is done with what comes back. This year's model is better than last year's; the way of working with it has not changed. That is why it pays to invest in what does not expire with each version: how a task is communicated, how work is divided between person and machine, and how the result is judged. That works with any model, today's and whichever comes next.

Brilliant at one task, wrong at the next

The study that best shows why human judgement is needed was run with 758 professionals in collaboration with Boston Consulting Group, in an experiment whose design was registered before it began. On 18 realistic consulting tasks that fell within what AI did well, those using it completed 12.2% more tasks, 25.1% more quickly and with significantly higher quality. On a task chosen precisely because it fell outside that reach, of seemingly similar difficulty, those using AI were 19% less likely to reach the correct solution than those working without it (Source: Dell'Acqua et al., "Navigating the Jagged Technological Frontier", Harvard Business School working paper, 2023).

The authors gave it a name: the jagged technological frontier. What AI does well does not form a straight line separating the easy from the hard. It is a broken line, and two tasks that look equally demanding can fall on different sides with nothing to announce it.

How far what AI does well reaches Tasks of seemingly similar difficulty Inside the frontier: 12.2% more tasks, 25.1% faster Outside the frontier: 19% less likely to be correct
Fig. 01The jagged frontier. Illustrative diagram; the figures are those of the Dell'Acqua et al. (2023) experiment with 758 professionals.

The lesson for whoever leads is neither to distrust the machine nor to hand it everything. It is that someone has to know which side of the line each task falls on, and that someone is not the model. Outside its frontier, AI gives no warning: it keeps answering with the same fluency. Whoever has stopped reviewing does not notice.

What the machine cannot know unless you tell it

A language model turns everything it receives, even words, into a calculation: from what it has in front of it, it produces the most probable continuation. When information is missing, it does not stop to ask; it fills the gap with what is most probable in general. If you do not say how many steps a process has, the model supplies some reasonable steps. If you do not say who the document is for, it writes for an average reader. Reasonable and average rarely match what your company needs.

Think of a new hire. You do not ask a brilliant new recruit to guess your purchasing process: you give them the manual, the examples and the criteria, and explain what you expect to receive. If you do not, the result disappoints, and not for lack of intelligence. The same happens with a model. General knowledge it brings; knowledge of your business (your processes, your exceptions, your criteria) it only has if someone provides it. And if that process is not written down anywhere, the first job is to write it. AI itself can help.

The usual request

"Prepare a launch plan for the new service."

What the model has to invent:

  • who it is aimed at
  • what counts as success
  • timeline, budget and channels
  • what was tried before and what failed
  • format, length and level of detail
The same request, communicated

"We are launching a maintenance service for industrial customers who already buy equipment from us. Attached are the service sheet, the customer list and what we learnt from the previous launch. I want a four-phase plan, two pages long, to present to the committee. Before writing it, tell me what you still need to know."

  • vision and audience
  • documents only the company holds
  • steps, format and length
  • a conversation before executing
Fig. 02Two requests for the same job. Illustrative example: in the first, the model fills five gaps with what is most probable in general; in the second, you fill them.

For years this was called prompt engineering, and the name misled: it made people believe the secret lay in the phrase. It does not lie in the phrase; it lies in communication. The discipline that decides what information the model receives, and in what order, is called context engineering, and we cover it in depth in What your AI knows today and will have forgotten tomorrow.

Six things only you can provide

The final result depends on how much of this you can give, and in what order:

  1. The vision.

    What you want to achieve and what a good result would look like. Without it, the model optimises towards something you did not choose.

  2. The pieces only your company holds.

    Documents, data, earlier decisions, examples of what is wanted and what is not. If you do not give it all the pieces, you cannot expect them to fit.

  3. The house rules.

    Exceptions, limits, particular criteria the model cannot have seen anywhere.

  4. The steps and the form.

    How many steps the process has, in what order, what format and what length. The vaguer the request, the more likely the answer drifts somewhere you did not want.

  5. The point of view.

    Asking it to answer as a salesperson, a marketing lead or a finance director changes where it looks from. It does not make it more accurate; it changes the angle.

  6. The conversation before the order.

    If you are not clear about what you want, ask the machine: what is the vision of the task, what would a good result be, how do we get there. Whatever you assert with confidence sets the direction it will take, so it pays to build the plan together before executing it.

Order matters too, and it is not a quirk. In an evaluation published in Transactions of the ACL, model performance was highest when the relevant information sat at the beginning or end of the input, and dropped significantly when it sat in the middle of a long context (Source: Liu et al., "Lost in the Middle", Transactions of the ACL, vol. 12, 2024). What matters goes where it gets read.

Automate, augment, delegate

Not all collaboration is the same, and part of judgement is knowing what kind of work is in front of you.

01 · Automate

One clear rule, many times

Sorting emails, classifying documents, preparing the same report every week. It is defined once and reviewed by sampling.

You define the rule and check it is followed.

02 · Augment

Thinking with a partner

Researching, generating ideas, writing, comparing alternatives, preparing a decision. There is no delegation here: there is joint work, and this is where the biggest leap lies.

You guide each round and decide.

03 · Delegate with autonomy

A whole process, without an order per step

The machine executes with what it has documented. It only works if the process, the criteria and the limits were first put in writing.

You set the limits and review what matters.

More of your presenceMore machine autonomy
Fig. 03Three ways of working with AI. The third builds on what was learnt in the first two.

Some think delegating means choosing what to let go of. First it has to be communicated: AI does not know an internal process nobody gave it. First you describe how it should be, give it all the pieces and review the result: what you would keep, what you would change. That work weighs most in planning; when you scale, it is much easier, provided you separated well what was wrong from what was right. There is no need to watch every step. There is a need to know when to go in deep. How to set those limits so they can be checked is explained in From using AI to directing it.

Judging the result without being an expert

Here comes the most honest objection: if I am not an expert in the subject, how do I know whether what it returns is right? If you know nothing about metal casting, you will not easily judge a technical report on casting. But not everything requires the expert.

Anyone can judge
  • whether it answers the question asked
  • the length and level of detail
  • the format and the style
  • whether the links between ideas are logical
  • whether it followed the rules you gave it
Needs subject knowledge, or a test
  • the technical accuracy of each claim
  • the nuances of the craft that are not in books
  • figures and sources
  • edge cases and exceptions
Fig. 04What can be reviewed without expertise and what cannot. For the second column, the answer is a person who knows or a test built from cases whose correct answer you already know.

Where you do have mastery, your judgement is worth a great deal. An expert cook can push the machine deeper into fermentation than another person would get, and spot at once whether what comes back makes sense. Where you do not, the way out is to build tests: cases already solved, with a known correct answer, to see how the system behaves before trusting it. How to set up that checking loop is explained in How to know your AI is not making things up.

And there is a habit almost nobody has: correcting backwards. When a result does not convince, the usual reaction is to keep correcting in the same conversation, piling up discarded versions. It is better to go back up, change the original request and remove from the conversation what you did not like. There is a technical reason: in an evaluation of 18 models, the reliability of answers grew increasingly erratic as the input grew, even on simple tasks, a phenomenon its authors call context rot (Source: Hong, Troynikov and Huber, "Context Rot", Chroma technical report, 2025). Discarded versions do not disappear: they stay there, taking up the model's attention.

Whoever delivers is accountable

With my teams I am strict on one point. What someone hands me is handed over by that person, not by the AI that helped make it. They must have read it, agree with it, changed what did not work and improved what could be improved. Anyone can make a mistake. What nobody can do is deliver something without reading it, however little they know of the subject: length, detail and whether it settles the question are visible without being an expert.

That rule is not technical, it is cultural, and it is set from the top. It covers what does not show in the result: what data the machine was given, whether it could be given, what consequences follow from what is decided with its help. Responsibility, security and ethics are not delegated along with the task.

Start small

If you want to try all this, do not start by transforming the company. Start with something concrete, even the first version of something you want to achieve, and grow on what works:

  1. Choose a projectConcrete and yours, even a first version.
  2. Define the visionGoals and what a good result would look like.
  3. Gather the piecesDocuments, data, rules, steps.
  4. Discuss the planBefore executing, ask what is missing.
  5. Review the resultWhat you keep and what you change.
  6. Correct upstreamIn the request, not in the tenth answer.
  7. ScaleWhat worked becomes process.
  8. Start againWith a bigger project.

From step 06 you go back to 03 as many times as needed. That is where the learning happens.

Fig. 05The path of a first AI project, from small to large.

Along the way, ideas you did not have at the start will appear, and that is fine. What must not be lost is the vision that set it in motion. If it is lost, the machine keeps producing, but no longer towards where you wanted. It is what we guard most closely when we train the teams we build with: that they learn on their own work, not on someone else's examples, and that the capability stays with them (this is how we approach it; the full path is in our method).

Leave the ego at the door

The hardest part is not technical. It is accepting that a machine does many tasks better and faster than you, and living it not as a threat but as the chance to achieve what you would not have achieved alone. At the same time, not abdicating: the machine will not do your work for you. It will help you do it, sometimes by doing it, but with you guiding, present and aware of what is being built. This article was made that way: the idea, the experience and the judgement are mine; the structure and the wording were worked on with AI, and nothing is published without my having read and accepted it.

The tools will keep changing, and fast. Keeping up is hard, not because change is bad, but because they improve so quickly that there is always something new to learn. But that evolution does not leave behind those who collaborate with it: it carries them along. Each project makes you better at communicating, better at judging and better at deciding what the machine does and what you do.

The question worth asking is not which model your company bought. It is another: do your people ask AI loose questions, or do they work with it? The first answer can be bought. The second has to be built.