Callbacks

1. Open Agents → Request a callback.
2. Choose an Agent / project, or choose Any agent to let the next eligible agent in your account pick up the request.
3. Add a Message (optional), up to 500 characters. For example: “Let’s compare the travel options before I decide.” Leading and trailing spaces are trimmed; the message accompanies the request so the agent has context for your conversation.
4. Choose Request a callback and wait for confirmation.

Once acknowledged, the request appears as Queued in Requests. It waits up to 30 minutes for pickup. Choose Cancel if you no longer need it; after it becomes Expired, choose Request again or Dismiss.

The Call me action on an agent’s row is a shortcut for that target. Use the request form when you want to include a message.

1. Queued: your request is waiting for a matching agent. The phone is not ringing yet.
2. Picked up: the agent receives it through check_in or an outstanding stand_by wait.
3. Call requested: the agent calls request_human to start the conversation.
4. Answer: your enrolled devices may ring; open the call and answer when it reaches you.

Other tool results can include a pending: "call_requested" hint. That is a peek at a waiting request, not pickup or a delivery receipt. A request disappearing from the list also does not prove that a call rang or was answered.

A specific target combines the client type and project as agentType|project. A matching check-in can pick up that target’s request or an Any agent request, represented by *. It cannot take a request for another project just because the client type matches. Matching stays within your account.

Ask the agent to pass the same meaningful project name when it checks in, stands by and calls. For example, keep regional-travel-options-comparison consistent across those steps. Without a meaningful project, it may not appear as a named target; use Any agent if you cannot select the intended connection.

Client identity comes from available client metadata or a meaningful User-Agent, and can be unknown. A client/project label is not a verified process identity: two sessions using the same pair share a target. Give separate work distinct project names when you need to reach it separately.

The Agents page summarizes observed tool activity. Its labels are estimates, not a process monitor:

Working now

The agent used a tool recently. It can pick up your request when it checks in.

Recently active

There was recent activity, but your request still waits for the next check-in.

No recent activity

No recent tool use has been observed. The agent may be waiting or may have stopped.

Availability unknown

There is not enough reliable activity information to estimate availability.

Last known

The latest read failed. These are older observations, not current availability.

A working agent checks in when its runtime allows. A standing-by agent has a tool call waiting for a request. An agent sitting at its prompt makes no new tool calls until work resumes; an exited process must be restarted outside AgentCall. The activity list cannot reliably distinguish those last two situations.

Stale entries can remain, and a listed agent may no longer be running. The shared roster expires after seven days without a refresh; this is not a separate seven-day removal timer for each agent.

A callback requests one conversation. You can also tell an active compatible agent when to initiate updates during research, planning, operations, or other work:

• “While researching, call me every hour with a short update.”
• “Call when the daily checks finish, even when everything is on track.”

Save your preferences in Your call rules, or give the agent instructions for the task at hand. These are instructions for an active agent to follow. They do not create a recurring schedule in AgentCall, launch a process, or guarantee an hourly call. See the call rules guide for details.

Before stepping away, ask a compatible agent to wait for your requests. This works through its MCP connection; it is not limited to a coding task or the Claude Code helpers below.

I'm stepping away — stand by for calls.

One stand_by call lasts up to four minutes, checking for a matching request roughly every two seconds. It can return pending: "none"when the wait ends. Ask the agent to keep calling stand_by for the availability window you want; a single wait does not keep it reachable indefinitely.

For example, make it a standing rule: “When your work is done, stand by for calls for 30 minutes.” The end_call and check_in tool instructions also nudge the agent to stand by when no work remains. Actual response time depends on transport and the agent making request_human after pickup. See the stand_by tool reference.

The watcher is a local helper for Claude Code. First connect and authenticate the MCP server. Then run the helper from a checkout, in the project you want to reach, before the agent completes a turn:

cd your-repo
node /path/to/agentcall/cli/src/agentcall.mjs watch

It installs a project Stop hook and keeps a local lease alive while it runs. At the first eligible Stop, the hook asks Claude to call stand_by once. The second Stop passes through, and a pending: "none" result is allowed to stop. The helper itself makes no network calls; the connected agent’s MCP calls still do.

Keeping the watcher running does not make a prompt-idle agent poll forever. It needs a new eligible Stop and cannot wake a closed process. For a longer waiting window, give the agent the explicit repeated-standby instruction above. Ctrl-C stops the lease, allowing turns to finish normally again. To stop for good, run agentcall unwatch — it releases the lease like Ctrl-C and also removes the Stop hook the helper installed, which Ctrl-C leaves in your settings file. If that settings file cannot be read or parsed, it stops the watch but leaves the file alone, says so, and exits with code 3 — the hook entry may still be in there for you to remove by hand.

This hook asks for one check_in when an eligible Claude Code turn tries to finish. Merge it into the project’s .claude/settings.json, preserving your other settings. Using ~/.claude/settings.json applies it across sessions on the machine. This is the same recipe shown in Settings:

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "input=$(cat); case \"$input\" in *'\"stop_hook_active\":true'*|*'\"stop_hook_active\": true'*) exit 0;; esac; grep -qs '\"agentcall\"' \"$HOME/.claude.json\" .mcp.json || exit 0; printf '%s' '{\"decision\":\"block\",\"reason\":\"Before you stop, call the agentcall check_in tool once, with project set to this repo directory name. If it returns call_requested, call request_human and take the call. If it returns none, stop.\"}'"
          }
        ]
      }
    ]
  }
}

The first Stop is blocked with an instruction to check in once, using the project directory’s name as project, then call request_human if a request was picked up. Claude Code’s stop_hook_active guard lets the second Stop pass. The recipe does nothing in sessions where the MCP server is not registered.

Voicemail is opt-in under Settings → Availability → Voicemail. After an eligible unanswered call, the agent can use leave_voicemail to save a short message about its work and what it will do next. A missed ring does not automatically create a message.

1. Read it in History. Open the voicemail entry in History. A notification may also reach your device; check History even if no notification arrives.
2. Listen if you prefer. Choose Play voicemail. Saved text is synthesized on demand; you can use Pause voicemail, Resume voicemail or Replay voicemail. If playback is unavailable, the message stays readable. See Privacy & data for retention details.
3. Ask for a conversation. Choose Request a callback for the saved agent/project. After acknowledgement, Request queued confirms the request, with a link to Agents. The agent still has to pick it up and call you.