Built-In Workspace Integrations
First-party tools for files, state, web access, approved browser and desktop sessions, dashboards, data transformation, code execution, and 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 or user-approved local desktop session, present data as a dynamic dashboard, 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, ortransform - 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, agent-browser-ai, agent-browser-stealth-ai, and local-computer-control-agent 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 | A governed hosted browser session agents can navigate, read, click, type, download from, and hand to a human when needed | start_session, ensure_connected, show_live_view, snapshot, navigate, run_steps, click, type, request_human, resume |
agent-browser-stealth | A tougher hosted browser environment for web workflows that challenge standard automation | start_session, ensure_connected, show_live_view, session_status, snapshot, navigate, run_steps, click, type, request_human, resume |
agent-browser-ai | The same governed browser session plus model-backed actions for goal-level instructions, extraction, and element discovery | ensure_connected, show_live_view, snapshot, navigate, run_steps, act, extract, observe |
agent-browser-stealth-ai | The tougher hosted browser plus model-backed actions for goal-level instructions, extraction, and element discovery | ensure_connected, show_live_view, session_status, snapshot, navigate, run_steps, act, extract, observe |
agent-local-browser-control | A user-approved Chrome session on the user's own device and network for logged-in browser work | start_session, ensure_connected, session_status, show_live_view, snapshot, navigate, run_steps, click, type |
local-computer-control | Visible, user-approved Mac desktop access for agents that need local apps, local network access, or device trust | start_session, ensure_connected, session_status, snapshot, observe, screenshot, list_targets, activate_target, focus_ref, press_ref, set_text_ref, select_ref, scroll_ref, move_mouse, click, drag, type, press_key, scroll, wait, wait_for, run_steps, request_human, resume, end_session |
local-computer-control-agent | A local desktop agent that can observe a selected Mac app, plan safe steps, act, wait, verify, and stop for user confirmation | act, plan, observe_goal, extract_from_screen, run_recipe, stop_task, plus the local computer observation and fallback controls |
weavz-dynamic-dashboard | Experimental read-only dashboard rendering for outputs gathered by other tools | profile_data, suggest_dashboard, validate_dashboard, render_dashboard |
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, agent-browser-stealth, agent-browser-ai, agent-browser-stealth-ai, and agent-local-browser-control 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. local-computer-control does not use persistence settings; the local user selects the visible desktop target for each session.
agent-local-browser-control also supports settings.localBrowser.runtime. New workspace integrations default to chrome_extension; set managed_profile only when the user needs the CLI fallback.
| 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. |
{
"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.
{
"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:
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',
})