AI for Mediation Practice: Intake, Scheduling and Confidential Records

AI for a mediation practice works best as a narrow agent that handles intake forms, session scheduling and administrative records, while the mediator keeps caucus content, decisions about neutrality and any message about settlement terms. The useful question is less whether a capable model can read a case file than which memory it may hold, which tools it may call and which confidential material it must never reach. This article describes those boundaries for practices that want to decide what to hand off first.

Key takeaways

• Start with intake, scheduling and administrative records, and keep caucus content and mediator judgment outside the agent's reach.
• Treat every free-text intake field as untrusted input, because a party can type anything into it.
• Scope each matter so that one party's details never appear in a message or calendar entry sent to another party.
• Require a named human to approve anything that could affect neutrality, disclosure, deadlines or settlement communication.
• Define one observable success criterion, such as a weekly review of incomplete intake records and rescheduling errors, before widening the agent's role.

What should an intake form for a mediation practice collect?

Intake for mediation is narrower than intake for a litigation firm. The goal is to confirm that the matter is suitable for mediation, that every party can be identified, that the practice can schedule a session and that the mediator can check for conflicts before anyone discusses the substance of the dispute. The form should therefore collect names and contact details for each party and any counsel, the broad category of dispute, any court or agency deadline that already applies, language and interpreter needs, accessibility requirements and the preferred format, whether in person or by video.

Keep the form short. A long narrative box invites parties to describe the conflict in detail, which creates a record that must then be protected, stored and eventually deleted. If the mediator needs the story, the mediator should hear it in a controlled setting, not in a form that an automated tool processes first. Practices that run other kinds of confidential intake face the same tension, and the limits described in AI for Behavioral Health Clinics: Intake and Scheduling Limits apply here too.

A separate safety field deserves its own rule. If a party indicates a safety concern or a significant imbalance that might affect whether joint sessions are appropriate, the agent should flag the form to the mediator immediately and should not classify, score or respond to the concern on its own. The mediator decides what happens next.

How should session scheduling handle parties who must not meet?

Mediation scheduling has rules that a general booking tool does not know. A practice may run joint sessions, separate caucus blocks, sessions with counsel present, sessions that need an interpreter and sessions that need a room configured in a particular way. Buffers between sessions matter, because a caucus that runs long should not push the next party into the lobby with the previous one. The most important rule is simple: one party's availability, contact details and rescheduling requests must never be visible to another party.

A workable scheduling setup usually follows these checks:

• Joint sessions and private caucus blocks use separate calendar labels, so a caucus is never described to the other side.
• Each party receives messages built from a template that contains only that party's name, the session time and the practice's contact route.
• A proposed time is held for a short period and released automatically unless the mediator confirms it.
• Any change to a confirmed session goes to the mediator's queue before the message is sent.
• Interpreter and room bookings are checked against the same calendar, so a conflict appears before a party is told the session is confirmed.

Notice what the agent does not decide. It does not choose which party gets an earlier slot when there is a conflict, and it does not explain to one party why another party requested a change. Those are judgment calls, and they belong to the mediator.

How should confidential records be stored and retrieved?

Mediation records fall into layers, and they should not sit in one folder. The administrative file holds names, dates, invoices, the signed agreement to mediate and correspondence about scheduling. The logistics layer holds session times, room bookings and reminder history. The mediator's private notes and any content shared in caucus form a separate and more sensitive layer. Written settlement drafts, if the practice produces them, are a fourth layer with their own handling rules. Most practices should keep the first two layers accessible to operations and the last two accessible only to the mediator.

This separation matters most when an agent retrieves context. If the agent answers a question from a document store, retrieval should be filtered by matter and by layer before any content reaches the model. A reminder message needs the session time and the party's name, not the mediator's notes from the previous session. The retrieval pattern described in the [Google Cloud retrieval-augmented generation architecture](https://docs.cloud.google.com/architecture/rag-capable-gen-ai-app-using-vertex-ai) shows how a retrieval step can sit in front of the model, and that is where the layer filter belongs.

Retention needs an explicit rule. Decide how long intake and logistics records are kept, who may request deletion, and how each deletion is logged. Confidentiality and record-keeping obligations for mediators differ by jurisdiction and by professional body, so the practice should confirm its duties with its own counsel or professional association before configuring any automatic deletion.

What access limits must a more capable agent respect?

A more capable agent can reason across more documents, which makes its permissions more important, not less. The principles are the familiar ones. Each agent role gets the smallest set of permissions that its task requires. Credentials are scoped to a role and, where possible, to a matter. Read access is the default, write access is granted per tool, and any action that reaches a party outside the practice passes through a human approval step. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) states the general idea: authorization decisions should be made by the system enforcing access, not left to the content the user or the model produces.

