![](assets/kapernikov-logo.png)

# Agentic AI for Executives

**Moving your organisation into the agentic era — thoughtfully**

Kapernikov · 24 June 2026 · Pepibru, Anderlecht

---

# Agenda (2 hours)

| # | Section |
|---|---------|
| 1 | Foundations — what an LLM is, why context matters |
| 2 | From chatbots to agents — what they are, where they run, who for |
| 3 | Agents applied — a quick primer (weaknesses, your role, skills) |
| 4 | Risks, best practices, and the EU AI Act |
| 5 | Agents in your organisation — from software dev to every function |
| 6 | Impact on HR — hiring, training, wellbeing |

---

# 1. Foundations

## What an LLM is, and why context matters

---

# An LLM is a next-token predictor

</div>

<!--
TOKEN LOOP (animated — press → to step through it; 3 predict→append cycles):

This is the whole mechanic, before we look inside it.
- The model reads the whole context so far and predicts exactly ONE next token —
  "on" (red = just predicted), below the model.
- That token slides up into the input box, which grows to make room — now "on"
  is just input (plain). The model runs again, predicting "the", then "mat".
- predict → append → repeat is the entire model.
- The rest of this section unpacks how a single prediction actually works
  (attention), then where that ability comes from (training).
- Two things to plant for later:
  * no memory between runs — each step re-reads the whole sequence from scratch
    (pays off in "engineer for the lack of memory").
  * the model can't tell its own past output from the original prompt — once
    appended, a predicted token is just more input.
-->

---

# Step 1 — words become vectors

![w:868 h:328](./assets/ail-88f94262.svg)

</div>

