4. Put agents in a team

Some requests deserve a second opinion before anyone acts. Closing a case is one of them: someone should check the notes first. In this step a team reviews a case. A team is a group of agents that discuss a request in a group chat before the coordinator answers. This team has two agents: an analyst who reads the case and a reviewer who decides. When they approve, the specialist from step 3 closes the case.

Before you start: finish 3. Hand off to a specialist agent.

Create CaseReports.cs:

using Novior.MentorAgent.Attributes;

public class CaseReports(CaseStore store)
{
    [MentorAction(
        Description = "Gets a support case with all its notes, for a review",
        ReadOnly = true)]
    public SupportCase? GetCaseForReview(string caseNumber)
        => store.Find(caseNumber);
}

Team members only read here. Changes go through the specialist, where roles and confirmation apply.

ReadOnly = true declares that the tool only reads. MentorAgent then tells the Analyst that its tools are read-only.

CaseReports belongs to the Analyst only. The team lists the class in the Tools of that member (you see this in the next section), so the coordinator does not get get_case_for_review.

Create ClosureReviewTeam.cs:

using Novior.MentorAgent.Attributes;

[MentorTeam(
    Name = "ClosureReview",
    Description = "Reviews whether a support case is ready to be closed.",
    TriggerOn = ["closure review"],
    MaxIterations = 4,
    HandoffTo = ["CaseSpecialist"])]
public class ClosureReviewTeam
{
    [TeamMember(
        Role = "Analyst",
        Instructions = "Read the case and its notes. Say whether the customer's "
            + "problem is solved, quoting the notes.",
        Tools = [typeof(CaseReports)])]
    public object? Analyst { get; set; }

    [TeamMember(
        Role = "Reviewer",
        Instructions = "Check the analyst's answer against the notes. Approve "
            + "the closure only if a note shows the problem is solved.")]
    public object? Reviewer { get; set; }

    [TeamTerminationCondition]
    public bool ShouldTerminate(string lastMessage, string lastSpeaker)
        => lastSpeaker == "Reviewer"
           && (lastMessage.Contains("[TEAM:APPROVED]")
               || lastMessage.Contains("[TEAM:REJECTED]"));
}

• [MentorTeam] turns the class into a group chat. The coordinator receives it as one tool named after the team: closure_review.
• Description tells the coordinator what the team is for. TriggerOn adds a rule to the coordinator's instructions: always call the team when a request mentions a closure review. Keep these words specific: a broad word such as "case" would send ordinary requests through the team.
• Each [TeamMember] property is one member: an agent with a Role and its Instructions. The members speak in turn, in the order of the properties. The property is only a place for the attribute: MentorAgent ignores its type and its value, so leave it unset.
• MentorAgent tells every member to mark a final verdict with [TEAM:APPROVED], or with [TEAM:REJECTED] for a definitive no. A member who only asks for changes writes no marker. ShouldTerminate, the method marked with [TeamTerminationCondition], ends the discussion as soon as the Reviewer gives a verdict. The markers are removed before the text reaches the user.
• MaxIterations = 4 ends the discussion after four member turns at most. Without a termination method, the team stops at the first member message with a verdict, or at this limit. Each time the coordinator calls the team, the count starts again.
• HandoffTo names the specialist that carries out an approved decision. When the final message of the discussion carries [TEAM:APPROVED] and no member wrote [TEAM:REJECTED], the coordinator is told to execute the approved actions, and it hands them to CaseSpecialist. An approval earlier in the discussion does not count. The model still decides whether to hand the actions over, so leave the change itself to the specialist, behind its role check and its confirmation.

In Program.cs, register the class of the analyst's tools:

builder.Services.AddScoped<CaseReports>();   // the Analyst's tools

The team class itself needs no registration. A tool class that is not registered is left out with a warning in the log, and the member works without it.

Run the app and sign in as Sam: /dev/sign-in?name=Sam&role=Supervisors.

1. Type "Run a closure review of case C-3". While the team works, the widget shows which member is speaking. The only note on C-3 says that the customer was asked for the export log. So the team does not approve the closure, and the coordinator tells you why. Waiting for the customer is not a definitive no, so the reviewer often writes no verdict, and the members talk until MaxIterations.
2. Type "Add a note to C-3: the customer confirmed the export works now", and confirm.
3. Ask for the closure review again. This time the reviewer can approve. The coordinator passes the closure to CaseSpecialist, and the confirmation box appears before the case is closed. Click Confirm.

The verdict comes from the model, so its wording, the turn in which it comes, and sometimes the decision, can change from one run to the next.

Every member turn is at least one model call, plus one for each tool it calls.

In this step, a review that the reviewer settles in its first turn takes five model calls:

1. the coordinator calls the team;
2. the analyst calls get_case_for_review;
3. the analyst answers;
4. the reviewer decides;
5. the coordinator writes the reply.

An approved review that ends with the closure takes nine, because the handoff adds four: the coordinator calls route_to_specialist, the router picks CaseSpecialist, and the specialist calls close_case and answers.

A discussion where nobody decides stops after four member turns, the value of MaxIterations. This can happen in the first review of C-3: then the review takes at least seven model calls, because the analyst and the reviewer speak twice each.

All of them run on your ChatClient and count in the token usage.

• Use a team when a request needs more than one point of view before anyone acts: a review, a decision, an analysis that a single agent tends to rush.
• Do not use a team for lookups and single changes. An action, or a specialist, answers faster and costs less.
• Keep the tools of the members read-only, and leave changes to actions and specialists, where roles and confirmation apply.

You have finished the tutorial. The Cases agent reads and changes cases, checks roles, asks for confirmation, hands work to a specialist and runs a review team.

• The three agent levels compares actions, specialists and teams, with their costs.
• Roles, confirmation and governance explains the checks on every channel.
• Channels shows how the same actions reach JavaScript clients, Model Context Protocol (MCP) clients and other agents.
• Set MentorAgent up for your host and model provider with the Configure pages.
• Before you go to production, replace the test sign-in with your real one and go through the Production checklist.