Teaching AI Agents to Computer Science Students Without a Vendor

Teaching AI agents to computer science students goes best, I think, when everything you grade belongs to no vendor. That means the loop, tool contracts, the context budget, evaluation, and the question of what signal shows a run worked. Named tools belong in the labs, pinned and swappable, on terms your syllabus states.

That is an opinion, and this page argues it and then prices it. I should say first what the argument cannot claim. I found no study that compares a vendor-neutral agents course with a vendor-specific one on any outcome, so nothing here says students learn more this way.

The case rests on dated evidence of what changes, on what six public course pages state, and on a bet the book behind this site makes in its Preface. You leave with a table of which material ages fastest, an eight-item audit of your syllabus, and a tool policy to paste into it.

What does “without a vendor” mean when teaching AI agents to computer science students?

It means that nothing you grade depends on one company’s product, while the labs stay free to use products. The title overstates my position, and I would sooner narrow it here than defend it. Every lab that calls a live model calls somebody’s model.

The word I can defend is swappable. A course is swappable when a retired model, a renamed framework or a withdrawn free tier changes one lab handout and leaves the lectures, the rubric and the exam alone.

Chapter 27 of the book (in the full book) has a rule of custody for this, written about production systems: “never store what you own inside what you rent”. In a course, what you own is the set of ideas you examine. What you rent is every named thing a lab touches.

The figure is drawn for a deployed system. Its center holds what a team owns, in the caption’s words “prompts, tool schemas, the eval set”, and the rented parts plug in around it. I borrow the picture because a course faces the same custody question. The analogy is mine; the book never applies this figure to teaching.

What goes stale in an agents course, and how fast?

The fast layers are model names, unpinned library releases and a vendor’s product line. In the dated examples below they changed inside one term or between two yearly offerings of a course. The slow layer is the set of ideas underneath, and its durability is a bet that nobody has measured.

A commenter who teaches computing at the University of Illinois, by their own account, wrote on Hacker News in March 2026: “Research about how to incorporate AI in computing education is outdated before the ink is dry.”

You will also hear that agent material is out of date by the final exam. For model names and unpinned libraries the record shows it can happen: two notice periods are shorter than a term, and one library broke a course template within 59 days of the version the template had been built on. For the rest, the honest sentence is “by the next time you teach it”.

Every product in the table is a labeled example of a category, read on 2026-10-06, and none is a recommendation. The third column assumes a course taught once a year.

How does the arithmetic work against one term?

Compare each period with the length of a term and with the gap between two offerings. A 13-week term is 13 × 7 = 91 days. One published Fall 2026 term, the Michigan course in the table below, runs from August 31 to December 11, which is 102 days. A yearly course comes around again after 365.

Four periods are shorter than 91 days: 14 days of notice for a preview model, 55 days between two library releases, 59 days from the pinned release to the broken-template report, and 60 days of minimum notice at one provider. Each can start after your first lecture and finish before your last.

Five more fall between 102 and 365 days. They are 119 and 132 days between one framework’s early release series, 176 days between two versions of a course README, about 183 days for a six-month notice, and 365 days for the API surface. A handout written last summer can name something that is gone by this one.

The last gap, 399 days between two releases of that framework, is longer than a year. Hence the two sentences: “by the final exam” can hold for model names on short notice and for unpinned libraries, and “by the next time you teach it” holds for product lines.

What does this evidence leave unshown?

It shows no rate for the field and nothing about learning. These are examples I went looking for, from two model providers and three framework or library lines. The notice periods are minimums that two vendors currently publish, so a real retirement may come with more warning.

Stable counter-examples exist too. The framework in the table now states: “Breaking changes to the public API will only occur in major version releases”. I did not check whether its earlier releases broke public interfaces.

What happened to two courses built on a vendor’s stack?

Both needed repairs that learners or contributors reported, because the stack under them moved. I hold that against nobody. It is what any course built on a vendor’s products has to do when the vendor moves.

One is a cloud vendor’s free agents course. On 2025-08-28 its README listed “Semantic Kernel” and “AutoGen” among the frameworks it uses; on 2026-02-20 the list read “Microsoft Agent Framework (MAF)”. One of the earlier two now opens its own README with “AutoGen is now in maintenance mode.”

Repairs continued inside the new framework. A pull request dated 2026-06-26 reports that a class “was removed in agent-framework v1.8.x”.

The second is a model hub’s free agents course, which describes itself as “a living project”. The issue in the table was still open when I read it. A comment dated 2026-09-04, 461 days after the report, begins “This is still current”.

