Turn a fresh laptop into a financial-intelligence agent you chat with on Telegram

April 21, 2026

NemoClaw, Bigdata, Telegram/30 minutes read

NemoClaw is alpha software. Do not use in production.

OpenClaw arrived and then everyone started talking about agents. It paved the way for new businesses at the same time it made others obsolete. Now the topics in everyone’s mind are personal agents and teams comprised exclusively of agents. One thing that complicates the idea of agents being used by companies, however, is the security aspect: these agents are designed to be powerful and self-sufficient, which means they need a good model and access to your credentials. In this post, we explore how to give access to the financial knowledge of Bigdata to an OpenClaw agent running with NVIDIA’s NemoClaw connected with Telegram. NemoClaw adds several layers of protection so the final agent can make requests to only some domains and does not know about ANY of our API keys. By the end, you’ll be asking your Telegram bot about earnings and market news — with zero API keys exposed to the agent.

Create a Telegram bot

Install NemoClaw and pair it to the Telegram bot

Access OpenClaw dashboard

Open the firewall to Bigdata

Set up the Bigdata API key and wire it into the sandbox

Turn the experience to eleven: install the build-with-bigdata skill

See the agent in action

How to read the commands in this guide

The agent runs in an isolated sandbox, separate from your Mac. Commands in this guide target one of those two environments — check the prefix before copying anything:

Command prefix	Where to run it
`nemoclaw …`	Your Mac terminal
`openshell …`	Your Mac terminal
`openclaw …`	Inside the sandbox (via `ssh openshell-my-assistant '…'`)

nemoclaw and openshell are the management tools that live on your Mac and talk to the gateway from outside. openclaw is the agent runtime that lives inside the sandbox — running it locally won’t work because it has no gateway to connect to.

Before you start

You’ll need:

macOS with Node.js and Docker Desktop (or Colima) running.
A Telegram account.
An API key for your inference provider. NemoClaw supports several — NVIDIA Build, OpenAI, Anthropic, and others. Pick whichever you have access to.

Step 1 — Create a Telegram bot

We will create a Telegram bot to configure in the personal agent, so we can use Telegram to communicate with it.

Don’t get hacked in step 1! There are bots that look similar, so ensure you pick the official ones; they will have a blue checkmark next to their names. Use the following two:

BotFather — official Telegram bot with blue checkmark

User Info bot — get your numeric Telegram user ID

Open Telegram, message @BotFather, and send:

/newbot

Pick a name and a @username. BotFather replies with a token that looks like 123456789:ABCdef.... Keep it handy — ideally, store it in your password manager. You will also need your Telegram User ID: Message @userinfobot and copy your numeric user ID. NemoClaw will allowlist exactly this ID so only you can DM your bot.

/start

Step 2 — Install NemoClaw and pair a Telegram bot

Open Docker Desktop and wait for the whale icon to stop animating. Then you can install NemoClaw with the following command:

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Are you getting a cryptic connection error halfway through?

Make sure Docker Desktop (or Colima) is running or run docker info and confirm it returns without error.

When prompted for an agent name, leave the default my-assistant. Don’t worry about giving the agent this bland name; once you start chatting, you can give the agent a name, and it will adopt that identity. Follow the guide. These are three of the configuration steps:

Inference provider: Pick whichever provider you have an API key for (NVIDIA Build, OpenAI, Anthropic, and others are supported). Enter the key when prompted.
Messaging channels: Enable Telegram. Enter your bot token and your Telegram user ID (the numeric one from @userinfobot) so only you can DM the bot.
Policy tier: Select Restricted and then make sure telegram, github, and pypi are selected:
- telegram opens api.telegram.org:443 so the bot can send and receive messages.
- github opens github.com + *.githubusercontent.com so your agent can later download the Bigdata skill from GitHub.
- pypi opens pypi.org so we can install Python packages. We give access to every PyPI repo; however, once we finish the installation and download the required packages, we will remove this policy. When it finishes, you have:

nemoclaw and openshell in ~/.local/bin (add to your PATH if not already there).
A running gateway (openshell-cluster-nemoclaw container).
A sandbox named my-assistant with the OpenClaw agent inside.
A live Telegram channel polling for your messages from inside the sandbox.
Network rules already open for Telegram, GitHub, and PyPI.

Open Telegram, find your bot and send:

/start

You should get a reply within a few seconds. That’s the whole install. Your agent is alive, sandboxed, and reachable from your phone.

