Before we start

Where you may already encounter AI

One approach: machine learning

Normally, you write the rules

if "lottery" in subject:
    mark_as_spam()
if "winner" in subject:
    mark_as_spam()
# ...and 400 more rules
# that spammers work around
# by writing "w1nner"

The one-line version

Machine learning uses examples to learn patterns. AI also includes approaches based on explicit rules.

But notice something

Many models are specialised

A task-specific model does not automatically generalise to unrelated work.

A starting point for language models

Finish this sentence

“The canteen is always ______ during lunch break.”

A language model generates tokens using patterns learned during training and the context it receives. The next token is selected from a probability distribution.

Next-token generation is the starting point, not a complete account of training, reasoning or tool use.

One piece of vocabulary

Tokens

But there's a problem

A fictional attendance question

Why this answer is unsupported

The needed evidence is missing

Add relevant evidence

Give it the document first

Retrieve relevant passages and ask for a grounded answer. Check the cited passage: retrieval can miss evidence and does not guarantee correctness.

Same fictional question, with a fictional rulebook

A grounded answer

Separate what the source supports from what is still unknown.

Without a connected booking tool

“Book me a lab slot for Thursday”

Helpful. But you still have to do it.

The leap

Give it tools

How that actually works

A tool call crosses a system boundary

• The application defines available tools and their parameters
• The model can propose a call, such as book_slot("Thu","2 PM")
• For a custom function, your application validates permission and arguments, then executes it
• The result returns to the model. Hosted tools execute in the provider’s runtime

A proposed call is not proof that the action was allowed, executed or successful.

And now it has a name

Model + tools + a control loop

In this talk, an agent uses model decisions to choose steps toward a goal. A fixed workflow can also call tools without being agentic.

Where we are

A working model, not a universal taxonomy

An analogy that works

Two people in your class

Same instruction. One executes. One pursues the goal.

The five ingredients

Five properties to design and test

• A goal and boundaries, including what the system may change
• It selects steps, using a model within an application-controlled loop
• It uses permitted tools, with validated arguments and results
• It observes and adapts, looks at what happened, changes the plan
• It needs stopping rules, limits, failure handling and human escalation

The loop that makes it possible

Think → Act → Look → repeat

Illustrative run · event summary

“Find me a slot to demo my project this week”

Think    Need a free hall, and everyone's free time.
Act      check_hall_availability("this week")
Look     Only Fri 3–5 PM is free.
Think    Now check if the team is free then.
Act      read_calendar(team, "Fri 3–5 PM")
Look     Two members have a lab till 4.
Think    Won't work. Try the AV room instead.
Act      check_hall_availability("AV room")
Look     Free Fri 4–6 PM. Everyone available.
Think    Ask before committing the booking and notification.
Act      confirm_permission("book and notify") → approved
Act      book("AV room","Fri 4-6"); notify(team)
Done     Verify booking receipt and notification result.

The important bit

Nobody told it to try the AV room

It hit a wall, and changed its own plan.

Adaptive planning is useful when it preserves the user’s constraints, requests required approval and checks the outcome.

Common application patterns

Where you'll meet it

Be honest about it

Where it goes wrong

Design limits for steps, time and spend. Validate tool boundaries, define approvals and provide a safe failure path.

The question I want you to ask

How would you know if your agent is any good?

If it worked in your demo three times, you have proved almost nothing.

What to measure

Four things

• Did it finish the task? Not "did it sound good", did the slot actually get booked
• Was the path appropriate? Track tool calls, retries and unnecessary actions alongside quality
• Did it do anything it shouldn't? Wrong booking, wrong email, wrong refund
• Cost and time per task, the numbers that decide if it ever ships

Define success criteria. Use realistic, edge and failure cases; repeat runs, compare changes and keep held-out cases. A small demo is a starting point.

Build one

One bounded project to start

Start with one bounded task and clear tests. Add tools only when the task needs them; more tools do not by themselves make a system agentic.

Thank you

Questions