Choosing the Right Boundary for the Job
Grok Build's final design question is not “which interface has the most features?” It is which boundary best fits the work: interactive development, unattended automation, or integration into another application. This chapter brings together the shared session and tool runtime, the permission and sandbox stack, parallel work, and continuity. The result is conditional guidance: choose a surface and control posture based on who must approve actions, how much work can run concurrently, what must survive interruption, and what still needs independent verification.
The central conclusion is that Grok Build is one stateful agent runtime presented through different control contracts. The TUI optimizes for a person watching and intervening. Headless mode optimizes for a script consuming a result or an event stream. ACP optimizes for another client owning the presentation and integration. None of those surfaces makes the underlying side effects safe by itself. Safety and reliability come from the layers underneath: typed tools, workspace mediation, permission rules, hooks, sandbox profiles, task ownership, persistence, and current verification.
Three surfaces, one runtime
The TUI is the right boundary when a person needs to watch the agent make decisions and intervene as the work unfolds. The scrollback can show prompts, model messages, tool calls, edits, task activity, and permission interactions together. That visibility is valuable for tasks whose success depends on judgment: a refactor that may touch several modules, a test failure whose cause is uncertain, or a command whose output needs interpretation before the next step. The TUI's cost is attention. A person must remain available for approvals, inspect meaningful changes, and decide when a background task should be retrieved or stopped.
The TUI's default permission posture reflects that relationship. The user can approve individual operations, switch to an automation-oriented mode, or configure narrower rules and hooks. A sandbox profile can add process-level containment, but it may also prevent actions that ordinary development needs. Interactive work is therefore a good fit for a workspace profile or a carefully chosen custom profile when the user wants a useful write area with a bounded reach. It is a poor fit to assume that one permissive mode, by itself, supplies review, containment, and recovery.
Headless mode changes the primary observer from a person to a program. A script can request plain text, a single JSON result, or a newline-delimited event stream. The JSON form can return response text, stop reason, session identity, request identity, turn counts, and usage fields when the backend reports them. The streaming form can expose typed text, thought, tool-call, plan, usage, end, and error events. A consumer should switch on event type rather than parse display prose.
That makes headless mode useful for code review, pre-commit checks, CI tasks, batch transformations, and wrappers that need to resume a multi-step conversation. It also changes what a permission decision means. A non-interactive process cannot answer a prompt that is waiting for a human, so automation should use an explicit permission posture, tool allowlist or denylist, rules, hooks, and sandbox settings rather than relying on an invisible interactive approval. Always-approve can remove ordinary waiting, but deny rules, hooks, and administrator locks still matter. An automation pipeline should fail visibly when its policy cannot authorize an action instead of silently widening access.
Headless output also has an evidence limit. The documentation describes explicit fidelity caveats for partial usage, durations, cost, model breakdowns, and backend-specific fields.