What an AI coach should and should not do inside a leadership program

There is a version of an AI coach that is easy to build and bad for people. It is always available, always agreeable, and always has an answer. It tells you what you want to hear, it drifts away from the program you are in, and when someone says something that should worry a human, it carries on chatting.

We did not want to build that. This post is about the boundaries we set instead, and why.

What the coach is for

Inside a leadership program, the useful window is the time between sessions. A participant has left a workshop with one thing they mean to try. The next session is two weeks away. In that gap, a coach can do three things well.

It can help someone prepare. A conversation the night before a difficult one-to-one, working through what they want to say and what they are worried about, is genuinely useful.

It can help someone reflect. After the conversation happens, talking through what went well and what did not, without judgement, is how practice turns into learning.

And it can keep the program present. The coach knows which capabilities this person is working on, which lesson was shared this week, and what they said they would try. It can bring those back gently, which is more than most follow-up emails manage.

What the coach should do

It should stay inside the program. The AI coach in Paldar works from the practitioner's own material: the program's capabilities, the lessons in the content library, the notes the practitioner chooses to share. It is not a general assistant that happens to know about leadership. If a participant asks about something outside the program, it says so and points them back.

It should be honest about what it is. Every conversation is clearly with an AI. Every email it sends says so. There is no attempt to pass as the practitioner.

It should ask more than it tells. Feedback research has a sobering finding: a large share of feedback interventions make performance worse, especially when they draw attention to the person rather than the task. A coach that mostly asks questions and reflects back is safer, and usually more useful, than one that mostly advises.

It should defer to the practitioner. The practitioner sets the boundaries, sees the patterns, and can turn the coach off for a participant or a whole program. The coach is a tool inside their program, not a replacement for them.

What the coach should not do on its own

This is the shorter list, and the more important one.

It should not handle distress alone. If a participant says something that suggests they are at risk, or raises something sensitive about their wellbeing, the coach does not try to be a counsellor. It responds with care, it does not push, and it escalates to a human on the practitioner's side. This is not configurable. It is the same for every program on Paldar.

It should not send anything the practitioner has not agreed to. Where the coach writes an email to a participant, the practitioner decides whether those go out automatically or wait for approval, and sensitive cases always wait.

It should not make decisions about a person. It does not grade participants, rank them, or decide who is doing well. It can notice that someone has gone quiet and tell the practitioner. What happens next is a human decision.

It should not pretend to remember what it does not. The coach only sees what it has been given. It does not infer things about a participant from outside the program, and it says when it does not know.

Why the boundaries are fixed

We could have made every one of these a setting. Some practitioners would prefer a coach that gives more direct advice, or one that handles more on its own. We chose to fix the safety boundaries because the cost of getting them wrong falls on the participant, not on the person configuring the program.

Paldar is pre-launch, and these boundaries will be tested by real programs before anyone relies on them. If you run leadership programs and want to be part of that, the waitlist is open.