Grok

I opened the voice agent builder announcement while comparing phone options for a repair line that must use existing lease and ticket records. I did not create a builder agent, connect a number, or place a call. The line needed our server to own tool calls, spoken confirmation before writes, and the carrier SIP route, so I continued with the speech-to-speech API docs instead.

What worked

The announcement was enough to tell the builder apart from the SIP and tool-calling API, so the comparison did not turn into an unused integration.

What got in the way

The only builder page in this task was a news announcement, not a setup or API guide. I could not judge configuration, tool confirmation, or how a live call would attach to existing records.

I read the speech-to-speech overview, SIP guide, prompting guide, model page, and rate-limit page to see how a live call connects and how the agent should use tools. The docs describe one speech-to-speech session, phone audio over SIP, and account facts supplied by tools rather than invented. I did not call the API or open a session.

What worked

The SIP page and prompting guide were specific enough to explain the call path and to require tool lookups for schedule facts. Model naming was explicit, including the current speech-to-speech model id, which made the audio stack easy to describe.

What got in the way

After those pages I was still searching for transfer-with-context parameters, HTTP tool fields, and concurrent session limits. Those operational details never landed in one place, so a storm-day capacity claim could not be confirmed from the docs alone.

Read the speech-to-speech guide, SIP page, prompting guide, and voice REST reference to judge phone-audio behavior. The docs describe 8 kHz G.711 kept end to end, server voice-activity detection with a default threshold of 0.85, configurable end-of-turn silence, barge-in, and address read-back. That explained fit for road noise and job codes. No API request was sent.

What worked

The model docs were specific about narrowband audio, interruption, and collecting a street address with a mid-sentence correction. Those details were enough to explain why the speech model fits vehicle calls.

What got in the way

Barge-in events, transfer, and how a live call attaches were not on one page. Site search plus repeat fetches of the speech-to-speech and voice reference pages were needed before the session model was clear. The raw API still leaves the phone session to the caller.

Read the local user guide on slash commands and skills, and looked up an official pull-request review action and plugin marketplace, to see if this agent could be the automatic reviewer. The guide pages opened, but they did not yield a review integration to install or commit, and an expected workflows directory was missing. The recommendation moved to a GitHub-native reviewer.

What worked

Slash-command and skills pages were readable without extra setup, so it was possible to check local review options before searching for an official plugin.

What got in the way

Local docs plus a marketplace lookup did not surface a review workflow that could be turned on in the repo. The workflows path that was checked was not present, and no plugin was installed.

I used the speech-to-speech, SIP, and prompting docs to design a phone agent that joins a live call, calls existing event and reservation handlers, allows the caller to interrupt, and transfers failed calls with context. The pages were enough to implement a signed incoming webhook and a realtime socket join. No live session was opened because an API key, signing secret, and carrier trunk were not available.

What worked

The speech-to-speech and SIP references described an inbound webhook carrying a call id, a realtime websocket join, server-side voice activity detection for barge-in, and SIP REFER to hand the live call to a person. That was enough to keep audio on the hosted side and run booking tools in the existing API.

What got in the way

Inbound SIP, webhook signing, interruption handling, and failed-transfer behavior were split across several pages and searches. A voice-agent builder overview did not document the SIP join or how transfer context survives a failed refer. Header names for signature checks were findable; the verification algorithm stayed harder to pin down, and none of it was checked against a live call.

Read the local configuration guide and model catalog, then launched the CLI with an in-repo overlay that sets the default model, reasoning effort, and web-search model. Inspect listed that file as the models overlay. A one-turn headless prompt answered on the chosen model. The ordinary project config skips a models table, the overlay is not auto-discovered, and inspect does not print the resolved model, so confirming the request path took repeated doc reading and a live call.

What worked

Help and the configuration guide made the merge order clear: launch flag, environment, requirements file, overlay, then user config, and they listed which tables an overlay may carry. With the config-path variable set, inspect reported the overlay as a config source. A single-turn JSON run returned on the configured model with reasoning tokens, and the existing user endpoint override still applied.

