Assist is a platform where teams can build, host, and deploy internal AI software and agents in one place — giving companies a safe, controlled environment to standardize workflows and improve operations.

What are sandcastles?

Sandcastles are purpose-built internal apps created by non-technical teams on the Assist platform. They allow employees to build custom tools and workflows without engineering resources.

How much does Assist cost?

Assist uses pay-as-you-go pricing: provider costs + 5%, $0.17 per 1k tool calls, with no seat fees. Enterprise custom pricing is also available.

Do we need engineers to use Assist?

No. Assist is designed for non-technical teams to build and deploy AI tools. Engineers can use it too, but it doesn't require engineering resources to get started.

Troubleshooting

Common issues and solutions related to subagents.

The main chat won't delegate to my agent, even when the request seems obvious

The agent's description is too vague. The main chat picks an agent by reading its description, not its job description. If the description is empty or generic ("Helps with stuff"), the chat has nothing to match against. Open the agent and write a one-sentence description that names the specific job: "Produces a daily summary of support tickets grouped by severity." The next request that mentions a support summary will route correctly.

If the description is fine, try explicit delegation: "Use the Support Digest subagent to ..." That bypasses the routing step and confirms the agent itself works.

My subagent doesn't have a tool I expected it to have

Tool whitelists are exact. If you set any tools on the agent, only those tools (plus the built-in delegation and scheduling tools) are available. Open the agent's edit page, scroll to Tools, and add the tool you need. If you want the agent to have access to every tool in the workspace, remove all selections from the tool whitelist — an empty whitelist means "all tools."

If the tool exists in the workspace but does not appear in the picker, check that the tool is current and registered in the tools table. Newly added tools sometimes need a refresh of the create/edit page.

A scheduled run never appeared

Check that the trigger is active and the schedule resolved correctly. Open /agent-tasks to see recent runs across the workspace. If your trigger is missing entirely, ask the agent in chat to "List your scheduled tasks" — if it does not show up, the trigger was never created. Re-run the schedule prompt and confirm the agent reports the trigger was created.

If the trigger exists but the run did not happen, verify:

The schedule timezone matches your expectation. A "9 AM" trigger configured in UTC fires at 4 AM Eastern.
The trigger is active. Triggers that have failed many times in a row may be auto-disabled.
The scheduled time has actually passed. Trigger.dev runs slightly after the scheduled minute, not exactly on it.

A scheduled run failed

Open the run details from /agent-tasks and read the execution log. Common causes:

The agent tried to call a tool that requires user-level credentials (Slack identity, OAuth) that are not present in a scheduled context. Either change the tool to a workspace-level credential or run the workflow as the user who has the credential.
The prompt depended on something only present interactively ("the file I just uploaded"). Scheduled runs start fresh — the prompt must be self-contained.
A downstream system was unavailable. Re-run manually to confirm whether it was a transient failure.

A Slack message in a mapped channel gets no response

The bot is probably not in the channel, or the channel ID is wrong.

In Slack, type /invite @YourAssistBotName in the channel. If the bot is already a member, Slack will tell you.
Compare the channel ID in the Channel Mappings list against the one in Slack. Open the channel, click the channel name, scroll to the bottom of the About tab, and check the Channel ID. They must match exactly.
Confirm the agent has at least one Slack tool (typically from the slack_v1 tool pack) so it can post a reply.

I get an error trying to delete a subagent

The agent is linked to a sandcastle. Sandcastle-linked agents cannot be deleted directly because the sandcastle relies on them. Open the linked sandcastle, remove the link or delete the sandcastle, then delete the agent.

If the agent is not sandcastle-linked, deletion may have failed because of a permissions issue. You need Admin on the agent (or workspace admin) to delete it.

My subagent says it can't delegate to another subagent

The delegation depth limit was reached. By default, a subagent that was called by the main chat cannot delegate further. This is a guardrail to prevent runaway chains of agents calling agents. If you need deeper chains, ask your workspace admin to raise the SUBAGENT_MAX_DELEGATION_DEPTH setting.

If you want a chain that crosses two or more subagents, design it so the main chat is the orchestrator: it calls agent A, takes the result, then calls agent B, rather than agent A trying to call agent B directly.

The chat with the agent uses a different model than I configured

The agent's model is empty, so it falls back to the workspace default. Open the agent's edit page and set Model explicitly. If the model you want is not in the dropdown, ask your workspace admin to enable it for the workspace.

A custom tool I just created isn't showing up in the subagent's tool selector

The tool is still a draft. Only tools with a published current version appear in the selector. Open the tool in /tools, go to the draft's edit page, commit the draft to make it an immutable version, and publish it. Reload the subagent edit page and the tool will appear in the dynamic_tools pack.

If the tool is published but still missing, confirm it is current (the list view shows a green status indicator for the current version) and that you are in the right workspace — tools do not cross workspace boundaries.

My subagent's tool call failed with a missing credential or network error

The tool's permissions are misconfigured, not the subagent's. Credentials and allowed network domains are declared on the tool, not on the agent. Open /tools/<id>, check the tool's permissions section, and confirm:

The environment variables the tool references are granted (either as static workspace secrets or through an OAuth connection).
The network domains the tool needs to reach are on its allow list.

For OAuth-backed tokens, make sure the connection is active and hasn't expired. Fixing the tool's permissions automatically fixes every subagent that uses it — no per-agent config needed.

A tool call returned the wrong thing and I can't tell why

Open /tool-history and read the actual invocation. Every tool call the subagent makes is logged with the exact input, the full return value, timing, and any error or stdout. Filter by tool name or by the subagent's chat to narrow it down.

Two patterns to look for:

The tool was called with an input the subagent inferred incorrectly from the user's request. Tighten the parameter descriptions in the tool's input schema.
The tool's output shape doesn't match what the agent's prompt expects. Either update the agent's prompt to handle the real shape, or publish a new tool version that reshapes the response.

I starred an agent but it doesn't show up in Agent Favorites

Refresh the page. Stars use optimistic updates and SWR caching, but a stale tab can occasionally fall out of sync. If a hard refresh does not bring the agent back into favorites, unstar and re-star it.

If you see no favorites section at all, you have not starred any agents in the current workspace. Stars are scoped to the workspace you are in.

Still need help?

Contact your workspace administrator or open a support ticket. When reporting an issue, include the subagent name, the workspace, and (for failed scheduled runs) the run ID from /agent-tasks.