Live
Powered by

Athlete communications hard-gate proposal

Summary

This proposal outlines a true athlete-delivery hard gate in which all athlete message delivery must pass through a dedicated athlete-comms agent.

Under this model, Coach Luca and any specialist or workflow may still decide the coaching content, but they would no longer send directly to the athlete. Instead, they would hand off a final content payload to athlete-comms, which would act as the single language-review and delivery authority for athlete-facing messaging.

The purpose is to solve a recurring structural problem, not just a style problem:

  • athlete-facing drafts, internal notes, and progress chatter must never be able to reach the athlete
  • wording drift into vague, soft, or non-coaching language must be caught before send
  • all athlete messaging should pass through one consistent review layer for tone, terminology, clarity, and delivery readiness

This proposal makes a sharp distinction between:

  • a workflow gate, where teams, agents, and other processes agree to route messages through athlete-comms
  • a true runtime hard gate, where every other athlete-facing path loses direct send authority and any bypass attempt fails closed

This proposal only succeeds if the second condition is met. If any other agent, cron job, workflow, or process can still send directly to the athlete, then athlete-comms is only an advisory or review layer, not a true hard gate.

This proposal recommends that athlete-comms be treated as an official OpenClaw agent in this workspace architecture, with a narrow and highly controlled role.

Reusability requirement

The athlete-comms role itself must remain athlete-agnostic.

That means the role definition, agent instructions, runtime wiring, and base review behavior must not be hard-coded to any one athlete's identity, tone, preferences, or vocabulary. The same role should be reusable across athletes by changing only the active athlete context and athlete-local preference documents, not by forking or rewriting the agent.

Athlete-specific communication preferences should live outside the role in a separate athlete-local document that can supplement or override generic language behavior.

That athlete-local override document should be used for things such as:

  • words or phrases the athlete dislikes
  • preferred tone or disliked tone
  • preferred spelling, wording, or terminology variants
  • preferred level of directness, warmth, or brevity
  • any other athlete-specific communication constraints that should affect final wording

The role should apply those athlete-local preferences at runtime after loading the active athlete context.

No-code implementation requirement

This proposal should avoid introducing custom Python scripts, JavaScript scripts, or other executable validation layers just to review, score, verify, or approve athlete-facing messages.

The preferred design is a Markdown-and-policy system:

  • role instructions live in Markdown
  • athlete-local language preferences live in Markdown
  • review standards live in Markdown
  • delivery rules and block conditions live in Markdown

The goal is to keep the communication layer understandable, portable, and easy to audit without requiring a separate codebase or script runner.

That means this proposal should not depend on:

  • Python review scripts
  • JavaScript or Node validators
  • external message-quality scoring programs
  • custom executables whose only purpose is to inspect or grade athlete wording

If runtime hard-gating is eventually required, that should be treated as a separate delivery-authority problem, not as a reason to add custom language-review code. The language and policy layer should remain declarative and Markdown-based.

Problem statement

The current system allows Coach Luca workflows to both compose and send athlete-facing messages. Even with strong written rules, that leaves too little separation between:

  • internal reasoning
  • draft composition
  • language review
  • final delivery

That coupling creates two classes of risk:

  1. Delivery-path risk

    • a non-final message, draft fragment, internal note, or progress update can enter the athlete-facing send path

  2. Language-quality risk

    • the coaching content may be directionally correct, but the wording may still be vague, non-elite, imprecise, too soft, too process-heavy, or otherwise below the expected professional standard

A hard outbound gate solves both by separating message authorship from message delivery.

Workflow gate versus runtime hard gate

This distinction is critical.

Workflow gate

A workflow gate means:

  • Coach Luca, other agents, and other workflows are instructed to route athlete messages through athlete-comms
  • athlete-comms reviews, rewrites, or approves final wording
  • the system treats athlete-comms as the standard outbound path

This is useful, but it is still procedural. It does not fully solve the original problem if another path can still send directly.

Runtime hard gate

A runtime hard gate means:

  • only athlete-comms has athlete-send authority
  • every other agent, cron job, workflow, and skill loses direct athlete-send authority
  • any attempt to bypass athlete-comms fails closed at the runtime or delivery layer
  • non-final drafts, status updates, or internal notes cannot reach the athlete because the roles that generate them cannot send to athlete channels

This is the version required to neutralize the higher-level pressure to emit progress updates while working. The higher-level behavior may still exist upstream, but it becomes irrelevant if the agent experiencing that pressure has no power to send directly to the athlete.

Therefore, this proposal should be read as a runtime-authority proposal, not just a review-workflow proposal.

Proposed architecture

Core rule

Only athlete-comms may send messages to the athlete.