What just happened? Your Telegram message hit Telegram’s servers, your sandbox polled them through an explicitly allowlisted route (api.telegram.org:443), the OpenClaw agent generated a response with an LLM, and the response was sent back through the same allowlisted route. No port was opened on your Mac. No credential left the gateway in plaintext.

Step 3 — Access OpenClaw dashboard

Several steps in this guide require running commands inside the sandbox. The easiest way to do that is plain SSH through the gateway. The first command generates an SSH config block and appends it to your ~/.ssh/config. The second tests that the connection works:

openshell sandbox ssh-config my-assistant >> ~/.ssh/config
ssh openshell-my-assistant 'echo "sandbox: $(hostname)"'

This command ran inside the sandbox. It retrieved the name of the hostname. You should see sandbox: my-assistant. From now on, ssh openshell-my-assistant drops you into the sandbox, and ssh openshell-my-assistant '' runs a one-liner inside it. The sandbox runs a web dashboard for managing the agent — reloading skills, browsing sessions, viewing logs. It listens on port 18789 inside the sandbox, so you need a port forward to reach it from your Mac. First, get the dashboard URL with its auth token:

ssh openshell-my-assistant 'openclaw dashboard'

Copy the URL with the #token=… fragment. Then start the port forward:

openshell forward start 18789 my-assistant

Error: Port 18789 is already forwarded to sandbox 'my-assistant'?

If you get this error, then you are already set, you can go to the next step.

Now open the URL in your browser (replace localhost with 127.0.0.1):

http://127.0.0.1:18789/#token=<your-token-here>

Do you have problems connecting to the OpenClaw dashboard?

Run openclaw dashboard before openshell forward. The openclaw dashboard command briefly binds port 18789 to display the URL. If the port forward is already running, the dashboard command will fail with “port in use.” Get the token first, then start the forward.Use 127.0.0.1, not localhost. The gateway’s allowed-origins list includes http://127.0.0.1:18789 but not http://localhost:18789. If you use localhost you’ll see “origin not allowed” in the dashboard.Use openshell forward, not raw SSH tunnels. ssh -N -L 18789:… forwards TCP but doesn’t handle the WebSocket connection the dashboard needs. openshell forward start does both.

You should now be able to interact with your agent directly from the dashboard — browse sessions, view logs, and chat:

Step 4 — Open the firewall for Bigdata

Your sandbox starts with deny‑by‑default networking. Telegram, GitHub, and PyPI are already open from onboard — everything else, including api.bigdata.com, is blocked until you say otherwise. That’s a feature: every external dependency is something you opt into, in writing, by name. NemoClaw makes this easy with policy presets — small YAML files that bundle a single capability. We’ll add one: bigdata.

4.1 Drop in the Bigdata preset

Create ~/.nemoclaw/source/nemoclaw-blueprint/policies/presets/bigdata.yaml:

preset:
  name: bigdata
  description: "Bigdata.com REST API access"

network_policies:
  bigdata:
    name: bigdata
    endpoints:
      - host: api.bigdata.com
        port: 443
        protocol: rest
        enforcement: enforce
        rules:
          - allow: { method: GET,  path: "/**" }
          - allow: { method: POST, path: "/**" }
      - host: agents.bigdata.com
        port: 443
        protocol: rest
        enforcement: enforce
        rules:
          - allow: { method: GET,  path: "/**" }
          - allow: { method: POST, path: "/**" }
      - host: s3.amazonaws.com
        port: 443
        access: full
      - host: content.bigdata.com
        port: 443
        access: full
    binaries:
      - { path: /usr/bin/curl }
      - { path: /usr/bin/python3* }
      - { path: /usr/local/bin/python3* }
      - { path: /usr/local/bin/node }
      - { path: /usr/bin/node }

Three things worth noting:

protocol: rest with explicit rules — the gateway terminates TLS on these hosts, inspects every request, and only allows the listed HTTP methods. This is what makes credential injection (Step 5) possible: the proxy sees the X-API-KEY header in plaintext and can rewrite the placeholder before forwarding it to Bigdata.
s3.amazonaws.com and content.bigdata.com with access: full — Bigdata’s upload and download flows are two‑step: the API returns a pre‑signed URL on a separate data‑plane host (s3.amazonaws.com for upload, content.bigdata.com for download), and the signature is baked into the query string. The proxy must not terminate TLS or modify headers on those hosts — any change breaks the signature and you get HTTP 403 SignatureDoesNotMatch. access: full creates a CONNECT tunnel that passes bytes through untouched.
binaries — only these executables are allowed to use this rule. A rogue script in another language can’t piggyback on it.

