AI for Coaching: Useful Workflows, Human Limits, and a Pilot Plan

AI works best in coaching as a structured assistant around a human-led program. It can run a practice conversation, collect a reflection, remind a participant about an agreed action, or prepare a recap for review. It cannot understand a person's life or workplace with the judgment and duty of care expected from a qualified coach.

Keep that boundary visible. A participant should know when they are interacting with AI, what information is recorded, who can access it, and how to reach a person. The system should never diagnose a mental-health condition, present itself as therapy, or decide whether someone deserves a promotion, performance action, benefit, or other consequential outcome.

Start with the coaching agreement

Before selecting a model or voice, define what the coaching program is for. A leadership practice tool, sales role-play assistant, employee development program, and wellbeing service carry different risks.

The International Coaching Federation Code of Ethics places responsibility on ICF professionals to explain the nature of the engagement, protect confidentiality, manage conflicts, and work within their competence. Adding AI does not transfer those responsibilities to the software.

Write an agreement that a participant can understand:

• the AI's role and the topics it may cover;
• the human coach or program owner responsible for the engagement;
• whether conversations are transcribed or recorded;
• how data will be used, retained, shared, and deleted;
• which actions the system may take;
• how to correct a record or challenge an output; and
• when the interaction stops and a qualified person takes over.

Consent to coaching is not blanket consent to surveillance, model training, employee evaluation, or sharing sensitive reflections with a manager.

Choose bounded workflows

Good first workflows have a clear beginning, end, and human owner.

Practice and role-play

An AI agent can play a customer, interviewer, stakeholder, or direct report so a participant can rehearse a conversation. The scenario and rubric should come from a coach or subject-matter expert. Feedback should point to observable behavior in the session, not infer personality, honesty, emotion, or future performance.

Reflection between sessions

The agent can ask questions chosen by the coach: What did you try? What happened? What would you change? A participant can decide what to share at the next human session. The system should not turn an incomplete answer into a clinical or employment conclusion.

Agreed reminders and check-ins

AI can remind a participant about an action they chose and record a simple status. Make reminders optional, frequency-limited, and easy to stop. Escalation should occur only under rules the participant and program owner understand.

Administrative support

Scheduling, resource delivery, and coach-approved recaps are often lower-risk than advice. Even here, integrations matter. A calendar write or CRM update is successful only when the connected system confirms it.

Keep humans responsible for judgment

Do not use a conversational model as the sole evaluator of coaching progress. It can miss context, misread a joke, confuse speakers, or produce a confident explanation that is not grounded in the conversation.

A human coach or program owner should approve the scenarios, knowledge, instructions, tools, review rubric, escalation rules, and material program changes. Participants need a clear way to request review and correct a summary. If the coaching program informs employment decisions, separate developmental conversations from performance records unless the organization has a lawful, disclosed, and nondiscriminatory process for using them.

The NIST AI Risk Management Framework offers a practical structure: govern the system, map the people and context it may affect, measure performance and harm, and manage the identified risks. It does not certify that a coaching application is safe. The program still needs evidence from its own users, workflows, and failure cases.

Define hard stops and escalation

A coaching assistant should recognize when it is outside scope. Create explicit responses for:

• threats of self-harm or harm to others;
• requests for diagnosis, treatment, emergency, legal, or financial advice;
• harassment, discrimination, retaliation, or workplace-safety reports;
• decisions about hiring, firing, promotion, pay, benefits, or eligibility;
• uncertainty about the participant's identity or permission; and
• a participant asking for a human or asking the system to stop.

The correct response depends on the program and jurisdiction. It may be a transfer, a published emergency resource, a report to an authorized safeguarding contact, or a clean end to the session. Do not improvise crisis handling with a general prompt. Have qualified owners approve the language and test it before launch.

How a Dasha coaching assistant can fit

Dasha can provide the conversational layer for a bounded voice workflow. Teams can expose approved data and actions through webhook-defined tools, connect phone or web conversations through the documented conversation types, and configure human call transfers.

Those components do not create a coaching method or duty-of-care policy. Your application decides which participant record the agent may access, which resources it may present, what it may write back, and what a failed tool call means. Use least-privilege access and require confirmation before calendar, messaging, or record-changing actions.

For development, teams can test voice or chat sessions in a browser. After a session, Call Inspector can expose the transcript, recording when enabled, model inputs and outputs, tool executions, timeline, and latency details. Restrict that access. A coaching transcript may contain sensitive personal or workplace information even when the program did not ask for it.

Build an evaluation around the real task

Generic model benchmarks do not tell you whether a coaching workflow is useful or safe. Build a test set from approved scenarios and likely failures. Include interruptions, vague answers, code-switching, silence, a tool timeout, an out-of-scope request, a participant who withdraws consent, and a request for a human.

Review measures such as:

• completion of the required AI disclosure and privacy notice;
• adherence to the approved coaching questions;
• unsupported advice or invented facts;
• correct refusal and escalation behavior;
• accuracy of confirmed scheduling and record updates;
• participant-reported clarity, pressure, and ability to stop;
• false or misleading session summaries; and
• access, deletion, and retention-control failures.

Treat automated post-session labels as triage, not final truth. Dasha supports configurable post-call analysis fields, but important findings still need human validation against the transcript and program rules.

A practical pilot plan

Use one non-clinical, non-consequential workflow, such as a voluntary role-play exercise designed by a coach. Recruit a small group who understand that the system is being evaluated. Give them a human contact and a way to remove their data.

Before launch:

1. The coaching owner approves the purpose, scenarios, rubric, limits, and escalation plan.
2. Privacy and security owners approve data collection, vendors, access, retention, and deletion.
3. Engineering constrains tools, identity, permissions, retries, and failure behavior.
4. Reviewers test ordinary and adversarial conversations and set stop conditions.
5. Participants receive the disclosure and choose whether to take part.

Review sessions frequently and pause when a material boundary, privacy, or escalation control fails. Expand only when the evidence supports a specific next workflow. The goal is not to replace the coach. It is to give the coach and participant a well-controlled way to practice and follow through between human conversations.