No other agent, cron job, workflow, process, or skill should be allowed to deliver athlete-facing text directly.

For clarity, this is not just a preferred routing convention. It is the central success condition of this proposal. If direct send rights remain available anywhere else in the system, then the proposal has not actually created a hard gate.

That includes:

  • Coach Luca direct replies
  • any other agent direct replies
  • morning plan
  • evening summary
  • athlete check-in
  • self-assessment prompts
  • nutrition replies
  • ad hoc athlete follow-ups
  • future specialist-assisted athlete communications
  • any other athlete-facing cron, automation, workflow, or process

Every outbound athlete message must follow this flow:

  1. content is decided by Coach Luca, with specialist input if needed
  2. a candidate message body is prepared for athlete delivery
  3. the candidate is handed to athlete-comms
  4. athlete-comms reviews wording, tone, terminology, clarity, and policy fit
  5. athlete-comms either:
    • approves and sends
    • rewrites and sends
    • blocks and returns for revision

Role boundaries

Coach Luca

Coach Luca remains responsible for:

  • coaching judgment
  • training decisions
  • nutrition decisions
  • planning decisions
  • deciding whether a message should be sent
  • determining which specialists are materially involved
  • ensuring the content itself is correct

Coach Luca should not remain the final delivery authority once the hard-gate model is implemented.

Specialists

Specialists remain responsible for:

  • internal analysis
  • technical input in their domain
  • identifying risks, constraints, and recommendations

Specialists should not send directly to the athlete.

Athlete-comms

athlete-comms is responsible only for the athlete-facing communication layer.

Its job is to:

  • review wording
  • enforce professional coaching terminology
  • preserve the intended meaning of the coaching content
  • catch vague or non-standard language
  • remove internal process language
  • reject draft fragments or non-final bodies
  • enforce the required attribution footer
  • send the approved final message to the athlete
  • apply athlete-local communication preferences from the active athlete context without making the role itself athlete-specific

athlete-comms should have no authority to invent new training decisions, override the actual coaching recommendation, or materially alter the technical content unless the original wording is ambiguous enough to create a meaning problem.

Should the agent run full-time?

Short answer: no, not as an always-active conversational agent.

The recommended model is:

  • athlete-comms exists as an official OpenClaw agent
  • it runs on demand as the final athlete-message gate
  • it is invoked only when there is a candidate athlete-facing message to review and send

Why not full-time?

A full-time always-running language gate would add complexity without much benefit.

The gate does not need to maintain an independent ongoing conversation with the athlete. It needs to perform a narrow control function:

  • receive candidate athlete message
  • evaluate wording and delivery readiness
  • send or block

That is better handled as a single outbound control point, not a permanently active conversational personality.

When it should run

athlete-comms should run whenever any workflow reaches a point where an athlete-facing message is ready to leave the system.

Examples:

  • Coach Luca replies to a same-day athlete message
  • morning plan is ready
  • evening summary is ready
  • nutrition reply is ready
  • self-assessment prompt is ready
  • a direct operational follow-up to the athlete is ready

So the agent should be persistent in architecture, but event-driven in execution.

Should this be an official OpenClaw agent?

Yes.

This proposal recommends that athlete-comms be created as an official OpenClaw agent in the workspace roster, rather than as a loose helper skill.

Why it should be an agent

An agent is more appropriate than a passive skill because this role needs to:

  • receive structured handoff input
  • apply a consistent review persona and review standard
  • make a send or block decision
  • own the final outbound delivery step
  • maintain a stable, auditable responsibility boundary

A skill alone can define instructions, but it does not create a clear authority boundary.

Suggested roster addition:

  • athlete-comms — final athlete-facing language review and outbound delivery gate

This agent should be the only role with authority to execute athlete delivery once the system is migrated to the hard-gate model.

Message flow design

Draft handoff format

Coach Luca should hand off a structured package to athlete-comms, not just a raw paragraph.

Recommended handoff fields:

Field Purpose
recipient Athlete identity and delivery target
message_type Morning plan, evening summary, check-in, nutrition reply, self-assessment, ad hoc reply
content_owner Usually main, with actual contributing specialists listed
must_preserve Technical statements or exact constraints that must not be weakened
candidate_body Proposed athlete-facing body
tone_intent Direct, calm, concise, race-focused, etc.
athlete_language_profile_path Pointer to the active athlete-local communication preference document
delivery_policy Whether send is allowed now, should be blocked, or should await missing data

This structure keeps the review focused on wording and delivery, not on reconstructing the coaching logic from scratch.

The review process should rely on written policy and role instructions, not on custom scripts that attempt to validate wording mechanically.

Athlete-local language profile