4.2 Apply the preset

nemoclaw my-assistant policy-add
# Pick "bigdata" from the list, confirm.

That’s it. policy-add updates the sandbox’s preset list and pushes the merged policy to the live gateway in one shot — no sandbox restart, no downtime. Confirm it’s active (look for the filled dot ●):

nemoclaw my-assistant policy-list
# ● telegram  — Telegram Bot API
# ● github    — GitHub releases and raw content
# ● bigdata   — Bigdata.com REST API access

4.3 Smoke test the firewall

You don’t need an API key yet — you just need a 401, not a 403. A 401 means the request reached Bigdata; a 403 means the proxy blocked it.

ssh openshell-my-assistant \
  'curl -sSi https://api.bigdata.com/profiles/me --max-time 5 | head -1'

Response	Meaning
`HTTP/2 401`	✅ Firewall is open. Bigdata is just asking for a key.
`HTTP/2 403` from the proxy	❌ Preset not applied. Re‑run 4.2.
Connection refused / timeout	❌ Wrong host or port. Re‑check 4.1.

Step 5 — Set up the Bigdata provider with your API key

It is time to get an API key in Bigdata. Remember, the agent will not get to see the key, just a placeholder. We will configure NemoClaw to inject the correct API key.

5.1 Create a Bigdata API Key

Go to Bigdata Developer Platform > API Keys and log in
Click on “Generate API key”.
Copy the key somewhere safe. You won’t see it again after you close the dialog.
Create an environment variable file with your preferred text editor .env and add the Bigdata API Key

 vi ~/.nemoclaw/.env

.env file:

BIGDATA_API_KEY="<your-bigdata-api-key>"

5.2 Store the key in the gateway as a provider

Here’s the part that makes OpenClaw different from “just throw the key in a .env inside the container.” The sandbox never holds the real key. Instead:

Agent sends HTTP request        Gateway (L7 proxy)            Bigdata API
────────────────────────        ──────────────────            ───────────
X-API-KEY:            ───►      looks up BIGDATA_API_KEY ───► X-API-KEY:
  openshell:resolve:env:          in the attached provider      <real-key-value>
  BIGDATA_API_KEY                 and rewrites the header

Config files, environment variables, and the agent’s own memory only ever contains the placeholder string openshell:resolve:env:BIGDATA_API_KEY. The gateway swaps it for the real value on the way out. If the sandbox is ever compromised, the attacker walks away with a string that reads openshell:resolve:env:… — not an API key. This injection logic is handled by the command openshell provider so that is what we will use now. The command reads the key from your environment, so the variable needs to be exported and not just set, before you run it. The set -a trick exports everything sourced in one shot:

set -a; source ~/.nemoclaw/.env; set +a

Why not just source ~/.nemoclaw/.env? That sets the variables in your current shell, so echo $BIGDATA_API_KEY works fine. But openshell is a child process and only inherits exported variables. Without set -a you’ll get --credential BIGDATA_API_KEY requires local env var 'BIGDATA_API_KEY' to be set even though the value looks present.

openshell provider create \
  --name my-assistant-bd-key \
  --type generic \
  --credential BIGDATA_API_KEY \
  -g nemoclaw

Now confirm my-assistant-bd-key shows up. This is the provider with the logic to inject BIGDATA_API_KEY:

openshell provider list

The --credential BIGDATA_API_KEY flag tells the gateway: “read the value from the BIGDATA_API_KEY env var right now, and store it under that name.” This is also the name that goes in the placeholder. After running this command, you may delete the .env file; we won’t be using it anymore.

5.3 Attach the provider to the sandbox

In the current OpenShell release (v0.0.26), providers can only be attached at sandbox creation time — not to a running one. That means we need to recreate the sandbox.

If you’re following this guide in a later version, NemoClaw may have lifted this restriction. Test it by running:

ssh openshell-my-assistant 'curl -sSi https://api.bigdata.com/profiles/me --max-time 5 | head -1'

If it returns 200, the provider is already active and you can skip to the next step.

Recreating the sandbox resets the live network policy. The bigdata, telegram, and github presets you applied during installation and in Step 4 get stripped from the gateway — even though nemoclaw my-assistant policy-list will still show them as ● applied (that command reads from sandboxes.json, not the live gateway).

