The act tool

A single intent-dispatched tool surface for arbitrary external services.

Conventional MCP servers expose one tool per operation. A Slack server publishes chat.postMessage, conversations.list, files.upload, and dozens more. Multiply that by every service an agent needs to touch and the tool catalog quickly grows past the point where any model can reason about it cleanly. Token cost scales linearly with the catalog. Context pressure scales with it. The probability of the model selecting the wrong tool grows with it.

Weldable takes the opposite approach. The entire surface area of every connected integration is collapsed into a single MCP tool, act, that accepts a free-form natural-language intent. The work of resolving that intent into a concrete operation, locating credentials, validating arguments, and dispatching execution happens server-side, inside a deterministic loop that the agent never sees.

The core loop

Every act call traverses the same pipeline. Each stage is independent, observable, and addressable as its own concern.

1. Tool surface

The agent sees exactly one tool. Its schema is fixed and tiny: a required intent string plus an optional arguments object. There is no per-integration registration, no client-side discovery handshake, and no schema bloat as new integrations come online. From the agent's perspective the catalog is infinite and its prompt cost is constant.

2. The action catalog

Every operation Weldable can perform on a user's behalf is modeled as an action. An action is a typed, named unit of work with a canonical identifier (slack.post, github.issue.create), a description, an input schema, and an executor. Actions are Weldable's universal currency: intent matching ranks them, credential resolution targets them, dispatch executes them, and the audit log records them.

There are two ways an action enters a user's catalog:

• Integration actions are contributed by connected integrations. Connecting Slack populates the catalog with slack.post, slack.search, and the rest of Slack's surface. These actions wrap a single API call and execute in-process on the Action Worker.
• Installed workflow actions are contributed by workflows the user has installed from the community library or authored themselves. From the catalog's perspective, an installed workflow looks identical to any other action: it has a canonical identifier, a description, an input schema, and shows up in intent matching alongside slack.post. The difference is hidden in the executor. When dispatched, a workflow action enqueues a durable, multi-step run rather than a single API call.

This uniformity is the point. The agent issues act("file last week's expenses") without needing to know whether the resolution will be a one-shot integration call or a fifteen-step workflow that touches Gmail, Drive, and a finance API. Installing a workflow is the same kind of operation as connecting an integration: both extend the user's catalog, and both become reachable through the same intent dispatch path.

Actions are not thin transliterations of upstream APIs. Each one is hand-crafted for agent ergonomics: input schemas are flattened and named for how a model would describe the operation, defaults are chosen to make the common case a single argument, descriptions are written for an LLM reader rather than a human SDK consumer, and side effects are documented where they matter for safety. The goal is that the action a model wants to call and the action that exists in the catalog converge.

The catalog is also open source. Every action definition, every integration wrapper, and every shared workflow lives in a public repository. Anyone on the Weldable platform can submit a fix, propose a better description, add a missing argument, ship a competing implementation, or contribute an entirely new integration. Improvements made by one user propagate to every other user the moment they merge. The catalog grows and sharpens through community contribution rather than vendor roadmap.

3. Intent matching

The intent string is matched against the live catalog of actions registered to the calling user. Matching combines semantic similarity over action descriptions with keyword overlap on canonical names, then ranks the result against the user's actually connected integrations and installed workflows. The output is a single typed action identifier plus any structured arguments extracted from the intent.

Crucially, the catalog is loaded at request time from the user's own integration and workflow installations, not baked into the agent. Connecting a new integration or installing a new workflow is a server-side change. No client update, no prompt change, no re-indexing of any tool list on the model side.

The matching algorithm itself is a learning system. Every act call produces a labelled trajectory: an intent, a candidate ranking, the action that was ultimately dispatched, and a downstream signal about whether that dispatch satisfied the user. Weldable uses reinforcement learning over these trajectories to continuously refine the ranker, so intent resolution gets sharper as the platform sees more traffic. Improvements ship globally without any change to integrations, workflows, or agent prompts. The matcher is a product surface that gets better on its own, and every user benefits from every other user's interactions.

4. Credential & argument resolution

Once an action is selected, Weldable resolves the credentials it requires. OAuth tokens live in Nango and are refreshed transparently. If the user has not yet connected the relevant provider, the loop short-circuits: instead of failing, act returns a connect_url and a structured missing payload. The agent can render the link directly to the user, who completes the OAuth flow, and the next act call resumes from the same intent. No state is lost, and the agent never has to reason about token lifetimes.

The same short-circuit applies to required arguments. If the matched action needs a channel name and the original intent did not provide one, act returns a missing_inputs hint describing exactly what is needed. The agent prompts the user, then re-issues act with the additional arguments. This is the feedback edge in the diagram above: Action/Workflow Definitions → /act. The loop is designed to converge through dialogue rather than through error handling.

5. Dispatch

With an action identifier and credentials in hand, the loop branches on the kind of executor the matched action carries.

Integration actions dispatch to action execution. The action runs on the Action Worker as a portable DBOS child workflow on the integration-actions queue. The worker resolves credentials from Nango, invokes the integration's execute() function, and writes a step record to Supabase. Because every action is a DBOS workflow, retries, backoff, and at-least-once semantics are enforced uniformly. The agent receives a structured result.

Installed workflow actions dispatch to workflow execution. Weldable enqueues a parent run on the workflow-runs queue. A Python Workflow Worker picks it up, executes the user's workflow code, and emits child integration-action calls back through the same integration-actions queue. From the agent's perspective the call signature is identical: it issued a single act against a single action identifier, and a single result comes back. Underneath, an arbitrarily long durable execution may have run, survived restarts, retried failed steps, and resumed across worker deployments.

6. Observability

Every act call is recorded: the original intent, the matched identifier, the resolved arguments, the result, and the full workflow trace if one ran. The user can audit exactly what their agent did on their behalf, and operators can replay any failed run from its DBOS checkpoints.

Design properties

Pushing intent matching, auth, and dispatch onto the server, rather than onto the model, yields several properties that are difficult to reproduce with conventional one-tool-per-action MCP servers.

Constant prompt cost. The agent's tool schema does not grow with the catalog. A user with two integrations and a user with two hundred present the same surface area to the model.

Late binding. The set of available operations is resolved at call time against the user's connected integrations. New integrations and new workflows become reachable the moment they are deployed, with no model-side update.

Actionable failure modes. Missing auth becomes a connect_url. Missing arguments become a structured missing_inputs hint. When a dispatched action fails at the upstream API, Weldable returns a descriptive, model-readable error that explains what went wrong and, where possible, how to fix it: the offending argument, the upstream constraint it violated, the suggested correction. Agents can self-correct on the next turn instead of bailing out. Every failure mode is designed to be resolved by another turn in the conversation rather than by an exception path.

Uniform durability. Single calls and multi-step workflows are dispatched through the same DBOS-backed queues. Retry, idempotency, and crash recovery are properties of the platform, not of each integration.

Auditability. Every dispatched operation is a row in a queryable log, tied back to the natural-language intent that produced it.

The result is a tool surface that scales with the number of services a user connects, not with the number of operations those services expose, and a control plane that turns every agent action into a durable, replayable, inspectable unit of work.