Towards Data Science published a guide to six ways of building AI agents on October 11, written by Partha Sarkar for people who build these systems. I read it as a teacher who will mostly be on the receiving end of a vendor’s pitch for one. Each design comes with a failure mode Sarkar names, and those turn into plain questions a school can ask.
Sarkar describes an agent as four pieces: a language model that does the reasoning; tools it can call, such as a web search, a database query, or a function that sends an email; a way of deciding what to do next; and memory of what has happened so far. A chatbot returns text, while an agent can also act, by looking something up and, if it needs another step, taking it. A product that pulls a student’s record, drafts feedback, and posts it is acting on its own.
Loops, assembly lines, routers, supervisors, and swarms
Five of the six designs are mostly about how work gets routed. The simplest is a loop, where one model reasons, calls a tool, reads the result, and repeats until it decides it’s finished. It’s flexible, but it can lose track of its goal or loop endlessly on a broken tool, so Sarkar recommends a hard cap on the number of steps. An assembly line passes work from a researcher to an analyst to a writer, each seeing only the finished work before it. That makes it easy to tell which stage failed, and awkward to send work backward when a later stage finds that an earlier one missed something.
A router uses a small, fast model to send each request to the right pipeline, such as technical support or billing, and it’s the standard design for customer-service automation. When it misreads a request, the request goes to the wrong pipeline. A supervisor breaks a big task into pieces for specialist workers, checks what comes back, and writes the final answer, and Sarkar says that if its plan is poor, the whole system fails. A swarm puts many agents in a shared space with no manager. Sarkar calls it the most advanced, experimental, and chaotic of the six, with no guarantee of an answer in a finite number of steps, and for strict automation he says to almost always choose something more predictable.
A school can turn each of these into a question: what ends the loop when the agent is wrong, which stage made a given mistake, whether a person ever sees a message the router filed wrongly, who reads the supervisor’s plan before the work starts, and why a vendor would pick a swarm for routine work.
Reflection, where one model checks another
The sixth design is reflection, where one model writes and another critiques, and the writer revises until the critic approves or a limit is reached. Sarkar calls it mandatory for autonomous coding, data science, and high-stakes drafting. In code the critic can be a test suite that says objectively whether the program runs, and he warns that a model critic can invent a flaw and push the writer to ruin good work. Elsewhere in the guide he advises cheap fixed checks along the way and a model critic only on the final output. Student writing has no test suite, so a feedback tool built this way would be leaning on the model critic.
Xi Zhao, Xinyue Jiao, and Zhen Xu compared three commercial models with an instructor on 3,041 student answers from an undergraduate software engineering course at one university in Spain, in a paper posted to arXiv on October 7. The models’ scores tracked the instructor’s fairly well, with correlations of about 0.8, which the authors call moderate to strong. Their written comments flagged a misconception in 4.8 to 7.4 percent of cases, against 15.0 percent for the instructor.
On answers the instructor graded 0 to 2 out of 10, the instructor flagged a misconception in 31.5 percent of comments and the models in roughly 5 to 7 percent. The models’ comments on those answers stayed positive in tone, while the instructor’s were slightly negative. The authors counted misconceptions by keyword matching, in one course, with zero-shot prompts and no critic loop, so I’d treat the percentages as rough. Anyone evaluating a feedback tool can ask whether its comments name what the student got wrong, because in this study scores that tracked the instructor’s came with comments that flagged far fewer misconceptions.
Where a person signs off
Sarkar’s section on human-in-the-loop is brief, and it’s the one I’d hand to an administrator. His rule is that anything other than a read operation could do harm, so the agent should pause before it acts: before it sends an email, authorizes a payment, or drops a database table. A person reviews and edits the draft, then approves it, and only then does the system continue. For a school, that means emailing a parent, posting a grade, or changing a record, and the questions are which of those a product can do without asking and where the approve button is. He also names step-by-step logging of every thought, action, and observation as the standard way to debug an agent after it goes wrong.
A security test from outside education
Simon Willison, who coined the term “prompt injection,” named a combination in June 2025 that he called the lethal trifecta: an agent that can read private data, can take in untrusted content from outside, and can communicate externally in a way an attacker could use. An attacker can put instructions in that outside content, and because a model can’t reliably tell its owner’s instructions from ones in a document it was asked to read, those instructions can send the private data out. His advice is to avoid having all three in one system. A grading assistant that reads student essays, can see the gradebook, and can make web requests would have all three, with the essays as the untrusted content. That example is my own, not a documented school case.
Teacher-built chatbots
One more study tested whether a chatbot a teacher configures does what the settings say. Bahare Riahi and colleagues had 27 middle school teachers in two US states each build a classroom chatbot during about an hour of a summer workshop, by setting a purpose, a persona, and a set of rules. An AI model then scored each bot’s responses in the teachers’ own short test chats against a rubric, and the researchers checked a fifth of those scores against human ratings and found close agreement. No students used the bots, and the paper is a preprint.
Of the 27 bots, 88.9 percent passed on responding to the prompt and 81.5 percent on keeping the assigned persona. Only 70.4 percent passed on following the teacher’s rules, and 59.3 percent on serving the stated purpose, the lowest of the four. If a school asks teachers to build bots like these, I’d budget time for testing them before students ever see one.
Takeaway for Teachers
If a vendor, a coordinator, or a colleague uses the word “agent” this week, ask for four things in writing: the tools it can call, meaning what it can do besides write text; the data it can read and what it can send, post, or change; which of those actions wait for a person to approve, and who that person is; and whether it keeps a step-by-step log of what it did. Then, before it touches a real student, write ten pieces of sample student work yourself, include a few with the mistakes you see every year, and check whether the feedback names the mistake.
If you’re thinking through questions like this one, about what a tool can do on its own and who checks it, my book goes deeper. The AI Doesn’t Know Your Students is available on Amazon and at shouldiuse.ai/book.
David Jacobson is a high school history teacher. He writes about AI, education, and the messy intersection of the two at shouldiuse.ai.
