Custom Tools at Runtime: Let Users Add Integrations Without Shipping a Single Line of Code

In the workspace, a user navigates to Tools → Custom and gets three inputs: name and description (free text), parameter schema (JSON), and a JavaScript body. That's it.

The schema field accepts a JSON Schema fragment — properties, required, types, descriptions. The agent's LLM sees this verbatim when deciding whether to call the tool, so the descriptions matter as much as the field names. We provide a Zod-backed validator in the editor that flags malformed schemas before save; you cannot create a tool that an agent cannot understand.

The code body is plain JavaScript with a single export: a function that takes the validated params and returns a result. No imports. No file system. No process access. The runtime that executes it has none of those things available.

Sandboxed Execution Through isolated-vm

The hard part is running user-supplied code safely. We do not run it on the request thread, in a worker process, or even in a Node.js vm — all of those leak too much. We run it inside isolated-vm, an out-of-process V8 isolate with a hard memory cap and no host bindings.

Every custom tool invocation gets its own isolate with:

• a 30-second wall clock timeout. If the code does not return by then, the isolate is killed and the tool returns a timeout error to the agent.
• a 128 MB memory cap. Allocate past that and V8 aborts the isolate, again returning a clean error to the agent.
• no network primitives. We hand the isolate exactly the helpers it needs — fetch, console.log to a captured buffer — and nothing else. No require, no process, no fs.

Egress fetches still pass through our existing SSRF guard (proxy.ts), so a custom tool cannot use the platform as a probe into our private network. Tool code is hostile by assumption.

Per-Workspace Isolation Is Hard, Not Optional

The other half of safety is making sure workspace A's custom tools cannot leak into workspace B. We solved this with two design choices.

First, the customTools row carries both userId and workspaceId. The tool registry filters on workspace context at every lookup; a tool from one workspace is invisible to agents in another, full stop. No "shared library" shortcut.

Second, every isolate is single-use. We do not pool isolates across calls because pooling means state could survive between invocations. The cost is a few milliseconds of cold-start per call — well worth it for the guarantee that no information leaks across tool runs, let alone across workspaces.

Agents See Custom Tools The Second They Save

This is the part that makes it feel like a product, not a hack. There is no deploy. There is no rebuild. The agent's tool-discovery layer queries the registry on each conversation turn, and the registry is just a database read. Save a tool at 14:02; an agent in the same workspace can call it at 14:03.

That changes how customers work with us. Instead of "we should email AACFlow and ask if they support our internal X endpoint," the conversation becomes "we should define a custom tool for our internal X endpoint." The platform stops being a place where capabilities arrive on someone else's release schedule. It becomes a place where capabilities arrive on the customer's release schedule.

For us this also means our 321 built-in tools are not a moat to defend — they are a baseline. Anything we have not built can be defined in five minutes by anyone who knows their own API.

Why JavaScript and Not Another Language

We are a TypeScript shop. Every other handler in our executor is JavaScript. The LLMs we route to (Anthropic, OpenAI, Gemini, Groq, Cerebras, Mistral, xAI, all the rest) speak JSON Schema natively. JavaScript happens to be the language that lines up perfectly with our schema format, our runtime, our isolate substrate, and the cognitive overhead users already absorbed by writing function blocks in the canvas.

Adding Python would mean a second sandbox model, a second packaging story, a second security review. We may do it later. We will not do it before the JavaScript version has been stress-tested at scale. The minimum viable surface is the right surface.

Custom Tools Are Just Tools

The thing we kept reminding ourselves during the design: a custom tool is not a special category. It is a tool. It shows up in the same tool-picker UI as Slack and Postgres. The agent does not know — and does not care — whether the implementation lives in our codebase or in a row of customTools. The contract is the same.

That is why we did not build a separate "scripts" feature or a "plugins" feature. We extended the existing tool primitive to accept user-defined bodies, and we let the rest of the system stay unchanged. The executor, the agent's tool-use prompt, the observability layer, the per-call billing — none of them needed to learn anything new.

Stop waiting for your platform to ship every integration you need. Define the tool yourself, save it, let the agent call it. The platform that does not let you do that is asking you to wait. AACFlow does not. Open the editor, type a schema, paste a function body, save — your next agent run already sees it.