Built-In Workspace Integrations

First-party workspace integrations for Filesystem, State KV, web requests, browser control, data transformation, Sandbox execution, and AI agent memory.

Built-In Workspace Integrations

Weavz includes first-party integrations that are not tied to a third-party SaaS account. Add them to a workspace the same way you add Slack, GitHub, or Google Drive, then expose them through REST, SDKs, Playground, or MCP servers.

These integrations are useful because they make an agent or workflow self-sufficient: it can use a Filesystem, keep scoped State KV, call HTTP or GraphQL endpoints, fetch web pages, drive a browser, transform JSON, run code in a Sandbox, and keep working memory without leaving the Weavz integration model.

Why they are workspace integrations

Built-ins still use workspace integration configuration because the workspace integration controls:

The stable alias an agent sees, such as files, memory, browser, http, or transform
Which actions are enabled for API, SDK, Playground, and MCP execution
Persistence settings for stateful tools
Sandbox policy for managed execution
Automatic MCP tool sync when the workspace changes

Most built-ins use no external authentication, so you do not create a connection for them. ai-toolkit and agent-browser-ai are the exceptions: they are first-party, but they use provider credential connections so Weavz can call the selected model provider.

Catalog

Integration	Best for	Key actions
`storage`	Filesystem for files and artifacts that should persist across executions	`read_file`, `write_file`, `delete_file`, `list_files`, `get_download_url`
`kv-store`	State KV for JSON state, counters, caches, lists, and small records	`put`, `get`, `delete`, `add_to_list`, `remove_from_list`
`agent-memory`	Knowledge graph memory for agents	`create_entities`, `add_observations`, `create_relations`, `search`, `read_graph`
`agent-scratchpad`	Named notes, plans, drafts, and working memory pages	`read_page`, `write_page`, `append_page`, `list_pages`, `search_pages`
`sequential-thinking`	Structured reasoning chains with branches and revisions	`add_thought`, `branch_thought`, `revise_thought`, `get_chain`, `summarize_chain`
`http`	Direct HTTP calls to APIs that do not need a full connector	`send_request`
`graphql`	Direct GraphQL calls to arbitrary GraphQL endpoints	`send_request`
`web-reader`	Fetching pages for markdown, text, links, and metadata	`fetch_as_markdown`, `fetch_as_text`, `extract_links`, `extract_structured_data`, `fetch_multiple`
`agent-browser`	Hosted browser control with snapshots, element refs, screenshots, file upload, and human handoff	`snapshot`, `navigate`, `click`, `type`, `request_human`, `resume`
`agent-browser-ai`	Optional natural-language browser driver through your configured LLM provider	`act`, `extract`, `observe`
`data-transformer`	JSON reshaping between tool calls	`transform_json`, `merge_objects`, `filter_array`, `batch_array`
`datetime`	Date parsing, formatting, math, and business-hour checks	`parse_date`, `format_date`, `date_math`, `is_business_hours`
`hash-encode`	Hashing, encoding, decoding, and UUID generation	`hash`, `encode`, `decode`, `generate_uuid`
`code`	Lightweight JavaScript Sandbox for data transformation	`run_code`
`advanced-code`	Sandbox for JavaScript, Python, or shell execution	`run_code`
`ai-toolkit`	Pre-prompted AI helper actions through your configured provider	`ask_json`, `extract_structured_data`, `classify_text`, `transform_data`, `generate_text`

Stateful integrations

storage, kv-store, agent-memory, agent-scratchpad, sequential-thinking, agent-browser, and agent-browser-ai support settings.persistence on the workspace integration. This setting decides where state or browser profile data is stored for every call that targets that configured integration.

Scope	Use when
`end_user`	Each end user should have isolated files or memory. This is the default.
`workspace`	The whole workspace should share files or state.
`external`	Your application wants a custom namespace such as a tenant, project, or job ID.

json

{
  "integrationName": "storage",
  "alias": "files",
  "settings": {
    "persistence": {
      "scope": "workspace"
    }
  }
}

Code and sandbox integrations

Use code for small, deterministic JavaScript Sandbox transforms that need no network, filesystem, or imports. Use advanced-code when the workflow needs JavaScript, Python, shell commands, network access, or optional persistent Sandbox state.

Sandbox policy is owner-controlled on the workspace integration. Runtime callers provide language and code, but they do not choose persistence, filesystem mounts, or timeout.

json

{
  "integrationName": "advanced-code",
  "alias": "sandbox",
  "settings": {
    "advancedCode": {
      "timeoutSeconds": 300,
      "sandboxPersistence": "persistent",
      "storageMountScope": "workspace"
    }
  }
}

How agents see them

In MCP Tool Mode, each enabled built-in action appears as an individual tool. In MCP Code Mode, each configured workspace integration appears under weavz.<alias>. For example, aliases such as files, kv, http, and transform give agents a compact API surface:

javascript

await weavz.files.write_file({
  path: 'runs/summary.json',
  content: JSON.stringify({ status: 'complete' }),
})
 
const response = await weavz.http.send_request({
  method: 'GET',
  url: 'https://api.example.com/status',
})

Built-In Workspace Integrations

Why they are workspace integrations

Catalog

Stateful integrations

Code and sandbox integrations

How agents see them

Related docs