@zibby/skills 0.1.32 → 0.1.34

package/docs/cloud/limits.md

@@ -5,24 +5,24 @@ title: Limits & quotas
 
 # Limits & quotas
 
-## Workflow runtime cap
+## Agent runtime cap
 
-Every workflow execution has a **30-minute hard cap**. If a workflow exceeds it, the
+Every agent execution has a **30-minute hard cap**. If an agent exceeds it, the
 container is terminated with exit code `124` (timeout) and the execution is marked
 `failed` with reason `TIMEOUT`.
 
 Why this exists:
-- Stops runaway workflows (infinite loops, hung HTTP calls, stuck npm installs)
+- Stops runaway agents (infinite loops, hung HTTP calls, stuck npm installs)
   from burning unbounded compute
 - Predictable per-execution cost ceiling
 - Industry standard — GitHub Actions defaults to 6 hours, GitLab CI defaults to
   1 hour, Vercel functions cap at 5 minutes. We picked 30 min as the sweet spot
-  for AI-driven workflows
+  for AI-driven agents
 
-If your workflow needs to run longer:
+If your agent needs to run longer:
 - Split it into multiple shorter executions chained via input/output
 - Move long-running work (large npm installs, video processing) into your bundled
-  artifact at deploy time so the workflow itself stays short
+  artifact at deploy time so the agent itself stays short
 - Contact us about a Pro tier with a longer cap
 
 The cap is enforced **inside** the container by a watchdog timer set on startup,
@@ -43,7 +43,7 @@ marked failed.
 
 ## Container freedom (what you CAN do)
 
-Inside your container, your workflow has **full control**:
+Inside your container, your agent has **full control**:
 
 - Install any npm package (`npm install`, `pip install`, `apt install` if root)
 - Run any shell command (`curl`, `git`, `docker`-in-docker not supported)
@@ -58,7 +58,7 @@ no side effects on Zibby infrastructure.
 
 | Boundary | Why |
 |---|---|
-| Talk to other customers' workflows | Each task is a separate isolated container |
+| Talk to other customers' agents | Each task is a separate isolated container |
 | Use someone else's static IP | Only your account's IP is reachable from your task |
 | Run beyond the 30-min cap | Watchdog kills the process |
 | Read Zibby infra secrets | Container IAM role only sees your execution data |
@@ -66,7 +66,7 @@ no side effects on Zibby infrastructure.
 
 ## Outbound network
 
-By default your workflow exits via a random AWS IP that changes every run. If you
+By default your agent exits via a random AWS IP that changes every run. If you
 need a stable IP for whitelisting customer firewalls, see
 [Dedicated egress IP](./dedicated-egress) ($50/mo addon).
 
@@ -74,8 +74,8 @@ need a stable IP for whitelisting customer firewalls, see
 
 | Endpoint | Limit |
 |---|---|
-| Trigger workflow | 60/min per account |
+| Trigger agent | 60/min per account |
 | Read logs | 600/min per account |
-| Deploy workflow | 30/hour per account |
+| Deploy agent | 30/hour per account |
 
 Hitting a rate limit returns `429 Too Many Requests` with a `Retry-After` header.

package/docs/cloud/triggering.md

@@ -5,18 +5,18 @@ title: Triggering programmatically
 
 # Triggering programmatically
 
-The CLI is the public surface for triggering workflows. CI runners, cron hosts, webhook handlers — all of them shell out to the same command:
+The CLI is the public surface for triggering agents. CI runners, cron hosts, webhook handlers — all of them shell out to the same command:
 
 ```bash
-zibby workflow trigger <uuid>
-zibby workflow trigger <uuid> -p ticket=BUG-123
-zibby workflow trigger <uuid> --input '{"ticket":"BUG-123","priority":"high"}'
-zibby workflow trigger <uuid> --input-file payload.json
+zibby agent trigger <uuid>
+zibby agent trigger <uuid> -p ticket=BUG-123
+zibby agent trigger <uuid> --input '{"ticket":"BUG-123","priority":"high"}'
+zibby agent trigger <uuid> --input-file payload.json
 ```
 
 Auth: set `ZIBBY_API_KEY` in the environment, or run `zibby login` once on a workstation. Either works; the CLI picks up whichever is available.
 
