datavessel teams are hired, not assembled: one team lead agent plans the cycle, dispatches the right specialists, waits for their results, surfaces any write approvals to you, and hands back a single consolidated report. You can run a team two ways — straight from your terminal with the CLI, or from inside Claude Code with the datavessel plugin. This tutorial walks through both, end to end.
This post is part of our complete guide to the e-commerce CLI — running your store from the terminal.
Three teams are available today:
- Ecommerce Operator Team — runs the store’s day: platform ops, support resolution, revenue protection, back office, reporting.
- Ecommerce Marketing Team — SEO, AEO (AI-answer visibility), catalogue content, paid-search hygiene, lifecycle email.
- Store Expansion Builder — builds new surface area for an existing store: landing pages, campaign pages, catalogue depth.
Option A — from the terminal (datavessel CLI)
1. Install and sign in
npm install -g datavessel-cli
# browser sign-in:
datavessel login
# or headless, with an API key from the app:
datavessel init --api-key "$DATAVESSEL_API_KEY"Either way you should see your connected sources, tier, and remaining tool-call quota. If a source you need is missing, the wizard tells you exactly where to connect it:
datavessel setupsetup is optional but worth the two minutes: it saves your GA4 property, Search Console site, store platform, and standing rules to team memory, so every team you run starts fully briefed instead of spending turns rediscovering your setup.
2. Find the team lead
datavessel --json run datavessel_list_agents --params-json '{"type":"official"}'Look for ecommerce_operator_team, ecommerce_marketing_team, or store_expansion_builder_team and note the id.
3. Brief it and dispatch
datavessel --json run datavessel_run_agent --params-json '{
"agent_id": "<lead-id>",
"template_inputs": {
"goal": "prep the weekend: clear support, recover carts, protect disputes",
"mode": "interactive",
"max_member_runs": "3"
}
}'The knobs:
goal— outcome-shaped, in plain language. Pass"auto"to let the lead pick the highest-leverage work of the day from its charter and memory.mode—"autopilot"runs the cycle unattended;"interactive"makes the lead narrate its dispatch plan and each approval as it happens.max_member_runs— the member-run budget for the cycle (1–8, default 3). Each member run counts against your daily agent-run quota, so a default cycle costs the lead’s run plus three.
The call returns a runId immediately — the whole cycle runs server-side. Nothing is tied to your terminal staying open.
4. Wait like a grown-up (long-poll, don’t spam)
datavessel --json run datavessel_get_run_output --params-json \
'{"run_id": "<runId>", "wait_seconds": 120}'Repeat while status is "running". A full team cycle typically takes several minutes: the lead recalls prior cycles, plans, dispatches members concurrently, and digests their results as they land.
5. Sign off the writes — this is the point
Reads run free; writes ask first. When any team member wants to change something real — refund an order, update a product, publish a page — the member run pauses and your poll comes back with:
"status": "awaiting_approval",
"pendingApprovals": [
{ "toolName": "create:product", "provider": "shopify",
"params": { "title": "…", "status": "draft" } }
],
"approvalUrl": "https://app.datavessel.io/…"Open the approvalUrl — it lands you on the Workforce page with that exact decision front and center: the tool, the parameters, the amounts, one big approve/deny action and keyboard shortcuts for the next one. Approve it and the member resumes; deny it and the change simply never happens. Either way the lead keeps working the other lanes and folds the outcome into the report.
Two things worth knowing about the gate: approving happens in the app, signed in as you — an agent holding your API key cannot approve its own writes. And approval of one change never carries over to the next; every write is its own decision.
6. Read the report
When status is "completed", the run’s content is the lead’s consolidated report: what ran in each lane, what was done (with ids and links), what’s still pending your approval, what’s advisory, and the 2–3 priorities it suggests for the next cycle. The same report is saved in the app, and the cycle is remembered in team memory — the next run starts where this one left off.
Option B — from Claude Code (the plugin)
The same teams, without leaving your coding session. The datavessel CLI repo doubles as a Claude Code plugin that ships the base skill, one skill per team, and a small agent hierarchy for local read/write work.
1. Install the plugin
/plugin marketplace add djr4/datavessel-cli
/plugin install datavessel@datavessel2. One-command setup
/datavessel:setupThis installs the CLI if needed, takes your API key, runs datavessel init, and reports which sources are connected and which teams are ready to run.
3. Just ask for the team
In a Claude Code session:
run the operator team — goal: why did revenue dip this week?The team skill does exactly what Option A does — finds the lead, briefs it, dispatches, long-polls — and presents the report in your session when the cycle completes. If a member pauses on a write, Claude surfaces the pending change and the approval link in chat; the decision is still yours, still made in the app.
What to expect on quota
Member runs draw from your plan’s daily agent-run budget. A default cycle (max_member_runs: 3) costs four runs — the lead plus three members. If the budget runs out mid-cycle, the lead stops dispatching, synthesizes what it has, and says so plainly in the report rather than failing silently.
The short version
npm install -g datavessel-cli
datavessel init --api-key "$KEY"
datavessel --json run datavessel_list_agents --params-json '{"type":"official"}'
datavessel --json run datavessel_run_agent --params-json '{"agent_id":"…","template_inputs":{"goal":"auto"}}'
datavessel --json run datavessel_get_run_output --params-json '{"run_id":"…","wait_seconds":120}'Hire the team, keep the sign-off. That’s the whole model.
Leave a Reply