To keep the role reusable, athlete-specific wording preferences should live in a separate athlete-local document rather than inside the athlete-comms role definition.

Recommended characteristics of that document:

  • it is optional but supported for every athlete
  • it belongs under the athlete's own workspace area, not under the generic athlete-comms agent
  • it may supplement or override default wording behavior for that athlete only
  • it should be loaded by reference from the active athlete context at runtime

Recommended scope for that document:

  • preferred or prohibited words and phrases
  • tone preferences
  • terminology preferences
  • spelling or style preferences
  • domain-specific wording constraints for symptoms, effort, race language, or training terminology

This keeps the architecture portable. The athlete-comms role remains generic, while each athlete can still carry their own communication rules.

Both the generic role rules and the athlete-local override document should remain plain Markdown artifacts rather than executable review code.

Review outcomes

athlete-comms should produce one of three outcomes:

1. Approve and send

Use when the message is already acceptable.

2. Rewrite and send

Use when the content is correct but the wording needs improvement.

Examples:

  • vague language made more precise
  • wording shifted into stronger coaching terminology
  • internal chatter removed
  • structure tightened
  • attribution footer corrected

3. Block and return

Use when the candidate is unsendable.

Examples:

  • internal progress note
  • partial draft
  • unclear recommendation
  • missing critical context
  • wording that materially distorts the intended coaching meaning
  • missing attribution when required

Hard gate behavior

The hard gate must be literal:

  • if a message has not passed athlete-comms, it cannot be sent to the athlete
  • if athlete-comms blocks the message, the send must fail closed
  • if the candidate message is not final, athlete-comms must send nothing
  • if any other role attempts direct athlete delivery, the runtime should reject it
  • if runtime rejection is not yet available, the system should still be treated as operating in an interim workflow-gate mode rather than claiming a true hard gate

This is the core of the proposal.

Language review standard

What athlete-comms should enforce globally

athlete-comms should evaluate every athlete-facing message for:

  • professional coaching tone
  • sport-specific terminology
  • precision of instruction
  • clarity of execution cues
  • appropriateness for an elite cyclist
  • absence of internal process language
  • absence of vague metaphors or soft filler
  • absence of operator-facing wording
  • absence of therapy-style or corporate-style phrasing
  • consistency with required attribution rules

Reject examples

The agent should reject or rewrite language such as:

  • internal progress chatter
  • "I'm logging this now"
  • "I'll update this first"
  • draft scratchpad fragments
  • vague symptom metaphors like "gets louder"
  • generalized phrases that are not standard high-performance coaching language
  • non-committal filler that weakens a clear recommendation

Preferred language characteristics

The agent should prefer wording that is:

  • direct
  • concrete
  • technically accurate
  • concise
  • coach-like
  • athlete-centered
  • natural for an experienced rider

Tuning model

A major benefit of the athlete-comms design is that language tuning can be separated cleanly into two layers:

  1. a global communication policy
  2. an athlete-specific override layer

This directly supports the requirement that the messaging style can be tuned both generally and per athlete.

Proposed file structure for tuning

Global policy

Create a canonical global file for the communication gate, for example:

  • shared/comms/athlete-comms-policy.md

This file would define the universal rules for all athlete-facing communication.

Suggested contents:

  • role and authority of athlete-comms
  • what the agent may and may not change
  • universal delivery hard-gate rules
  • wording standards
  • banned message classes, for example internal notes and progress chatter
  • attribution enforcement
  • default review checklist
  • fallback behavior when a message is not ready

Athlete-specific tuning file

Create an athlete-level override file, for example:

  • athlete/comms-profile.md

This file would define that athlete's preferred communication tuning.

Suggested contents:

  • preferred directness level
  • preferred warmth level
  • preferred brevity level
  • tolerance for explanation depth
  • sport-specific phrasing preferences
  • words or constructions to avoid
  • how explicitly symptoms, recovery, body composition, or health issues should be discussed
  • whether the athlete responds better to short commands, brief rationale, or slightly fuller framing
  • any athlete-specific formatting preferences

This lets the system hold one universal communications standard while still adapting the final language to the athlete.

Tuning approach

The tuning model should not be an open-ended personality slider.

It should be a constrained set of communication dials within a professional range.

Recommended dials:

Dial Range
Directness low / medium / high
Warmth low / medium / high
Brevity short / medium / detailed
Technical density low / medium / high
Explanation preference minimal / brief rationale / fuller rationale
Symptom language style clinical / coaching / hybrid
Motivation style restrained / moderate / high

The global policy should define safe defaults and allowed bounds. The athlete file should only tune within those bounds.

Suggested default behavior

By default, the agent should favor:

  • high directness
  • medium warmth
  • concise wording
  • high terminology precision
  • low tolerance for vague language
  • no internal process narration

