When an AI agent makes a mistake, adding another instruction can feel like the obvious fix. Add a specialist tool, another checklist and perhaps a second agent to oversee the first. Before long, the system meant to simplify work has acquired a maze of its own.

A better question is not how much machinery surrounds an agent, but whether each part helps it do its job. Universities, businesses and the public all have reasons to care about what an agent does and who remains responsible.

That machinery is often called a harness: the instructions, tools, access limits and checks that shape how an AI agent works. The model generates responses and makes decisions; the harness gives it a working environment and boundaries. A stronger model cannot by itself settle which files it should be allowed to open.

More guidance is not always clearer guidance. In an account of OpenAI’s work with coding agents, Ryan Lopopolo describes replacing a giant instruction file with a shorter map pointing to relevant documentation. A long, outdated rule may obscure the task or conflict with newer guidance. This is one team’s approach, not proof that shorter instructions always win.

François Zaninotto’s analysis for Marmelab, which focuses on harnesses for software development and coding agents, suggests a practical discipline: start with observed problems, change one thing at a time and evaluate whether the change helps. An unused tool or repetitive rule deserves review. A safeguard does not become unnecessary merely because it makes the system larger. An enforceable access control can be more dependable than an instruction asking an agent to behave.

Simplicity can also mean matching the model to the task. A routine question may not need the most powerful model available, while a difficult coding problem may. The LangChain team tested a router that chose among three model tiers from the first human message and kept that choice for the thread. It did not automatically switch models when a conversation became harder.

In its coding-agent experiment, LangChain reported a 64% lower median language-model cost per thread for routed conversations than for conversations always assigned to its strongest model. That is not a 64% reduction in total operating costs. The measured difference in merged pull requests did not establish that the approaches were equally good, and the result concerns one coding-agent setting.

Cheapest is not automatically best, either. LangChain stopped a separate fast-model-only trial early after engineers reported poor output. A low price is little comfort if the answer needs extensive correction or misses the point of the task.

For higher education, including the UTM community, the implication goes beyond choosing a tool for students. Teaching could focus on how to frame a question, inspect evidence and explain why an answer should be trusted, rather than treating a fluent generated answer as the end of learning.

That means asking students to show their reasoning, trace claims to course sources and identify where an answer needs checking. An assessment could reward the quality of that examination rather than the speed of producing polished text. These are choices for educators to make, not automatic benefits of installing an agent.

Consider a course-material assistant that could help students locate explanations in approved teaching resources. Its access could be limited to those materials, and it could point students back to them rather than present an unsupported answer as fact. A lecturer would still be responsible for teaching decisions and correcting misleading material.

UNESCO’s guidance on generative AI in education calls for a human-centred approach that protects data privacy and considers pedagogical design. In this example, that principle would mean deciding what information the assistant needs before granting access, and making it clear when students should seek a lecturer’s help.

For UTM, this points to an institutional responsibility: promote responsible AI practices in teaching, learning and research, with clear educational purposes, access limits and safeguards.

For industry, including small and medium-sized enterprises, the relevant price is the cost of a finished task, not the model price alone. Staff time spent checking, repairing and repeating work belongs in that calculation, along with tools and infrastructure. A business comparing assistants could use the same representative tasks and examine whether each result is usable, how long it takes and what human work remains.

For society, the stakes include more than efficiency. An agent handling personal information should have access limited to what its job requires. Consequential actions, such as changing an important record, could require human approval before they happen. People affected also need a clear route to question and correct an error, with a person or organisation accountable for resolving it.

This accountability also affects how organisations introduce an agent. A useful demonstration is not enough: people need to know what the system is permitted to do, when a decision remains theirs and where to report a problem. Without those routes, the work of discovering and repairing mistakes can fall on the people least able to challenge them.

The goal is not to strip away protections in pursuit of a smaller agent. Simplicity is disciplined design: remove clutter that does not earn its place, keep safeguards that address real risks and judge the system by the work it completes. Less machinery can be better, but only when people can still understand, check and correct what it does.