AI Basics (Level I)

The one-sentence version

It is an assistant you talk to in writing, which is extremely good at working with language — reading it, rewriting it, summarising it, drafting it — and which has read an enormous amount of text.

Three things it is not

• Not a search engine. A search engine finds documents that exist. This produces text that reads well. Those are different jobs, and confusing them is the source of most bad experiences.
• Not a database. It does not "look up" your customer record. It has no record of anything unless someone put it in front of it.
• Not a person. No memory of you between conversations, no judgement about consequences, no stake in being right.

What that means practically

It is superb at the part of your job that is moving language around — and useless at the part that requires knowing a fact nobody has told it. Almost everything in this course is a consequence of that one split.

The question you actually came with

Is it coming for my job?

The honest answer is that nobody credible knows, and anyone giving you a percentage is making it up. What we can say from watching this thing work:

• It is good at the parts of a job that involve producing text, and bad at the parts that involve knowing what is true, deciding what matters, and being accountable.
• The tasks it does well are usually the ones you least enjoy — the first draft, the summary, the reformatting, the "can you write this up".
• The people getting the most out of it are not the ones who trust it most. They are the ones who know precisely what it is bad at, which is the entire third section of this course.

Treat it as a fast, tireless, slightly unreliable assistant who has read everything and remembers nothing. That framing will serve you better than either the hype or the panic.

The highest-value thing in this course for most people, and the one that pays for itself the first week.

The blunt email

You have written what you actually think:

Mark — this is the third time your team has missed the cutoff. We can't keep
rebuilding the report because someone couldn't be bothered to submit on time.
I need this fixed, not explained again.

Send that and you have a different problem tomorrow. The ask:

Rewrite this so it stays firm about the deadline and the impact, but is something I can send to a peer in another department without it becoming an HR conversation. Keep it short. Do not add pleasantries I did not write.

What comes back:

Hi Mark,

The submission deadline was missed again this month, which meant rebuilding
the report after the cutoff. That's the third time this quarter and it's
costing us most of a day each time.

Can we agree a way to make the deadline stick — either an earlier internal
cutoff on your side or a reminder from us the day before? Happy to do
whichever is easier for your team.

Thanks,

Same message. Same firmness. No incident.

The exec summary

The opposite direction. You have four paragraphs of accurate technical detail, and your director will read the first two lines.

Below is my write-up of the outage. Turn it into three sentences for a director who does not know what a load balancer is: what broke, what the impact on customers was, and what stops it happening again. No jargon. Do not use the word "mitigation".

Why this works so well

You supply all the facts. It supplies the register. There is nothing for it to invent, which removes the main failure mode entirely.

The one check that matters

Read it for meaning drift. Rewriting occasionally softens a commitment into something stronger or weaker than you meant — "we will fix this by Friday" appearing where you wrote "we're looking at it". Read the rewrite as if you were the recipient, and specifically look for promises you did not make.

The limitation you have been working around

Every example so far had you doing the finding. You knew which contract, you went and got it, you opened it, you pasted it.

That is fine when you know where the document is. It is useless for the question you actually have on a Tuesday, which is usually "didn't we agree something about this last year?"

The shift

   ON ITS OWN                         CONNECTED

   +----------------+                 +----------------+
   |   assistant    |                 |   assistant    |
   +----------------+                 +----------------+
          ^                                  ^   |
          |                                  |   | "go and look"
    you paste in                             |   v
    everything it                     +------+----------------+
    needs to know                     |  shared drive         |
                                      |  mailbox              |
   It knows: this chat.               |  wiki / runbooks      |
   Nothing else.                      |  ticket queue         |
                                      +-----------------------+

                                      It knows: this chat, plus
                                      whatever it was connected to.

What it is called

There is a standard way of plugging systems into assistants, called the Model Context Protocol — MCP. You will hear the acronym. That is all it is: an agreed way for a company's systems to be made available to an assistant, so that every tool does not need a bespoke integration.

You do not need to know anything else about it. What matters is what it changes, which is the rest of this section.

The honest framing

Nothing about the assistant gets smarter. It gets better informed, which turns out to matter far more. Every failure mode from section three — invented specifics, not knowing your policy, not knowing today — is a symptom of it having nothing in front of it.

Connecting it is the fix for all of them at once.