Spinnable

Native OAuth and API key integrations let workers read and write in named systems, with credentials scoped per worker and a route to custom tools. They cover Gmail, Outlook, Google Calendar, Outlook Calendar, Google Docs, Google Drive, Slack and others, 35+ in all. Read and write come as separate tools, so what a worker can act on is explicit. Gmail (Read) reads and searches the inbox, and Gmail (Send) sends.

A user level connection lets a worker use the user's account, while a worker specific connection authenticates each worker with its own account, and Spinnable explains the trade off. For custom tools, Spinnable says that "if your tool has an API, your AI worker can use it". The customer stores a key in the Worker Vault, shares the API documentation and then saves the working call as a skill. Sage, Primavera, Microsoft Dynamics, Zoho, SAP, QuickBooks and Xero are named examples.

Sourcedocs.spinnable.ai/concepts/tool-permissions, /tools/overview, /guides/custom-integrations; readread 2026-09-15

Workers save multi step workflows as reusable skills, and projects split work across several workers. Skills are "reusable workflows your workers learn and save, a packaged set of instructions and code they'll remember and execute reliably", built for multi step operations involving multiple tools. In the invoice example, a worker receives a PDF by email, extracts fields, formats them, adds a Google Sheets row and sends a confirmation.

Skills mix deterministic code with agent steps. A saved skill is invoked by name and can run on a schedule, and projects can hand recurring automations to a skill. Projects also route work across workers. A team can "assign a researcher, a writer, and an editor worker to the same project to handle different stages of the goal", and projects have Owner and Lead roles.

Spinnable names no explicit branching, retry or fallback paths, and no skill versioning. Workflows are written in conversation, not in a builder.

Sourcedocs.spinnable.ai/concepts/skills, /concepts/projects; readread 2026-09-15

Customers can attach reference files to projects and let workers read connected drives. Projects let a customer "upload files as project resources so reference material lives with the work", and the worker uses those files, which the customer can download or remove. Workers read connected Google Drive and Docs through tools, and a worker can answer product questions from the official documentation. New knowledge enters as files, not retraining.

Spinnable describes no indexing, retrieval settings or citations for project resources, so the context is assembled on each run. The worker's memory knowledge base persists and stays queryable. It holds preferences, work context and task patterns the worker proposes and the user approves.

Sourcedocs.spinnable.ai/concepts/projects, /tools/overview; readread 2026-09-15

Action boundaries are enforced per worker, but sign off on a draft is an instruction to the worker, not a setting. Tools come in split versions. Gmail (Read) lets a worker "read emails but not send them", separate from Gmail (Send), and the same holds for Outlook, so a customer can withhold the ability to act at all. Approval happens in conversation.

Spinnable advises customers to "review drafts before they send for high-stakes communications" and notes that "you can always tell your worker" to hold an email until you have reviewed it. It says a Sales Assistant "should start with your review before sending external messages".

Spinnable names no setting for which actions need sign off, who signs off, or what happens when nobody does. The boundary is stated to the worker, not enforced by the product. The read and send split is enforced.

Sourcedocs.spinnable.ai/concepts/tool-permissions, /guides/security-best-practices; read; docs.spinnable.ai/guides/security-best-practicesread 2026-09-15

Access controls go deep for each worker, and the SOC 2 Type 2 report is still in progress. A worker's email and WhatsApp communication can be open to anyone, team members only or manager only. Team membership comes from an explicit Spinnable team invitation, not domain matching. A worker specific connection lets each worker authenticate with its own account instead of the user's, API keys sit in a Worker Vault, and the product supports co-managers and project roles.

The trust center at trust.spinnable.ai covers GDPR and a SOC2 Type 2 report in progress, with 136 controls and 26 subprocessors behind access.

Sourcedocs.spinnable.ai/guides/worker-communication-restrictions, /concepts/tool-permissions, /guides/security-best-practices, trust.spinnable.ai; readread 2026-09-15

Activity and oversight logs exist for each worker. Spinnable tells customers to "check your worker's activity log" and review sent messages. Its oversight logs "clearly indicate external sender addresses and incoming email context so you can verify who communicates with your worker".

Spinnable does not say what the logs record about tool calls, steps and outcomes. It points customers to recent activity in connected tools, where the apps' own histories supply the record in the customer's own systems.

Sourcedocs.spinnable.ai/guides/security-best-practices; readread 2026-09-15

Each worker has a long term memory, which Spinnable calls "persistent knowledge that carries across conversations". It is stored in each worker's memory knowledge base and covers preferences, work context, domain knowledge and task patterns. Conversational refinement sits alongside it and resets with each conversation. Memories "are specific to each worker" and do not transfer between workers, and they "persist indefinitely until you remove them".