An instructor who adopts either course as the lab adopts its maintenance schedule too.

What do six public course pages state about tools and cost?

Two of the six state a tool-independence rule in writing, and three state how model access is paid for. I read each page on 2026-10-06 and record only what it says about itself.

The sample is small and represents nothing beyond itself. These are six pages that happened to be public and readable. I chose them by hand, and they support no sentence that begins “most courses”.

The Michigan row matters most to my argument, because it holds the thesis and the concession in one syllabus. The lab names its tools, and the student’s own code answers to a neutral contract.

This table records tool dependence and cost. Week order, grading weights and a comparison of public courses by where evaluation sits are in the post on how to sequence and assess an AI agents course syllabus.

What should students still be able to do after the tools change?

Students should leave able to do eight things that name no product. The list is this post’s own, assembled from the book’s Preface and Chapters 1, 3 and 27. It is my extension of the book to a classroom, and the book offers no such list of learning outcomes.

The Preface (free to read) names the raw material: “The durable knowledge in this field lives in concepts and patterns—the loop, the tool contract, the context budget, the evaluation harness—and those transfer across every vendor and framework.” It then says what does not transfer: “The syntax of any one product does not transfer, and it ages in months.”

Use the list as an audit of your own syllabus. Tick an item only when some graded piece of work assesses it and the question could be answered without naming a product.

Why these eight?

Each one is a question a student can ask of a product released after the course ends. Chapter 1 gives the first as a test to apply “whatever its label says”: “does the model decide the next step, or does code?” The sixth is the first bearing of the compass, the book’s set of four bearings.

The fifth has a line for the whiteboard, from Chapter 1: “The particular numbers vary; the arithmetic does not, and it is merciless.” The compounding error calculator lets a class try its own rates.

The seventh asks for an eval set, a curated collection of tasks with a way to grade each one. The third can be practiced on any tool description with the tool contract linter.

Where does a named tool belong, and on what terms?

A named tool belongs in a lab, after students have built the thing it replaces, with its version pinned and its conveniences mapped back to course concepts. It stays out of the rubric and the exam. I concede this much to the other side gladly, because the book does too.

Chapter 27 lists building small things among its habits for keeping current: “Reading about tools informs you. Building against them calibrates you.” Chapter 3 gives the order: “Build from scratch to understand. Adopt a framework to scale—and only once you can name what it is saving you.” Both chapters are in the full book.

An instructor of non-technical business students, by their own description, argued the opposite on Hacker News in April 2025: “It is much more valuable to see what works and how to use it.” For that audience I agree. My claim is about students who will build these systems.

Why map the tool back to the concept?

Map it because recognizing an old idea under new syntax does not happen by itself, at least for novices in the nearest field studied. Tshukudu and Cutts (2020) followed near-novice students moving between two programming languages. On concepts that were the same underneath but spelled differently, they report “little or no semantic transfer”.

That is a study of programming languages. I am using it as an analogy for agent tooling, and nobody has tested the analogy.

A second study gave programmers a tool that explains an unfamiliar language in terms of one they know. Participants found the mapping useful and “were reluctant to accept facts without code execution” (Shrestha, Barik and Parnin, 2018). Learners want to run things. So the strong form of my advice includes a lab on a real tool, with the mapping written down.

One published account of teaching agents inside an undergraduate AI course did both. Mello and Maher (2026) list “Agnostic (no lock-in to a single LLM provider)” among their design principles and teach through a small framework their own lab wrote. It is one course, with no comparison group.

A tool policy to paste into the syllabus

The policy below governs what the course depends on. It is a template: brackets are yours to fill, and a bar inside a bracket separates options. What students may use on graded work, and how that work is verified, belongs to a separate policy. The post on AI agents assignments for students has one, and this template points to it.

TOOLS IN [COURSE CODE], [TERM]

This section says what the course depends on. Which tools you may use
on graded work, and how work is checked, are in [the AI-use policy].

1. What is graded is tool-independent.
   Assessed components: [labs | project | exam | paper reviews].
   Rubrics and exam questions are written in terms of the loop, tool
   contracts, context, evaluation and "what signal tells you it
   worked?". No graded item requires one product's syntax.

2. One seam.
   All model calls in your own agent go through a single module with
   this contract: [messages and tool definitions in; text or tool
   requests out]. No provider-specific call appears outside it. The
   staff may grade by swapping what sits behind the seam. Labs under
   item 4 are exempt and may call the named tool directly.

