CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
CIS 4394 Agentic AI · Fall 2026 · Dr. Xinyu Fu
Function calling has a reputation for being magic. It is not: the model emits a small piece of structured text naming a function and its arguments, and your program decides what to do about it. Once you see the round trip clearly, every framework, every protocol, and every safety control this semester lands in an obvious place.
A tool is an ordinary function in your codebase — calculator(), lookup_order(), send_email() — that you have described to the model in a form it can read. Function calling (also called tool calling) is the model's ability to respond, instead of with prose, with a structured request to run one of those functions with specific arguments.
Three sentences worth memorising:
Four of the six steps are plain software you can unit-test. This is the same ownership split as the loop in Week 4 — and the reason agent safety is mostly an engineering problem, not a prompting problem.
The episode: “Our Berlin supplier invoiced 4,817 units at €293 each, plus 18% VAT. What is that in USD?” The agent has two tools — calculator and fx_rate — and it will get one call wrong on purpose so you can watch what happens next. Press Step.
The short arrow from Model decides straight to Final answer is the exit: a turn where the model emits no tool call is how the loop ends. The amber box is therefore a stop condition, not a step.
fx_rate call did not raise an exception into your users' faces; the validation error was handed back to the model as an observation, and the model repaired its own call. (3) Read the whole trace as the Week 2 evidence standard: state before → observation → available actions → selected action → result → state after. Every tool call produces that record for free.The fx_rate value of 1.08 above is an illustrative fixed rate returned by a stub tool written for teaching — not a live or historical quote. The euro subtotal (4,817 × 293 × 1.18 = 1,665,429.58) is exact.
1 · What the model emits. A name and a bag of arguments. That is the whole payload. Different vendors wrap it differently, but every one of them reduces to this.
Because it is a request, three useful things are possible before anything runs: you can validate it, you can refuse it, and you can show it to a human. Page 02 is entirely about using that window.
2 · What the model sees. Before the conversation starts, your harness sends the model a list of tool schemas. This is the only thing the model knows about your systems.
Name, description, typed parameters, required list. Notice that the enum is what made the simulator's error message useful: the harness could tell the model precisely what the legal values were.
The simulator above with the machinery stripped out — this is what actually sits in the model's message history at the end of the run. Four roles, strictly alternating.
In LangChain and LangGraph, defining a tool is defining a function. The type hints become the parameter types; the docstring becomes the description. You saw bind_tools in Week 4 — here is what it is binding.
The signature (base: str, quote: str) -> str generates the JSON parameter types the model receives. Change a type hint and you have changed the model's contract.
The docstring is the description — the sentence that decides whether the model reaches for this tool at the right moment. Note that it says what the tool is for and one thing the model must not do.
The body is your enforcement point. It returns an error string rather than raising, so a bad call becomes an observation the model can recover from instead of an exception that kills the run. That idea gets its own section on page 02.
Your capstone agent needs at least two real tools with clean schemas. Start them now, in this shape: typed parameters, a description that states when to use the tool, and errors returned as data. Group Assignment 2 grades exactly these properties.
Interleaving reasoning traces with actions — Thought → Action → Observation, looped — so that the model's next decision is grounded in a real result rather than in its own guess. Week 4 used it as a reasoning pattern; this week, the “Action” is literally a tool call and the “Observation” is literally a return value. arXiv:2210.03629 ↗
The paper whose title is the claim: Language Models Can Teach Themselves to Use Tools. It showed that a model can learn, in a largely self-supervised way, which API to call, when to call it, and what to pass — deciding for itself where a tool call helps. That is why tool use is a general capability you can design around, not a trick that needs bespoke training per tool. arXiv:2302.04761 ↗
The enterprise framing of everything on this page: the model as the reasoning layer, tools as the boundary to the systems that actually hold your data. Watch it before page 02.
1 · Every time the speaker says the model “calls” something, mentally substitute “asks your code to call.” Does any claim in the video break? (It should not.)
2 · Note where the video puts the boundary line between the model and the enterprise systems. That line is the thing you design this week.
3 · Count how many of the four gaps from the week home — cutoff, private data, computation, actions — the examples are closing.
Reference explainer if you want the same material as text: IBM Think — What Is Tool Calling? ↗ · Framework docs: LangChain — Tool calling ↗
query_warehouse accept arbitrary SQL or a table name from an enum? Does email_customer accept any address, or only addresses already attached to the ticket? Is the validation inside the vendor's harness (auditable, versioned, testable) or inside the prompt (a polite request the model can ignore)? A secondary question worth asking in the same breath: what happens on failure? An agent that crashes on a bad argument is annoying; an agent that silently retries a write tool is a duplicate-payment incident. You are looking for the same ownership split as this page: model proposes, harness disposes, every call logged.