Built-In Workspace Integrations

First-party workspace integrations for files, state, web requests, data transformation, code 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 store files, keep scoped state, call HTTP or GraphQL endpoints, fetch web pages, transform JSON, run code, 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, http, or transform
Which actions are enabled for API, SDK, Playground, and MCP execution
Persistence settings for stateful tools
Sandbox policy for Advanced Code
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 is the exception: it is first-party, but it uses a provider credential connection so Weavz can call the selected model provider.

Catalog

Integration	Best for	Key actions
`storage`	Files and artifacts that should persist across executions	`read_file`, `write_file`, `delete_file`, `list_files`, `get_download_url`
`kv-store`	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`
`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 data transformation	`run_code`
`advanced-code`	JavaScript, Python, or shell execution in a managed sandbox	`run_code`
`ai-toolkit`	Pre-prompted AI helper actions through your configured provider	`extract_structured_data`, `classify_text`, `transform_data`, `generate_text`

Stateful integrations

storage, kv-store, agent-memory, agent-scratchpad, and sequential-thinking support settings.persistence on the workspace integration. This setting decides where state 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 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.

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

json

{
  "integrationName": "advanced-code",
  "alias": "sandbox",
  "settings": {
    "advancedCode": {
      "timeoutSeconds": 45,
      "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