3. Baseline access costs you nothing.
   Every graded item can be completed with: [a scripted model client |
   a model served on your own or a lab machine | the course endpoint].
   Second route if the baseline is lost: [___].
   No graded item requires a paid account or a personal payment card.

4. Named tools this term: [none | tool, category, lab number].
   A named tool is allowed in a lab on four terms.
   a. The handout names it as one example of a category and names a
      second example.
   b. The handout pins the version and gives the date the staff
      tested it: [version, date].
   c. The handout says which course concept the tool is an instance
      of, and which of its conveniences you could build yourself.
   d. The deliverable can be checked without the tool: [a run record |
      an eval result | a written mapping from tool to concept].

5. Keys and costs.
   Who pays for model calls: [nobody, the baseline costs nothing |
   the course | a named partner | you, optional and never required].
   Keys: [none needed | issued by the course, capped at ___ per
   student | your own].
   Never commit a key to a repository. Spending beyond the baseline
   earns no extra credit. Tell the staff by week [N] if access is a
   problem.

6. If a tool changes mid-term.
   The staff handles a model retirement, a breaking release or a quota
   change. The affected lab falls back to the baseline in item 3, or
   to the second route if the baseline is what changed, and its
   deadline moves by [N] days.

7. Vendor materials: [none | what was supplied, and by whom].
   Slides, labs, credits or a kit from a vendor are named here.
   Items 1 to 4 still hold.

8. Review.
   The staff re-tests every pinned lab [N] weeks before each term and
   writes the date in the handout.

9. Academic integrity.
   This section adds one rule: a key is personal. Using another
   person's key, or sharing yours, goes to [the institution's
   process]. All else is in [the AI-use policy] and [the institution's
   academic integrity policy], which govern.

Where does each clause come from?

Four clauses come from the book or from a public syllabus, and three are my own design. Item 2 is Chapter 27’s insurance against model lock-in, “one seam in your codebase through which all model calls pass”, and Michigan’s rule about hostnames.

The exemption in item 2 is also Chapter 27’s: “A weekend prototype deserves none of this; wrap nothing, hard-code freely, let it be disposable.” A one-week lab on a named tool is that kind of code.

Item 3 follows Michigan’s zero-spend statement. Item 4a is the Preface’s rule for naming tools, “as labeled examples of a category”. Item 4c is Chapter 3’s “name what it is saving you”, turned into a deliverable.

Items 4b, 6 and 8 are mine, and they answer the repairs described earlier: a pin, a fallback and a date.

Does it hold up on two different courses?

It did after two changes. I filled the template for two invented courses. One is a 13-week undergraduate elective with no budget for model access. The other is a graduate seminar where a lab partner supplies credits and a kit.

Here is the elective, shortened:

TOOLS IN [an undergraduate elective], 13 weeks, no access budget
1. Assessed: labs, a project, a final exam.
2. Seam: one module, the contract as written.
3. Baseline: a scripted model client. Second route: a small
   open-weight model on your own machine, optional.
4. Named tools: one open-source agent framework, lab 6, pinned.
   Students read its source; no model call is needed. Deliverable:
   a written mapping from its classes to the four parts.
5. Who pays: nobody. Keys: none needed. Access: week 2.
6. Fallback: the scripted client; lab 6 deadline moves 7 days.
7. Vendor materials: none.
8. Review: 3 weeks before term.
9. Integrity: as written.

The seminar needed the two changes. Its baseline is the partner’s credits, so the fallback in my first draft pointed back at the thing that had just failed. Item 3 now asks for a second route, and the seminar’s is a scripted client. The draft also assumed an exam, which a seminar may lack, so item 1 now lists the assessed components.

Every other field could be filled. Item 5 reads “a named partner”, with course-issued keys under a cap, and item 7 names the partner, the credits and the kit. Item 4a is the expensive one: the kit’s handouts will not name a second example of their own category, so the instructor writes that addendum.

What does teaching this way cost you?

Teaching AI agents to computer science students this way costs preparation, a subsidy and a line on your students’ CVs. Chapter 27 says of portability in systems, “Portability has a price, and buying it everywhere is its own failure mode.” A course pays the same kind of price.

No vendor hands you neutral labs. You write them, add the concept mapping to every tool handout, and re-test the pinned ones each term.