For a mediation practice, a practical permission map looks like this:

• The intake agent can create intake records and read only the record it is currently processing. It cannot see outcomes, other matters or any notes.
• The scheduling agent can read and write the logistics calendar. It has no access to the note store and cannot export calendar entries with descriptions of caucus content.
• The records agent can read the administrative file for a matter. It cannot export mediator notes and cannot send anything outside the practice.
• Any outbound message to a party is drafted by the agent and released only after a named person approves it.
• No agent produces statements about neutrality, likely outcomes or legal rights. Those remain human work.

Prompt injection is the failure mode that makes these limits necessary. An intake form, an email or a scanned document can contain text written to look like an instruction, such as a request to forward a previous summary. The [OWASP guidance on prompt injection prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html) recommends treating external content as data and not as commands. The stronger protection is architectural: if the agent has no access to caucus notes, it cannot leak them, however persuasive the instruction.

Illustrative scenario: a party submits an intake form in which the free-text field asks the assistant to send the other party the summary from an earlier private session. The intake agent holds no caucus content, so it cannot comply. The form is flagged to the mediator as a possible confidentiality concern, and the mediator contacts the party directly. The record of the attempt is kept in the audit log.

The same logic applies to tool design. A tool that can send email should require an approval state outside the model's text, so that a well-worded paragraph cannot move a message from draft to sent.

A step-by-step plan for a first deployment

A first deployment should be small enough that its failures are visible. The practice does not need to automate the whole administrative life of a mediation office in one step. The following sequence keeps the first agent inside a boundary that the mediator can inspect.

• Map every record type the practice handles and mark which layer each belongs to: administrative, logistics, private notes or settlement drafts.
• Write the intake form with the minimum number of fields, and add a separate safety field that routes directly to the mediator.
• Choose one role for the first agent, such as intake triage and scheduling holds, and write down what it must never do.
• Assign read, write and send permissions for each tool, and confirm that the agent cannot reach the private notes layer.
• Set approval points: which messages need a human, which bookings wait in a queue and who receives each queue.
• Define the success criterion in plain terms, for example that a weekly review finds every intake record complete and no outgoing message containing another party's information.
• Log each action with the matter reference, the tool used and the approver.
• Test the setup with invented intake forms, including several that contain instruction-like text, before any real matter enters the workflow.
• Review the log after a fixed period, then decide whether the scope should widen, stay the same or shrink.

The practice that follows this sequence will learn more from its first month of logs than from any vendor demonstration. For a broader view of how legal intake and deadline work is set up, the notes in AI Agents for Law Firms: Setup Guide for Intake and Deadlines cover similar sequencing decisions.

How does Be Human handle this in a managed setup?

Be Human begins with one role, defines the memory and tools that role needs, sets the approval boundaries and writes an observable success criterion before any broader use. For a mediation practice, that usually means intake triage and scheduling holds first, with caucus content kept in a separate compartment that those roles cannot reach. In managed operations, Be Human monitors the agent's actions against the defined boundaries, runs recurring evaluations on a set of invented test cases, reviews permissions whenever a tool or staff member changes, and handles incidents when a boundary is approached or crossed. The service is remote and available in English and Portuguese. If you are unsure which task should go first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent draft session summaries for a mediation practice? It can help with logistics summaries, such as the date, room, attendance and reminder history, if those fields are kept separate from the mediator's private notes. Summaries of caucus content or substantive discussion should remain the mediator's work, because they carry confidentiality and neutrality obligations that an operations agent should not hold. The practice should confirm the rules that apply to its own records with its counsel or professional body.

Is it safe to put mediation intake forms into an AI system? Safety depends on the design more than on the tool name. The agent should hold only the intake data it needs, store it in a system the practice controls, avoid retaining free text longer than necessary and never treat form content as instructions. A safety field should route straight to the mediator, and every access should appear in an audit log that a named person reviews.

Do we need a lawyer to approve the intake form and the permission map? Most practices benefit from a review by counsel or by the mediator's professional association, particularly for the wording of consent and confidentiality notices and for retention periods. Be Human can structure the operational side, including the layers, permissions and approval points, but the practice remains responsible for its legal and ethical obligations and should confirm them independently.

How will we know whether the agent is working correctly? Define a success criterion before launch, such as a weekly review of incomplete intake records and scheduling errors, and check it against a fixed set of test cases. Review the audit log for attempted actions outside the agent's scope, not only for completed tasks. In a managed setup, these checks recur, and any change to tools or staff triggers a new permission review.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.