Send a message to the AI athlete assistant
Send a chat message to the AI assistant. Normal clients use the same request and two-item athlete/assistant response envelope; approved evaluation clients may additionally correlate a QA Scenario Lab run for cleanup. *
- Loop dispatch: After the global feature gate, athlete allowlist, request validation, idempotent replay lookup, conversation lifecycle checks, and any server-handled Deal Folder reminder reply, every message uses the bounded tool loop. There is no server-side engine selection. Duplicate
client_message_idexecution remains serialized for longer than the bounded outbound request plus persistence and delivery side effects. - Loop routing: Free text, exact server-rendered quick-button labels, and ordinal references are interpreted by the loop through its authorized tool surface. A complete legacy
scope=deal/deal_type/job_idtuple is still parsed, authorized, and logged for compatibility, but it does not choose the loop’s route or bypass tool authorization. Invalid or unauthorized complete tuples are rejected without numeric coercion. - Deterministic loop fast paths: Explicit MOGL Support requests and reviewed safe no-deal knowledge questions may return the same strict loop result without model or tool calls. All other loop turns use bounded model/tool budgets. Public source IDs are filtered to successful current-turn evidence; malformed or contradictory loop results fail closed rather than exposing untrusted data.
- Loop portfolio parity: A fresh unqualified portfolio request is normalized to all lifecycles, the
allsegment, and offset zero. Overview output is grouped from canonical server counts across current and historical deals; count output uses the canonical requested-segment total rather than page length. List output preserves backend order and renders each deal once. Lists of three or fewer deals may include next-deliverable and next-action detail, while lists of four or more remain compact. Multiple actions compose in the fixed overview, count, list, guidance order. Athlete-facing active, open, current, and high-level in-progress requests usework_remaining(in_progress+resubmit_needed). Legacyactiveremains a deprecated compatibility count. Thevoidedsegment includes fully voided deals plus partial-void conditions; exclusivesummary_counts.voidedcounts fully voided deals only. - Conversation handling:
conversation_idis the canonical conversation identifier.session_idis accepted as a backwards-compatible alias. If neither is supplied, or the supplied conversation cannot be reused, the server creates a new conversation. Normal clients usemessage,client_message_id, andconversation_idorsession_id. After idle session rotation, a tap that matches the current persisted Deal Folder nudge label is resolved server-side; clients do not send action IDs or reply-to turn IDs. - Evaluation cleanup correlation: Approved non-production evaluation athletes may provide
qa_scenario_run_idtogether with one requested conversation UUID inconversation_id(or itssession_idalias). Before Assistant dispatch, Laravel creates and manifests that exact dedicated session, canonically bound to the fixture-created job; a retry may reuse it only when it is already a Created session entity of the same run and athlete. This prevents fallback to another active athlete session and leaves failed processing cleanup-owned. Persisted portfolio turns and logs may havejob_id=null; non-null values must match the fixture job. Normal athletes, mismatched runs/jobs/sessions, cross-athlete requests, and cross-run attachments fail validation. Clients cannot supply entity IDs. - Historical turns: Turns persisted by the retired v3 semantic-routing path remain readable through idempotent replay and history. They keep their stored
context_resolution, quick-button labels, andclarification_draftlinkage; no new turn is created by that path. - Quick buttons: AI answer-stage suggestions are suppressed, and athlete-prompted loop responses return an empty list. Historical v3 turns replay their persisted labels. Proactive assistant turns may also return up to three server-owned suggestions. Deal Folder reminder buttons name the deal and item; tapping a label, a brand-draft button, or a support button is handled by the existing chat, clarification-draft, and support-mailto paths (never auto-sent).
- Hybrid answer contract (jobs only): In the answer stage,
direct_answer_with_clarificationreturns both a factual answer and a persisted brand-message draft, and draft-bearing job responses return a non-nullclarification_draftwith no quick buttons. Brand draft text is validated natural brand-facing copy; machine-only clarification reasons/topics remain tracing metadata and known internal namespaces are repaired or rejected before persistence. A historical v3 routing clarification is the exception on replay: it may useresponse_type=clarificationbut returnsclarification_draft=nulland may expose bounded deal-choice buttons. - Contact support: Existing job-scoped support remains supported. A no-deal support request uses
assistant_help/support_contact, returnsjob_id=nullandresolved_job_ids=[], and may returnresponse_type=escalation, a sanitizedsupport_request_summary, and a proposal-onlysupport_actionmailto. The athlete must click, review, and send the email; the backend never sends it automatically. For example, “Please contact MOGL support about my payout” can return an escalation with the summary “I need help resolving a payout issue.” and no deal metadata. The athlete-facing label ispre-filled in email here. - Knowledge lookup: A safe no-deal KB question uses
assistant_help/knowledge_lookupand returns a direct curated answer with itsathlete_kb:*source IDs. It hasjob_id=null,resolved_job_ids=[], no support summary/action, no clarification draft, and no quick buttons. For example, “What is MOGL?” can return a direct MOGL overview sourced byathlete_kb:what-is-mogl. - Access control: Athlete must be allowlisted. Portfolio data is rebuilt from the authenticated athlete’s authorized jobs. Job-scoped questions require a non-cancelled application. Fan requests require ownership (
fan_request_service.athlete_id). Returns 403 otherwise.
Authorizations
JWT Bearer token authentication. Use the /api/login endpoint to obtain a token.
Body
The athlete's message to the assistant (max 2000 characters).
2000"Which 3 am I waiting on payment for?"
Legacy compatibility discriminator. With allowlisted deal_type and a strictly integral positive job_id it forms a complete tuple. The tuple is authorized and logged for compatibility; it does not direct loop tool selection. Partial tuples are logged and discarded.
athlete, deal "deal"
Legacy tuple type: job references a partner job and fan_req references an athlete-owned, non-deleted fan service request. The complete tuple is authorized but does not route the turn; the loop resolves the message through authorized tools.
job, fan_req "job"
Polymorphic legacy tuple ID: partner_jobs.id for job or fan_request_service.id for fan_req. Laravel authorizes and logs complete tuples, rejects invalid or unauthorized values, and never truncates decimal or floating-point values. The value does not direct loop routing.
x >= 142
Canonical ID of an existing conversation to continue. When qa_scenario_run_id is supplied, this (or session_id) must be a UUID and becomes the exact dedicated run-owned session; both aliases may be sent only when identical.
255"550e8400-e29b-41d4-a716-446655440000"
Backwards-compatible alias for conversation_id. When qa_scenario_run_id is supplied, this (or conversation_id) must be a UUID; both aliases may be sent only when identical.
255"550e8400-e29b-41d4-a716-446655440000"
Idempotency key required for modern requests. Optional only for legacy payloads that include a non-null deal_type or job_id.
64"8dc1b7b7-716e-4f26-b4fa-cc9c8d300c18"
Optional evaluation-only cleanup correlation. Requires one requested conversation UUID. Accepted only for a server-approved non-production evaluation athlete and a matching succeeded single-athlete run of an evaluation-correlated scenario (evaluation.recent_hire_support_escalation@1, files.mixed_deliverables@1, files.needs_review@1, or files.revision_requested@1) in the current environment. The server reserves that exact run-owned session before dispatch and derives all attached turn entity IDs from persisted data; clients cannot supply them.
"44444444-4444-4444-8444-444444444444"
Deprecated compatibility field from the retired v3 path. It is still validated and accepted from released clients but does not route the turn; the loop resolves the message through its tools and does not promise cursor continuation for arbitrary lists.
512Response
Message sent. Returns the two-item envelope containing the athlete message and assistant reply plus required server-derived evaluation metadata. Clients cannot enable, disable, or spoof metadata values: both booleans are false for normal athletes and true only for approved non-production evaluation athletes. New turns return a loop-1 trace context_resolution; replayed historical v3 turns return their stored semantic context_resolution; top-level compatibility fields remain available in both cases. Loop-1 portfolio turns may persist optional strict compact portfolio_state metadata inside context_resolution for trusted continuity, without exposing raw tool arguments or full results. No-deal support replies may include a sanitized support_request_summary and review-only support_action. Safe knowledge replies contain curated text/source IDs and omit support actions, drafts, and buttons.
"success"
"Message Sent Successfully!"
Server-derived evaluation and notification-safety metadata. Clients cannot enable, disable, or spoof these values. Both fields are false for normal athletes and true only for approved non-production evaluation athletes.