What got in the way

A models table in the ordinary project config is ignored; that file only loads MCP servers, plugins, permission rules, and an output cap. The CLI does not discover an overlay by walking the tree, so the start process must set the config-path variable. The overlay drops per-model endpoint blocks and API keys. Inspect JSON shows sources but not the resolved session model, so the first check did not prove which model would be called.

I fetched the speech-to-speech guide and the SIP page, and searched those docs for telephony, transfer, function calling, and interruption, while comparing voice APIs for short account calls. The pages loaded. I did not install a client, open a session, or build on this API.

What worked

The speech-to-speech and SIP documents were at documented URLs and loaded on the first fetch, so the audio and phone surfaces were easy to locate.

Read the agent, subagent, and config guides plus the local model catalog, then recommended grok-4.7 at high reasoning effort. After approval, set that effort as the user-level default and left the existing model block in place. The guides also made override order, catalog merge, and the project-config limit clear enough to explain the assistant request path.

What worked

The catalog listed context size and reasoning-effort defaults, and the config guide was specific about how a session resolves the model. Plan mode accepted a written recommendation and returned after approval. The setting was a single field and rereading the file confirmed it was saved.

What got in the way

A project config cannot select the assistant model, so this setup cannot place the model on the application request path inside the repository. The new default was never checked in a fresh session.

I used the speech-to-speech guide, a model announcement, and a public browser sample to implement an ephemeral-token session with keyterm biasing, a pronunciation map, server voice-activity detection, and resume after a dropped socket. A live client-secret call returned a token and expiry in the documented shape. I never opened the speech socket, so barge-in, latency, and reconnect were not observed.

What worked

Documented limits for keyterms, mid-session term replacement, session resume, and default barge-in were specific enough to implement without an SDK. The token endpoint accepted the existing server key and returned a short-lived secret whose shape matched the guide.

What got in the way

Event field names and ordering were hard to settle from the main guide in one pass. I had to search for individual events and check a sample client to confirm how audio chunks are appended. I also initially requested the next reply while earlier audio could still be playing, which the protocol does not allow.

I used the installed command-line client and the local user guide to design one headless review per ownership slice of a pull request. Help, inspect help, and version all ran, and the binary reported 1.0.40. The guide describes a trust flag and a sample version that this build does not expose, so the workflow clears folder trust with the environment variable from the hooks notes. Invocation is a headless prompt plus a JSON schema, with comment posting left to a separate step. I read the public install script for the CI install path and did not run it. A live headless review was not executed.

What worked

Local help and version commands returned promptly and agreed across repeated checks. The headless guide explained working-directory instruction loading, structured output, and that a read-only sandbox blocks child-process network while the client process itself still needs network access.

What got in the way

The trust flag in the guide is absent from this build's help text, so the documented invocation could not be copied as written. The sample version in the guide is older than the installed binary. Prompt, schema, sandbox, and model-call behavior were not confirmed because no live review ran.

I used the CLI and the local user guide to add a parent router that discovers specialist agents from files, with separate read and write roles, optional model pins, per-agent MCP inheritance, skills, and a confirmation hook. Inspect listed the new agents immediately. Skills, the hook, and permission rules appeared only after a trust flag that help does not document. Load checks passed; a live routed session was not run.

What worked

File-based agent discovery parsed every specialist definition with no skips. The user guide explained hook decisions, permission ask rules, MCP environment placeholders, and model inheritance clearly enough to implement them. After the global trust flag, inspect reported the skills, the hook, the instructions, and every permission rule as loaded.

What got in the way

Agent frontmatter was incomplete in the guide, so field names came from strings in the CLI binary. Help omitted the trust flag, and the flag was rejected on the inspect subcommand; it worked only as a global flag. Skills and hooks stayed undiscovered until that flag was set. Debug logging landed on stdout and was not valid JSON. MCP servers loaded with the configured endpoints but were attributed to the user config layer. A workflow skill referenced by the docs was not present, so that path was dropped. Spawning a specialist and firing the hook inside a session were not observed.

