#Choose an Agent
An Agent-capable Flow asks Jig to perform intelligent work. You choose the client, model, and credentials on the host; the Flow supplies the task and its selected Skills. Ordinary Flows that do not call an Agent need no configuration.
Run jig review in a terminal. If the project uses an Agent and you have not
selected one, Jig lists clients with available local configuration and asks you
to choose. It remembers that client for this project on your machine; subsequent
reviews and Runs reuse it. Projects without Agent capabilities need no choice.
Unavailable clients appear in a short secondary line. Use jig review --details
to expand their setup instructions; Jig shows those instructions automatically
when no client is usable.
The menu labels native clients as supporting live updates and API clients as supporting the final result only. The current declarations do not establish whether Flow code needs live Agent updates, so the menu cannot guarantee that an API client supports every runtime call. A Flow that requests those updates needs a native client. No extra project configuration is required for the menu.
Jig reads exported model and credential variables for both jig review and
jig run. Project .env files are not loaded automatically. Credentials being
present do not select an Agent. The menu makes no model requests.
For scripts, set JIG_AGENT_CLIENT to codex, claude, pi, or api, or use
an existing remembered choice. --yes approves the displayed revision; it
does not choose an Agent. Explicit selection takes precedence over a remembered
choice. Selection and execution approval remain separate.
#API access
Choose API access in the menu, or set JIG_AGENT_CLIENT=api.
For OpenRouter, export OPENROUTER_API_KEY and OPENROUTER_MODEL. Jig selects
OpenRouter's Chat Completions endpoint; there is no need to rename these
variables to OPENAI_*.
For direct OpenAI access, export OPENAI_API_KEY and OPENAI_MODEL. An
OpenAI-compatible service can additionally set OPENAI_BASE_URL to its HTTPS
endpoint and OPENAI_API to responses or chat-completions. The default
wire format is responses; Jig supplies no default model.
Select one API variable family at a time. If both OpenRouter and OpenAI variables are present, Jig asks you to resolve the ambiguity.
#Local clients
Choose a native client in the review menu, or set JIG_AGENT_CLIENT explicitly
to codex, claude, or pi. For example, in automation:
The current native adapters use ACP to request bounded Agent work. They do not grant the Agent a terminal or access to your original repository. Client-specific requirements are listed in the Agent Run specification.
Jig finds the selected native client on your exported PATH, including an
operator-managed profile or nix-shell. You can select a particular executable
with an absolute CODEX_PATH, CLAUDE_PATH, or PI_PATH. An invalid override
must be corrected or unset; it does not fall back to PATH discovery. Review
shows the resolved executable so you can check which installation you selected.
Discovery skips relative PATH entries, the project tree, and ancestor
node_modules directories, including symlink routes through them. Shell aliases
are not visible to Jig. The adapters require supported native installations;
a shell wrapper or npm JavaScript launcher is not itself the native executable.
#Codex
Install Codex and sign in as the OS user running Jig, using Codex's login instructions. Jig supports standalone Linux x86-64 Codex binaries and native packages using Nix's binary PATH wrapper. It retains the executable and required shared libraries as individual reviewed files.
For Codex's nested sandbox, Jig selects an unprivileged bwrap from the
installation wrapper's PATH prefix or your exported PATH. If none is available,
it uses the installation's matching codex-resources/bwrap. You do not need that
bundled directory when your package supplies Bubblewrap separately.
JIG_BWRAP_PATH configures only Jig's outer containment tool.
The current adapter reads a file-backed login from $CODEX_HOME/auth.json,
defaulting to ~/.codex/auth.json. Configure Codex with
cli_auth_credentials_store = "file" before signing in. Jig does not currently
read Codex's OS-keyring credentials.
The current adapter supplies a short-lived credential to the contained client; it does not give it your full authentication store or refresh credentials.
#Switching
Choose the new client or API configuration, then run jig review again.
Client, endpoint, model, and executable changes affect the admitted execution
identity. Use the same selection for the subsequent jig run; rotating only
a credential does not require another review.
To select API access explicitly, set JIG_AGENT_CLIENT=api and export the
chosen API variables. Unsetting JIG_AGENT_CLIENT restores a remembered choice;
it does not select API access. A missing or incompatible client produces
an unavailable diagnostic; Jig does not silently select another provider.
The prompted choice is saved immediately, even if you later decline approval.
It stores only the client name in your operator state directory
($XDG_STATE_HOME/jig/agent-choices, normally ~/.local/state/jig/agent-choices),
separately for each canonical project directory. Credentials remain in your
existing environment or client login. Copying a project does not copy this choice.
#Build your first Agent method
Turn a support request into a draft reply, without sending it to anyone.
Start inside the hello-jig project from the quickstart, with
an Agent configured as described above; review can prompt for the client.
This keeps the greeting and adds a second ordinary Flow—no new project configuration is needed because
jig.ts already discovers flows/.
These downloads are package-local contract files, not API endpoints or credentials. Inspect them before approving the package. The second file is referenced by the Agent contract even though this method uses no live channel. The copied manifest keeps the same exact SDK dependency as your greeting; you do not run an installer inside either Flow.
Create flows/reply/FLOW.md:
Create flows/reply/input.schema.json:
Create flows/reply/flow.ts:
Review the source and newly requested Agent power, approve it, then run:
Expect Execution: completed, application outcome done, and a draft with
reviewRequired: true. The wording varies by model. blocked, limit, or a
failed Run must remain visible; they are not a usable draft. Execution completion
does not establish factual accuracy. The instructions are guidance, not a proved
prompt-injection defense, and this Flow has no capability to send the reply.
Only use synthetic or otherwise approved records: the request goes to your selected provider, whose data policy is separate from Jig's containment. Review checks local configuration, not remote availability. The two-minute deadline bounds work; Ctrl-C cancels local work and waits for cleanup but cannot retract an already accepted remote request.
Try --input '{"message":"hello"}': Jig rejects the object before calling
the Agent and identifies the expected string input. Then change the instructions
to request a one-sentence reply, review the changed source, and rerun. Until
approval, the retained method is unchanged. Keep the same provider selection
for review and run.
Once this single method is useful, compose code and Agent methods through a caller that does not need to know how each method works.