AI is your apprentice (almost)

A new contract lands in your inbox. Twenty-two pages, two attachments, a reference to a standard you have never seen. You open your agent, upload the PDF into it and write: go through the contract, check it and summarize it for me. A few seconds later you have an answer. Polite, well organized, full of bullet points and dashes¹. It says the contract governs the delivery of services, that it contains standard confidentiality provisions and that the notice period is three months. At the end the agent asks whether you would like any point elaborated.

You read the answer. You nod. And you have learned nothing new about the contract.

And yet the fault was not in the model.

Who are you actually working with?

An AI agent is not that different from someone who is learning the ropes at your place. It is an apprentice. It tries to complete the task it was given, it wants to please, and when it does not know, it would rather do something than nothing.

Compared to a human it has a few undeniable advantages. It does not get tired². It has read piles of books, even if it sometimes mixes up the pages in them. It never has a bad day and is never embarrassed by a stupid question³.

But it also has disadvantages that are worth naming. It is explicitly trained in flattery – reinforcement learning from human feedback (RLHF⁴) rewards answers the rater likes, not necessarily the true ones.⁵ And when it does not know, it would rather make something up. Not out of malice, but because that is where the way models are evaluated leads it: making something up pays off more than admitting ignorance.⁶ Like at an exam. A blank sheet is a zero and you walk away empty-handed. If I take a guess, at least I have a chance.

Put differently – an agent is not an answer machine. It is an amplifier. It makes a good brief even better. A confused one even worse⁷.

What does a good brief look like?

When you are training a person, you do not tell them “go through this contract for me” and leave for lunch. You tell them what you are looking for, what to watch out for, where to verify information, how they should hand you the result and what they must not do. The same holds for an agent. Every brief should cover four areas:

• Task – what I want the model to do. Read the contract, search through the e-mails, propose a design, translate the manual. A concrete activity, not a vague topic or a suggestion of a possible activity.
• Tools – what it should use for it. Web search, the company glossary, existing translations from the past, the brand book, a specific directory in the repository. When you do not mention a tool, the model will make do with what it remembers. And either it remembers inaccurately, or it simply hallucinates the blind spot into place.
• Output – what the thing I get should look like. Length, structure, the key areas that must be covered, language style, target audience.
• Boundaries – what the model must not do. It must not send an e-mail. It should not flatter me, but be direct. It should not use jargon. It should not make up numbers that are not in the document (and when it does not find them, it should say so).

Try that difference on our contract. Instead of go through the contract for me, rather (though we will do it even better at the end of the article):

I am the supplier. Find every provision in the attached contract that establishes an obligation, a deadline or a penalty for me. For each one give the article number and a verbatim quotation. Draw only on the text of the contract and its attachments. Where it refers to a standard or another document that you do not have available, say so. Do not summarize anything. Highlight five key points I should focus on.

The time you save on the brief, you pay on the review. (And usually with considerable interest.)

Example: Spec-Driven Development

It is best seen in software development, because there the result can be measured by machine.

A practice has taken shape around coding agents that is called spec-driven development.⁸ The idea is almost banal: the main output is not the code, but the brief. First you write down what should happen and how it will be recognized. Only then does anything get done.

An agent whose task is “make the tests pass” has two routes to the goal. Either it fixes the code, or it deletes the test. The second route is shorter. And the described cases look exactly like this: the agent turned a failing test into a skipped one, or just removed the actual test condition from it. Brief fulfilled. Problem still there.

It did not lie. It met the criterion. This is not a failure of the model – the criterion was set badly. Does that not sound familiar? Surely it has already happened to you that you gave a team of people some KPI. Only to find out later that the KPI is being hit splendidly, while at the same time the whole thing does not work, the customers are annoyed and want to go elsewhere.

Our description of the Output must therefore be concrete. Not “write it well”, but “this is how I will know it is done”. The difference between a wish and a criterion lies in whether somebody other than the person who did the task can decide about it.⁹

We set concrete rules that define the boundaries we do not want to cross:

• the tests run through successfully without a single one skipped
• no tag for skipping a test may be added in the changes
• no existing test or test condition may disappear in the changes

With an apprentice you usually do not have to write this down. They know that somebody will check them and that it will be their embarrassment. An agent faces no embarrassment. The prohibitions therefore have to be in the brief.

Do not give up control prematurely

You would not let a person use a saw for the first time without supervision either. You stand behind them, you watch the first cut, and when their hand goes wrong, you say so right away. Not at the fifth plank.

With an agent the temptation is the opposite. It looks competent, it answers fluently, and so one quickly lets go of its hand. Let it work on a rough draft first. Check the output. And give direct, concrete feedback – not “that is not it”, but “this claim has no support in the text, add a citation or throw it out”.

But supervision is not a binary state. It is a spectrum:

• Propose – the model prepares an option, I decide.
• Do it and show me – the model carries it out, but I approve it before use.
• Do it and tell me – the model carries it out and reports to me what it did.
• Do it – the model carries it out and I only ask about the result.

