Feature request: expose create_goal to the model so Grok can start a Goal itself

[2836603852]

Feature request: model-facing create_goal in Grok Build

Audience: Grok Build / xAI harness team
Filed here because: xai-org/grok-build has Issues disabled. This follows the same public-channel workaround as #147.

Problem

Today a persistent Goal can only be started by the user (/goal ...). When background workflows are on (the default), the host owns the goal loop and the model does not receive create_goal / update_goal in the tool list.

Codex exposes create_goal / get_goal / update_goal to the model (create only when no goal exists). Kimi Code exposes CreateGoal. Grok cannot decide to persist a long-running objective on its own, even when the task clearly needs multi-round continuation and a verifiable done-when.

This is a product-capability gap, not a prompt-policy gap. The model cannot “just hang a Goal” because the tool is not there.

Request

Expose a restricted model-facing Goal tool surface:

Tool	Model may
get_goal	Read the current Goal, if any
create_goal	Create only when no Goal is active
update_goal	Report progress / request completion verification

Keep user/runtime-only:

• /goal as the user entry point
• pause / resume / clear
• token budget
• adversarial completion verification

Do not auto-create a Goal for every prompt. The model should only create one when the work is multi-round, retryable, and has a concrete done-when. Ordinary Q&A, one-shot edits, and reviews must stay Goal-free.

Why this design

Codex already uses this split: the model can start and complete a Goal, but cannot seize pause/resume/clear. That is enough for long tasks without giving the agent control of the whole lifecycle.

Grok’s skeptic/evidence gate on completion should stay host-owned. This request is only about who may start a Goal.

Suggested acceptance

1. With goal mode enabled, an interactive session includes get_goal and create_goal in the model tool list.
2. create_goal fails closed if a Goal is already active.
3. After a successful create_goal, the existing host continuation + evidence review path runs unchanged.
4. /goal pause|resume|clear remain user/runtime only.
5. Docs state that model-created Goals use the same verification as /goal.
6. Default policy does not create a Goal unless the model explicitly calls create_goal.

Non-goals

• Replacing /goal
• Letting the model pause, resume, clear, or raise the token budget
• Weakening completion verification
• Auto-Goal on every user message

Ask

Please consider giving the model the same narrow create/read/complete surface Codex already ships, while leaving lifecycle control with the user and the host.