To avoid losing your configuration, we’ll snapshot everything — the network policy, the image tag, and the inference config — then recreate the sandbox with all of it restored, this time with the provider attached. 1. Find the sandbox image tag:

docker images | grep sandbox-from | head -1
#    openshell/sandbox-from   1776263201   …

Copy the image tag from the second column. 2. Note your current inference provider and model:

openshell inference get

Copy the provider name and model. 3. Snapshot the live policy before deleting:

openshell policy get --full my-assistant > ~/pre-recreate-policy.yaml

4. Trim the preamble from the saved policy file. openshell policy get --full outputs a metadata header before the actual YAML:

Version:  1
Hash:     5f4d0984…
Status:   Loaded
Active:   0
Created:  1776345959982 ms
---
version: 1
...

The --policy flag only accepts the YAML part. Open ~/pre-recreate-policy.yaml in an editor and delete everything above (and including) the --- line. The file must start with version: 1. If you leave the header in, sandbox create fails with unknown field 'Version'. Now you have all of the information needed for recreating the sandbox but this time with the my-assistant-bd-key provider:

Docker image and tag
Provider name and model
The policy the sandbox was using (remember to strip the metadata header!)

5. Delete the sandbox and recreate it with the provider and saved policy:

openshell sandbox delete my-assistant

openshell sandbox create \
  --name my-assistant \
  --from openshell/sandbox-from:<image-tag-from-step-1> \
  --policy ~/pre-recreate-policy.yaml \
  --provider my-assistant-bd-key \
  --provider my-assistant-telegram-bridge

6. Re-attach inference (always reset by recreation):

openshell inference set \
  --provider <your-inference-provider> \
  --model <your-model>

A few flags worth calling out:

--policy ~/pre-recreate-policy.yaml — restores Telegram + GitHub + PyPI + Bigdata network presets.
--provider my-assistant-telegram-bridge — the Telegram bot token provider, created automatically by the installer. Re-attach it or the bot goes dark after recreation.
--provider my-assistant-bd-key — the Bigdata key provider you just created.

5.4 Verify the OpenShell Gateway is properly attached to the OpenClaw agent.

After recreation, OpenClaw may treat the sandbox as an unpaired device. Any command that talks to the gateway’s control plane (cron, devices, some skills) will fail with a pairing prompt until you accept it. If you get an error connecting to the sandbox at this point, connect to it first:

nemoclaw my-assistant connect

Then open the TUI to check the device state:

ssh openshell-my-assistant 'openclaw tui'

If the TUI lands on a “device not enabled” screen or openclaw commands complain about pairing, enable the device from inside the sandbox:

ssh openshell-my-assistant 'openclaw devices enable'

Re-run the TUI — you should land in the normal chat view. Devices stay paired until revoked, so this is a one‑time step per recreation.

5.5 Verify the key is reachable — and still invisible

The sandbox should now be able to authenticate against Bigdata without the real key being anywhere inside it.

# Send a placeholder through the proxy — the gateway will rewrite it on the fly.
ssh openshell-my-assistant '
  curl -sS -o /dev/null -w "%{http_code}\n" \
    -H "X-API-KEY: openshell:resolve:env:BIGDATA_API_KEY" \
    https://api.bigdata.com/profiles/me
'
# → 2xx / 4xx from Bigdata (the proxy resolved the placeholder; Bigdata decides auth).
#   Anything other than a proxy-level 403/5xx means the injection path is working.

# Prove the real key is nowhere inside the sandbox.
ssh openshell-my-assistant 'env | grep -i bigdata; find /sandbox -name "*.env*" -o -name "*bigdata*"'
# → (nothing sensitive — at most, placeholder strings)

At this point we have the environment with access to Bigdata and zero plaintext inside the sandbox!

Step 6 — Turn the experience to eleven: install the skill `build-with-bigdata`

The build-with-bigdata skill teaches your agent how to drive the Bigdata public API: document search, volume analysis, co‑mentions, the Knowledge Graph, and file upload/download. The skill lives in a GitHub repo as a folder with a SKILL.md file and reference docs.

Alternatively, you could point the agent at the raw API documentation, but the skill smooths the process by showing the agent exactly how to structure requests and which pitfalls to avoid.

NemoClaw has a first‑class command for this: nemoclaw <sandbox> skill install <path>. It validates the skill, uploads it over SSH, and registers it — all from your Mac.