Users get full visibility, edit access, delete capability and export. A worker asks "should I remember this for future conversations?" before saving, so new memories need approval. Memories can be deleted through the knowledge base interface. Workers propose updates when circumstances change, so the agent writes the memory and the user governs it. Skills are saved workflows, separate from memory.

Sourcedocs.spinnable.ai/concepts/how-workers-learn; readread 2026-09-15

Workers run only in Spinnable's hosted application (app.spinnable.ai), each with a spinnable.app email address. There is no dedicated, VPC, on premises or self hosted option. No hosting region is published, and there is no residency choice.

The trust center at trust.spinnable.ai lists 26 subprocessors and infrastructure controls (infrastructure as code, host hardening) behind its access flow.

Sourcedocs.spinnable.ai index and account pages, trust.spinnable.ai; readread 2026-09-15

Customers hire workers from a browsable marketplace of role based candidates. Each candidate card in the marketplace shows a role overview with the candidate's core domain, "pre-loaded skills, and recommended tool integrations", a job description and a voice sample.

A customer can "select a candidate card from the marketplace and click Hire", and "the worker is instantly added to your account with recommended settings and tool templates". Each marketplace template has its own readable URL slug, such as /marketplace/customer-support, and free plan users can browse all AI worker candidates on /hire. An executive assistant, sales rep, content creator or customer support worker is each a whole role on its own.

Roles can be edited after hiring, by reviewing the initial role instructions and assigning tools. A customer can also build a custom role by describing the job to Bob, the hiring assistant. Spinnable names no customer references for each template.

Sourcedocs.spinnable.ai/guides/hiring-workers, /release-notes/2026-09-09; readread 2026-09-15

Schedules and inbound channels start work with no person asking. Workers "have access to tools and can schedule tasks (one-time or recurring)", and "AI workers can remember to do things, both one-time and recurring". Projects "automate recurring work with schedules".

Each worker has its own email address and can receive messages from customers, vendors or colleagues on email and WhatsApp, answer in Slack channels, join WhatsApp groups, and sit behind a website chat widget. Email, WhatsApp and Slack are first class channels with their own setup guides, and several channels feed the same worker. Voice calls are coming soon.

Spinnable names no webhook or tool event that starts a worker, and no handling of duplicates.

Sourcedocs.spinnable.ai/concepts/communication-channels, /concepts/ai-workers, /concepts/projects; readread 2026-09-15

The model or models that run the workers are not named. Spinnable names no customer or admin model selection, workspace model policy or bring your own key option. The Worker Vault holds service credentials for tools, not model keys. Spinnable does not say whether one model provider or several run the workers. The trust center at trust.spinnable.ai lists 26 subprocessors, and the documentation names no model and has no AI or privacy page.

Sourcetrust.spinnable.ai (overview, metadata and counts only), docs.spinnable.ai index; readread 2026-09-15

There is no published way for outside systems to call Spinnable itself. Spinnable publishes no API reference, SDK or MCP page. Its documentation at docs.spinnable.ai, built on Mintlify, covers concepts, guides, tools and account settings. Custom integrations run outward, with the worker calling other systems' APIs using keys from the Worker Vault. The website chat widget is a channel for reaching a worker.

Sourcedocs.spinnable.ai index, /guides/custom-integrations, api.spinnable.ai probe; readread 2026-09-15

Testing is a manual practice the customer runs in conversation. Spinnable advises customers to "prepare test cases, write example conversations that previously caused issues", then "run the scenario, have the worker respond to the test case" and check whether feedback was applied. It also suggests testing a new skill on a fresh example. Spinnable names no harness, stored test set, score or gate, and the product does not run or record the tests. It names no way to score quality over time. A customer satisfaction score appears as a business metric to watch, not a platform output.

Sourcedocs.spinnable.ai/guides/training-feedback, /concepts/skills; readread 2026-09-15

For sites with no API, workers "access these websites programmatically, without opening a browser". They use direct HTTP requests and a third party CAPTCHA solving service, with "no Selenium, no Playwright, no headless Chrome". Spinnable calls this autonomous web scraping "an advanced, experimental technique".

Spinnable also names "browser automation, your AI workers tries to use the browser" as a heavier alternative, which implies a browser capability exists. Spinnable describes no browser tool or setup for it.

Sourcedocs.spinnable.ai/guides/autonomous-web-scraping, /tools/overview; readread 2026-09-15