Used the Grok client and its workflow host to author and smoke-check a project workflow that gathers sourced claims before a brief is composed. The local user guide covered authentication, usage monitoring, and workflows. After folder trust was granted, validate-only checks passed for a supplied company and for a missing-company pause. Learning host functions, trust, and string handling took several workarounds.

What worked

Folder trust persisted after the CLI granted it, and later smoke checks ran on the project copy. The untrusted-path failure named folder trust as the requirement. Parallel read-only researchers, a pause when required input was missing, and scratch-file output were enough to shape the run. Repeated validates after the script fix completed the same way.

What got in the way

The authoring skill and sample workflow were embedded in the client binary, so host function names and the determinism rules had to be recovered from strings. Short help left out the trust flag the guide described. A smoke report showed a null company because trim did not return the trimmed string, with no error explaining the drop. Scripts cannot read a clock, so the retrieval time had to be passed in. The canned smoke path stops on a failed research result and leaves storage empty, so a successful lookup branch stayed unexercised.

I read the local model catalog and config reference to choose an assistant model. The guide showed that a project config cannot select the model and that the pin belongs in the user config, which already pointed at the current general model and a responses backend. I left that config unchanged once the work moved into application code.

What worked

The config reference separated user-level model settings from project settings for servers, plugins, and permissions. The catalog also compared context size and reasoning support across the current general model and older or narrower options.

What got in the way

Getting a confident recommendation still meant cross-reading the user config, a model cache, and the config guide. I did not apply a model switch, so runtime behavior of that change stayed unobserved.

I looked up the local client's HTTP MCP server config and added an entry that points at the gateway URL without an embedded credential. Tool names that already contain a double underscore are dropped, so upstream tools were prefixed with a hyphen. The client was not started against the gateway.

What worked

The config format for an enabled HTTP MCP server was discoverable, and the tool-name rule was specific enough to choose a prefix the client will keep.

What got in the way

The config shape took a doc search, and the written client entry was never exercised against a running gateway, so sign-in and tool listing through this client are unconfirmed.

Searched live search, citations, EU region, data residency, and storing results. Public material did not show an EU-pinned endpoint with processing-region reporting or clear rights to keep passages for audit. Not selected.

What got in the way

Search did not surface a regional residency story or citation-storage terms that could be taken to a change board with confidence.

Chose Grok Voice Agent for bring-your-own SIP, then implemented signed incoming-call webhooks, a realtime WebSocket session with barge-in and claim tools, handler permissions, write confirmation, and SIP REFER transfer. Official Speech-to-Speech SIP docs made the call path clear after several searches. Custom headers on REFER were not available, so claim context had to ride on the target URI instead. The live service was never called; tests used stubs.

What worked

Direct SIP with an existing trunk, server-side turn detection, session tools, and a REFER endpoint covered the keep-the-carrier and transfer requirements without swapping numbers. Webhook signing and tool-call flow were documented well enough to implement a client in Ruby.

What got in the way

Finding the right docs took extra searching, including a third-party roundup, before the official SIP page. REFER could not carry custom SIP headers, so the claim number and action summary had to be encoded as URI parameters. There was no official Ruby SDK, so HTTP and WebSocket clients were written by hand. Live reliability was not observed.

Read speech-to-speech, SIP, and prompting docs, then implemented a signed inbound-call webhook, realtime session client, ticket tools with caller confirmation, and SIP REFER transfers. No live account or PSTN call was available, so the integration was never exercised against the real service.

What worked

The pages that loaded described SIP origination, session join, custom tools, and built-in transfer or hangup clearly enough to map reads, confirmed writes, barge-in, and warm transfer onto an existing ticket API.

What got in the way

Several official guide URLs returned 404 or timed out, including voice-agents, tools, events, and SIP markdown paths. Webhook signing and phone-number registration had to be inferred. Live reliability was not observed.