-The flag surface is identical to `zibby workflow run` (local) — same `-p / --input / --input-file`, plus `--idempotency-key` for the cloud-only dedup case below. Flip the verb and the same call shape goes from local to remote.
+The flag surface is identical to `zibby agent run` (local) — same `-p / --input / --input-file`, plus `--idempotency-key` for the cloud-only dedup case below. Flip the verb and the same call shape goes from local to remote.
 
 ### Input precedence
 
@@ -29,7 +29,7 @@ When more than one input source is provided, they merge with this **precedence (
 This means the common pattern of "load a base payload from disk, override a few keys for this run" works without manual merging:
 
 ```bash
-zibby workflow trigger <uuid> --input-file payload.json -p priority=urgent
+zibby agent trigger <uuid> --input-file payload.json -p priority=urgent
 ```
 
 ## CI / cron
@@ -39,10 +39,10 @@ Anywhere you can shell out, call the CLI. Don't hand-roll an HTTP client — you
 ### GitHub Actions
 
 ```yaml
-- name: Trigger Zibby workflow
+- name: Trigger Zibby agent
   run: |
     npm i -g @zibby/cli
-    zibby workflow trigger $WORKFLOW_UUID -p sha=$GITHUB_SHA -p pr=$PR_NUMBER
+    zibby agent trigger $WORKFLOW_UUID -p sha=$GITHUB_SHA -p pr=$PR_NUMBER
   env:
     WORKFLOW_UUID: 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
     ZIBBY_API_KEY: ${{ secrets.ZIBBY_API_KEY }}
@@ -61,7 +61,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - run: npm i -g @zibby/cli
-      - run: zibby workflow trigger $UUID --input '{"weekly":true}'
+      - run: zibby agent trigger $UUID --input '{"weekly":true}'
         env:
           UUID: ${{ vars.WORKFLOW_UUID }}
           ZIBBY_API_KEY: ${{ secrets.ZIBBY_API_KEY }}
@@ -79,7 +79,7 @@ app.post('/webhook', (req, res) => {
 
   try {
     execFileSync('zibby', [
-      'workflow', 'trigger', process.env.WORKFLOW_UUID,
+      'agent', 'trigger', process.env.WORKFLOW_UUID,
       '--input', JSON.stringify(req.body),
       '--idempotency-key', req.headers['x-event-id'],
     ], { env: process.env, stdio: 'pipe' });
@@ -97,7 +97,7 @@ If your runtime can't spawn a Node CLI (constrained Lambda layers, edge runtimes
 Pass an idempotency key to deduplicate triggers within a 24-hour window:
 
 ```bash
-zibby workflow trigger <uuid> \
+zibby agent trigger <uuid> \
   -p ticket=BUG-123 \
   --idempotency-key webhook-2026-05-02-event-7
 ```
@@ -109,14 +109,14 @@ Same key + same input within 24h returns the original `jobId` instead of startin
 After triggering, the CLI prints the `jobId`. To watch the execution:
 
 ```bash
-zibby workflow logs <uuid> -t
+zibby agent logs <uuid> -t
 ```
 
-See [`workflow logs` in the CLI Reference](../cli-reference#workflow-logs).
+See [`agent logs` in the CLI Reference](../cli-reference#agent-logs).
 
-## Per-workflow env vars
+## Per-agent env vars
 
-If your workflow needs credentials or config that's specific to it (different `ANTHROPIC_API_KEY` per pipeline, a workflow-only `DATABASE_URL`, etc.), set them via the env-var API — see [Per-workflow env vars](./env-vars). They get injected into the Fargate task at trigger time and override anything set on the project record.
+If your agent needs credentials or config that's specific to it (different `ANTHROPIC_API_KEY` per agent, an agent-only `DATABASE_URL`, etc.), set them via the env-var API — see [Per-agent env vars](./env-vars). They get injected into the Fargate task at trigger time and override anything set on the project record.
 
 ## Quotas
 

package/docs/concepts/agents.md

@@ -92,7 +92,7 @@ Then a node can use it:
 graph.addNode('plan', { prompt, outputSchema: Plan, agent: 'mine' });
 ```
 
-The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow` is BYO. The five built-ins above live in `@zibby/core`, which is what `zibby workflow new` scaffolds and what the cloud runtime preloads.
+The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow` is BYO. The five built-ins above live in `@zibby/core`, which is what `zibby agent new` scaffolds and what the cloud runtime preloads.
 
 ## Authentication
 
@@ -106,7 +106,7 @@ The framework ships **zero** agent strategies bundled — `@zibby/agent-workflow
 
 In Zibby Cloud, you have two options:
 
-- **Project-wide credentials**: set once on the project record (dashboard → Project → Secrets) — every workflow in the project uses them.
-- **Per-workflow overrides**: set on a single workflow via [`PUT /workflows/<uuid>/env`](../cloud/env-vars) — useful when one pipeline needs a different `ANTHROPIC_API_KEY` from the rest of the project, or when one workflow needs to talk to multiple agent vendors with their own keys.
+- **Project-wide credentials**: set once on the project record (dashboard → Project → Secrets) — every agent in the project uses them.
+- **Per-agent overrides**: set on a single agent via [`PUT /workflows/<uuid>/env`](../cloud/env-vars) — useful when one agent needs a different `ANTHROPIC_API_KEY` from the rest of the project, or when one agent needs to talk to multiple agent vendors with their own keys.
 
-Workflow env wins over project secrets on conflict (last-write-wins inside the Fargate task).
+Agent env wins over project secrets on conflict (last-write-wins inside the Fargate task).

package/docs/concepts/sessions.md

@@ -5,7 +5,7 @@ title: Sessions & artifacts
 
 # Sessions & artifacts
 
-Every workflow run — local or cloud — produces a **session folder** under `.zibby/output/sessions/<sessionId>/`. The folder is the canonical record of what happened.
+Every agent run — local or cloud — produces a **session folder** under `.zibby/output/sessions/<sessionId>/`. The folder is the canonical record of what happened.
 
 ## What's inside
 
@@ -31,7 +31,7 @@ Format: `<unix_ms>_<random>`. Generated when the graph starts running.
 You can override via:
 
 ```bash
-zibby workflow run my-pipeline --session 1777678254943_ymcw
+zibby agent run my-agent --session 1777678254943_ymcw
 ```
 
 Useful for replay — re-run from a saved input/state without re-paying earlier nodes.
@@ -39,7 +39,7 @@ Useful for replay — re-run from a saved input/state without re-paying earlier
 ## Replay a session
 
 ```bash
-zibby workflow run my-pipeline \
+zibby agent run my-agent \
   --session 1777678254943_ymcw \
   --node verify   # only re-run the 'verify' node
 ```
@@ -48,19 +48,19 @@ The graph reads `state.plan` and `state.implement` from the saved session and on
 
 ## Cloud sessions
 
-Cloud runs land in the same `.zibby/output/sessions/` layout, just inside the ECS container's `/workspace/`. The session folder is uploaded to S3 at the end of each run; `zibby workflow logs <uuid> -t` streams CloudWatch logs in real time.
+Cloud runs land in the same `.zibby/output/sessions/` layout, just inside the ECS container's `/workspace/`. The session folder is uploaded to S3 at the end of each run; `zibby agent logs <uuid> -t` streams CloudWatch logs in real time.
 
 To download a finished cloud session locally:
 
 ```bash
-zibby workflow download <uuid>
+zibby agent download <uuid>
 ```
 
-This pulls the workflow source (so you can edit and redeploy) plus the most recent execution's session folder.
+This pulls the agent source (so you can edit and redeploy) plus the most recent execution's session folder.
 
 ## Studio integration
 
-[Zibby Studio](https://zibby.app) is a desktop UI that watches `.zibby/output/sessions/`. Anything that writes a session folder shows up in Studio automatically — pin a session, watch state evolve live, or stop a workflow from the Stop button.
+[Zibby Studio](https://zibby.app) is a desktop UI that watches `.zibby/output/sessions/`. Anything that writes a session folder shows up in Studio automatically — pin a session, watch state evolve live, or stop an agent from the Stop button.
 
 The protocol is documented and stable:
 

package/docs/concepts/state.md

@@ -5,7 +5,7 @@ title: State & schema
 
 # State & schema
 
-Every workflow run carries one **state** object that flows from node to node. State is the only handoff mechanism — there's no shared globals, no hidden context.
+Every agent run carries one **state** object that flows from node to node. State is the only handoff mechanism — there's no shared globals, no hidden context.
 
 ## Shape
 

package/docs/concepts/sub-graphs.md

@@ -5,13 +5,13 @@ title: Sub-graphs (parent → child)
 
 # Sub-graphs
 
-A **sub-graph node** runs another deployed workflow as a child of the current one. Use it when a step is large enough to deserve its own workflow definition — its own state schema, its own version, its own activity-tab history — but you want a parent to dispatch it as part of a larger flow.
+A **sub-graph node** runs another deployed agent as a child of the current one. Use it when a step is large enough to deserve its own workflow definition — its own state schema, its own version, its own activity-tab history — but you want a parent to dispatch it as part of a larger flow.
 
 The shape is one extra field on the existing node config:
 
 ```js
 g.addNode('audit', {
-  workflow: 'deep-audit',   // ← name of another workflow in this project
+  workflow: 'deep-audit',   // ← name of another agent in this project
 });
 ```
 
@@ -22,7 +22,7 @@ That's it. No new imports, no UUID, no separate class. The engine recognizes `wo
 | Scenario | Sub-graph? |
 |---|---|
 | Two parents need the same multi-node flow | ✅ Yes — define it once as a child, reference by name |
-| One step needs different state schema than the rest | ✅ Yes — each workflow has its own schema |
+| One step needs different state schema than the rest | ✅ Yes — each agent has its own schema |
 | You want per-step activity-tab history + replay | ✅ Yes — each child run gets its own row |
 | Step is a single LLM call | ❌ No — just add a regular node |
 | Step has its own retry policy | Either works, but a sub-graph gives independent control |
@@ -77,7 +77,7 @@ g.addNode('audit', {
 
 ## How state flows
 
-Each workflow has its own state schema — they're independent. The parent must transform its state into the child's input shape, and (optionally) extract whatever it needs back out.
+Each agent has its own state schema — they're independent. The parent must transform its state into the child's input shape, and (optionally) extract whatever it needs back out.
 
 ### A complete example — `parent-orchestrator` calls `child-doubler`
 
@@ -184,13 +184,13 @@ err.subgraphStatus     // 'failed' | 'canceled' | 'timeout'
 
 ## What's deployed vs what you write
 
-You only ever reference workflows by **name**. The cloud handles the UUID resolution.
+You only ever reference agents by **name**. The cloud handles the UUID resolution.
 
 | Stage | What you write | What the backend does |
 |---|---|---|
-| `zibby workflow deploy child-doubler` | nothing about UUIDs | mints UUID, stores `(projectId, workflowType='child-doubler', uuid='…')` |
+| `zibby agent deploy child-doubler` | nothing about UUIDs | mints UUID, stores `(projectId, workflowType='child-doubler', uuid='…')` |
 | `subgraph('child-doubler')` in parent code | just the name | stored as a string in the parent's graph definition |
-| `zibby workflow deploy parent-orchestrator` | nothing | looks up `'child-doubler'` → UUID, snapshots the dependency |
+| `zibby agent deploy parent-orchestrator` | nothing | looks up `'child-doubler'` → UUID, snapshots the dependency |
 | Parent runs in Fargate → hits sub-graph node | nothing | POSTs to `/workflows/<uuid>/trigger` with `parentExecutionId` |
 
 Names are unique per project (DDB primary key enforces this), so `subgraph('child-doubler')` resolves unambiguously within the parent's project.
@@ -208,14 +208,14 @@ Each child execution row carries `parentExecutionId` pointing at the parent. The
 
 Sub-graph dispatch needs the `PROGRESS_API_URL` env var (the public API base). That's set automatically on Fargate runs. For local dev, you have two options:
 
-1. **Deploy both workflows to cloud, then trigger the parent.** The cloud path always works.
+1. **Deploy both agents to cloud, then trigger the parent.** The cloud path always works.
 2. **Mock the trigger + status endpoints locally.** See [`workflows/parent-orchestrator/mock-server.mjs`](https://github.com/ZibbyHQ/agent-workflow/tree/main/examples) in the agent-workflow repo for a 90-line example that simulates the dispatch + poll loop.
 
 In-process sub-graph execution (running the child in the parent's Node process directly, no HTTP) is **not supported** — we picked consistency between local and cloud over the 10s spawn-time savings.
 
 ## Cross-project sub-graphs
 
-`workflow: 'name'` resolves within the parent's own project. To call another project's workflow, pass an explicit project ID:
+`workflow: 'name'` resolves within the parent's own project. To call another project's agent, pass an explicit project ID:
 
 ```js
 g.addNode('audit', {

package/docs/get-started/deploy.md

@@ -5,34 +5,34 @@ pagination_prev: get-started/run-locally
 pagination_next: get-started/trigger-and-logs
 ---
 
-# Ship a workflow to Zibby Cloud
+# Ship an agent to Zibby Cloud
 
 ```bash
-zibby workflow deploy my-pipeline
+zibby agent deploy my-agent
 ```
 
 If you have multiple projects, the CLI prompts you to pick one. On success it prints a UUID:
 
 ```
-✔ Deployed my-pipeline (v1)
+✔ Deployed my-agent (v1)
 ✔ Bundle ready (78s) — runtime npm install eliminated
 
   UUID:        2b1ea07f-3ede-4bfd-a51d-431f0bab008e
 
   Next steps:
-    zibby workflow run my-pipeline         Run locally
-    zibby workflow trigger 2b1ea07f-...    Run in cloud
-    zibby workflow list                    View all workflows
+    zibby agent run my-agent         Run locally
+    zibby agent trigger 2b1ea07f-...    Run in cloud
+    zibby agent list                    View all agents
 ```
 
-The UUID is **canonical** — it never changes once issued. All cloud commands (`trigger`, `logs`, `download`, `delete`) take that UUID as their identifier. The CLI caches it in `.zibby/workflows/my-pipeline/.zibby-deploy.json` so you don't have to remember it. Commit that file to git; collaborators share the same canonical reference.
+The UUID is **canonical** — it never changes once issued. All cloud commands (`trigger`, `logs`, `download`, `delete`) take that UUID as their identifier. The CLI caches it in `.zibby/workflows/my-agent/.zibby-deploy.json` so you don't have to remember it. Commit that file to git; collaborators share the same canonical reference.
 
 ## What deploy actually does
 
 Two phases:
 
-1. **Source upload** — your workflow folder (sources only, no `node_modules`) is uploaded as a JSON payload to S3 via a presigned URL. The CLI also resolves your `.zibby.config.mjs` (if present at project root) and ships it inside the bundle as `zibby.config.json`, so the cloud sees the same config as your local runs.
-2. **Bundle build (Heroku-style)** — a CodeBuild job downloads the sources, runs `npm install --omit=dev`, packages the result as a tarball, and uploads it to S3. The tarball is what each cloud execution downloads at trigger time, so there's **no `npm install` at runtime** — workflows boot in seconds.
+1. **Source upload** — your agent folder (sources only, no `node_modules`) is uploaded as a JSON payload to S3 via a presigned URL. The CLI also resolves your `.zibby.config.mjs` (if present at project root) and ships it inside the bundle as `zibby.config.json`, so the cloud sees the same config as your local runs.
+2. **Bundle build (Heroku-style)** — a CodeBuild job downloads the sources, runs `npm install --omit=dev`, packages the result as a tarball, and uploads it to S3. The tarball is what each cloud execution downloads at trigger time, so there's **no `npm install` at runtime** — agents boot in seconds.
 
 You'll see a live spinner with the active build step:
 
@@ -44,7 +44,7 @@ Pass `--verbose` if you want to see raw CodeBuild logs.
 
 ## Re-deploys keep the same UUID
 
-Once a workflow has a UUID, every subsequent `deploy` increments the version but keeps the UUID stable:
+Once an agent has a UUID, every subsequent `deploy` increments the version but keeps the UUID stable:
 
 ```
 v1 → v2 → v3 → ...    (same UUID, same trigger URL)
@@ -56,20 +56,20 @@ So your `curl` calls and CI integrations don't break across deploys.
 
 A clean mental model:
 
-- **Workflow folder name** (`my-pipeline`) is *local* — used by `workflow new`, `start`, `deploy`. It's just a directory name.
+- **Agent folder name** (`my-agent`) is *local* — used by `agent new`, `start`, `deploy`. It's just a directory name.
 - **UUID** (`2b1ea07f-...`) is *canonical* — used by `trigger`, `logs`, `download`, `delete`. Stable across deploys.
 
-`workflow list` shows both:
+`agent list` shows both:
 
 ```
 ┌─────────────────────────────────────┬──────────────┬──────────┬─────┐
 │ UUID                                │ Name         │ Project  │ Ver │
 ├─────────────────────────────────────┼──────────────┼──────────┼─────┤
-│ 2b1ea07f-3ede-4bfd-a51d-431f0bab008e│ my-pipeline  │ Zibby UI │ 3   │
+│ 2b1ea07f-3ede-4bfd-a51d-431f0bab008e│ my-agent  │ Zibby UI │ 3   │
 │ -                                   │ scratchpad   │ -        │ -   │
 └─────────────────────────────────────┴──────────────┴──────────┴─────┘
 ```
 
-`-` in the UUID column means a local-only workflow that hasn't been deployed yet.
+`-` in the UUID column means a local-only agent that hasn't been deployed yet.
 
 → Next: [Trigger & tail logs](./trigger-and-logs)

package/docs/get-started/install.md

@@ -7,6 +7,8 @@ pagination_next: get-started/your-first-workflow
 
 # Install the CLI
 
+You build **Agents** with Zibby — deployed automations. The CLI command is `zibby agent`.
+
 ```bash
 npm install -g @zibby/cli
 ```
@@ -24,7 +26,7 @@ You should see something like `zibby v0.4.x`.
 Every example below works with `npx @zibby/cli` instead of `zibby`:
 
 ```bash
-npx @zibby/cli workflow new my-pipeline
+npx @zibby/cli agent new my-agent
 ```
 
 The first call downloads the package; subsequent calls use the cached copy.
@@ -43,7 +45,7 @@ For CI/CD, set `ZIBBY_API_KEY` in the environment instead — the CLI prefers th
 
 ## Pick an agent runtime
 
-Workflows hand off to external coding-agent CLIs at runtime. You'll need at least one of these installed (locally — the cloud runtime has them pre-installed):
+Agents hand off to external coding-agent CLIs at runtime. You'll need at least one of these installed (locally — the cloud runtime has them pre-installed):
 
 | Agent | How to install | Auth |
 |---|---|---|
@@ -55,4 +57,4 @@ Workflows hand off to external coding-agent CLIs at runtime. You'll need at leas
 
 You only need one. The cloud runtime supports all five out of the box.
 
-→ Next: [Your first workflow](./your-first-workflow)
+→ Next: [Your first agent](./your-first-workflow)

package/docs/get-started/run-locally.md

@@ -5,10 +5,10 @@ pagination_prev: get-started/your-first-workflow
 pagination_next: get-started/deploy
 ---
 
-# Run a workflow locally
+# Run an agent locally
 
 ```bash
-zibby workflow run my-pipeline
+zibby agent run my-agent
 ```
 
 One-shot: loads `graph.mjs`, instantiates your `WorkflowAgent` class, runs the graph against a real agent, prints results, exits. Output lands in `.zibby/output/sessions/<sessionId>/`:
@@ -18,11 +18,11 @@ One-shot: loads `graph.mjs`, instantiates your `WorkflowAgent` class, runs the g
 - `events.json` — JSONL execution log: which node ran when, what it received, what it returned, retries
 - `.session-info.json` — session metadata
 
-The flag surface mirrors `zibby workflow trigger` (cloud) on purpose: the call you make locally is the same call you make against the cloud, just with the verb flipped.
+The flag surface mirrors `zibby agent trigger` (cloud) on purpose: the call you make locally is the same call you make against the cloud, just with the verb flipped.
 
 ## Pass input
 
-Most workflows take input. Edit `graph.mjs` to define an input schema and reference `state.input`:
+Most agents take input. Edit `graph.mjs` to define an input schema and reference `state.input`:
 
 ```js
 graph.addNode('plan', {
@@ -35,14 +35,14 @@ graph.addNode('plan', {
 Then pass input via `--input`:
 
 ```bash
-zibby workflow run my-pipeline --input '{"ticket":"BUG-123"}'
+zibby agent run my-agent --input '{"ticket":"BUG-123"}'
 ```
 
 Or `--param key=value` (repeatable, dot-notation supported):
 
 ```bash
-zibby workflow run my-pipeline -p ticket=BUG-123 -p priority=high
-zibby workflow run my-pipeline -p user.name=Alice -p user.role=admin
+zibby agent run my-agent -p ticket=BUG-123 -p priority=high
+zibby agent run my-agent -p user.name=Alice -p user.role=admin
 ```
 
 Or `--input-file payload.json` for larger payloads.
@@ -56,15 +56,15 @@ Each run is a fresh process — re-edit `graph.mjs` or any node file and re-run.
 If you want auto-rerun on file change, run it under `nodemon`:
 
 ```bash
-npx nodemon --ext mjs,js --exec "zibby workflow run my-pipeline -p ticket=BUG-123"
+npx nodemon --ext mjs,js --exec "zibby agent run my-agent -p ticket=BUG-123"
 ```
 
-Or add it to your workflow's `package.json`:
+Or add it to your agent's `package.json`:
 
 ```json
 {
   "scripts": {
-    "dev": "nodemon --ext mjs,js --exec \"zibby workflow run my-pipeline\""
+    "dev": "nodemon --ext mjs,js --exec \"zibby agent run my-agent\""
   }
 }
 ```
@@ -85,10 +85,10 @@ cat .zibby/output/sessions/<sessionId>/result.json | jq
 Studio is a desktop UI for browsing live + past runs. It connects to a local HTTP server, so when you use Studio you start that instead:
 
 ```bash
-zibby workflow start my-pipeline   # long-lived server on :3848 (Studio talks to this)
+zibby agent start my-agent   # long-lived server on :3848 (Studio talks to this)
 zibby studio                       # launch the desktop app
 ```
 
-For CLI-only iteration, stick with `zibby workflow run`.
+For CLI-only iteration, stick with `zibby agent run`.
 
 → Next: [Deploy to cloud](./deploy)

package/docs/get-started/trigger-and-logs.md

@@ -4,12 +4,12 @@ title: 5. Trigger & tail logs
 pagination_prev: get-started/deploy
 ---
 
-# Run a deployed workflow and watch logs
+# Run a deployed agent and watch logs
 
 ## Trigger
 
 ```bash
-zibby workflow trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
+zibby agent trigger 2b1ea07f-3ede-4bfd-a51d-431f0bab008e
 ```
 
 The CLI returns immediately with a job ID:
@@ -24,24 +24,24 @@ The CLI returns immediately with a job ID:
     Triggered: 02/05/2026, 10:23:13
 
   Monitor execution:
-    zibby workflow logs 2b1ea07f-... 
-    zibby workflow logs 2b1ea07f-... -t
+    zibby agent logs 2b1ea07f-... 
+    zibby agent logs 2b1ea07f-... -t
 ```
 
 Pass input the same way as locally:
 
 ```bash
-zibby workflow trigger <uuid> -p ticket=BUG-123
-zibby workflow trigger <uuid> --input '{"ticket":"BUG-123"}'
-zibby workflow trigger <uuid> --input-file ./input.json
+zibby agent trigger <uuid> -p ticket=BUG-123
+zibby agent trigger <uuid> --input '{"ticket":"BUG-123"}'
+zibby agent trigger <uuid> --input-file ./input.json
 ```
 
-If you omit the UUID, the CLI shows an interactive picker over your deployed workflows.
+If you omit the UUID, the CLI shows an interactive picker over your deployed agents.
 
 ## Tail logs (Heroku-style)
 
 ```bash
-zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
+zibby agent logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 ```
 
 `-t` follows live. Without `-t` it dumps the last execution and exits.
@@ -52,7 +52,7 @@ zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 
 2026-05-02 23:30:51.345  zibby v0.4.x
 ────────────────────────────────────────────────────────────
- Workflow:  my-pipeline
+ Workflow:  my-agent
  Job:       ee333411-...
  Project:   6b60049d-...
  Agent:     cursor (model: auto)
@@ -65,24 +65,24 @@ zibby workflow logs 2b1ea07f-3ede-4bfd-a51d-431f0bab008e -t
 │ ◆ Model: auto | key: ***bc97
 │ ...
 └ done 19.4s
-[done] my-pipeline completed in 19.4s
+[done] my-agent completed in 19.4s
 ```
 
 The stream covers the full execution end-to-end — agent reasoning, tool calls, schema validation, completion summary.
 
 ## Multiple executions
 
-Workflow UUIDs follow the workflow, not a single run. After one execution finishes, `logs -t` waits for the next trigger of the same workflow and auto-switches to streaming it. Like `heroku logs --tail`.
+Agent UUIDs follow the agent, not a single run. After one execution finishes, `logs -t` waits for the next trigger of the same agent and auto-switches to streaming it. Like `heroku logs --tail`.
 
 To exit after the current run, just Ctrl+C — there's no "exit on completion" mode (yet).
 
 ## Triggering from anywhere
 
-The CLI is the easiest way, but workflows expose an HTTP API for programmatic triggering — see [Cloud → Triggering programmatically](../cloud/triggering).
+The CLI is the easiest way, but agents expose an HTTP API for programmatic triggering — see [Cloud → Triggering programmatically](../cloud/triggering).
 
 ## You're done
 
-You've now scaffolded, run locally, deployed, triggered, and tailed a workflow. The rest of the docs go deeper:
+You've now scaffolded, run locally, deployed, triggered, and tailed an agent. The rest of the docs go deeper:
 
 - [Concepts](../concepts/graph) — how the graph engine works
 - [CLI Reference](../cli-reference) — every command