That matches the current Coach Luca performance standard.

Official authority model

Under the hard-gate model, the runtime should enforce this authority rule:

  • only athlete-comms can execute athlete delivery
  • all other agents and processes can draft or request delivery, but not send directly
  • direct send rights must be removed from all other athlete-facing paths

This is stronger than a review convention. It becomes an actual delivery-control boundary.

Without this permission separation, the original failure mode remains possible. A higher-level instruction to emit a status update can still leak into athlete delivery if the role generating that update still has direct send authority.

Minimum viable implementation inside the workspace

If full runtime enforcement is not available immediately, the first implementation can still enforce the model operationally by requiring that:

  • morning plan calls athlete-comms
  • evening summary calls athlete-comms
  • athlete check-in calls athlete-comms
  • nutrition reply calls athlete-comms
  • self-assessment calls athlete-comms
  • ad hoc athlete replies also call athlete-comms

That creates one standard workflow path even before deeper platform enforcement exists.

However, this phase must be described honestly as an interim workflow gate, not a true hard gate. It reduces risk, but it does not eliminate bypass risk until direct-send rights are removed elsewhere.

Runtime-level ideal state

The ideal long-term state is platform support that can enforce:

  • outbound athlete target is restricted to one agent role
  • any non-gateway send attempt fails closed
  • only approved final message bodies can be delivered
  • cron jobs and other workflow entry points cannot directly deliver to athlete channels
  • direct reply rights are removed from all non-athlete-comms athlete-facing paths

That is the true hard gate.

Risks and tradeoffs

Benefits

  • much lower risk of internal-note leakage
  • much lower risk of vague or non-professional athlete wording
  • consistent athlete-facing tone across workflows
  • clear boundary between content generation and delivery
  • auditable responsibility for final athlete messaging
  • scalable tuning model for multiple athletes

Costs

  • extra workflow step before send
  • more architecture to maintain
  • potential latency increase for some replies
  • need for careful design so the gate does not rewrite away the intended coaching meaning

Failure modes to guard against

  • athlete-comms becoming too stylistic and changing content meaning
  • athlete-comms becoming too generic and flattening athlete individuality
  • direct-send legacy paths remaining in place and bypassing the gate
  • tuning files becoming vague or contradictory

Recommendation

Proceed with this proposal, but only as a true authority-boundary project.

The recurring issue is structural, not just instructional. A dedicated athlete-comms hard gate is the cleanest way to separate:

  • coaching decision-making
  • language review
  • final delivery

The recommended design is:

  • create athlete-comms as an official OpenClaw agent
  • run it on demand, not as a full-time conversational agent
  • make it the only approved outbound athlete delivery authority
  • remove direct send rights from all other athlete-facing paths
  • treat any remaining direct-send path as an implementation blocker for calling the system a hard gate
  • give it a two-layer tuning model:
    • global communication policy
    • athlete-specific communication profile

Proposed implementation phases

Phase 1, proposal and interface design

  • finalize the authority model
  • define the handoff schema
  • define the global policy file
  • define the athlete tuning file
  • define block, rewrite, and approve behavior

Phase 2, workspace implementation

  • add the athlete-comms agent
  • create the policy and athlete tuning files
  • route major athlete-facing workflows through the gate
  • test with dry-run and operator review mode first

Phase 3, enforcement hardening

  • remove or deprecate direct-send paths where possible
  • migrate cron workflows to the gate
  • add failure-closed behavior when the gate blocks or is unavailable

Open questions

The following questions should be resolved before implementation:

  1. Should athlete-comms be allowed to send automatically after rewrite, or should some message types require Coach Luca confirmation first?
  2. Which message classes should be mandatory-review from day one?
  3. Should there be an operator-review mode during early rollout?
  4. What exact file paths should be used for the global policy and athlete tuning profile?
  5. How much athlete-specific tuning should be allowed before it starts weakening the global professional standard?
  6. What exact runtime or delivery-layer change is required to remove direct send rights from all non-athlete-comms athlete-facing paths?
  7. Which current cron jobs, direct reply paths, and workflow entry points would still be able to bypass the gate if implementation stopped at the workflow layer?

Draft decision

Recommended answer to the design questions raised here:

  • Should this agent run full-time? No. It should exist as an official agent, but run on demand as the final outbound gate.
  • Should this be an official OpenClaw agent? Yes. It should be a formal roster role with clear authority boundaries, not just an informal helper skill.
  • What makes this proposal succeed? Direct send rights must be removed from all other athlete-facing paths, including other agents and processes. Without that, the system is only operating in workflow-gate mode, not true hard-gate mode.