An agentic tutor and a two-agent debate for postgraduate teaching

Context

One of our senior practitioners lectures on innovation in postgraduate business programmes for working professionals. That work is contracted and paid as teaching. None of these tools was commissioned by a school, and nothing here describes a consulting programme.

We publish it because teaching is where we work out how experienced professionals learn to work with agents, and because the tools built for it are small enough to describe completely. Participants bring a problem from their own organisation and have a few weeks to frame it, evidence it and propose a response.

Three artefacts are covered. Two were built for the practitioner's own courses: a conversational tutor for a problem-framing unit, and a demonstration in which two coding agents debate a business plan through a shared folder. The third, a self-paced course app for agentic coding, is built, with no record of it being taught.

The challenge

The first unit asks each participant to state an operational problem in a strict form: three sentences covering symptom, effect and cause, with a measurable indicator in the first and a cause expressed as something people do, never as something the organisation lacks. The tutor's filters name the usual failures: a desired technology presented as the problem, a strategic wish in place of daily friction, or affected people who cannot be interviewed during the course.

In an intensive five-week format there is little room for repeated rounds of that correction, and a poorly chosen problem costs a participant a week they do not have. A second difficulty is conceptual: agents working together stays an abstraction until people can read what the agents wrote to each other.

Our approach

We applied the rule we teach: the problem comes before the technology. Each tool answers one teaching bottleneck, stays small and leaves judgement with a person.

1. 1Write the method before the agentThe unit's viability criteria, sentence rules and approved examples live in a plain course document. A version of that document is the tutor's instruction set.
2. 2Make the tutor an auditorThe agent is instructed to reject unsuitable problems, and to say why, before it helps to draft anything.
3. 3Show coordination as filesFor the multi-agent demonstration we chose a protocol a class can inspect: a shared folder, one new file per turn, nothing overwritten.
4. 4Keep a human decision at the endThe tutor does not mark work; assessment stays with the lecturer. The debate's conclusion is explicitly left for human feasibility review.
5. 5Package practice as a course appAgentic-coding material was organised as drills, prompts and rubrics in a static app with no accounts and no backend.

What was built

• Problem-discovery tutor. A command-line conversational agent in three phases: a viability audit ending in the three-sentence problem paragraph, a Socratic interview on context, and a drafted unit deliverable with about 700 words of context.
• Two-agent business-plan debate. Two coding agents from different vendors exchanged numbered reports in a shared folder about a hypothetical local-services business. Each report cites those it reviewed and states objections, risks and an improvement.
• Agentic-coding course app. A dependency-free static app in phases: operating a coding agent, repeating one outcome under varied constraints, evidence-based problem discovery and a one-week launch sprint. Built; no cohort use on record.

The tutor's viability filter is the part we value most. It asks whether the participant can interview the affected people this week; if they are external customers or an unreachable board, the problem is dropped. It prefers daily operational friction, such as errors, rework and delays, to strategic wishes. And it rejects any problem defined by an absence: a participant who says the team has no customer system is asked how the work gets done today without one.

Quality is anchored by nine approved example paragraphs, and the agent is told to hold drafts to that standard, not to invent its own. Because the instruction set is a single document the lecturer edits, a change to it reaches the tutor on its next run, and no code is touched.

In the debate, a status file tracks the number of exchanges and the level of agreement, and at least ten exchanges are required before the agents may close. There is no orchestration platform to explain, which is why we chose this form as a teaching device.

Results

What we can evidence is that the artefacts exist and are built as described here. What we cannot evidence is how widely they have been used, or their effect on learning.

We hold no usage records for the tutor: no count of participants, sessions or drafts, and no comparison of marks with and without it. The ten exchanges describe one demonstration; two agents reaching agreement says nothing about whether a plan is sound, which is the point the demonstration is built to make. The course app is an artefact with no record of a cohort using it, so we call it built, not run, and leave it out of the count.

Governance and risk

The tutor stores no conversation by default. One is saved only when the operator asks for a transcript, which is written to a local file. The model is a configuration setting, not a dependency of the method, and the access key lives in the operator's environment, outside the instruction set.

Conversations are processed by a commercial model service, and participants describe friction inside their own employers. The approved examples identify an organisation by sector and team, not by name, and drafts are held to that style. That reduces the exposure; it does not remove it. This is a teaching tool, not a system cleared for confidential corporate data.

Academic integrity is the other risk. The tutor can draft the unit deliverable, so the design puts effort where a shortcut is least useful: it interrogates before it writes, and the substance has to come from interviews only the participant can conduct.

The debate is auditable by construction: every turn is a new numbered file and the folder is the record. The business figures the agents produced are fiction and we do not reuse them. The course app keeps progress ticks in the learner's own browser and records nothing centrally, which is also why we hold no usage data for it.

What we learned

• Write the method before the agent. A tutor is only as good as the criteria, rules and approved examples it is given, and a lecturer can maintain them in a plain document.
• An educational agent should be able to refuse. Turning away an unworkable problem in the first week is worth more than polishing it.
• Make multi-agent work legible. A shared folder with one file per turn lets a class, or an auditor, read exactly what each agent did.

Client identity, locations and identifying details are withheld under confidentiality. Figures are rounded. Measured figures come from engagement records; client-reported figures are attributed, not audited; modelled figures are projections from the engagement's business case and are labelled as such.