How far I loosen the reins depends on how much the task is a reversible or an irreversible decision . Most things can be taken back – they are two-way doors. A reworded paragraph, an architecture proposal, a draft e-mail. There the agent deserves a free hand. An e-mail sent to a client, deleted data, a database migration that has been run – those are one-way doors. There keep “pressing enter” for yourself.

An apprentice learns. A model does not

A human apprentice remembers things. You tell them once that you never write “hi” to client X, and they still know it a year later. Step by step they stop being an apprentice and become a master. That is the whole point of training someone. A model wakes up every morning with no past¹⁰. On Thursday you explain to it exactly how you format the notes from a meeting. On Friday you will be explaining it again, unless you write that knowledge down and make it available to the agent.

If it is a matter of recurring and more complex activities, it pays to create a so-called skill¹¹. You can write it yourself. Or have the agent write it and then edit it, which tends to be faster.

And there is one extra benefit – when you write a procedure for an agent, you write it for a new colleague as well. Most “skills” are just the documentation you have finally got around to. So really, nothing new again.

It does not get tired? Actually it does

A model does not get tired the way a person does. Its mood and its attention do not get worse after the eighth hour. But with the length of the context¹² its quality reliably drops. The model finds information in the middle of a long input considerably harder than the information at the beginning and at the end.¹³ And the degradation sets in long before you even fill up the context window – a model with a window of two hundred thousand tokens may be losing significantly already at fifty thousand.¹⁴

That is why it is often better to split the work into two interactions (e.g. two chats):

• In the first conversation I work out and refine the brief. The result is a clear brief in the form of a document (that specification / RFC).
• In the second conversation I use the brief to carry out the work.

Not only do we save context, we also avoid the problems where the agent explores again the dead ends we have already been down.

But it is similar with people – has it ever happened to you that someone forwarded you an e-mail thread of thirty e-mails and left it to you to find your way around in it?

Why not ask for a summary?

If you are trying to understand a complex document – a research paper, a contract, a technical proposal – do not ask for a summary.

That does not sound very intuitive, does it? A summary is surely exactly what I need when there is too much text. But a summary makes the text shorter, not more comprehensible. What disappears in it is precisely the thing you opened the document for: an unusual wording, a missing provision, an assumption the author never backs up anywhere. A summary gives you back what was expectable in the document. But you are looking for what is not expectable.

Do not ask for the condensate, ask for the individual fractions. Not “what it is about”, but “what exactly it says, where exactly it says it, and what it does not say”. This is what it looks like for me in practice for contracts and the like:

You are my advisor, not my assistant. I do not want a summary.

TASK
Go through the attached document article by article. I am not
interested in what it is roughly about, nor in superficial
impressions.

List every provision that for me means:
- a payment or other performance (how much, when, for what, how it
  changes),
- an obligation or a commitment,
- a deadline, a time limit or a notice period,
- an exception, an exclusion or a limitation of liability,
- a sanction, a penalty or grounds for withdrawal.

SOURCES
Draw exclusively on the text of the document and its attachments.
Do not add what tends to be usual in such contracts. If the
document refers to a standard, an attachment or another document
that you do not have available, list it as a separate row with the
note "not available to me".

OUTPUT
A table with five columns:
1. Article -- the number and a verbatim quotation of the sentence
   in question.
2. What it means -- in one sentence, in plain language, without
   legalese.
3. Why it is important -- the concrete impact on me, not a general
   lesson.
4. Severity -- high / medium / low according to this key:
   high     = unlimited or hard-to-quantify exposure, or a
              commitment that cannot be got out of,
   medium   = a quantifiable loss that I can bear,
   low      = administrative inconvenience.
5. Question -- what should I ask the other side in order to clarify
   or eliminate the risk?

After the table add two short lists:
A) Wordings that are ambiguous. For each one write two different
   readings that hold up.
B) What is missing from the document that I would expect to be
   there. Only here may you draw on what tends to be usual -- and
   write that you are doing so.

BOUNDARIES
Do not summarize anything and do not shorten anything. A long table
rather than an overview.
Do not judge whether the contract is good. Do not advise me whether
to sign it.
Do not write an introduction or a conclusion.
When you are not sure, write "I am not sure" and why. Do not guess.
Do not try to please me. Write what is disadvantageous for me first.

List B is the only place in the whole brief where the model may draw on what it knows from elsewhere. But it has to admit it.

A summary will not cover for you what is missing from the contract. A good lawyer knows this on their own and provides the information even if you do not ask for it. The model you have to ask about it explicitly.

Responsibility cannot be delegated

Let us return to the contract from the beginning.

Let us say that this time you wrote the brief well. The agent found three contentious provisions, one missing one, and for every claim it gave the article number and the quotation. It did a good job. But the contract will be signed by you.

An apprentice has skin in the game. They have a reputation, a career and colleagues they will have to look in the eye. When they mess something up, it costs them something. It costs the agent nothing. It has nothing to lose, because it has nothing.

That is why we cannot hide behind “well, the AI wrote it”. An agent can help with the work. But it cannot carry the responsibility.

And that’s it

The disappointments with AI that I have seen were mostly not disappointments with the model. They were disappointments with a brief that not even a human could have fulfilled.