Concepts
Product primitives and mental models for building with Weavz.
Concepts
Use these pages to understand the Weavz object model before wiring API calls or SDK code. The same primitives appear in the dashboard, REST API, TypeScript SDK, Python SDK, MCP servers, and LLM resources.
Product Model
Weavz separates durable product configuration from each runtime call:
| Primitive | Owns | Reach for it when |
|---|---|---|
| Workspace | Tenant, project, or agent boundary | You need isolation for integrations, connections, policies, MCP servers, files, or state |
| Workspace integration | The configured app/tool instance and alias agents call | You want a stable surface such as support_slack, files, state, or browser |
| Connection | The credential set used for a third-party app | A shared bot, tenant credential, or per-user account needs to authenticate an action |
| End user | Your user's identity inside a workspace | Calls must resolve to a particular user's connected accounts or personal state |
| Input partial | Saved defaults and locked values | You need to hide or enforce parameters before REST, SDK, MCP, or trigger execution |
| Human Gate | Approval policy and reviewer workflow | Execution may create external side effects or use sensitive credentials |
| MCP server | Agent-facing tool surface for one workspace | Agents should discover and call configured integrations through Tool Mode or Code Mode |
| Built-in integration | First-party files, state, browser, HTTP, memory, or sandbox tools | A workflow needs capabilities before any external account is connected |
The common build path is: create a workspace, add workspace integrations with stable aliases, attach shared or per-user connections, add partials and Human Gates, then expose the workspace through MCP or execute actions from your backend.
Start Here
| Page | Use it for |
|---|---|
| Organizations & Workspaces | Resource hierarchy, workspace isolation, and tenant patterns |
| Identifier Model | The difference between Weavz UUIDs, your user IDs, connection external IDs, and namespace keys |
| Integrations | Catalog integrations, actions, triggers, and authentication types |
| Integration Selectors | integrationName, alias, integrationAlias, and workspaceIntegrationId |
| Connections | Credential ownership, hosted connect, and connection resolution |
| End Users | Per-user identity, connect portals, and per-user connection strategies |
Execution And Agent Surfaces
| Page | Use it for |
|---|---|
| Actions | Running third-party operations through REST, SDKs, Playground, and MCP |
| Triggers | Receiving external events through callback URLs |
| MCP Servers | Exposing workspace integrations to AI clients |
| Agent Browser | Browser tools for MCP/workspace integrations, managed sessions, and live human handoff |
| Input Partials | Defaults and enforced values for actions, triggers, and MCP tools |
| Filesystem & State KV | Built-in scoped files and key-value persistence |
| Sandbox | Built-in JavaScript, Python, and Shell execution surfaces |
Operating Model
| Page | Use it for |
|---|---|
| Built-In Workspace Integrations | First-party tools such as Filesystem, State KV, HTTP, Web Reader, and Sandbox |
| Plan Limits & Quotas | Rate limits, resource caps, add-ons, and prepaid capacity |
Canonical Build Order
- Create or choose a workspace.
- Add workspace integrations with stable aliases and connection strategies.
- Add connections and end users.
- Add input partials and Human Gates for guardrails.
- Create MCP servers or execute actions and triggers from your app.
- Validate the full setup in Playground.