Where a model stops answering and starts doing. Titles are on the spines; the notes underneath are the three tellings, in short — for a ten-year-old, for the architect, and for the boardroom.
6 concepts on this shelf · Beginner → Advanced · about 7 min read
Kitchen table — A chatbot answers your question and stops. An agent gets a job. 'Plan the class trip' means it looks up the museum's opening hours, checks the bus timetable, counts the pocket money, notices the museum is shut on Monday, and picks Tuesday instead — step after step, checking its work as it goes. It is the difference between asking a friend what to cook and having a friend who goes shopping, cooks, and washes up. Exciting, and it had better wash up properly.
Whiteboard — A model plus a loop plus tools plus state — and the model is the smallest part. The harness is where reliability is won or lost: what the agent may touch, how many turns it gets, what it does when a tool fails, when it must stop and ask a human, how its work is verified before anything irreversible happens. Plan for partial failure as the normal case; an agent that cannot be interrupted, resumed and audited is a demo, whatever the launch post says.
Boardroom — This is the shift from AI that advises to AI that acts — booking, filing, purchasing, reconciling — and that is where the real value is, because advice still needs someone to act on it. It is also where the governance questions begin in earnest: an agent holds credentials, touches systems of record and leaves consequences, so it deserves the controls you would give a new employee — limited permissions, an audit trail, a probation period, and someone accountable for what it does. Autonomy is granted in degrees, and earned.
AI agents, agentic AI, autonomous agents, agent harness, harness engineering, tool use
Kitchen table — Two ways to do a big job. One: keep asking 'what should I do next?' after every step — flexible, but you can wander and lose the plot. Two: draw the whole map before you start — step one, then step two, then step three — reliable, but useless the moment something unexpected happens, like a recipe that never mentions what to do when the egg breaks. Real systems mix both: a map for the parts that must not go wrong, and 'decide as you go' inside the messy middle bits.
Whiteboard — A loop decides at runtime — model in charge, maximum flexibility, unbounded variance. A graph decides at design time — explicit nodes and edges, testable, auditable, brittle at the unexpected. Loops wander; graphs ossify. Production systems put a graph around the invariants (the approval gate, the irreversible step, the compliance check) and loops inside the nodes that need judgement. Deciding which parts of the process are load-bearing enough to deserve graph edges is the actual architecture work.
Boardroom — This dial sets how much freedom the system gets: more freedom means more capability and more variance, less means predictability and rigidity. That trade is an executive decision, not a technical one, because it is really a risk-appetite question — which steps of this process may an AI improvise, and which must run exactly as designed, every time? Expect hybrids, and expect to revisit the dial as trust accumulates. The vocabulary is worth having at the table when someone proposes 'full autonomy'.
agent loop, agent graph, orchestration, state machine, workflow, control flow
Kitchen table — On its own, the machine can only talk. Tools give it hands: now it can actually look up today's weather, do the sum on a real calculator, or send the permission slip — instead of just describing how one might. Each tool is like a button it is allowed to press, with a label explaining what the button does. Choose the buttons carefully. You would not give the class hamster the fire-alarm button, however clever the hamster.
Whiteboard — Function calling with schemas, and MCP emerging as the standard for exposing tools across vendors — write once, plug into any model. What actually decides whether the model uses a tool correctly is craft, not protocol: names that say what they do, descriptions written for a reader with no context, arguments that resist misuse, error messages that teach, idempotency so a retry is safe. A tool's interface is a prompt; design it with the same care.
Boardroom — This is the integration layer — how AI reaches your actual systems: the CRM, the ledger, the scheduler. Standardisation here is good news commercially (less bespoke plumbing, less lock-in) but the strategic point is sharper: every tool is a capability grant, and the tool boundary is exactly where access control must live. The model will improvise; the tools must not let improvisation become damage. Review an agent's tool list the way you review a new hire's system access — because that is what it is.
tool use, function calling, MCP, Model Context Protocol, API integration, tool design
Kitchen table — Without memory, every chat starts from zero — like a friend who forgets you overnight and must be told everything again each morning. With memory, it remembers you prefer the window seat and that your project is due Friday. But choosing what to remember is the hard part. Some things should be kept, some fade, and some — a secret you blurted out — are better forgotten. A friend who remembered everything, forever, word for word, would honestly be a bit creepy.
Whiteboard — Three different problems wearing one name: working context (this session), episodic notes (what happened before), durable facts (what stays true). Writing is trivial; curation is the discipline — deciding what deserves to persist, consolidating duplicates, expiring what went stale, and retrieving the three relevant facts instead of dumping the archive into context. Unbounded memory degrades retrieval and behaviour alike. Memory is a garden, not a log file: it needs weeding on a schedule.
Boardroom — Memory is what turns a tool into something that feels like a colleague — it is the personalisation moat, and customers feel its absence immediately. It is also a liability ledger: every stored fact about a customer is now data you hold, with retention, consent and deletion obligations attached, and 'the AI remembered it' will not soften a privacy regulator. Fund the forgetting as deliberately as the remembering; the deletion pipeline is a feature, not a compliance afterthought.
agent memory, long-term memory, context, personalisation, retention, state
Kitchen table — Like training a puppy. You cannot explain 'sit' in words — the puppy tries things, and when it happens to sit, it gets a treat. Slowly it works out which actions earn treats. Machines can learn the same way: try, score, adjust, try again — millions of times, usually in a pretend world where mistakes are free. And exactly like the puppy, it learns what you actually reward, not what you meant. Reward 'looking sorry' and you get a champion at looking sorry.
Whiteboard — Agent, environment, reward, policy. Credit assignment over long horizons is brutal — which of a thousand moves won the game? — sample efficiency is poor, and simulation quality decides everything, because the policy will exploit any gap between the sim and reality. Reward hacking is not an anecdote, it is the default outcome of a misspecified objective; assume the policy finds the cheapest path to the number. Where the sim is faithful and the score is clean, the results still look like magic.
Boardroom — The fit is narrow and real: a clear score, cheap practice, tolerable mistakes — pricing, routing, scheduling, bidding, recommendations. Where practice is expensive or errors are irreversible, this is the wrong tool, whatever the vendor deck says. The board-level question for any RL proposal is about the reward: what exactly is being maximised, and what is the ugliest behaviour that would still make that number go up? If nobody in the room can answer, the system will answer for you, in production.
reinforcement learning, RL, reward function, policy, exploration, bandits, Q-learning
Kitchen table — How do you teach a machine to be helpful when 'helpful' is not a thing you can score with a ruler? You show people two answers to the same question and ask 'which is better?' — thousands and thousands of times. The machine studies all those choices and slowly learns the taste of a good answer: polite, clear, actually answering the question. It is how the raw word-guesser from the shelf below got its manners. Somebody's idea of good manners, anyway.
Whiteboard — Train a reward model on pairwise human preferences, then optimise the policy against it — PPO classically, the DPO family when you would rather skip the reward model, constitutional and rubric-based variants when human labels are the bottleneck. Alignment is a data problem wearing a maths hat: whose preferences, which edge cases, how consistent the raters. Over-optimising the reward model produces sycophancy and safe blandness — the model learns to please the grader, which is not the same as being right.
Boardroom — This is the finishing step that turns a raw model into something safe enough to put in front of customers, and it is where a model's values and refusals actually come from — not physics, but choices made by whoever ran the preference process. 'Whose preferences went in?' is a fair and revealing vendor question. The residual risk to manage is agreeableness: a system tuned to please raters can drift toward telling users what they want to hear, which in your context may be a compliance issue, not a charming quirk.
RLHF, DPO, preference tuning, reward model, alignment, human feedback