Most agent demos fit into a short loop: receive a request, call a few tools, and return an answer. Real repository work does not. A migration, feature, or investigation can require a plan, dozens of edits, repeated tests, changing evidence, and recovery after the user closes the terminal.

xAI introduced /goal for Grok Build on June 22, 2026 to address that longer horizon. The mode turns an objective into a checklist and has the agent plan, execute, and verify work until it considers the checklist complete. A user can continue sending instructions while the goal runs, inspect status, pause it, resume it, or clear it.

That is an important product step, but “resumable agent” can imply more durability than one feature actually guarantees. A restored plan, a restored terminal session, and a safely resumed external job are three different things. Production systems must reconcile all three.

The /goal control loop

The official announcement describes a deliberate cycle rather than an endless autonomous chat. The agent first interprets the objective and produces a concrete checklist. It executes items, checks results, and updates the checklist. Verification is intended to prevent a task from being marked complete solely because an edit was attempted.

This structure helps with long work because the current objective is represented separately from the most recent conversation turn. A user can ask for status without rewriting the brief. New instructions can alter priorities while the agent is active. The published commands include /goal status, /goal pause, /goal resume, and /goal clear.

The checklist is still an agent-maintained interpretation. It may omit a requirement, use an inadequate test, or mark a weak proxy as success. A good initial objective should name the desired artifact, constraints, acceptance tests, forbidden actions, and the point at which human approval is required.

Goal state, session state, and world state

Long-running work spans three kinds of state:

  1. Goal state contains the objective, checklist, progress notes, and validation claims.
  2. Session state contains the conversation, tool results, model context, and local agent runtime.
  3. World state contains files, commits, cloud jobs, tickets, deployed services, credentials, and approvals that exist outside the model.

Grok Build’s headless documentation separately describes named sessions stored under the user’s Grok directory, along with resume and continue flags. Those controls restore an agent session. /goal manages the longer objective within Grok Build. Neither fact alone means an external API call is replay-safe.

Suppose an agent starts a render, loses its connection, and later resumes. The external render may still be queued, may have completed, or may have failed after charging the account. If the agent only remembers “start render” as an unchecked item, it may submit a second job. If it only remembers “render started,” it may wait forever because the task identifier was never persisted.

What a checkpoint needs to contain

A useful checkpoint is more than a prose summary. For each consequential step, store structured evidence:

The record should live in an application database or versioned task artifact appropriate to the sensitivity, not only in model context. Secrets and signed URLs should not be copied into a goal note. Save a stable asset ID or secret reference instead.

On resume, the controller reads this checkpoint before planning new actions. If a job ID exists, query it. If an output exists, validate it. If the previous state is ambiguous and the operation has side effects, stop for review. Only retry automatically when the service contract or an idempotency key makes duplication safe.

Planning and verification are separate skills

Long-horizon agents often fail by producing an impressive plan with weak completion tests. “Implement authentication” is not verified by the presence of a login file. “Optimize the site” is not verified by a successful build. Acceptance tests need to observe the behavior the user cares about.

For code, that may include targeted unit and integration tests, type checks, security analysis, a rendered UI inspection, and a clean diff. For research, it includes source freshness and citation checks. For an external job, it includes authoritative completion status and output validation.

Verification should be independent where risk is high. The same model that made an assumption can repeat it while reviewing its own work. Deterministic tests, schema validators, media probes, and human checkpoints provide stronger evidence. /goal supplies a place to organize these stages; it does not make every test sufficient.

Safe interruption and changing instructions

The ability to send guidance while work continues is useful when requirements evolve. It also creates race conditions. A new message may invalidate a step already in flight. Pausing the agent cannot necessarily cancel a command or external service that has already accepted a job.

Define interruption semantics before automation:

When instructions conflict, require an explicit decision. Do not silently rewrite the goal history. An audit trail should explain why a completed item became pending or why an existing artifact was abandoned.

Limits of long-running autonomy

Longer duration magnifies ordinary agent risks. Context can drift, dependencies can change, credentials can expire, costs can accumulate, and untrusted tool output can inject new instructions. A broad initial permission can remain active long after the user remembers granting it.

Use time, token, tool-call, and monetary budgets. Restrict filesystem and network scope. Pin extensions and review hooks. Require confirmation before deployment, deletion, publication, payments, or use of sensitive media. Emit a heartbeat so operators can distinguish slow progress from a stalled loop.

The declaration of completion should include evidence: which checklist items passed, which tests ran, what changed, what remains uncertain, and which external operations are still active. “All boxes checked” is an interface state, not proof by itself.

Resuming a Medux media task without duplicating it

The same principles apply when a coding agent coordinates Medux, although /goal and Medux are separate products with no implied native integration. The Codex video-editing tutorial demonstrates a signed-upload and asynchronous-task sequence. The Claude video-merge tutorial shows a similar flow from another agent host. In each case, Medux Remote MCP must be configured and authorized independently.

Consider a goal to merge two approved clips and verify the output. Before submission, the controller records the ordered input file hashes and Medux file identifiers. When the merge tool returns a task ID, that ID becomes the authoritative handle. The goal checklist can say “merge submitted,” but the durable record must contain the actual task ID.

If the agent pauses or its session ends, a resumed controller should query that task. A queued or processing state means wait and poll at a controlled interval. A completed state means retrieve the result URL and validate the MP4. A failed state means inspect the error and decide whether the same inputs can be retried. A missing or indeterminate state should trigger review before any resubmission.

Signed upload URLs are temporary credentials, not durable state. If an upload URL expires before the bytes are sent, request a new upload slot or follow the documented recovery path. Do not create a second media task merely because a URL used earlier is no longer visible in the agent transcript.

The acceptance evidence can include clip order, duration, resolution, codec, audio continuity, and successful playback. Only after those checks should /goal mark the media item complete. Grok Build can organize the long-running objective; Codex or Claude can organize the same pattern in their own environments; Medux reports the processing state. Reliability comes from reconciling those layers, not from assuming one resume button controls them all.