The subsidy is what you decline or constrain. One vendor’s generative-AI teaching kit, announced in February 2025, offers “lecture slides, lecture videos, hands-on labs, Jupyter notebooks, knowledge articles and checks”. It also states its terms: key concepts “are then examined using NVIDIA GPUs, tools, and services, as well as open-source libraries and frameworks.” The kit covers generative AI in general and lists no module on agents.

The cloud vendor’s free agents course described earlier states “Azure Account Required”. Both say plainly what they bind. The policy lets you accept either under item 7, and the price of acceptance is the work in items 1 to 4.

Who pays for model access?

Somebody does, and the syllabus should say who before week one. The six pages show three arrangements: local open-weight models with no required spend, credits supplied by vendors, and an account provided by the course. A scripted model client for everything graded is a fourth.

Silence has a cost that falls unevenly. A learner on one vendor course opened an issue in March 2025 because a quota ran out “When i call the first code”. A learner on the other, writing from Brazil in April 2025, was unsure whether the labs would generate charges and added: “1 USD equals 6 BRL here”.

Check what your institution’s license covers too. In a June 2026 r/Professors thread about instructors’ own use of agents, one reply reads: “our institution-provided LLMs are chatbot only”.

The free route has its own cost. A scripted client exercises the harness, meaning everything built around the model, and shows nothing about a live model. If your budget is zero, say so in the syllabus and give students one optional route to a real model.

One audit item feels this directly. A scripted client returns the same responses on every run, so an evaluation that reports a rate over several runs needs either the optional live route or a client scripted to vary.

What do students give up?

They give up some product names. A student will ask which framework goes on the CV, and a neutral course supplies fewer. I found no primary evidence on what employers reward, so I make no claim about hiring in either direction.

What I can offer the student is item 4: one named, pinned tool, and a written account of which parts they could have built. A computer science professor, by their own description, wrote on Hacker News in June 2026 that AI coding “deemphasizes knowing specific language features or frameworks, but requires having a careful, structured development process.”

What material fits this policy?

Four kinds of material fit the policy, and you can mix them. I list the site’s own last and as one option among the four.

• Papers and primary sources, with no textbook. The Michigan syllabus in the table says “There is no textbook”.
• A vendor’s free course or kit as lab material, under items 4 and 7. The two vendor courses and the kit named above are examples of this category.
• A small framework your own group writes for teaching, as in the Mello and Maher account.
• This site’s AI agents teaching kit: a 13-week syllabus and the first three lecture decks, with labs designed to run against a scripted model client.

The kit is built on AI Agents, Engineered. As an agentic AI textbook for a university course it has one property to know first: it is pseudocode throughout. Appendix A (in the full book) says why: “The program is in pseudocode, and the choice is deliberate.” No runnable code ships with the book, so translating it is your students’ work, or yours.

If you came looking for AI agents lecture slides, three decks exist today and the other ten weeks have a plan with no deck. They are lecture 1, on what an agent is, lecture 2, on the engine’s failure modes and the loop, and lecture 3, on planning, tools and the action space.

For exam review, the AI agents study guide sorts the book’s vocabulary by part and adds a self-test. For a demonstration that needs no account, Run the loop puts a student in the harness’s seat for one scripted run.

Where does this argument run out?

It runs out in four places.

Nobody has measured the outcome. That principles outlive several model releases is the book’s bet, and applying it to a course is mine. Its Preface concedes the risk: “Some details here will be superseded, probably sooner than I would like”. No course I could find has been followed across model releases.

The evidence is a set of examples. A handful of dated notices and six course pages, read on one day, show that the fast layers can move within a term. They give no odds that yours will.

A map has a limit. Chapter 27 says of the book’s own method that “a map cannot tell you whether to pack an umbrella”. A course built on concepts cannot tell a student which tool to pick this year. An engineering team meets the same question when it weighs build versus buy for AI agents.

Neutrality can become an excuse. A reply in the Illinois instructor’s thread argued that “the slow speed of adoption in education has a positive face; that is it filters out some of the hype.” I agree, and the same slowness can hide a course that never updates. Item 8 of the policy is the guard.

The one thing to keep

Teaching AI agents to computer science students is a custody decision before it is a choice of tools. Decide what the course owns, write down what it rents and on what terms, and a vendor’s next announcement costs you one handout.

The argument for that is in the book’s Preface and in Chapter 1, “What Is an Agent?”, both free to read; start with the Preface. The loop is in Chapter 3 and the layers are in Chapter 27, both in the full book. If the bet seems sound after the free chapters, see the formats.