6.1 Install requests library

The Requests library makes communication with Bigdata easier for the agent; otherwise it will default to using curl commands. That is why we enabled the PyPI policy during installation.

ssh openshell-my-assistant 'pip install --user requests'

And after the library is installed, we can remove the pypi policy:

nemoclaw my-assistant policy-remove

That means that the agent can no longer connect to PyPI and install any more packages.

6.2 Clone the plugin repo and install the skill

git clone --depth 1 \
  https://github.com/Bigdata-com/claude-plugin-build-with-bigdata-com.git \
  /tmp/bigdata-plugin

nemoclaw my-assistant skill install \
  /tmp/bigdata-plugin/skills/build-with-bigdata

The skill is now on disk at /sandbox/.openclaw-data/skills/build-with-bigdata/ inside the sandbox.

6.3 Reload the agent from the dashboard

The skill is on disk and registered, but the running agent process hasn’t read its contents yet. Until you reload, the agent is in a split state: it knows the skill exists (it can list it) but can’t actually use it — you may see messages like “I can see the skill but can’t access the file.” The dashboard reload is what closes that gap. Open the OpenClaw dashboard (set up in Step 3):

http://127.0.0.1:18789/

There are two ways to start a new session with the skill loaded. The image below shows both — the + button and the search bar (indicated by the arrow):

OpenClaw dashboard — + button and search bar highlighted

Option 1 — the + button. Click the + button in the dashboard to open a fresh chat. Note that the exact location may vary depending on your OpenClaw version. Option 2 — the command palette. Click the search bar at the top (the arrow points to it above). Start typing and a popup will appear — type /new to start a new session.

After the reload, the agent will include build-with-bigdata in its available skills.

Why not just message the bot?

The agent’s session caches which skills are available when it starts. A skill installed after the session began won’t be picked up until the agent reloads. The dashboard reload is the clean way to trigger this.

The agent says it can see the skill but can't read the file

The registered path likely contains a ~ that didn’t expand correctly in the agent’s runtime context. Tell the agent to use the absolute path directly:“Read the skill at /sandbox/.openclaw/skills/build-with-bigdata/SKILL.md”That path always works regardless of how ~ resolves in the current session.

6.4 Confirm the skill loaded

Send a message to the bot on Telegram:

What skills do you have available right now?

A correct answer mentions build-with-bigdata along with whatever skills ship in the base image.

Where you are now

✅ NemoClaw installed, onboarded, reachable from Telegram.
✅ The sandbox can reach Telegram, GitHub, PyPI, and Bigdata — and nothing else outside of what NemoClaw ships by default.
✅ Your Bigdata API key is stored in the gateway. The sandbox only holds the placeholder.
✅ Your agent knows how to use the Bigdata API, via a skill it installed itself from a chat message.

If you installed your agent on a machine that is not running 24/7, every time you reboot you will need to launch nemoclaw my-assistant connect but that’s it!

Step 7 — See the agent in action: creating a daily portfolio brief

Everything is wired up. This step shows a concrete end-to-end workflow: you tell the agent which stocks you follow, ask it to pull a 24-hour summary from Bigdata, and then schedule that report to run automatically every day. All from Telegram, without touching a single config file.

7.1 Tell the agent your portfolio

Send your bot a message on Telegram:

Remember my portfolio: NVIDIA, META, MSFT. From now on, whenever I ask for a portfolio update, use these three tickers.

The agent stores this in its session memory. You won’t need to repeat the list in follow-up prompts.

7.2 Request a 24-hour financial report

Generate a financial report for my portfolio covering the last 24 hours. Include key metrics (price change, volume, sentiment score), links to the source documents, and format it for mobile: short paragraphs, bullet points, no wide tables.

The agent will call the Bigdata Search and Volume endpoints, pull relevant news and filings, and compose the report.

If the report looks too verbose or too sparse, iterate in plain language: “Make it shorter”, “Add a sentiment summary at the top”, or “Show only negative signals.” The agent keeps the context from your previous message.

7.3 Schedule the report, deliver it to Telegram, and upload it to Bigdata

Once you are happy with the output, ask the agent to automate it:

Schedule this report to run every day at 8 AM. Each time it runs, send the result to me on Telegram and upload it to Bigdata so I can retrieve it later.

The agent will use the OpenClaw cron skill to register the schedule, the Telegram channel to deliver the report to your phone, and the build-with-bigdata upload flow to persist each result. From this point on, your portfolio brief arrives on Telegram every morning and is indexed in Bigdata without any manual steps.

