Skip to content

Make agent onboarding operator-light and self-healing #37

Description

@mostlydev

Problem

Model-driven onboarding currently requires the operator to run nearly every command, paste each result back into chat, and confirm after every one-to-three-command set. That makes the AI act mainly as a narrated runbook and creates substantial friction during first-machine setup.

The agent is already capable of safely doing most of this work: checking prerequisites, syncing a registered manifest, running setup, inspecting tools, installing local dependencies, rerunning failed steps, and validating the result. The operator should provide intent and approve meaningful boundaries—not serve as the command transport.

Dogfood example

On a first-machine JOIN_BOOTSTRAP flow on Linux ARM64:

  1. The operator manually checked Git, GitHub CLI, authentication, manifest sync, roles, setup, tools, and doctor in separate conversational turns.
  2. A required tool had no ARM64 release artifact. The agent was able to clone its public repository, install the Rust prerequisite, run 133 tests, build it locally, install it under ~/.local/bin, and verify it.
  3. Setup then failed with invalid_actor_response, even though gh api user returned a valid numeric id, node_id, and login.
  4. The cause was a gh launcher earlier on PATH that prints Mise status text to stdout before the API JSON. internal/access.ResolveGitHubActor attempts to unmarshal the entire command output as JSON, so harmless launcher output makes identity validation fail.

This is exactly the kind of routine diagnosis and remediation an onboarding agent should perform directly while keeping the operator informed.

Proposed behavior

Make agent-operated onboarding autonomous by default:

  • The agent runs safe, in-scope setup commands itself and narrates what it is doing.
  • It batches routine checks instead of requiring a confirmation round trip after every small command set.
  • It pauses only when the human must act or decide: authentication UI, a privilege/password prompt, policy acceptance, a material configuration choice, destructive work, or an outward publication.
  • When sudo is required, it gives the operator one exact command to run locally and resumes after confirmation; it never asks for a password in chat.
  • It installs manifest-declared tools when the install source is explicit and safe, handles architecture-specific failures, and validates the result. Optional tools remain opt-in.
  • It diagnoses errors, resolves one root cause at a time, and reruns the deterministic continuation command without making the operator relay every diagnostic command.
  • Keep a manual/learn-by-example mode for operators who explicitly want it, rather than making that the only onboarding experience.

Retain the existing safety boundaries:

  • Never collect or store literal secrets.
  • Never accept policy on the operator's behalf.
  • Never hand-edit manifests or generated files.
  • Run validation/setup/doctor/compile gates before publication.
  • Preview publication and require explicit human approval before a real publish.

Robustness follow-up exposed by onboarding

GitHub API parsing should not assume every executable named gh produces JSON and nothing else on stdout. Options include resolving the validated GitHub CLI binary rather than an earlier launcher, separating wrapper diagnostics reliably, or parsing a single valid API JSON payload with a clear diagnostic when surrounding output exists. Add a regression test where the runner returns a status prelude followed by a complete actor object.

Acceptance criteria

  • A JOIN_BOOTSTRAP agent can complete all reversible/local steps without asking the operator to type each command.
  • The operator is interrupted only for the explicit human boundaries above.
  • The existing fully manual walkthrough remains available as an option.
  • Onboarding tests cover automatic prerequisite checks, missing required-tool remediation, privilege handoff, retrying the continuation command, and noisy gh launcher output.
  • Failure summaries show what the agent tried, what changed, and the single next human action when one is genuinely required.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions