@zibby/skills 0.1.33 → 0.1.34

package/docs/cli-reference.md

@@ -5,22 +5,22 @@ title: CLI Reference
 
 # CLI Reference
 
-Every command lives under `zibby workflow <verb>` for consistency. The bare top-level forms (`zibby start`, `zibby deploy`, `zibby trigger`, `zibby logs`, `zibby g workflow`) are kept as backward-compat aliases — they call the same handlers — but new code should use the namespaced forms.
+Every command lives under `zibby agent <verb>` for consistency. The bare top-level forms (`zibby start`, `zibby deploy`, `zibby trigger`, `zibby logs`) are kept as backward-compat aliases — they call the same handlers — but new code should use the namespaced forms.
 
-## Workflow commands
+## Agent commands
 
 | Command | What it does |
 |---|---|
-| [`zibby workflow new <name>`](#workflow-new) | Scaffold a new custom workflow under `.zibby/workflows/<name>/`. |
-| [`zibby workflow run <name>`](#workflow-run) | One-shot local execution. Same input flags as `trigger`. |
-| [`zibby workflow list`](#workflow-list) | List local + deployed workflows. |
-| [`zibby workflow deploy [name]`](#workflow-deploy) | Deploy to Zibby Cloud. Interactive picker if name omitted. |
-| [`zibby workflow trigger [uuid]`](#workflow-trigger) | Run a deployed workflow remotely. UUID is canonical. |
-| [`zibby workflow logs [uuid] -t`](#workflow-logs) | Tail logs from a run, Heroku-style. |
-| [`zibby workflow download <uuid>`](#workflow-download) | Pull a deployed workflow back to local. Edit + redeploy. |
-| [`zibby workflow delete <uuid>`](#workflow-delete) | Delete a deployed workflow. |
-| [`zibby workflow start <name>`](#workflow-start) | Long-lived dev server (Studio integration). Most users want `run`. |
-| [`zibby workflow env <verb>`](#workflow-env) | Manage per-workflow encrypted env vars: `list`, `set`, `unset`, `push`. |
+| [`zibby agent new <name>`](#agent-new) | Scaffold a new custom agent under `.zibby/workflows/<name>/`. |
+| [`zibby agent run <name>`](#agent-run) | One-shot local execution. Same input flags as `trigger`. |
+| [`zibby agent list`](#agent-list) | List local + deployed agents. |
+| [`zibby agent deploy [name]`](#agent-deploy) | Deploy to Zibby Cloud. Interactive picker if name omitted. |
+| [`zibby agent trigger [uuid]`](#agent-trigger) | Run a deployed agent remotely. UUID is canonical. |
+| [`zibby agent logs [uuid] -t`](#agent-logs) | Tail logs from a run, Heroku-style. |
+| [`zibby agent download <uuid>`](#agent-download) | Pull a deployed agent back to local. Edit + redeploy. |
+| [`zibby agent delete <uuid>`](#agent-delete) | Delete a deployed agent. |
+| [`zibby agent start <name>`](#agent-start) | Long-lived dev server (Studio integration). Most users want `run`. |
+| [`zibby agent env <verb>`](#agent-env) | Manage per-agent encrypted env vars: `list`, `set`, `unset`, `push`. |
 
 Plus the test recipe + memory + project setup:
 
@@ -28,8 +28,8 @@ Plus the test recipe + memory + project setup:
 |---|---|
 | [`zibby test [spec]`](#test) | Run a test spec (or inline string). Drives the browser via Cursor / Claude / Codex / Gemini. |
 | [`zibby memory <verb>`](#memory) | Local + remote test-memory DB: `init`, `stats`, `cost`, `compact`, `reset`, `pull`, `push`, `remote …`. |
-| [`zibby init [project]`](#init) | Bootstrap a Zibby project (config + creds). `-t <template>` to also scaffold a workflow. |
-| [`zibby template <verb>`](#template) | List or add workflow templates: `list`, `add <name>`. |
+| [`zibby init [project]`](#init) | Bootstrap a Zibby project (config + creds). `-t <template>` to also scaffold an agent. |
+| [`zibby template <verb>`](#template) | List or add agent templates: `list`, `add <name>`. |
 
 Auth + admin:
 
@@ -40,10 +40,10 @@ Auth + admin:
 | `zibby status` | Show current auth state. |
 | `zibby list` | List projects + API tokens you have access to. |
 
-## workflow new {#workflow-new}
+## agent new {#agent-new}
 
 ```bash
-zibby workflow new [name]
+zibby agent new [name]
 ```
 
 Scaffolds `.zibby/workflows/<name>/` with a starter `graph.mjs`, `nodes/example.mjs`, `package.json`, and `workflow.json` manifest. Auto-runs `npm install` in the new folder unless `--skip-install`.
@@ -52,15 +52,15 @@ Options:
 - `--skip-install` — skip `npm install`
 - If `name` is omitted, the CLI generates one (`zealous-otter`, etc.)
 
-## workflow run {#workflow-run}
+## agent run {#agent-run}
 
 ```bash
-zibby workflow run <workflow-name>
+zibby agent run <agent-name>
 ```
 
 Loads `graph.mjs`, instantiates the entry class, runs the graph **once** in-process, prints results, and exits. Output → `.zibby/output/sessions/<sessionId>/`.
 
-Mirrors `zibby workflow trigger` so the same input flags work locally and in the cloud — flip the verb and the project, and your local dev loop is exactly the same call shape your CI/CD uses.
+Mirrors `zibby agent trigger` so the same input flags work locally and in the cloud — flip the verb and the project, and your local dev loop is exactly the same call shape your CI/CD uses.
 
 Options:
 - `-p, --param <key=value>` — input param (repeatable, highest precedence). Example: `-p ticket=BUG-123 -p priority=high`
@@ -69,40 +69,40 @@ Options:
 
 Examples:
 ```bash
-zibby workflow run my-pipeline
-zibby workflow run my-pipeline -p ticket=BUG-123
-zibby workflow run my-pipeline --input '{"ticket":"BUG-123","priority":"high"}'
-zibby workflow run my-pipeline --input-file payload.json -p priority=urgent
+zibby agent run my-agent
+zibby agent run my-agent -p ticket=BUG-123
+zibby agent run my-agent --input '{"ticket":"BUG-123","priority":"high"}'
+zibby agent run my-agent --input-file payload.json -p priority=urgent
 ```
 
-## workflow start {#workflow-start}
+## agent start {#agent-start}
 
 ```bash
-zibby workflow start <workflow-name>
+zibby agent start <agent-name>
 ```
 
-Long-lived local dev server (default port 3848). Listens on `POST /trigger` for input payloads and runs the workflow in-process. Used today by the Studio desktop app — for plain CLI use, prefer `workflow run`.
+Long-lived local dev server (default port 3848). Listens on `POST /trigger` for input payloads and runs the agent in-process. Used today by the Studio desktop app — for plain CLI use, prefer `agent run`.
 
 Options:
 - `-p, --port <port>` — override the default port (3848)
 
-## workflow list {#workflow-list}
+## agent list {#agent-list}
 
 ```bash
-zibby workflow list
+zibby agent list
 ```
 
-Shows both local workflows (folders under `.zibby/workflows/`) and deployed ones (from cloud, scoped to projects you have access to). Output is a table with UUID, Name, Project, Version. `-` in any column means "not applicable" (e.g. local-only workflows have no UUID yet).
+Shows both local agents (folders under `.zibby/workflows/`) and deployed ones (from cloud, scoped to projects you have access to). Output is a table with UUID, Name, Project, Version. `-` in any column means "not applicable" (e.g. local-only agents have no UUID yet).
 
 Options:
 - `--local-only` — skip the cloud query
 - `--remote-only` — skip the local scan
 - `--project <id>` — filter to one project
 
-## workflow deploy {#workflow-deploy}
+## agent deploy {#agent-deploy}
 
 ```bash
-zibby workflow deploy [workflow-name]
+zibby agent deploy [agent-name]
 ```
 
 Two phases:
@@ -114,16 +114,16 @@ After success, the CLI writes `.zibby/workflows/<name>/.zibby-deploy.json` with
 Options:
 - `--project <id>` — skip the project picker
 - `--api-key <key>` — auth via API key (or set `ZIBBY_API_KEY`)
-- `--env <path>` — sync a `.env` file into per-workflow env vars after deploy. Repeatable (later files override). See [Per-workflow env vars](./cloud/env-vars).
+- `--env <path>` — sync a `.env` file into per-agent env vars after deploy. Repeatable (later files override). See [Per-agent env vars](./cloud/env-vars).
 - `--verbose` — show raw CodeBuild logs during the bundle build
 
-## workflow trigger {#workflow-trigger}
+## agent trigger {#agent-trigger}
 
 ```bash
-zibby workflow trigger <uuid>
+zibby agent trigger <uuid>
 ```
 
-UUID is required (or omit for interactive picker). Names aren't accepted — pass the UUID from `.zibby-deploy.json` or `workflow list`.
+UUID is required (or omit for interactive picker). Names aren't accepted — pass the UUID from `.zibby-deploy.json` or `agent list`.
 
 Options:
 - `-p, --param <key=value>` — input param (repeatable, highest precedence)
@@ -132,14 +132,14 @@ Options:
 - `--idempotency-key <key>` — prevent duplicate executions
 - `--api-key <key>` — auth via API key
 
-## workflow logs {#workflow-logs}
+## agent logs {#agent-logs}
 
 ```bash
-zibby workflow logs <uuid>          # dump latest run
-zibby workflow logs <uuid> -t       # tail live (Heroku-style)
+zibby agent logs <uuid>          # dump latest run
+zibby agent logs <uuid> -t       # tail live (Heroku-style)
 ```
 
-When `-t` is set and the workflow finishes, the stream waits for the next trigger of the same workflow and auto-switches to streaming it. Ctrl+C to exit.
+When `-t` is set and the agent finishes, the stream waits for the next trigger of the same agent and auto-switches to streaming it. Ctrl+C to exit.
 
 Options:
 - `-t, --follow` — live tail
@@ -147,43 +147,43 @@ Options:
 - `--all --workflow <name>` — interleaved logs from all runs (requires `--workflow`)
 - `--api-key <key>` — auth via API key
 
-**Storage & retention.** Live logs are kept in CloudWatch for 30 days. Beyond that, the per-run session folder (uploaded to S3 at the end of every execution) is the long-term archive — pull it back with `zibby workflow download <uuid>`.
+**Storage & retention.** Live logs are kept in CloudWatch for 30 days. Beyond that, the per-run session folder (uploaded to S3 at the end of every execution) is the long-term archive — pull it back with `zibby agent download <uuid>`.
 
-## workflow env {#workflow-env}
+## agent env {#agent-env}
 
-Per-workflow encrypted env vars — KMS-stored on the workflow record, injected into the Fargate task at trigger time. Workflow env wins over project secrets on conflict.
+Per-agent encrypted env vars — KMS-stored on the agent record, injected into the Fargate task at trigger time. Agent env wins over project secrets on conflict.
 
 ```bash
-zibby workflow env list <uuid>                       # show key names (no values)
-zibby workflow env set <uuid> ANTHROPIC_API_KEY=sk-…  # add or rotate one
-zibby workflow env unset <uuid> OLD_KEY               # remove one
-zibby workflow env push <uuid> --file .env [--file .env.prod]   # bulk replace from .env files
+zibby agent env list <uuid>                       # show key names (no values)
+zibby agent env set <uuid> ANTHROPIC_API_KEY=sk-…  # add or rotate one
+zibby agent env unset <uuid> OLD_KEY               # remove one
+zibby agent env push <uuid> --file .env [--file .env.prod]   # bulk replace from .env files
 ```
 
 `push` accepts repeatable `--file` (later files override). `list` only ever returns key names — values never leave the encrypted blob.
 
-The shortcut for first-time setup is `zibby workflow deploy --env .env`, which runs `push` automatically against the new UUID. Full guide: [Per-workflow env vars](./cloud/env-vars).
+The shortcut for first-time setup is `zibby agent deploy --env .env`, which runs `push` automatically against the new UUID. Full guide: [Per-agent env vars](./cloud/env-vars).
 
-## workflow download {#workflow-download}
+## agent download {#agent-download}
 
 ```bash
-zibby workflow download <uuid>
+zibby agent download <uuid>
 ```
 
-Pulls the deployed workflow's sources back into `.zibby/workflows/<name>/`, including the `.zibby-deploy.json` manifest. Useful when collaborators need the source from cloud.
+Pulls the deployed agent's sources back into `.zibby/workflows/<name>/`, including the `.zibby-deploy.json` manifest. Useful when collaborators need the source from cloud.
 
 Options:
-- `--type <type>` — for built-in workflows (`analysis`, `implementation`, `run_test`)
+- `--type <type>` — for built-in agents (`analysis`, `implementation`, `run_test`)
 - `--output <dir>` — alternate output base
 - `--include-default` — pull the built-in default graph if no custom one exists
 
-## workflow delete {#workflow-delete}
+## agent delete {#agent-delete}
 
 ```bash
-zibby workflow delete <uuid>
+zibby agent delete <uuid>
 ```
 
-Removes the workflow from cloud (and its trigger URL). Local files are not touched.
+Removes the agent from cloud (and its trigger URL). Local files are not touched.
 
 ## test {#test}
 
@@ -240,10 +240,10 @@ zibby init [project-name]
 zibby init -t browser-test-automation   # also scaffold the test recipe
 ```
 
-Bare init by default — writes `.zibby.config.mjs`, sets up agent credentials, configures memory. Pass `-t <template>` to also scaffold a workflow template into `.zibby/`.
+Bare init by default — writes `.zibby.config.mjs`, sets up agent credentials, configures memory. Pass `-t <template>` to also scaffold an agent template into `.zibby/`.
 
 Common options:
-- `-t, --template <name>` — workflow template to scaffold (see `zibby template list`). Default: none (config + creds only).
+- `-t, --template <name>` — agent template to scaffold (see `zibby template list`). Default: none (config + creds only).
 - `--agent <claude|cursor|codex|gemini>` — pick the agent up front instead of prompting
 - `--memory-backend <mem0|dolt>` — memory backend (default: `mem0` — semantic vector memory, billed through the agent run in cloud, falls back to `dolt` if the embedding proxy is unavailable; pass `dolt` for self-contained structured memory — see [Chat memory](./skills/chat-memory.md))
 - `--skip-install` / `--skip-memory` — skip `npm install` / skip memory setup
@@ -258,7 +258,7 @@ zibby template list             # see what's available
 zibby template add <name>       # copy template into .zibby/ (overwrites = doubles as update)
 ```
 
-Templates are starter workflow scaffolds. `add` overwrites existing files in place — use it to upgrade an outdated agent helpers block, or to grab a recipe you didn't pick at `init` time.
+Templates are starter agent scaffolds. `add` overwrites existing files in place — use it to upgrade an outdated agent helpers block, or to grab a recipe you didn't pick at `init` time.
 
 `zibby template add zibby-workflow-claude` (or `-cursor`, `-codex`) refreshes the per-agent guidance files emitted by this template — the `<!-- zibby-template-version: N -->` markers make the upgrade idempotent.
 
@@ -442,20 +442,20 @@ Drains the ECS service, deletes the task definition revision, removes the ALB li
 | `ZIBBY_API_KEY` | API key for non-interactive auth (CI). Preferred over saved session. |
 | `ZIBBY_PROJECT_ID` | Default project for commands that take `--project` |
 | `AGENT_TYPE` | Default agent strategy when no per-node override and no project default |
-| `ZIBBY_DEPLOY_VERBOSE=1` | Same as `--verbose` on `workflow deploy` |
+| `ZIBBY_DEPLOY_VERBOSE=1` | Same as `--verbose` on `agent deploy` |
 | `ZIBBY_SESSION_LOG=1` | Re-enable the diagnostic `[zibby:session]` log line in run output |
 | `ZIBBY_RUN_DIAG=1` | Cloud runtime: dump per-copy `agent-workflow` registry state |
 | `ZIBBY_DEBUG=true` | Verbose debug logs from the framework |
 
 ## Legacy aliases
 
-These still work and route to the same handlers, but new code should use the `zibby workflow <verb>` form:
+These still work and route to the same handlers, but new code should use the `zibby agent <verb>` form. The `zibby workflow <verb>` namespace also remains a full alias for `zibby agent <verb>`:
 
 | Legacy | Canonical |
 |---|---|
-| `zibby g workflow <name>` | `zibby workflow new <name>` |
-| `zibby start <name>` | `zibby workflow start <name>` |
-| `zibby run <name>` | `zibby workflow run <name>` |
-| `zibby deploy [name]` | `zibby workflow deploy [name]` |
-| `zibby trigger <uuid>` | `zibby workflow trigger <uuid>` |
-| `zibby logs <uuid>` | `zibby workflow logs <uuid>` |
+| `zibby g workflow <name>` | `zibby agent new <name>` |
+| `zibby start <name>` | `zibby agent start <name>` |
+| `zibby run <name>` | `zibby agent run <name>` |
+| `zibby deploy [name]` | `zibby agent deploy [name]` |
+| `zibby trigger <uuid>` | `zibby agent trigger <uuid>` |
+| `zibby logs <uuid>` | `zibby agent logs <uuid>` |

package/docs/cloning-repositories.md

@@ -3,13 +3,13 @@ sidebar_position: 8
 title: Cloning Repositories
 ---
 
-# Cloning Repositories in Custom Workflows
+# Cloning Repositories in Custom Agents
 
-Custom workflows can clone your project's configured repositories (GitHub/GitLab) using the `cloneRepo()` helper function from `@zibby/core`.
+Custom agents can clone your project's configured repositories (GitHub/GitLab) using the `cloneRepo()` helper function from `@zibby/core`.
 
 ## Overview
 
-When your workflow runs in the cloud, it has access to:
+When your agent runs in the cloud, it has access to:
 - All repositories configured in your project settings (GitHub/GitLab)
 - Authenticated tokens for cloning (injected securely by the platform)
 - A clean isolated container environment
@@ -135,9 +135,9 @@ If a repository fails to clone, its value will be `null`:
 }
 ```
 
-## Complete Example Workflow
+## Complete Example Agent
 
-Here's a full workflow that clones repos and runs analysis:
+Here's a full agent that clones repos and runs analysis:
 
 ```javascript
 // graph.mjs
@@ -224,11 +224,11 @@ Return a comprehensive security audit report.`;
 ## How It Works
 
 1. **Project Configuration**: You configure repositories in your project settings (Web UI)
-2. **Secure Token Injection**: When the workflow runs, Zibby injects:
+2. **Secure Token Injection**: When the agent runs, Zibby injects:
    - `REPOS` env var (array of repo metadata with clone URLs)
    - `GITHUB_TOKEN` and/or `GITLAB_TOKEN` (OAuth tokens for authentication)
 3. **Authenticated Clone**: `cloneRepo()` constructs authenticated URLs and clones via `git clone`
-4. **Isolation**: Each workflow run gets a fresh container with no cached state
+4. **Isolation**: Each agent run gets a fresh container with no cached state
 
 ## Supported Platforms
 
@@ -269,7 +269,7 @@ Common failure reasons:
 
 ## Local Development
 
-When running workflows locally (`zibby workflow run`), you'll need to:
+When running agents locally (`zibby agent run`), you'll need to:
 1. Set `REPOS` env var manually (JSON array)
 2. Provide `GITHUB_TOKEN` or `GITLAB_TOKEN`
 3. Ensure `git` is installed
@@ -279,7 +279,7 @@ Example for local testing:
 ```bash
 export REPOS='[{"name":"myorg/backend","provider":"github","cloneUrl":"https://github.com/myorg/backend.git"}]'
 export GITHUB_TOKEN="ghp_your_token"
-zibby workflow run my-workflow
+zibby agent run my-agent
 ```
 
 In production (cloud), these are injected automatically.

package/docs/cloud/bundles.md

@@ -5,12 +5,12 @@ title: Bundle build (Heroku-style)
 
 # Bundle build
 
-When you `zibby workflow deploy`, two things happen:
+When you `zibby agent deploy`, two things happen:
 
-1. **Source upload** — your workflow folder (sources only, no `node_modules`) is sent to S3 via a presigned PUT URL. The CLI does this; the backend never has S3 IAM credentials for your account's bucket.
+1. **Source upload** — your agent folder (sources only, no `node_modules`) is sent to S3 via a presigned PUT URL. The CLI does this; the backend never has S3 IAM credentials for your account's bucket.
 2. **Bundle build** — a CodeBuild job downloads the sources, runs `npm install --omit=dev`, packages a tarball, uploads it back to S3.
 
-The tarball is what the cloud runtime downloads at trigger time. **No `npm install` happens at runtime** — workflows boot in seconds regardless of dependency tree size.
+The tarball is what the cloud runtime downloads at trigger time. **No `npm install` happens at runtime** — agents boot in seconds regardless of dependency tree size.
 
 ## What's in the bundle
 
@@ -41,7 +41,7 @@ export default {
 
 ## Why this matters
 
-Without bundling, every cloud trigger would run `npm install` inside the ECS task. For a typical workflow with `@zibby/core` + a few skills, that's 30–90 seconds per cold start. With the bundle:
+Without bundling, every cloud trigger would run `npm install` inside the ECS task. For a typical agent with `@zibby/core` + a few skills, that's 30–90 seconds per cold start. With the bundle:
 
 ```
 trigger → tarball download (3s) → graph.run() → done
@@ -64,23 +64,23 @@ Pass `--verbose` (or set `ZIBBY_DEPLOY_VERBOSE=1`) to see the raw CodeBuild logs
 
 ## Re-deploys reuse the bundle path
 
-The bundle URL is keyed by workflow UUID — re-deploys overwrite the previous bundle. Old executions in flight finish against the *previous* bundle (no rug-pull) because each ECS task downloads the tarball at the moment it starts.
+The bundle URL is keyed by agent UUID — re-deploys overwrite the previous bundle. Old executions in flight finish against the *previous* bundle (no rug-pull) because each ECS task downloads the tarball at the moment it starts.
 
 ## Security model
 
 The CodeBuild role has **zero S3 IAM permissions**. It receives presigned GET (for sources) and PUT (for bundle) URLs as build-time env vars. URLs are scoped to single keys, expire after 15 minutes.
 
-This means a malicious `postinstall` script in a workflow's `package.json` can't escape its sandbox to read other customers' bundles or sources.
+This means a malicious `postinstall` script in an agent's `package.json` can't escape its sandbox to read other customers' bundles or sources.
 
 ## Bundle size
 
 Typical: 100–200 MB compressed. Mostly node_modules. The bundle includes everything `npm install --omit=dev` produces — runtime deps only, no dev deps.
 
-To slim it: audit your workflow's `package.json` for unused deps, and prefer the lightest agent SDK that does the job.
+To slim it: audit your agent's `package.json` for unused deps, and prefer the lightest agent SDK that does the job.
 
 ## Source-fetch fallback
 
-If the bundle is missing or fails to extract, the cloud runtime falls back to source-fetch + runtime `npm install`. Slower, but workflows still run. You'll see this in logs:
+If the bundle is missing or fails to extract, the cloud runtime falls back to source-fetch + runtime `npm install`. Slower, but agents still run. You'll see this in logs:
 
 ```
 [setup] Bundle extract failed (...); falling back to source install

package/docs/cloud/dedicated-egress.md

@@ -5,12 +5,12 @@ title: Dedicated egress IP
 
 # Dedicated egress IP
 
-By default, every Zibby workflow exits via a random AWS IP that changes every run.
-For most customers that's fine — but if your workflow needs to talk to a service
+By default, every Zibby agent exits via a random AWS IP that changes every run.
+For most customers that's fine — but if your agent needs to talk to a service
 behind a firewall (private GitLab, Salesforce, Oracle Cloud, internal API behind a
 corporate VPN), the random-IP behavior makes it unusable.
 
-The **dedicated egress IP** addon pins all your workflow's outbound traffic to a
+The **dedicated egress IP** addon pins all your agent's outbound traffic to a
 single static IP that you can whitelist once on the destination service.
 
 ## Pricing
@@ -34,11 +34,11 @@ single static IP that you can whitelist once on the destination service.
    Internet (sees your static IP, e.g. 54.66.241.180)
 ```
 
-Every outbound HTTPS call from your workflow exits via your dedicated IP:
+Every outbound HTTPS call from your agent exits via your dedicated IP:
 
 | What | Whether it tunnels |
 |---|---|
-| `fetch()` from workflow code | ✅ via static IP |
+| `fetch()` from agent code | ✅ via static IP |
 | `git clone` private repos | ✅ via static IP |
 | `npm install` from private registries | ✅ via static IP |
 | `curl` / `wget` in shell scripts | ✅ via static IP |
@@ -110,7 +110,7 @@ Your IP is **stable for as long as you have the addon enabled**:
 
 - Survives Zibby infrastructure changes (we replace proxy boxes regularly)
 - Survives our region failovers
-- Survives your own workflow redeploys
+- Survives your own agent redeploys
 
 The only way the IP changes is if **you** disable the addon, in which case the IP
 is released back to AWS at the end of your billing period.

package/docs/cloud/env-vars.md

@@ -1,26 +1,26 @@
 ---
 sidebar_position: 4
-title: Per-workflow env vars
+title: Per-agent env vars
 ---
 
-# Per-workflow env vars
+# Per-agent env vars
 
-Each deployed workflow has its own encrypted env-var bag. The cloud runtime injects those vars into the Fargate task that runs the workflow — they show up in `process.env` like any other env var.
+Each deployed agent has its own encrypted env-var bag. The cloud runtime injects those vars into the Fargate task that runs the agent — they show up in `process.env` like any other env var.
 
-Use this for credentials that are **specific to one workflow** — different `ANTHROPIC_API_KEY` per pipeline, a workflow-only `DATABASE_URL`, an external webhook secret. Project-wide secrets stay on the project record (set in dashboard); workflow env wins on conflict.
+Use this for credentials that are **specific to one agent** — different `ANTHROPIC_API_KEY` per agent, an agent-only `DATABASE_URL`, an external webhook secret. Project-wide secrets stay on the project record (set in dashboard); agent env wins on conflict.
 
 ## The fast path: `--env` at deploy
 
-Most users want to ship a `.env` alongside the workflow:
+Most users want to ship a `.env` alongside the agent:
 
 ```bash
-zibby workflow deploy my-pipeline --env .env
+zibby agent deploy my-agent --env .env
 ```
 
-The CLI deploys the workflow as usual, then syncs the `.env` into per-workflow env vars. You'll see:
+The CLI deploys the agent as usual, then syncs the `.env` into per-agent env vars. You'll see:
 
 ```
-✔ Deployed my-pipeline (v1)
+✔ Deployed my-agent (v1)
 ✔ Bundle ready (78s)
 ✔ Synced 4 env vars from .env
 ```
@@ -28,21 +28,21 @@ The CLI deploys the workflow as usual, then syncs the `.env` into per-workflow e
 Multiple files merge with later wins (mirrors how dotenv libraries usually layer):
 
 ```bash
-zibby workflow deploy my-pipeline --env .env --env .env.prod
+zibby agent deploy my-agent --env .env --env .env.prod
 ```
 
-## Manage after deploy: `zibby workflow env`
+## Manage after deploy: `zibby agent env`
 
-Four verbs, all keyed by the workflow UUID (from `zibby workflow list` or `.zibby-deploy.json`):
+Four verbs, all keyed by the agent UUID (from `zibby agent list` or `.zibby-deploy.json`):
 
 ```bash
-zibby workflow env list <uuid>                       # show key names (no values)
-zibby workflow env set <uuid> ANTHROPIC_API_KEY=sk-…  # add or rotate one
-zibby workflow env unset <uuid> OLD_KEY               # remove one
-zibby workflow env push <uuid> --file .env [--file .env.prod]  # bulk replace
+zibby agent env list <uuid>                       # show key names (no values)
+zibby agent env set <uuid> ANTHROPIC_API_KEY=sk-…  # add or rotate one
+zibby agent env unset <uuid> OLD_KEY               # remove one
+zibby agent env push <uuid> --file .env [--file .env.prod]  # bulk replace
 ```
 
-`set` is for surgical updates — leaves every other key alone. `push` is the deploy-flow `--env` exposed as a standalone command for when you want to update env without redeploying the workflow itself.
+`set` is for surgical updates — leaves every other key alone. `push` is the deploy-flow `--env` exposed as a standalone command for when you want to update env without redeploying the agent itself.
 
 `list` only returns key names, never values. Once you set a value, the only place it surfaces is inside the running container.
 
@@ -50,19 +50,19 @@ zibby workflow env push <uuid> --file .env [--file .env.prod]  # bulk replace
 
 Rotate one key:
 ```bash
-zibby workflow env set 1a255ded-9f57-44ad-81cf-70726b13d653 ANTHROPIC_API_KEY=sk-ant-rotated
+zibby agent env set 1a255ded-9f57-44ad-81cf-70726b13d653 ANTHROPIC_API_KEY=sk-ant-rotated
 ```
 
-Wipe all env on a workflow (push an empty file):
+Wipe all env on an agent (push an empty file):
 ```bash
-zibby workflow env push <uuid> --file /dev/null
+zibby agent env push <uuid> --file /dev/null
 ```
 
 CI rotation (GitHub Actions):
 ```yaml
 - run: |
     echo "ANTHROPIC_API_KEY=$ANTHROPIC_KEY" > .env.cd
-    npx @zibby/cli workflow env push $WORKFLOW_UUID --file .env.cd
+    npx @zibby/cli agent env push $WORKFLOW_UUID --file .env.cd
   env:
     ANTHROPIC_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
     WORKFLOW_UUID: ${{ vars.WORKFLOW_UUID }}
@@ -74,10 +74,10 @@ CI rotation (GitHub Actions):
 When a Fargate task starts, env vars come from three layers (later wins):
 
 ```
-built-in container vars  →  project secrets (DDB)  →  workflow env (DDB)
+built-in container vars  →  project secrets (DDB)  →  agent env (DDB)
 ```
 
-So if both your project record and your workflow env define `ANTHROPIC_API_KEY`, the workflow's value is what `process.env.ANTHROPIC_API_KEY` returns inside the run.
+So if both your project record and your agent env define `ANTHROPIC_API_KEY`, the agent's value is what `process.env.ANTHROPIC_API_KEY` returns inside the run.
 
 ## Validation
 
@@ -87,11 +87,11 @@ So if both your project record and your workflow env define `ANTHROPIC_API_KEY`,
 | Value | Any string. Empty string is allowed. |
 | `.env` files | Standard dotenv syntax — comments, quoted values, blank lines, `KEY=value` per line. |
 
-The CLI validates locally before the API round-trip, so `zibby workflow env set <uuid> lowercase=v` fails fast with a readable message instead of a 400.
+The CLI validates locally before the API round-trip, so `zibby agent env set <uuid> lowercase=v` fails fast with a readable message instead of a 400.
 
-## Use case: multi-agent workflows
+## Use case: multi-vendor agents
 
-Different nodes in the same workflow may want to call different model vendors:
+Different nodes in the same agent may want to call different model vendors:
 
 ```js
 // graph.mjs
@@ -110,7 +110,7 @@ CURSOR_API_KEY=key_...
 OPENAI_API_KEY=sk-...
 EOF
 
-zibby workflow deploy multi-agent --env .env
+zibby agent deploy multi-agent --env .env
 ```
 
 Each agent reads its own env var when invoked. No prompt-stuffing keys, no per-node config.
@@ -118,13 +118,13 @@ Each agent reads its own env var when invoked. No prompt-stuffing keys, no per-n
 ## Security model
 
 - **Encryption**: KMS envelope encryption with per-account keys. The plaintext never lands in CloudWatch, DDB, or Lambda logs.
-- **Access control**: every env command needs project-level access on the workflow's project — checked on every request.
+- **Access control**: every env command needs project-level access on the agent's project — checked on every request.
 - **Audit**: KMS logs every decrypt operation. Cross-reference with `WORKFLOW_JOB_ID` to see exactly which run pulled which secret.
-- **Rotation**: `zibby workflow env set` with a new value — the next triggered run picks it up. Currently in-flight runs keep using the value they decrypted at start time.
+- **Rotation**: `zibby agent env set` with a new value — the next triggered run picks it up. Currently in-flight runs keep using the value they decrypted at start time.
 
 ## What this is *not*
 
-- **Not for the project's primary credentials** — those live on the project record (dashboard → Project → Secrets). Use workflow env for *workflow-specific* overrides.
+- **Not for the project's primary credentials** — those live on the project record (dashboard → Project → Secrets). Use agent env for *agent-specific* overrides.
 - **Not a values-readable store** — `list` returns key names only. If you need to retrieve the value, you'll have to push it again. This is intentional.
 - **Not 1Password / Vault** — no rotation policies, no version history. Plain CRUD.
 

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.