<!--
REHEARSED NARRATION (Frank's live phrasing):
First we translate words into something a model can use. A neural net eats
numbers, not words. So every word becomes a VECTOR — a list of numbers that
encodes its meaning. Each vector has the same WIDTH (same number of slots), but
the NUMBER of words can still vary — width is fixed, count is free. The fixed
width is what lets us stack them into a matrix and do the linear algebra
downstream. (Really it's tokens — units a bit smaller than words — but let's
keep it simple.) We don't hand-design this encoding; it's LEARNED, optimized
end-to-end for whatever yields the best final predictions. Typically that means
words with similar meaning end up with similar vectors — close together. That
map from word to vector is the "embedding."

ATTENTION BUILD — stage 1/5: words become vectors.

The model never sees letters or words directly. Text is first split into TOKENS
(roughly words or word-pieces), and each token is turned into a VECTOR — a
fixed-length list of numbers (a few thousand of them).

Correction worth making out loud for anyone with a classic ML / neural-net
background: the input is NOT a single fixed-length vector for the whole sentence.
It's a variable-length STACK of fixed-width vectors — n tokens, each of width d,
where n changes from prompt to prompt. The model's weights act on the d
dimension and are SHARED across all positions (the same way a CNN kernel is
shared across every pixel). That weight-sharing is exactly why a transformer can
swallow an input of any length without a fixed-size input layer.

At this stage the vectors are "bare": they encode what each word is on its own,
plus WHERE it sits in the sequence (a position signal is added to each vector,
because attention by itself is order-blind — it would otherwise treat the
sentence as an unordered bag of words). No context has been mixed in yet.

This is the raw input. Everything that follows is the model progressively
ENRICHING these vectors until the last one can predict the next word.
-->

---

# Step 2 — one attention head looks

![w:735 h:562](./assets/ail-2372ffed.svg)

</div>

<!--
REHEARSED NARRATION (Frank's live phrasing):
The revolution that brought us today's LLMs is HOW we do this refinement step —
it's called attention. The idea: replace each word's vector (from step 1) with a
NEW vector that encodes not just the word but its context. We build that by
pulling information from the other words — but not all of them equally. We first
work out which words are relevant to the current one, a kind of learned
"matchmaking": highly relevant words contribute a lot, irrelevant ones little or
nothing. Hence "attention." (I won't unpack the query mechanism in detail.)
Reading this grid: each ROW is a word doing the looking; the darker the cell, the
more it pulls from that column's word. Notice the brightest cell in each row is
on the DIAGONAL — a word keeps most of ITSELF and mixes in a bit of context; the
strongest outside pull is the word just before it. And the top-right is empty: a
word predicting what comes next can only look BACKWARD, never at the future.
[DON'T explain the empty triangle unprompted — skip it. ONLY if someone asks why
the top-right is blank: "it only looks at words that already exist — it reads
left to right, one word at a time, like the loop we saw at the start." Don't go
into masking/training; that one callback sentence is enough.]
And what is this first layer probably DOING? Roughly: each word figures out its
local grammatical role from its neighbours — am I the subject, the verb, the
thing being described? That local groundwork is what LATER layers build on to
make the higher-level connections (next slide). [Say "probably/roughly" — this is
an illustrative interpretation, not a proven readout; a real layer has many heads
doing many things at once, and later layers BUILD ON earlier ones, they don't
strictly depend on them finishing first.]

ATTENTION BUILD — stage 2/5: one layer looks (an attention head).

Attention is the mechanism that lets tokens share information with each other.
This grid is ONE attention "head".

How to read it: each ROW is a token doing the looking (the "query"); each COLUMN
is a token being looked at (the "key"). A dark cell means "the row's token pays a
lot of attention to the column's token." Here the columns and rows are the same
six words — every token is simultaneously something that looks and something that
can be looked at.

Why it's a triangle: a token can only attend to itself and the tokens BEFORE it —
it cannot see the future. That's the blank upper-right. Note the bottom row (the
most recent token) is the only fully-populated one — and it's the row that will
end up predicting the next word.

The "attention budget", stated honestly: each row is a softmax, so its weights
sum to exactly 1. Every token has ONE unit of attention to distribute across
everything it can see. THAT is the real basis for the "attention budget" idea —
but it's PER QUERY (per row), not a single global pool that drains as the
conversation grows. The total attention in the grid is actually n (one unit per
row). What bites as context grows is that a given row must spread its one unit
over more competitors, so more of it leaks to distractors; and the cost grows as
n² (n queries × n keys), which is why long context is slow and expensive. If an
exec takes one thing: more context is not free, and not automatically better.

What layer 1 is doing here (stylized): local structure — each word mostly attends
to itself and the word just before it. Early layers tend to handle surface,
local patterns.
-->

---

# Step 3 — a deeper layer resolves meaning

![w:735 h:562](./assets/ail-29bfb246.svg)

</div>

<!--
REHEARSED NARRATION (Frank's live phrasing — go QUICK, this is a light slide):
Same matchmaking as before, but now it reaches across the WHOLE sentence: "it"
looks back and finds "cat." Layer 1 couldn't do that — it only saw its
neighbours. And notice "cat" is quietly picking up baggage: its vector is no
longer just "cat the animal," it's starting to mean "the thing this sentence is
about, the thing 'it' points to." (Don't say "learns" live — say "figures out /
resolves"; the model learned this skill in training, it's just applying it now.)

SIDE REMARK (optional, the grid makes it visible): this grid is words × words.
Add words and it grows in BOTH directions at once — sideways AND down. So double
the words and you don't double the work, you QUADRUPLE it (4× the squares). Say
"4× the ATTENTION work" — not 4× everything; other parts of the model grow only
linearly. But attention is the part that bites as context gets long. One exec
takeaway: more context isn't free, and isn't automatically better.

ATTENTION BUILD — stage 3/5: a deeper layer resolves meaning.

The point that's easy to miss: layer 2 does NOT attend over the original words.
It attends over the ENRICHED vectors that layer 1 produced. What flows upward
between layers is the stack of (increasingly contextual) token vectors — not the
attention grids. Each layer reads the previous layer's vectors and writes
richer ones.

What this head is doing: coreference. The "it" row looks back and binds strongly
to "cat" — the model is working out what "it" refers to. As a result, the
cat-position vector now carries more than the bare word. (The callout tags that
spell this out DEBUT on slide 4 — keep slide 3 clean and just say it verbally so
slide 4's tags land as a reveal.) Watch the vector boxes along the top of each
grid — they deepen layer to layer and accumulate meaning.

The honesty point to say out loud: the LABELS mark WHERE each word entered. A
position stays anchored to the word fed there, which is why we still call it the
"cat" column. But by the upper layers the VECTOR at that position is a CONTEXTUAL
BLEND — it now also encodes "the subject" and "what 'it' refers to" — not the
dictionary word "cat". The address stays fixed; the contents grow. This is the
whole reason stacking layers works: a later layer attending to the "cat" column
pulls in an enriched meaning, not a bare lookup.
-->

---

# Step 4 — the last token gathers the answer

![w:735 h:562](./assets/ail-c6527fc2.svg)

</div>

<!--
REHEARSED NARRATION (Frank's live phrasing):
We keep refining. Here's the next layer. For the example we stop at four layers
with one head each — but they wouldn't be called LARGE language models if that
were all; real ones stack dozens to hundreds of layers, many heads each. Notice
the "it" vector now also carries what "it" really means in this context — and
this happens for EVERY word at once, not just "it". As we go up the layers our
vectors get more refined and more information-dense — same number of slots,
richer contents. (NOT longer — the width is fixed, like slide 1. The diagram
shows it: the vector boxes stay the same size stage to stage, they just get
DARKER. Point at them.)

ATTENTION BUILD — stage 4/5: toward the answer.

Layer 3: the last token, "was", reaches back across the whole sentence and
gathers the subject's state — pulling from the now-"cat / subject"-enriched
positions. Its row is the highlighted one because "was" is the token that will
produce the prediction.

By the top of the stack, the "was" vector encodes enough of the sentence's
meaning to say what comes next.

This layered build-up is the real takeaway for a non-technical audience: the
model is NOT doing surface keyword-matching or autocomplete. It resolves meaning
across the sentence in stages before it commits — early layers handle surface
structure, middle layers build relationships (who is "it"?), the top layer gets
ready to answer. That progression is real even though the clean one-job-per-layer
story is a simplification.
-->

---

# Step 5 — read out the next word

![w:817 h:333](./assets/ail-508d903e.svg)

</div>

<!--
REHEARSED NARRATION (Frank's live phrasing):
After enough layers, the last word has assembled everything it needs to predict
what comes next. Why the LAST word? Because it's the word we're continuing FROM —
the next token goes right after it (back to the opening loop: predict after the
last token, append, repeat) — and by now it has gathered what it needs. We take
that vector and COMPARE it — a dot-product — against our entire vocabulary. That
gives a score per word; softmax turns the scores into PROBABILITIES; then we PICK.
Usually the most likely word. But we don't have to: instead of always taking the
top word we can roll a weighted die over the candidates — that's TEMPERATURE. Low
temperature = almost always the top word (deterministic, safe, can be boring);
high temperature = less-likely words get a real chance (more variety/creativity,
also more risk of nonsense).
[Don't say "training forced everything into the last word" — every position is
trained to predict ITS next token; the last one's just the frontier we read at
generation. Save the "training punishes bad predictions" point for the
Pretraining slide — that's "where the skill comes from," a different question.
And keep them distinct: dot-product = scores; softmax = probabilities; pick/
sample = the choice. Temperature lives in the choice, not in softmax.]

ATTENTION BUILD — stage 5/5: read out the next word.

How the actual next word appears — and it is NOT a magic step. Take the last
token's final vector and compare it against every word in the vocabulary. The
comparison is a DOT-PRODUCT (how aligned are the two vectors?), and a softmax
turns those scores into probabilities. Notice: that's the SAME dot-product-then-
softmax machinery as attention — only now we're matching against the vocabulary
instead of against the context tokens. Attention and the final read-out are the
same trick pointed at different things.

In the picture, "tired" points in nearly the same direction as the "was" final
vector → highest score → it wins. "happy" and "green" point elsewhere → near
zero. Then the model appends "tired" and runs the whole thing again to get the
word after that. That loop — feed all tokens in, predict ONE token, append,
repeat — is all an LLM ever does. (Ties back to the opening point: tokens in,
one token out.)

Caveat to say out loud: this is a deliberately stylized cartoon. One head, three
layers — real models stack DOZENS of heads in each of DOZENS of layers, and
nobody hand-assigns "coreference" to layer 2; the jobs are smeared across many
heads and layers. What IS real: the direction of travel — surface structure →
meaning → commit to a word — and that everything the model does is moving and
matching these vectors.

Executive bridge (optional, into the rest of the deck): this is why "context
engineering" is the whole game. What you put in the context window is the raw
material these vectors are built from. Bloat or junk in the window → diluted
attention and worse predictions out. Managing context is managing quality.
-->

---

# Pretraining: where the knowledge comes from

Trained on a vast slice of human writing — books, code, the web — with one task: **predict the next token**.

To predict well, it had to absorb facts, grammar, reasoning, style. **Knowledge is a side-effect of getting good at that game.**

The catch: that knowledge is **frozen** at training time. No live memory, nothing past its cutoff — unless you put it in the context.

<!--
BRIDGE FROM THE ATTENTION CHAPTER (say this to open the slide):
On the last slide we saw the model gather what it needs and predict the next
word. But why is it any GOOD at that — why does it gather the RIGHT information?
That's what this slide answers. During training the model made billions of
next-word predictions; every bad one was punished and its weights nudged. Get
good at "predict the next word" over a vast slice of human writing, and knowledge,
grammar and reasoning fall out as a side-effect. THAT is where the skill we just
watched comes from.

PRETRAINING (detailed — trim for delivery):
- Picture reading most of the library and getting very good at "what word comes
  next." You can't do that well without absorbing how the world, language and
  code actually work — so knowledge falls out of the prediction task for free.
- This is the expensive stage: months of compute over enormous text corpora. It
  yields a "base model" — knowledgeable but not yet helpful (that's the next slide).
- Frozen weights: the model doesn't learn from your conversation, doesn't
  remember you between sessions, and has a knowledge cutoff. Anything newer or
  private must be supplied in the context window (ties to context engineering).
- Exec takeaway: the model's knowledge is real but static and generic. Your
  proprietary, current or confidential information is NOT in there — you provide it.
-->

---

# Fine-tuning: from knowledge to instrument

A raw next-token predictor just **continues** text — it rambles, imitates, doesn't reliably *help*.

A second, much smaller stage trains it on **human feedback**: follow instructions, be useful, stay on task, refuse harmful requests.

**Pretraining builds the knowledge; fine-tuning turns it into a useful instrument.**

Watch the side-effect: it's trained to be *agreeable* — it rarely says "I don't know," and will give confident, plausible-but-wrong answers.

---

# 2. From chatbots to agents

## What an agent actually is

---

# How a chatbot talks to an LLM

</div>

---

# Three roles, one system

![w:760 h:410](./assets/ail-5331345f.svg)

</div>

<!--
THE METAPHOR (say it as the picture assembles):
You don't ride bareback. Three things have to come together.
- The HORSE is the LLM: raw power. Strong, fast — but on its own it doesn't
  know where to go.
- The SADDLE and reins are the AGENT: the harness. Tools, memory, a loop, and
  reins to steer. It's what turns a powerful-but-undirected animal into
  something you can actually ride.
- The RIDER is the HUMAN: sets the destination, stays in the saddle,
  course-corrects.
The point: you don't control the LLM directly — you control it THROUGH the
agent. Human -> agent -> LLM. That layering is what the next slide unpacks.

CAVEAT (only if someone pushes): the saddle looks passive, but the agent is
ACTIVE — it runs the loop, calls tools, decides. The reins carry the "steering"
idea; the next slide shows it actually looping. Don't oversell the agent as
mere equipment.
-->

---

# The Agentic Loop

</div>

---

# Vocabulary you'll keep hearing

<div style="display:flex; flex-wrap:wrap; gap:18px 34px; justify-content:center; align-items:baseline; max-width:1060px; margin:40px auto 0; line-height:1.0">
<span style="font-size:2.6em; font-weight:800; color:#c0392b">context</span>
<span style="font-size:2.4em; font-weight:800">token</span>
<span style="font-size:1.95em; font-weight:700; color:#2c7a8c">context window</span>
<span style="font-size:1.8em; font-weight:700">attention</span>
<span style="font-size:1.5em; font-weight:600; color:#c0392b">context engineering</span>
<span style="font-size:1.6em; font-weight:600">hallucination</span>
<span style="font-size:1.4em; font-weight:600">prompt</span>
<span style="font-size:1.35em; font-weight:700; color:#2c7a8c">kv cache</span>
<span style="font-size:1.3em; color:#2c7a8c">time to first token</span>
<span style="font-size:1.1em; color:#6b7378">temperature</span>
<span style="font-size:1.05em; color:#6b7378">next-token prediction</span>
<span style="font-size:1.0em; color:#2c7a8c">context rot</span>
<span style="font-size:0.95em; color:#6b7378">embedding</span>
<span style="font-size:0.95em; color:#2c7a8c">context dilution</span>
<span style="font-size:0.9em; color:#6b7378">system prompt</span>
</div>

---

# 3. Agents applied — a quick primer

## Where the agent stops, and you begin

---

# An agent's weaknesses are your job description

An AI agent writes code at a very high speed in any technology you want. But it has some weaknesses:

* **Limited memory** — doesn't learn from past failures, limited context window
* **Notoriously bad at judging** — is this good enough? Are we optimizing what should not exist?
* **Doesn't identify structural issues** — an agent is always happy and never says "I can't continue working this way"
* **Doesn't see patterns over time** — an agent is really a text factory

> Key to successful agent usage is taking these limits into account

---

# Know your role

| Human (long-term memory) | | Agent (fast executor) |
|--------------------------|:-:|----------------------|
| Remembers past failures | → | Implements safeguards |
| Identifies friction | → | Builds tooling |
| Updates instructions and feedback | → | Follows best practices |
| Spots patterns | → | Writes tests to catch them |

**The asymmetry:**
- **Agent:** fast execution, cheap implementation, no memory across sessions
- **Human:** slow execution, but remembers patterns and failures over time

---

# Skills: the company wiki, not a memorised handbook

Skills are reusable playbooks the agent loads **on demand**:

![h:400](./assets/mermaid-d982846d.svg)

</div>

<!--
SKILLS (sequence diagram from the dev deck; text moved here to keep the slide light).
Talk track — the wiki/print analogy Frank wants, say it slowly:

The agent's context is its working memory — and it's finite. Cram everything in
"just in case" and quality drops: it loses the thread, weighs trivia equally with
what matters. Everything important = nothing important. So good agents keep context
LEAN — they pull in knowledge on demand, not all upfront.

A new hire doesn't memorise the whole company wiki on day one. When they need to
print, they look up "how do I print here?" — right then, and only then. A skill is
exactly that for an agent: a small, named playbook — "how we deploy," "how we write
a tender" — that the agent recognises and loads the moment a task calls for it. A
huge library of know-how, at almost no cost to its attention until it's needed.

Forward hook: this is the primitive that makes agents practical at scale — the same
lean-context discipline you'll apply when you roll them out across the org (§5).
Progressive disclosure (only if asked): name+description always resident, body loads
on trigger, references load only when reached.
-->

---

# Sub-agents

Sub-agents provide **context isolation**:

![h:420](./assets/mermaid-f346a29e.svg)

</div>

---

# MCP: API made discoverable

![h:420](./assets/mermaid-a4aaebb3.svg)

</div>

<p class="ref">one standard, many tools — the "USB-C of agents". The flip side: whatever a connector exposes, the agent can reach — a permission you grant deliberately (§4)</p>

---

# 4. Risks, best practices, EU AI Act

---

# What can actually go wrong

Not rogue AI. **Good intentions + too much access + mistakes** — plus one new twist: hijack.

| Risk | What it looks like |
|---|---|
| **Data & IP leakage** | an over-eager agent commits secrets to the repo, or sends source / customer data to an outside model |
| **Prompt injection** | hostile content the agent reads hijacks it into leaking or acting *(next slide)* |
| **Supply chain** | the agent pulls in a malicious or typo-squatted dependency |
| **Destructive mistakes** | a good-faith agent with too much access breaks or deletes the wrong thing |
| **Unreviewed output** | hallucinated facts or insecure code shipped because nobody checked |

**Treat the agent like a capable junior — not malicious, but don't hand it root.**

---

# Prompt injection: the lethal trifecta

*Why* it's possible at all — and *when* it actually harms:

![w:520 h:245](./assets/ail-9a49cb61.svg)

</div>

**Break any one leg (least privilege, human approval) and it's defanged.** <span class="ref">"lethal trifecta" — Simon Willison, 2025</span>

<!--
The lethal trifecta (Simon Willison): an injection only causes HARM when all three
legs are present — the agent reads untrusted content, has privileged access (to
systems OR data; your prod cluster counts even with no personal data in it), AND
can act / reach out. Remove any one leg → defanged. So it's an ARCHITECTURE
problem, not "is the model immune".

ROOT CAUSE (left box) — why injection is possible AT ALL: LLMs have no
control-plane/data-plane separation (unlike e.g. parameterised SQL, where the
query is separate from the data). The system prompt, the user's input, tool
output and retrieved documents ALL arrive as one undifferentiated token stream,
so the model can't reliably tell an instruction-to-follow from data-to-read.
That's why it can't be fully patched away. The Venn (right) is then WHEN that
possibility turns into actual harm.

Honesty (matches Frank's hands-on test — he hid reworded instructions in documents,
had Claude read them, they never fired): blatant overrides bounce off frontier
models now; what survives is the SUBTLE, task-aligned kind (the curl|bash "fix").
Don't oversell injection — rank it honestly: an over-broad git commit leaks secrets
far more often than a clever injection.

The curl|bash example is BOTH categories at once — delivery is task-aligned indirect
injection, payload is supply-chain/RCE. Taxonomy blurs; control doesn't: it only bit
because the agent could EXECUTE untrusted code unattended. Live guardrails (a shell
command needs the user's permission; the model is wary of curl|bash) ARE the
least-privilege + human-gate controls — turning them off (YOLO / auto-approve) is
the real vulnerability.
-->

---

# Containing it

| Lever | What it means |
|---|---|
| **Least privilege** | the agent gets only the data & tools its task needs — not prod secrets, not root |
| **Review the artifacts** | check what it *produced* — the output, the diff — not the permission prompts |
| **Sandboxed, sanctioned tools** | provisioned business-tier tools; embedded in-app agents for non-coders; containerised runtimes for devs |
| **Human on consequential calls** | a person owns anything with legal or material effect (ties to the AI Act & GDPR) |

**Your real security boundary is the output you review — not the checkbox you click.**

<!--
The mitigation companion. Key insight from the dev deck, generalised: per-action
permission prompts give a FALSE sense of control — time-of-check ≠ time-of-use
(approve "run make" + approve "edit Makefile" = arbitrary code execution). No one
reads the bash prompt anyway. So move the security boundary to the ARTIFACTS the
agent produces (the diff, the output you'd review like a junior's PR), not the
side effects you rubber-stamp mid-run.

- Least privilege: scope data + tools to the task (RBAC, tenant/row scoping). The
  single highest-leverage control — it shrinks the blast radius of every other risk.
- Sandboxed/sanctioned tools: this is also the shadow-AI fix — give people a good
  provisioned tool so they don't reach for personal free accounts. For non-coders,
  the in-app EMBEDDED agent is the safer path: the sandbox is the app's own
  permissions & data boundaries, not trust in a CLI prompt.
- Prompt injection defence: break the lethal trifecta — don't combine untrusted
  input + sensitive data + ability to act, all unattended.
- Human oversight on consequential actions joins this up with §3 legal (Art. 14 /
  GDPR Art. 22).
Don't claim "secure" — claim "contained": least privilege + review the output.
-->

---

# The legislation: when, where, who

**The text** — Regulation (EU) 2024/1689, the world's first comprehensive AI law. Binding as written in all 27 EU states — no national transposition. Full text & 13 annexes live on EUR-Lex.

**Who it binds** — every actor in the EU & EEA. And, like GDPR, anyone *outside* the EU who places AI on the EU market or whose **output is used in the EU** — a Swiss or US firm is caught the same way.

| When | What kicks in |
|---|---|
| 1 Aug 2024 | entered into force |
| since Feb 2025 | the bans + the AI-literacy duty |
| 2 Aug 2026 | transparency duties |
| Dec 2027 / Aug 2028 | high-risk rules — *deferred (Digital Omnibus, provisional)* |

<p class="ref">Regulation (EU) 2024/1689 — authoritative text on EUR-Lex (CELEX 32024R1689)</p>

---

# EU AI Act: risk-driven regulation

It regulates AI by **risk**, not by technology — the higher the risk, the more you must do.

| Risk level | Examples | Your obligation |
|---|---|---|
| **Unacceptable** | social scoring, manipulation, emotion-tracking at work | **banned outright** |
| **High** | hiring & HR, credit, education, medical, critical infrastructure | strict: human oversight, logging, data governance, conformity |
| **Limited** | a bot your *customers* talk to; AI content you *publish* (deepfakes, public-facing text) | tell people it's AI |
| **Minimal** | AI as your *own* tool — chatting, drafting, generating your own work | no obligations |

**Most work lands in Minimal.** The label duties hit only narrow cases — a bot posing as human, a deepfake, or AI-written publications with no human editor.

<!--
The one mental model execs need: the Act tiers AI by RISK, and obligations scale
with the tier — it is NOT a blanket "AI is regulated" regime.

Four tiers:
- Unacceptable → prohibited (already in force since Feb 2025): social scoring,
  manipulative/ subliminal techniques, untargeted face-scraping, emotion
  recognition in workplace & education, most real-time biometric ID.
- High-risk (Annex III) → the heavy column: employment/HR screening, credit,
  education, medical devices, critical infrastructure, biometric ID. Duties:
  risk management, data governance, logging, human oversight, conformity
  assessment, registration.
- Limited → transparency only (Art. 50): tell people they're talking to AI;
  label AI-generated/manipulated content (deepfakes). Applies 2 Aug 2026.
- Minimal → no obligations. Most office-productivity use lands here.

Timeline as of mid-2026:
- In force: prohibitions + AI-literacy duty (Art. 4) since Feb 2025; GPAI model
  obligations since Aug 2025.
- 2 Aug 2026: transparency obligations (Art. 50).
- High-risk obligations were due 2 Aug 2026, but the Digital Omnibus (Nov 2025;
  Council+Parliament provisional deal 7 May 2026) defers them to 2 Dec 2027
  (stand-alone) and 2 Aug 2028 (embedded in products). NOT yet formally adopted —
  if it isn't adopted before 2 Aug 2026, the original date applies. Flag this as
  "moving target, but the direction is more time, not less."

Don't read the table aloud — point: "find your use case's row, that's your duty."
(Refs: artificialintelligenceact.eu high-level summary; EC digital-strategy FAQ.)
-->

---

# Does your AI content need a label?

| What you put out | Label it? |
|---|---|
| image / audio / video that resembles a **real** person or event & looks authentic | **yes** — disclose it's AI |
| text published to inform the public on **matters of public interest** | **yes** — unless a human editor is accountable |
| a decorative or clearly *illustrative* image (invented people) | no — light touch at most |
| AI used as your *own* working tool | **no** — *if you're the final reviewer and accountable* |

**"Matters of public interest" is narrow** — journalism, public affairs, even a listed company's market-moving statements; *not* internal docs or a deck like this one.

<p class="ref">the Act makes you label AI — it doesn't make AI true; falsity lives in other law (DSA, defamation, GDPR)</p>

<!--
THE LIVE MOMENT. Run the test on the deck itself.
- The deep-fake definition (Art. 3(60)): AI image/audio/video that (a) resembles
  existing persons/objects/places/events AND (b) would falsely appear authentic
  or truthful. Both prongs needed.
- Walk the cover/hinge image (slide 14) through it: invented people, not a real
  identifiable person; not a depiction of a real event; plainly decorative. Fails
  prong (a)/(b) → not a deep fake → no Art. 50(4) disclosure duty. Belt and braces:
  even if borderline, it's the artistic/illustrative carve-out (light disclosure);
  and the transparency duties don't apply until 2 Aug 2026 anyway.
- The provider machine-readable MARKING duty (Art. 50(2)) is on the image tool's
  maker, not on you.
- Zoom out to the WHOLE deck (the strong beat): it's AI-assisted and it faces an
  audience — yet it owes no label. A human authors, reviews and presents every
  slide (editorial ownership → the text carve-out), it isn't public-interest
  journalism, and the images depict invented people, not real ones. "Facing
  people" was never the test; a human standing behind the content is.

Honesty caveats to say out loud:
- This is a brand-new, largely untested law — first CJEU reference only pending
  (C-806/24). Final interpreter is the CJEU; Commission/AI-Office guidelines are
  influential but not binding. The Commission's May-2026 draft guidance says the
  test does NOT turn on your intention to deceive but on audience perception — so
  "I didn't mean to fool anyone" is not the legal test.
- The veracity gap: the Act governs PROVENANCE (is it AI, is it labeled), not
  TRUTH. Hallucinations & fake news fall to other regimes. That's the deeper point.
- Asymmetry: images owe a label whenever they're a deep fake (broad); text only
  when published on public-interest matters without human editorial review (narrow).
- I'm not a lawyer; fine for training, not a legal opinion for a real dispute.
-->

---

# Organisational impact

| Level | What you do |
|---|---|
| **Must** *(the law)* | train staff in AI (literacy, in force now) · disclose user-facing AI · never run a prohibited use case · **+ if a use case is high-risk:** impact assessment & notify, 6-month logs, human oversight, registration |
| **Should** *(govern)* | keep an **inventory** of AI in use · **risk-classify** each use case · an acceptable-use policy (your shadow-AI lever) · an incident path |
| **May** *(optional)* | adopt a voluntary code of conduct · name an AI owner — none is mandated · go beyond the minimum to earn trust |

**Most of "Should" is your existing GDPR + InfoSec governance. The real job is inventory + classification — the duties just follow from the tier.**

<p class="ref">Art. 4 (literacy) · Art. 50 (transparency) · Art. 5 (prohibited) · Arts. 26–27, 49 (high-risk deployer) · Art. 95 (voluntary codes)</p>

<!--
The org-level companion to the "as a knowledge worker" thread. Framed must/should/may.

MUST — unconditional, lands on (almost) every deployer:
- Art. 4 AI literacy — staff who use/oversee AI must be trained. Enforceable since
  2 Feb 2025. Satisfied by a documented programme, NOT a filing.
- Art. 50 transparency — disclose user-facing AI / label the narrow deepfake &
  public-interest-text cases.
- Art. 5 — never deploy a prohibited practice (kill-switch).
- CONDITIONAL must (only if an Annex III use case → high-risk): Art. 27 FRIA +
  notify the authority (public bodies, public-service providers, credit/insurance);
  Art. 26 keep logs >=6 months, assign human oversight, monitor, consult worker
  reps (26(8)); Art. 49 register (public authorities). + GDPR Art. 35 DPIA in
  parallel. Build/brand a high-risk system → you're a PROVIDER (tech docs, QMS,
  conformity, CE, post-market, incident reporting — the full load).

SHOULD — not mandated at limited risk, but the sensible response AND the
prerequisite to knowing your obligations: an AI inventory, a per-use-case risk
classification, an acceptable-use policy (the shadow-AI control), an incident path.
Most of it reuses existing GDPR + InfoSec governance — not a new bureaucracy.

MAY — genuinely optional: Art. 95 voluntary codes of conduct (apply high-risk-style
rigour to non-high-risk systems); naming an AI lead (there is NO mandatory "AI
officer", unlike GDPR's DPO); exceeding the minimum as a trust play.

Board hooks:
- Myth-buster: at LIMITED risk there is essentially NO mandated AI-Act paperwork —
  no published risk analysis, no registration. The mountain only appears at high risk.
- Penalties scale with the breach: up to EUR 35M / 7% turnover (prohibited),
  EUR 15M / 3% (most breaches), EUR 7.5M / 1.5% (wrong info to authorities).
- This is also where §4's "foundation work" pays off: inventory, logging, oversight
  are the same plumbing — and §3's shadow-AI risk is the reason you need the policy.
(Untested law; not legal advice — pair with DPO/counsel for high-risk.)
-->

---

# There's still the GDPR

| GDPR *(in force since 2018)* | What it means for your agent |
|---|---|
| **Lawful basis & minimisation** | the agent may only touch personal data it needs, for a stated purpose |
| **International transfers** *(Art. 44)* | a prompt can send personal data abroad — a **business-tier DPA** (SCCs / DPF) covers the transfer; consumer & free tiers don't |
| **Automated decisions** *(Art. 22)* | a human must own decisions that **legally or significantly affect a person** (hiring, credit) — not the agent's routine tool choices |
| **Storage limitation & erasure** | transcripts and agent memory are personal data — retention limits, honour deletion |
| **Processor agreement** *(Art. 28)* | sign a DPA with your model vendor — they process your data on your behalf |

<!--
The companion to "Organisational impact": the MUST items that aren't AI-Act-specific
at all — they're GDPR, which has applied since 2018 and bites the moment an agent
touches personal data. Reinforces the earlier finding that much of the fullstack-sota
"compliance kit" is GDPR + security mislabeled as AI Act.

Per row (agentic translation):
- Lawful basis & minimisation (Art. 5/6): the agent needs a legal basis to process,
  and least-privilege access — only the data the task needs. Maps to RLS/tenant scoping.
- International transfers (Art. 44+): the big one for US LLM APIs. A prompt containing
  personal data leaving the EEA is a transfer — needs adequacy/SCCs or an EU-region/
  EU-hosted model. This is usually the real blocker, not the AI Act.
- Automated decisions (Art. 22): the right not to be subject to a SOLELY automated
  decision with legal/significant effect. An autonomous agent making consequential
  calls hits this → human-in-the-loop + the right to contest. Also why mutating-tool
  consent matters.
- Storage limitation & erasure (Art. 5(1)(e), 17): chat transcripts + agent memory are
  personal data → retention limits and the ability to honour deletion requests.
- Processor agreement (Art. 28): the model vendor is your processor → DPA + sub-processor
  chain. Plus security (Art. 32) and a DPIA (Art. 35) where processing is high-risk.

Takeaway: don't let the shiny new AI Act distract from the law that already applies.
For an agent touching personal data, GDPR is usually the heavier, more immediate duty.
(Not legal advice; pair with your DPO.)
-->

---

# 5. Agents in your organisation

## from software development to every function

---

## AI for software development

---

# Working with AI is a trainable skill

![w:1180 h:354](./assets/ail-65f799c3.svg)

</div>

---

# The platform — and the team that owns it

![w:1180 h:533](./assets/ail-b01c9583.svg)

</div>

---

# Make review easy again

Agents make code cheap — so **review becomes the bottleneck**. Automate the net: review gets easy again (humans glance, machines check), and every stage hands the agent a **signal to self-correct**.

![w:900](./assets/ail-106d255a.svg)

</div>

<p class="ref">our batteries-included starter kit (fullstack-sota): review apps · security & dependency scanning · e2e tests · error tracking · daily perf benchmarks — the net is there from commit 1</p>

---

## Does it pay, and scale?

---

# Even a "modest" 20% is serious money

![w:780 h:406](./assets/metr-uplift-update.png)

<!--
THE UPSIDE BEAT (deliberately optimistic — §4 supplies the honest counter; this
slide also answers the reviewer's note that a measurement beat should come early).
Updated METR (Feb 2026 "uplift update"): the original headline "−19% slowdown"
came from a setup that's genuinely hard to measure; the follow-up RCT shows
speed-ups (~+18% repeat participants, ~+4% newcomers) and METR believes the true
number is biased downward. So land on a conservative ~20%, not the scary −19%.

The €: ~20% of a knowledge worker's loaded cost × the whole headcount is a very
large number — have them do the arithmetic for their own org. And it's PER
PERSON — the bridge to the next slide: 20% is huge for developers, but developers
are the minority, so the real prize is org-wide.

Honest caveat (forward-ref §4/§4): a task-level ~20% is the POTENTIAL; capturing
it firm-wide is the rollout/adoption story (§4) and the measurement reality (§4).
Sell the upside here; keep the firm-level honesty for later.
-->

---

# Productivity gains?

> Only ~10% of companies report a measurable productivity gain from AI so far — *NBER "Firm Data on AI," 2026 (≈6,000 executives)*

![w:912 h:420](./assets/ail-0f8d383f.svg)

</div>

<!--
The productivity J-curve. A general-purpose technology SUPPRESSES measured
productivity at first, because the complementary work — process redesign,
retraining, reorganisation — is expensed before any payoff appears.
The dip = you pay first; the harvest = the gains compound later.

The gap between "what's promised" (a straight climb) and the actual curve right
now is where the skeptical headlines come from — MIT's "95% no P&L impact" and
METR's "−19%" are measurements taken IN THE DIP.

The tagline stat: a ~6,000-firm survey across four advanced economies (NBER WP
34836, "Firm Data on AI", 2026) found ~70% of firms now use AI but ~90% report
NO measurable impact on productivity or employment "so far" — yet those same
firms predict AI will lift their productivity ~1.4% over the next three years.
That "nothing yet, but a boom is coming" is the J-curve in firms' own words.

We're roughly at the inflection in early 2026 — Brynjolfsson argues the harvest
is just beginning (US productivity ~2.7% in 2025, ~2× the decade average).

It's the normal pattern, not an AI failure: electricity took ~30 years
(1882 → visible aggregate impact), the PC over a decade.
(Brynjolfsson–Rock–Syverson 2021; David 1990; ILO Aggregation Paradox 2026.)

Takeaway: measure the WORKFLOW CHANGE, not the tool — and start the unglamorous
foundation work early, because that's the slow part and therefore the moat.
-->

---

![](assets/excavators.png)

---

# From a local win to a company-wide gain

The International Labour Organization identified the conditions for local wins to translate into organisation-wide gains. The three a firm controls:

| ILO condition | Your move |
|---|---|
| **Adoption breadth** | get the agent into **every team**, not one |
| **Complementary human capital** | **train people** to use, adapt and supervise it |
| **Complementary intangible investment** | **redesign the workflow + fix the data** — the slow, expensive part |

**The personal win:** tasks run **10–70%** faster. **The organisational win:** ~**4 in 5** firms that adopt AI report *no* measurable productivity gain — yet.

<p class="ref">Chan & Shedania (2026), <em>The Aggregation Paradox of AI</em>, ILO Research Brief — Table 2 (three of eight conditions, at firm level); task gains 10–70%; ~4 in 5 adopters report no measurable gain (Yotzov 2026)</p>

<!--
§4 REBUILD, slide 2 of 3 — the honest table. FIXES the review finding that the
old slide was a generic data-governance / MDM checklist ("could've been my
data-governance talk") AND that it had INVENTED a "Leadership" row + flattened
the real Table 2.

DESIGN (settled with Frank): the brief's Table 2 ("Conditions for Translating
Micro-Level Gains to MACROECONOMIC Impact", 8 rows) is a one-firm→all-firms
ECONOMY-level translation. The excavator story is the SAME shape one level down
(one team→all teams inside a company). So we MINIMALLY translate Table 2 to the
firm level — and only the rows that survive the level-shift stay:
  KEEP (firm actions): Adoption breadth · Complementary human capital ·
    Complementary intangible investment.
  DROP (don't translate to "your teams"):
    - Measurement adequacy — real, but not Frank's priority here.
    - Competitive dynamics, Labour-market adjustment, Regulatory environment —
      economy-only weather a firm can't pull.
    - Digital & physical infrastructure — partly firm-actionable but its
      data-infra half is already inside "intangible investment", and the rest
      (broadband, compute capacity, energy) is macro → redundant, dropped.
Left column = the ILO term (shows it's faithful, not invented); right column =
the firm's move, in the excavator frame. Maps to spread · train · rebuild.

Talk track / support (from executive/ilo-aggregation-paradox-summary.md):
- The "real money, not a fail, just a blip" point has a hard number now: Yotzov
  et al. 2026 (~6,000 execs) — ~FOUR-FIFTHS report NO measurable productivity
  gains despite adopting; Aldasoro 2026a (EIB, >12k firms) — AI raises labour
  productivity ~4% on avg but CONCENTRATED in medium/large firms.
- On-message ILO quote: gains "depend less on the capabilities of frontier AI
  developers and more on whether firms … can integrate AI into workflows,
  upgrade skills and redesign jobs."
Full faithful summary: executive/ilo-aggregation-paradox-summary.md.
-->

---

# Which approach fits you?

![w:900](./assets/ail-d31d8050.svg)

</div>

---

<h1 style="color:#ffffff; text-align:center; width:100%; text-shadow:0 2px 14px rgba(0,0,0,0.55)">Beyond the development team</h1>

<!--
AXIS 2 — audience — opens §4 and is its hinge. Standalone on purpose: one
phrase, let it land. Pivot from §2's dev-flavoured examples.

Say the substance out loud (it's deliberately off the slide):
- In most organizations, engineers are a small fraction of the headcount —
  insert your own org's number if you have it (engineering % of total).
- The agentic-productivity question is org-wide, not developer throughput.
- The pivot: stop asking "how much faster are my developers?" and start asking
  "where else in the org does this same loop apply?"
- BALANCE (important): look beyond code, but don't *ignore* code. Engineering is
  one column of the grid, not a column to discount — the coding win is real, it's
  just not the whole story. "Beyond, not instead of."
-->

---

# Where the value actually lives

![w:1180 h:504](./assets/ail-c16aac52.svg)

</div>

<!--
Two ways to point an agent, and both apply in EVERY function (Legal, Ops, Sales,
Analysts, Product, Support, Finance, HR — most knowledge work, not code):

- CUT COSTS — do today's work cheaper. Genuinely useful, not trivial.
- DIFFERENTIATE — do it better, or do what others can't. The edge isn't the
  model (everyone runs the same agent — like everyone has Word); it's how you
  apply it to YOUR data, craft and people, and that compounds.

Why prioritise differentiation even though cost-cutting is worth doing: the
downside of being late is asymmetric. Late to cut costs = you're a bit less
efficient (recoverable). Late to differentiate = a rival redefines the offer
and your efficient version of the old thing stops mattering (you can't undo
that). Hence the tagline: be late to differentiate, and the cost savings stop
mattering.

Sets up the stories below: tenders = the cost-only trap (cheap scale floods,
fit drops); 1-2-1 prep = the reframe to a people-business edge.
-->

---

# Success story: prepping our 1-2-1s

**"Prepare me for my 1-2-1 with [name]."** The agent assembles the brief on its own:

- Pulls the calendar event and the shared 1-2-1 doc — what they wrote for today
- Reads their people file + the last few 1-2-1s, surfacing **patterns**: recurring themes, mood, open action items
- Scans recent Slack and email involving them
- Hands back one page: talking points, things to probe, what's still open

> Walk in prepared in 30 seconds instead of 20 minutes — and nothing from last time slips through.

---

# 1-2-1 prep: the legal catch

That briefing is **employee personal data** — mood, performance, Slack, email. Two regimes bite:

**GDPR** — needs a lawful basis (legitimate interest, *not* consent — power imbalance); tell staff; minimise; wellbeing notes are special-category; do a DPIA; a data-processing agreement with the model vendor, and **no training on the data**.

**EU AI Act** *(high-risk rules from 2 Aug 2026)* — "monitoring and evaluating worker performance" is **high-risk** (Annex III §4). 1-2-1 prep sits right on that line; cross it and you owe human oversight, logging, a FRIA, and **informing staff + reps first**.

> Keep it **decision-support, human in the loop**. The moment it *evaluates people*, the high-risk regime kicks in.

---

# Success story: submitting public tenders

Public tenders are **text-heavy and tightly specified** — exactly what LLMs are good at. An agent parses the spec, matches it to our profiles, and drafts the submission. Cheap, fast, scalable.

**The catch — feedback from Infrabel:**

> *We now get huge numbers of applicants, dirt cheap — but in the interview the person barely knows why they're there.*

- Cheap scale floods the channel; **genuine fit drops**
- The human gets disconnected from the AI-written application
- **Lesson:** automate the drafting, keep a human accountable for *fit* — quality, not volume, is the moat

---

# Treat your people as creative individuals

| Don't | Do |
|---|---|
| one project for one use case — the "request-holiday bot", or a chatbot that just searches your documents | **your agent is multipurpose** — not made to only execute one predefined task |
| hard-wire AI into a single fixed workflow | **let people improve and invent their own workflows** |
| assume the tool does the thinking | **train them in agentic workflows, skills & tools** |

> Your workforce is creative. Give them a tool they can shape — and the skills to shape it — not a box that does one thing.

<p class="ref">shadow-AI surveys (2026): ~90% pick general-purpose frontier tools; single-purpose enterprise builds get dropped for them</p>

<!--
Frank's strong team opinion — holds regardless of which infra you choose (§4).
The failure mode isn't just "unchanged workflow"; it's spending a whole project
to narrow a GENERAL-purpose technology down to ONE use case (the holiday-request
bot, the glorified RAG bolted onto Teams). That throws away the "G" — the value
of a GPT is its breadth.

Grounding:
- Shadow AI: ~90% of people reach for general-purpose frontier tools on their
  own; a lawyer dropped a $50K single-purpose enterprise tool because ChatGPT's
  output was better. People route around the narrow bought tool. (refs #31-32)
- ILO: scaling needs "system-level redesign", "not merely substitution of AI
  for human effort at isolated task nodes" (Agrawal/Gans/Goldfarb). (#35)
- Training is the enabler: people can only be creative with agentic workflows if
  they're taught the skills/tools — this is the human-capital row of the prior
  slide, made concrete. Ties straight to §4 ("Teaching your agent").
Takeaway: buy/build for breadth, train people to wield it, let workflows emerge.
-->

---

# The judgement burden

</div>

---

## Where agents run

---

# On a developer's laptop — everything local except the model

![w:1000 h:540](./assets/ail-9ee84a1c.svg)

</div>

---

# In the cloud — only the GUI is on your side

![w:1000 h:540](./assets/ail-f429b5ca.svg)

</div>

---

# Embedded in your product — the human is your customer

![w:1000 h:540](./assets/ail-336c2098.svg)

</div>

---

# The deployment landscape

| | **Developers** | **Everyone else** |
|---|---|---|
| **On a machine** | Claude Code, Cursor | Cowork, OpenClaw |
| **In the cloud** | Codex cloud, Copilot agent | Copilot Studio, Bedrock |
| **Inside an app** | dev copilots | `fullstack-sota`, in-app assistants |

**Developers are one column — most of your people are in the other.**

<!--
Architecture (rows) × audience (columns) — the space you actually deploy into.
Walk one cell per row so they see it's populated everywhere, then the nudge:
don't only buy the developer-tools column.

WHEN EACH FITS (narrate / future per-row detail):
- On a machine — interactive, individual: devs (coding agents), power users (desktop agents).
- In the cloud — delegated / IT-governed: cloud coding agents, citizen-dev platforms (Copilot Studio, Bedrock).
- Inside an app — embedded in a product you ship; safest path for non-technical staff & customers.
Adoption-strategy question ("who gets which tool, with what guardrails") lives
here and leads into the rollout slides (subscription ≠ strategy → training + DevSecOps).
-->

---

# Relieve, and train

![w:1180 h:544](./assets/ail-e88d52a3.svg)

</div>

<!--
Two axes, because you can't tool your way out of judgement:

RELIEVE — shrink the safety & access calls up front: prefer embedded / governed
agents over a raw general-purpose one (so the dangerous action isn't even
offered); a vetted catalog of pre-approved agents/connectors/use-cases; policy &
defaults (SSO-scoped connectors, DLP, blocklists) where tooling allows. Owned by
the central enabling team. BUT you can't remove them all — live "vet every
action" tooling is immature, and some duties (parts of the EU AI Act) aren't
tool-enforceable at all (see §3 (covered earlier)).

TRAIN — for what relieving can't remove: the safety/legal calls tools miss AND
the output-trust judgement ("do I trust this analysis?"), which relieving never
touches. Both are large and unavoidable, so build the judgement (lighter
scaffolding than the dev tier, but real; forward-ref §5 HR).
-->

---

# 6. Impact on HR

## Hiring, training, wellbeing

---

# The judgment trap

Agents commoditise fluency. They don't supply **judgment** — and they quietly erode the three things it's built from.

- **Dunning–Kruger, steepened.** The wow-effect breeds "nothing is difficult" — instant wins remove the small failures that used to calibrate you. Confidence climbs; competence doesn't.
- **An agent is a leaky abstraction.** Fine on easy problems — until one is hard enough that it leaks, and you fall through to a layer you never had to learn.
- **LLMs have "judgment blindness."** Capped at the text they learned from, they can be confidently wrong — with no world model underneath to catch it.

> The agent removes the friction — and friction was the teacher. Worse: the competence you'd need to *see* the gap is exactly the competence you skipped.

<p class="ref">Dunning–Kruger (1999) · Spolsky, "Law of Leaky Abstractions" (2002) · LeCun (2026): LLMs lack grounding & a world model · Microsoft/CMU (CHI 2025): more trust in AI → less critical thinking</p>

<!--
TODO: iteration needed — first version.

THE STORY (context for Frank, NOT on the slide): our first hire who had never
coded without an agent. Great CV, motivated, built spare-time webapps. Pattern
emerged: "rewrite it completely" reflex; pushed an obscure Postgres extension
with a grounded analysis (a no-go on customer-managed Postgres he couldn't
accept); weeks later didn't know what a SQL view was — and let me guess it
rather than say so. NOT dishonesty: in his model, a view is a detail the agent
handles. He was fooled by his agent the same way we were fooled by his
portfolio.

The three points are ONE trap (Dunning-Kruger is the connective tissue):
- Wow-effect STEEPENS Dunning-Kruger — agents front-load easy wins and delete
  the cheap deflations (small failures) that normally calibrate you. You skip
  the valley of despair, so the "nothing is hard" prior never gets corrected
  until a big, expensive problem.
- Leaky abstraction (Spolsky): all non-trivial abstractions leak; they save you
  time WORKING but not time LEARNING the layer beneath — for the day it leaks.
- No world model (LeCun): capped at the corpus; can't exceed the average of what
  was written, can't check text against reality. YOUR "no, not at this customer"
  beat the agent's analysis because your world model held the customer reality
  that was never in the text.
- Why it's a TRAP: Dunning-Kruger double-curse — the knowledge to produce a
  right answer is the same knowledge to recognise one. So the gap is invisible
  from the inside. Confidence decoupled from competence is DK with a UI.

Honest caveat: the DIAGNOSIS has real sources (CHI 2025, LeCun, Spolsky). The
REMEDIES are now better grounded than "blog consensus" — desirable difficulties
(Bjork) is peer-reviewed learning science — but the AI-specific application is
still early. Present the remedies as well-reasoned directions, not proven fixes.
-->

---

# Hiring for judgment

The portfolio now shows the **agent's** competence, not the candidate's. Screen for confidence that's *earned*, not *borrowed*.

| Look past | Look for |
|---|---|
| polished portfolio, fast task completion | **how they use AI** — a fallible junior to oversee, or an oracle to obey? |
| "knows the stack" trivia | **"a real mistake — and what it cost you"** — confidence calibrated to reality |
| green-field demos | **judgment inside existing systems** & real-world constraints |

> And keep hiring juniors. Agents can't pass on tacit knowledge — stop growing people and you'll have no seniors left to grow.

<p class="ref">junior/oracle vs fallible-junior framing & entry-level hiring −25% YoY (Stanford, 2024) · Microsoft/CMU CHI 2025: earned domain confidence → more critical engagement</p>

<!--
TODO: iteration needed — first version.

REMEDIES slide 1 of 2 — RECRUITMENT. Ties straight back to "The judgment trap":
we're hiring for the human's judgment, not the agent's fluency.

- "Earned vs borrowed confidence" is the spine. The portfolio/CV signal collapsed
  because it reflects the agent now (this is the story's first beat — great CV,
  spare-time webapps — without naming the hire).
- "How they use AI" = the senior/junior tell: seniors treat the agent as a
  fallible junior needing oversight; juniors as a genius oracle. Let candidates
  USE AI in the interview and watch which one they do (Osmani).
- "A mistake and what it cost you" = a Dunning-Kruger calibration probe. Someone
  with a world model knows the edge of what they know; the DK peak doesn't.
- Landing = the pipeline catch-22. Entry-level tech hiring −25% YoY (2024); devs
  22-25 down ~20% (Stanford); internships −30% since 2023. Agents can't transmit
  tacit knowledge (arXiv 2602.00496) — so cutting juniors starves the senior
  pipeline. The counterintuitive exec takeaway: the answer is to hire AND grow
  them differently, NOT to stop.
-->

---

# Growing judgment

You can't only hire it — you have to grow it. And judgment grows from **struggle**, not from being handed the answer.

- **Graduated autonomy** — juniors *earn* delegation; they don't start by outsourcing the thinking.
- **Keep the friction on purpose** — rotate them through what AI is bad at (debugging, legacy code, edge cases). The struggle is the mechanism that builds skill.
- **AI as teaching material, not the deliverable** — defend generated code in review; measure understanding, not tickets closed.

> The agent quietly removes the "desirable difficulties" that build expertise. Put them back — deliberately.

<p class="ref">Bjork: desirable difficulties & the generation effect (struggle strengthens learning) · arXiv 2602.00496 (graduated agency) · Microsoft/CMU CHI 2025</p>

<!--
TODO: iteration needed — first version.

REMEDIES slide 2 of 2 — DEVELOPMENT. You can't hire your way out; you must grow
judgment in the people you have.

- "Struggle grows judgment" = Bjork's DESIRABLE DIFFICULTIES — peer-reviewed
  learning science. "The struggle is the mechanism." Generation effect: solving
  (and failing) beats reading the answer. This is the scientific spine of the
  whole §5 thesis — the agent removes exactly these difficulties.
- Graduated autonomy: the arXiv SE study's "agency allocation" — juniors should
  gradually increase autonomy, not immediately outsource decisions. Over-reliance
  → "technically accomplished but contextually naive" devs (our hire exactly).
- AI as teaching material, not deliverable: use generated code to teach; require
  juniors to walk through and justify it; assess understanding over output.
- Closes the loop with "The judgment trap": friction was the teacher → so put the
  friction back on purpose. This is the actionable answer to the trap.

Closes the loop with "The judgment trap": friction was the teacher → so put the
friction back on purpose. This is the actionable answer to the trap.
-->

---

# Training: match the tier

Across every tier the scarce skill is the same — **verify, judge, and know the risks**, not prompt tricks. What changes is the depth:

| Tier | What to train |
|---|---|
| **Developers** | the agentic harness (skills, tests, CI) + code & architecture review; the real risks — prompt injection, least privilege, secrets, `curl\|bash` supply chain |
| **Power users** | building and adapting their own agentic workflows; verifying outputs; avoiding shadow-AI data leaks, staying in governed tools |
| **Business users** | AI literacy and when *not* to trust a confident answer; confidentiality and AI Act labelling duties |

<p class="ref">verification over prompt tricks — Microsoft/CMU (CHI 2025) · AI literacy is a legal duty — EU AI Act Art. 4 (in force Feb 2025)</p>

---

# Wellbeing: a different kind of tired

- **The slot-machine rush.** Prompt → result → prompt again: intermittent dopamine and adrenaline make agentic work genuinely addictive. Evenings and weekends erode.
- **Flow and breathers go.** The agent takes the low-effort typing and leaves you *waiting* and *reviewing* — passive boredom plus relentless judgment. Flow is the first casualty.

![](assets/slot-machine.png)

</div>

<p class="ref">Yegge / LeadDev (2025): agentic coding as a "slot machine" · Multitudes (500+ devs): +19.6% out-of-hours commits · Vella & Blincoe (2026): share reporting worse developer experience doubled 14%→27%, flow most vulnerable · Bainbridge (1983): the automation paradox</p>

---

# Wellbeing: the quieter costs

- **You quietly deskill.** Lean on the agent for everything and your own edge fades — one developer: *"I've definitely gotten worse because I already rely on the AI."* The dependency builds before you notice.
- **The work can isolate.** More solo prompting, less turning to a colleague. Generative-AI use tracks with workplace loneliness — and loneliness, more than job insecurity, is what turns into psychological distress.

<p class="ref">Frontiers in AI (2025) — genAI technostress, young professionals (qualitative, N=15): dependency & skill loss · Frontiers in Public Health (2026), N=424 (cross-sectional): genAI use → distress, chiefly via workplace loneliness</p>

---

# Managing for wellbeing

- **Plan time to verify.** Treat reviewing AI output as real work — allocate it; don't pretend the output is free.
- **Scaffold, not crutch.** Design work so people engage with and justify what the agent produces, rather than rubber-stamp it — the same thing that protects their skill.
- **Move people up to the judgment.** The role shifts to directing, evaluating, correcting. Designed for, a dull task becomes an interesting problem — *"how do I set the agent up so it knows when it's succeeded?"*
- **Protect recovery and connection.** Boundaries against the always-on rush; keep people in contact, not just solo with the machine.

<p class="ref">Frontiers in AI (2025): "explicitly plan… time to review AI output"; "scaffold rather than crutch" · Vella & Blincoe (2026): the role becomes supervisory — directing, evaluating, correcting</p>

---

# Be on the side that disrupts

**Not the one being disrupted.**

---

# How Kapernikov can help

<div style="flex:1; border-top:5px solid #ba2415; background:#f6f7f8; border-radius:8px; padding:24px 26px; text-align:left">
    <h2 style="margin:0 0 14px; font-size:1.45em; color:#ba2415">Expertise & co-development</h2>
    <p style="margin:0 0 14px; font-weight:600">We train your teams — and build alongside them.</p>
    <ul style="margin:0; padding-left:1.1em; line-height:1.4">
      <li>Hands-on training in working with agents.</li>
      <li>We collaborate on a real project of yours, embedding the best practices from this talk into how you actually work.</li>
      <li>The platform and safety net — tests, scans, review apps — set up from day one.</li>
    </ul>
  </div>

<div style="flex:1; border-top:5px solid #1D6E88; background:#f6f7f8; border-radius:8px; padding:24px 26px; text-align:left">
    <h2 style="margin:0 0 14px; font-size:1.45em; color:#1D6E88">Agentic applications</h2>
    <p style="margin:0 0 14px; font-weight:600">We build data-intensive applications with an agent at the core.</p>
    <ul style="margin:0; padding-left:1.1em; line-height:1.4">
      <li>The agent lives inside the product, working on your data.</li>
      <li>Engineering, data, and the safety net included — robust and maintainable in an industrial context.</li>
      <li>From first concept to a system you can run and trust.</li>
    </ul>
  </div>

</div>

<p class="ref">frank@kapernikov.com · let's talk about where this fits in your organisation</p>