Who is Caller Quick Start for?
It is for agent teams that want to call an external capability through CALL ANYTHING without deploying the full platform first. The page uses Local Mode to prove the minimum caller loop with a real result package.
What this page gets you to
From zero to one cross-process capability call
- · Start the local supervisor
- · Register a local Caller identity
- · Mount the built-in example Hotline
- · List catalog, submit a request, and fetch the result
- · Read the shared result_package shape
01
Clone the repo and install dependencies
The delegated-execution-dev superproject already wires client, protocol, and platform repos together. You can use the whole superproject or just the client repo if you only want the local loop.
bash
Superproject rootgit clone --recursive https://github.com/hejiajiudeeyu/delegated-execution-dev.git
cd delegated-execution-dev
corepack pnpm installbash
Client repo onlycd repos/client
npm installNoteThe rest of this page assumes your working directory is
repos/client.02
Start the supervisor
The supervisor is the local daemon that hosts the caller controller, responder controller, and ops control surface. The Console prototype also talks to it.
bash
export DELEXEC_HOME="$HOME/.delexec-quickstart-en"
export OPS_PORT_SUPERVISOR=8179
DELEXEC_HOME="$DELEXEC_HOME" OPS_PORT_SUPERVISOR="$OPS_PORT_SUPERVISOR" npm run ops -- startWarningThis runs in the foreground. Open a second terminal for the remaining steps. Once you see
supervisor listening on 127.0.0.1:8179 the runtime is ready.03
Initialize the first session
The first supervisor boot needs setup. After that, every admin request is scoped by the X-Ops-Session token.
bash
BASE="http://127.0.0.1:${OPS_PORT_SUPERVISOR:-8079}"
curl -s -X POST "$BASE/setup" -H 'content-type: application/json' -d '{}'
SESSION=$(curl -s -X POST "$BASE/auth/session/setup" -H 'content-type: application/json' -d '{}' | jq -r '.session')
echo "$SESSION"
export OPS_SESSION="$SESSION"TipIf you prefer the CLI path, the same runtime is also documented in
repos/client/docs/current/guides/local-mode-onboarding.md.04
Register a local Caller
Even in Local Mode the protocol keeps Caller identity explicit. This step writes a local account into your DELEXEC_HOME runtime state.
bash
CLInpm run ops -- auth register --local --email [email protected]bash
HTTPcurl -s -X POST "$BASE/auth/register-caller" -H 'content-type: application/json' -H "X-Ops-Session: $OPS_SESSION" -d '{ "email": "[email protected]" }'05
Mount the built-in example Hotline
Local Mode lets the same machine act as both Caller and Responder. That keeps the first verification loop small before you integrate any real capability.
bash
curl -s -X POST "$BASE/responder/enable" -H 'content-type: application/json' -H "X-Ops-Session: $OPS_SESSION" -d '{}'
curl -s -X POST "$BASE/responder/hotlines/example" -H 'content-type: application/json' -H "X-Ops-Session: $OPS_SESSION" -d '{}'06
List the local catalog
Catalog is the key Caller-side API. It defines which Hotlines are currently available to the agent runtime.
bash
curl -s "$BASE/catalog/hotlines" -H "X-Ops-Session: $OPS_SESSION" | jqExpectedYou should see
local.delegated-execution.workspace-summary.v1 in the list.07
Submit one real request
At this point the runtime is live. The next request simulates the first external capability call an agent would make.
bash
HTTPREQ=$(curl -s -X POST "$BASE/requests/example" -H 'content-type: application/json' -H "X-Ops-Session: $OPS_SESSION" -d '{}')
echo "$REQ"
REQUEST_ID=$(echo "$REQ" | jq -r '.request_id')bash
CLInpm run ops -- run-example --text "summarize my workspace"08
Fetch the result and inspect result_package
The protocol-level result envelope is the main thing to learn. Once your agent understands one result_package, it can reuse that outer shape across many Hotlines.
bash
curl -s "$BASE/requests/$REQUEST_ID/result" -H "X-Ops-Session: $OPS_SESSION" | jqjson
Successful shape{
"request_id": "req_xxx",
"status": "SUCCEEDED",
"result_package": {
"request_id": "req_xxx",
"responder_id": "responder_xxx",
"hotline_id": "local.delegated-execution.workspace-summary.v1",
"status": "ok",
"output": {
"summary": "..."
},
"timing": {
"elapsed_ms": 123
}
}
}json
One common failure shape{
"request_id": "req_xxx",
"status": "FAILED",
"result_package": {
"hotline_id": "local.delegated-execution.workspace-summary.v1",
"status": "error",
"error": {
"code": "AUTH_TOKEN_INVALID",
"message": "task token is missing or invalid"
}
}
}Fields your agent should inspect first:
- ·
status: request lifecycle status - ·
result_package.status: protocol-level success or error - ·
hotline_id: the exact capability version you called - ·
output: the capability-specific payload - ·
timing.elapsed_ms: runtime duration for observability and pricing
What to do next
You now have the minimum Caller-side loop. From here, either expand the set of Hotlines your agent can call or switch to the seller-side path and publish one yourself.
Expand the agent surface
Open the Console and Marketplace to see discovery, approvals, and runtime history from the team side.
Publish a capability
The same supervisor can also host a Responder. Switch to the seller-side path to publish your own Hotline.
Caller FAQ
Caller Quick Start common questions
These are the three questions most likely to block the first caller-side integration, and they are also emitted as English FAQ schema for answer engines.
Why start with the example hotline?
Because it reduces debugging scope. You first prove that Caller, supervisor, and Responder can complete one stable loop before you spend time integrating a real business capability.
What should I inspect after the first call succeeds?
Inspect the result_package shape: request status, hotline_id, output, and timing. That is the shared contract your agent will parse across many Hotlines.