wxctl by creating the calculator-weather-agents example from scratch: two Python tools, a knowledge base, and two agents (one delegates to the other). You write every file by hand (each one is copy-paste ready below), then deploy and test it. It needs only a watsonx Orchestrate profile, and both tools are self-contained, so there is nothing external to set up.
This assumes wxctl is already installed; if not, see Installation.
Prefer not to type it out? The finished example ships in the repo. Clone it with
git clone https://github.com/randyphoa/wxctl.git, cd wxctl/examples/primitives/calculator-weather-agents, and skip to Create your profile. Every file below is identical to what you would clone.Create the project
Make the directory layout the config expects. Tools load their source from a You will fill in this tree over the next steps. Every command from here runs from the
source_path directory, and the knowledge base loads its document by path, all resolved relative to config.yaml.calculator-weather-agents/ directory.Add the knowledge base document
The knowledge base is grounded in one plain-text document. Two of the tests assert facts taken straight from it (IBM founded in 1911 as the Computing-Tabulating-Recording Company). Create
resources/knowledge_base/ibm_history.txt:resources/knowledge_base/ibm_history.txt
Add the calculator tool
A Python Create Create
tool is a directory holding the implementation, its schema, and its dependencies. main() is the entry point the config names in binding.python.function, and schema.yaml is the source of truth for the tool’s input and output schema at apply time.Create resources/tool/calculator/calculator.py:resources/tool/calculator/calculator.py
resources/tool/calculator/schema.yaml:resources/tool/calculator/schema.yaml
resources/tool/calculator/requirements.txt:resources/tool/calculator/requirements.txt
Add the weather tool
The second tool returns bundled mock forecasts for a handful of cities, with a fair-weather fallback for anything else, so it runs with no external weather API.Create Create Create
resources/tool/weather/weather.py:resources/tool/weather/weather.py
resources/tool/weather/schema.yaml:resources/tool/weather/schema.yaml
resources/tool/weather/requirements.txt:resources/tool/weather/requirements.txt
Write the config
config.yaml is the whole deployment: nine YAML documents separated by ---, the knowledge base, the two tools, the two agents, then the four tests. The ${tool.…}, ${knowledge_base.…}, and ${agent.…} references wire the resources together; wxctl turns them into a dependency graph and creates each resource in order. The tool blocks declare no input_schema: each tool loads its schema from the schema.yaml you created beside it, which is the source of truth at apply time. Create config.yaml:config.yaml
Create your profile
A profile tells
Keep this file private; it holds a credential. To avoid writing the key to disk, set it in your shell and point the profile at it instead:
wxctl where your services live and how to authenticate. Every resource in this example is a watsonx Orchestrate resource, so the profile needs a single watsonx_orchestrate block.Create ~/.wxctl/profiles.yaml with exactly this content, then replace the three values called out below:~/.wxctl/profiles.yaml
| Replace | With | Where to find it |
|---|---|---|
us-south | Your instance region, if different (for example eu-de, au-syd) | The host in your Orchestrate instance URL |
<INSTANCE_ID> | Your Orchestrate instance ID (a GUID) | watsonx Orchestrate → your instance → Settings → API details, service instance URL |
••••… | Your IBM Cloud API key | cloud.ibm.com → Manage → Access (IAM) → API keys → Create |
apikey: "${env:WXCTL_WATSONX_ORCHESTRATE_APIKEY}".Prefer to scaffold instead of copy-paste? Run
wxctl init -f config.yaml from this directory. It writes this same watsonx_orchestrate block with placeholders you then fill in. For the full profile format, Software (Cloud Pak for Data) auth, and every auth type, see Profiles & credentials.Validate the profile
Confirm It prints a per-service line and exits non-zero on failure. A wrong host, instance ID, or key is caught here.
wxctl can reach Orchestrate and authenticate before you deploy anything.Preview the plan
A dry run that shows the dependency graph and every resource
wxctl would create. Nothing is changed.Apply
Validate, plan, then create the resources: the knowledge base, the two Python tools, and the two agents (five resources).
wxctl builds a DAG from the ${kind.ref_name} references in the config and creates resources in dependency order, resolving each reference into the ID the API expects.Test
Run the four The checks confirm the Calculator Agent calls
kind: test checks you wrote against the deployed agents.calculator_tool for 42 × 17 (714) and answers the “when was IBM founded” question (1911, as CTR) from the knowledge base, and the Weather Agent calls weather_tool for Tokyo and answers 19 + 23 (42) by delegating to the Calculator Agent.What you just deployed
The singleconfig.yaml holds nine YAML documents separated by ---: five resources you deploy plus four kind: test checks.
- 1 knowledge base,
ibm_history_kb, grounded in the short IBM company-history document. - 2 Python tools,
calculator_tool(add / multiply / divide) andweather_tool(mock city forecasts). - 2 agents: the Calculator Agent (calculator tool + knowledge base,
chat_with_docsenabled) and the Weather Agent (weather tool), which lists the Calculator Agent as acollaboratorsentry so it delegates arithmetic to it. - 4 tests: a calculation that must call
calculator_tool, an IBM-history question answered from the knowledge base, a Tokyo forecast that must callweather_tool, and a math question to the Weather Agent that exercises delegation.
${kind.ref_name} (the resource’s ID after creation) or ${kind.ref_name.field} (a specific field). That wiring is the DAG wxctl builds, then applies in dependency order.
Core commands
| Command | Description |
|---|---|
wxctl init [-f <file>] | Scaffold a profile with service URLs, auth, and credentials |
wxctl profile validate | Check the profile against the live services |
wxctl plan -f <file> | Dry run that shows what would change |
wxctl apply -f <file> | Validate, plan, and execute |
wxctl test -f <file> | Run kind: test checks against deployed resources |
wxctl destroy -f <file> | Tear down the resources in a config |
wxctl resources | List the resource kinds wxctl supports |
wxctl explain <kind> | Show a kind’s fields, dependencies, and endpoints |
-f accepts files, directories, or - for stdin, and is repeatable. Global flags: -p, --profile <name> selects a profile, --profile-path <path> uses a custom profile file, --full-trace captures full-fidelity run records.
Next steps
Build it with IBM Bob
The other way to build this: describe the scenario in one sentence and let IBM Bob compose it over MCP.
Worked example
Build a tool, agent, and test from scratch, one resource at a time.
Profiles & credentials
Every auth type, the Software (CP4D) shape, and
${env:VAR}.Resource kinds
Every kind wxctl supports, with its deployment and endpoint.
Declarative model
Resources,
${kind.ref_name} references, and how the DAG is built.