What just happened? Your agent queried the Bigdata API through the allowlisted proxy, the gateway injected the real BIGDATA_API_KEY header on the way out, and the response came back without the key ever touching the sandbox. The schedule runs inside the sandbox on the same sandboxed network, so even the automated job can only reach the domains you explicitly opened in Step 4.

When the report gets complex enough, OpenClaw will automatically spawn sub-agents to work on different parts in parallel: one fetching news, another pulling volume data, another formatting the output. The dashboard makes this visible:

OpenClaw dashboard — multiple sub-agents spawned to handle complex report generation

As a follow-up: uploading each report to Bigdata gives you more than remote storage. The content gets indexed, so it can be returned in future queries. This becomes especially powerful once you have a growing history of uploads and the files have a rich structure.

Diego de Aguilar

Senior Backend Engineer

April - 2026

March - 2026

Turn a fresh laptop into a financial-intelligence agent you chat with on Telegram

Before you start

Step 1 — Create a Telegram bot

Step 2 — Install NemoClaw and pair a Telegram bot

Step 3 — Access OpenClaw dashboard

Step 4 — Open the firewall for Bigdata

4.1 Drop in the Bigdata preset

4.2 Apply the preset

4.3 Smoke test the firewall

Step 5 — Set up the Bigdata provider with your API key

5.1 Create a Bigdata API Key

5.2 Store the key in the gateway as a provider

5.3 Attach the provider to the sandbox

5.4 Verify the OpenShell Gateway is properly attached to the OpenClaw agent.

5.5 Verify the key is reachable — and still invisible

Step 6 — Turn the experience to eleven: install the skill `build-with-bigdata`

6.1 Install requests library

6.2 Clone the plugin repo and install the skill

6.3 Reload the agent from the dashboard

6.4 Confirm the skill loaded

Where you are now

Step 7 — See the agent in action: creating a daily portfolio brief

7.1 Tell the agent your portfolio

7.2 Request a 24-hour financial report

7.3 Schedule the report, deliver it to Telegram, and upload it to Bigdata

April - 2026

March - 2026

​Before you start

​Step 1 — Create a Telegram bot

​Step 2 — Install NemoClaw and pair a Telegram bot

​Step 3 — Access OpenClaw dashboard

​Step 4 — Open the firewall for Bigdata

​4.1 Drop in the Bigdata preset

​4.2 Apply the preset

​4.3 Smoke test the firewall

​Step 5 — Set up the Bigdata provider with your API key

​5.1 Create a Bigdata API Key

​5.2 Store the key in the gateway as a provider

​5.3 Attach the provider to the sandbox

​5.4 Verify the OpenShell Gateway is properly attached to the OpenClaw agent.

​5.5 Verify the key is reachable — and still invisible

​Step 6 — Turn the experience to eleven: install the skill build-with-bigdata

​6.1 Install requests library

​6.2 Clone the plugin repo and install the skill

​6.3 Reload the agent from the dashboard

​6.4 Confirm the skill loaded

​Where you are now

​Step 7 — See the agent in action: creating a daily portfolio brief

​7.1 Tell the agent your portfolio

​7.2 Request a 24-hour financial report

​7.3 Schedule the report, deliver it to Telegram, and upload it to Bigdata

Before you start

Step 1 — Create a Telegram bot

Step 2 — Install NemoClaw and pair a Telegram bot

Step 3 — Access OpenClaw dashboard

Step 4 — Open the firewall for Bigdata

4.1 Drop in the Bigdata preset

4.2 Apply the preset

4.3 Smoke test the firewall

Step 5 — Set up the Bigdata provider with your API key

5.1 Create a Bigdata API Key

5.2 Store the key in the gateway as a provider

5.3 Attach the provider to the sandbox

5.4 Verify the OpenShell Gateway is properly attached to the OpenClaw agent.

5.5 Verify the key is reachable — and still invisible

Step 6 — Turn the experience to eleven: install the skill `build-with-bigdata`

6.1 Install requests library

6.2 Clone the plugin repo and install the skill

6.3 Reload the agent from the dashboard

6.4 Confirm the skill loaded

Where you are now

Step 7 — See the agent in action: creating a daily portfolio brief

7.1 Tell the agent your portfolio

7.2 Request a 24-hour financial report

7.3 Schedule the report, deliver it to Telegram, and upload it to Bigdata