chore: import upstream snapshot with attribution
CI / Migrate Dev DB (push) Has been skipped
CI / Detect Version (push) Has been cancelled
CI / Migrate DB (push) Has been cancelled
CI / Build Dev ECR (./docker/app.Dockerfile, ECR_APP) (push) Has been cancelled
CI / Build Dev ECR (./docker/db.Dockerfile, ECR_MIGRATIONS) (push) Has been cancelled
CI / Build Dev ECR (./docker/pii.Dockerfile, ECR_PII) (push) Has been cancelled
CI / Build Dev ECR (./docker/realtime.Dockerfile, ECR_REALTIME) (push) Has been cancelled
CI / Deploy Trigger.dev (Dev) (push) Has been cancelled
CI / Build AMD64 (./docker/app.Dockerfile, ECR_APP, ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Build AMD64 (./docker/db.Dockerfile, ECR_MIGRATIONS, ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Build AMD64 (./docker/pii.Dockerfile, ECR_PII, ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Build AMD64 (./docker/realtime.Dockerfile, ECR_REALTIME, ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/app.Dockerfile, ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/db.Dockerfile, ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/pii.Dockerfile, ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/realtime.Dockerfile, ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Check Docs Changes (push) Has been cancelled
CI / Process Docs (push) Has been cancelled
CI / Create GitHub Release (push) Has been cancelled
CI / Test and Build (push) Has been cancelled
Publish CLI Package / publish-npm (push) Has been cancelled
Publish Python SDK / publish-pypi (push) Has been cancelled
Publish TypeScript SDK / publish-npm (push) Has been cancelled
CI / Migrate Dev DB (push) Has been skipped
CI / Detect Version (push) Has been cancelled
CI / Migrate DB (push) Has been cancelled
CI / Build Dev ECR (./docker/app.Dockerfile, ECR_APP) (push) Has been cancelled
CI / Build Dev ECR (./docker/db.Dockerfile, ECR_MIGRATIONS) (push) Has been cancelled
CI / Build Dev ECR (./docker/pii.Dockerfile, ECR_PII) (push) Has been cancelled
CI / Build Dev ECR (./docker/realtime.Dockerfile, ECR_REALTIME) (push) Has been cancelled
CI / Deploy Trigger.dev (Dev) (push) Has been cancelled
CI / Build AMD64 (./docker/app.Dockerfile, ECR_APP, ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Build AMD64 (./docker/db.Dockerfile, ECR_MIGRATIONS, ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Build AMD64 (./docker/pii.Dockerfile, ECR_PII, ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Build AMD64 (./docker/realtime.Dockerfile, ECR_REALTIME, ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/app.Dockerfile, ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/db.Dockerfile, ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/pii.Dockerfile, ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Build ARM64 (GHCR Only) (./docker/realtime.Dockerfile, ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/migrations) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/pii) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/realtime) (push) Has been cancelled
CI / Create GHCR Manifests (ghcr.io/simstudioai/simstudio) (push) Has been cancelled
CI / Check Docs Changes (push) Has been cancelled
CI / Process Docs (push) Has been cancelled
CI / Create GitHub Release (push) Has been cancelled
CI / Test and Build (push) Has been cancelled
Publish CLI Package / publish-npm (push) Has been cancelled
Publish Python SDK / publish-pypi (push) Has been cancelled
Publish TypeScript SDK / publish-npm (push) Has been cancelled
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,101 @@
|
||||
---
|
||||
slug: copilot
|
||||
title: 'Inside Sim Copilot — architecture, benchmarks, and how it fits'
|
||||
description: 'A technical overview of Sim Copilot: the architecture behind it, our early benchmarks, and how Copilot integrates with agentic workflows in Sim.'
|
||||
date: 2025-11-08
|
||||
updated: 2025-11-08
|
||||
authors:
|
||||
- sid
|
||||
readingTime: 7
|
||||
tags: [Copilot, AI Assistant, Benchmarks, Architecture, Sim]
|
||||
ogImage: /blog/copilot/cover.png
|
||||
ogAlt: 'Sim Copilot technical overview'
|
||||
about: ['AI Assistants', 'Agentic Workflows', 'Retrieval Augmented Generation']
|
||||
timeRequired: PT7M
|
||||
canonical: https://www.sim.ai/blog/copilot
|
||||
featured: false
|
||||
draft: true
|
||||
---
|
||||
|
||||
> This is a technical deep‑dive scaffold for Sim Copilot. We’ll keep updating it as we publish more results and open up additional capabilities.
|
||||
|
||||
## TL;DR
|
||||
|
||||
- Copilot is a context‑aware assistant embedded into the Sim editor.
|
||||
- It has first‑class access (with user approval) to workflows, blocks, logs, and docs.
|
||||
- The system is retrieval‑centric with strong guardrails and deterministic execution paths.
|
||||
|
||||
## Architecture at a glance
|
||||
|
||||
1. Intent understanding
|
||||
- Lightweight classifier + instruction parser directs requests into tools.
|
||||
2. Context assembly
|
||||
- Indexed sources (workflows, blocks, logs, docs) with semantic and lexical signals.
|
||||
- Safety filters for scope + permission checks.
|
||||
3. Tooling and actions
|
||||
- Read‑only tools (explain, compare, search), propose‑changes tools, and execution tools.
|
||||
4. Response synthesis
|
||||
- Deterministic templates for diffs, plans, and explanations.
|
||||
5. Human‑in‑the‑loop
|
||||
- All writes gated behind explicit user approval.
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
U[User] --> I(Intent)
|
||||
I --> C(Context Builder)
|
||||
C -->|RAG| R[Retriever]
|
||||
R --> T(Tools)
|
||||
T --> S(Response Synth)
|
||||
S --> U
|
||||
```
|
||||
|
||||
## Retrieval and grounding
|
||||
|
||||
- Sources: workspace workflows, block metadata, execution logs, and product docs.
|
||||
- Indexing: hybrid scoring (BM25 + embeddings) with recency decay and per‑source caps.
|
||||
- Normalization: chunking with stable anchors so diffs remain line‑referential.
|
||||
|
||||
## Early benchmarks (scaffold)
|
||||
|
||||
> Numbers below are placeholders for the structure; we’ll replace with full runs.
|
||||
|
||||
| Task | Top‑1 Retrieval@K | Edit Accuracy | Time (p50) |
|
||||
| ----------------------------------- | -----------------:| ------------: | ---------: |
|
||||
| Explain a workflow block | 92% | 88% | 1.2s |
|
||||
| Propose a safe fix for an error | 78% | 70% | 2.1s |
|
||||
| Generate a new block configuration | 74% | 65% | 2.6s |
|
||||
| Find relevant execution logs | 90% | 84% | 1.4s |
|
||||
|
||||
Measurement notes:
|
||||
|
||||
- Retrieval@K: correctness of the top candidate chunk for a labeled query.
|
||||
- Edit Accuracy: human‑validated acceptance rate for proposed changes.
|
||||
- Time: server‑side latency (excludes model cold‑start).
|
||||
|
||||
## Guardrails and safety
|
||||
|
||||
- Scope enforcement: actions limited to the open workspace with explicit user triggers.
|
||||
- Sensitive data policies and redaction in logs.
|
||||
- Proposal mode: diffs are reviewed and applied only on user approval.
|
||||
|
||||
## How Copilot fits into Sim
|
||||
|
||||
- In‑editor assistant for building and editing workflows.
|
||||
- Shortcut to documentation and examples with live context from your canvas.
|
||||
- Bridge to evaluation: Copilot can set up test runs and compare outputs side‑by‑side.
|
||||
- Works with the same permissions model you already use in Sim.
|
||||
|
||||
## Roadmap (high‑level)
|
||||
|
||||
- Multi‑turn plans with sub‑tasks and rollback.
|
||||
- Deeper evaluation harness and dataset management.
|
||||
- First‑party tool plugins for common blocks and providers.
|
||||
|
||||
## Repro and transparency
|
||||
|
||||
- We’ll publish a benchmark harness and anonymized evaluation sets.
|
||||
- Expect a detailed methodology post as we widen the beta.
|
||||
|
||||
— Sid @ Sim
|
||||
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
---
|
||||
slug: emcn
|
||||
title: 'Introducing Emcn — Sim’s new design system'
|
||||
description: Emcn is the heart of our new design language at Sim. Here’s the scaffolding of the system—principles, tokens, components, and roadmap—as we prepare the full launch.
|
||||
date: 2025-11-08
|
||||
updated: 2025-11-08
|
||||
authors:
|
||||
- emir
|
||||
readingTime: 6
|
||||
tags: [Design, Emcn, UI, UX, Components, Sim]
|
||||
ogImage: /blog/emcn/cover.png
|
||||
ogAlt: 'Emcn design system cover'
|
||||
about: ['Design Systems', 'Component Libraries', 'Design Tokens', 'Accessibility']
|
||||
timeRequired: PT6M
|
||||
canonical: https://www.sim.ai/blog/emcn
|
||||
featured: false
|
||||
draft: true
|
||||
---
|
||||
|
||||
> This post is the scaffolding for Emcn, our new design system. We’ll fill it in as we publish the full documentation and component gallery.
|
||||
|
||||
|
||||
|
||||
## What is Emcn?
|
||||
|
||||
Emcn is the design system that powers Sim’s product and brand. It aims to give us:
|
||||
|
||||
- Consistent, accessible UI across web surfaces
|
||||
- A fast path from Figma to code with strongly‑typed tokens
|
||||
- A composable component library that scales with product complexity
|
||||
|
||||
## Principles
|
||||
|
||||
1. Opinionated but flexible
|
||||
2. Accessible by default (WCAG AA+)
|
||||
3. Strongly‑typed, themeable tokens (light/dark + brand accents)
|
||||
4. Composable components over one‑off variants
|
||||
5. Performance first (minimal runtime, zero layout shift)
|
||||
|
||||
## Foundations (Tokens)
|
||||
|
||||
- Color: semantic palettes (bg, fg, muted, accent, destructive) with on‑colors
|
||||
- Typography: scale + weights mapped to roles (display, title, body, code)
|
||||
- Spacing: 2/4 grid, container and gutter rules
|
||||
- Radius: component tiers (base, interactive, card, sheet)
|
||||
- Shadows: subtle elevation scale for surfaces and overlays
|
||||
- Motion: duration/easing tokens for affordances (not decoration)
|
||||
|
||||
## Components (Initial Set)
|
||||
|
||||
- Primitives: Button, Input, Select, Checkbox, Radio, Switch, Slider, Badge, Tooltip
|
||||
- Navigation: NavBar, SideBar, Tabs, Breadcrumbs
|
||||
- Feedback: Toast, Banner, Alert, Dialog, Drawer, Popover
|
||||
- Layout: Grid, Stack, Container, Card, Sheet
|
||||
- Content: CodeBlock, Markdown, Table, EmptyState
|
||||
|
||||
> Each component will include: anatomy, a11y contract, variants/slots, and code examples.
|
||||
|
||||
## Theming
|
||||
|
||||
- Light + Dark, with brand accent tokens
|
||||
- Per‑workspace theming hooks for enterprise deployments
|
||||
- SSR‑safe color mode with no flash (hydration‑safe)
|
||||
|
||||
## Accessibility
|
||||
|
||||
- Focus outlines and target sizes audited
|
||||
- Color contrast tracked at token level
|
||||
- Keyboard and screen reader interactions defined per component
|
||||
|
||||
## Tooling
|
||||
|
||||
- Tokens exported as TypeScript + CSS variables
|
||||
- Figma library mapped 1:1 to code components
|
||||
- Lint rules for token usage and a11y checks
|
||||
|
||||
## Roadmap
|
||||
|
||||
- v0: Foundations + Core components (internal)
|
||||
- v1: Public docs and examples site
|
||||
- v1.x: Data display, advanced forms, charts bridge
|
||||
|
||||
## FAQ
|
||||
|
||||
- What does “Emcn” mean?
|
||||
A short, crisp name we liked—easy to type and remember.
|
||||
|
||||
- Will Emcn be open‑sourced?
|
||||
We plan to share the foundations and many components as part of our commitment to open source.
|
||||
|
||||
## We’re hiring
|
||||
|
||||
We’re hiring designers and engineers who care deeply about craft and DX. If you want to help shape Emcn and Sim’s product, we’d love to talk.
|
||||
|
||||
— Team Sim
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
'use client'
|
||||
|
||||
import { useState } from 'react'
|
||||
import { ArrowRight, ChevronRight } from 'lucide-react'
|
||||
|
||||
interface ContactButtonProps {
|
||||
href: string
|
||||
children: React.ReactNode
|
||||
}
|
||||
|
||||
export function ContactButton({ href, children }: ContactButtonProps) {
|
||||
const [isHovered, setIsHovered] = useState(false)
|
||||
|
||||
return (
|
||||
<a
|
||||
href={href}
|
||||
target='_blank'
|
||||
rel='noopener noreferrer'
|
||||
onMouseEnter={() => setIsHovered(true)}
|
||||
onMouseLeave={() => setIsHovered(false)}
|
||||
style={{
|
||||
display: 'inline-flex',
|
||||
alignItems: 'center',
|
||||
gap: '7px',
|
||||
borderRadius: '5px',
|
||||
background: isHovered ? '#E0E0E0' : '#FFFFFF',
|
||||
borderWidth: '1px',
|
||||
borderStyle: 'solid',
|
||||
borderColor: isHovered ? '#E0E0E0' : '#FFFFFF',
|
||||
paddingTop: '5px',
|
||||
paddingBottom: '5px',
|
||||
paddingLeft: '9px',
|
||||
paddingRight: '9px',
|
||||
fontSize: '13.5px',
|
||||
fontWeight: 430,
|
||||
color: '#000000',
|
||||
textDecoration: 'none',
|
||||
transition: 'background 200ms, border-color 200ms',
|
||||
}}
|
||||
>
|
||||
{children}
|
||||
<span style={{ display: 'inline-flex' }}>
|
||||
{isHovered ? (
|
||||
<ArrowRight style={{ height: '16px', width: '16px' }} aria-hidden='true' />
|
||||
) : (
|
||||
<ChevronRight style={{ height: '16px', width: '16px' }} aria-hidden='true' />
|
||||
)}
|
||||
</span>
|
||||
</a>
|
||||
)
|
||||
}
|
||||
@@ -0,0 +1,175 @@
|
||||
---
|
||||
slug: enterprise
|
||||
title: 'Sim for Enterprise'
|
||||
description: 'Access control, BYOK, self-hosted deployments, on-prem Copilot, SSO & SAML, whitelabeling, Admin API, and flexible data retention—enterprise features for teams with strict security and compliance requirements.'
|
||||
date: 2026-02-11
|
||||
updated: 2026-02-11
|
||||
authors:
|
||||
- vik
|
||||
readingTime: 10
|
||||
tags: [Enterprise, Security, Self-Hosted, SSO, SAML, Compliance, BYOK, Access Control, Copilot, Whitelabel, API, Import, Export]
|
||||
ogImage: /blog/enterprise/cover.jpg
|
||||
ogAlt: 'Sim Enterprise features overview'
|
||||
about: ['Enterprise Software', 'Security', 'Compliance', 'Self-Hosting']
|
||||
timeRequired: PT10M
|
||||
canonical: https://www.sim.ai/blog/enterprise
|
||||
featured: true
|
||||
draft: false
|
||||
---
|
||||
|
||||
We've been working with security teams at larger organizations to bring Sim into environments with strict compliance and data handling requirements. This post covers the enterprise capabilities we've built: granular access control, bring-your-own-keys, self-hosted deployments, on-prem Copilot, SSO & SAML, whitelabeling, compliance, and programmatic management via the Admin API.
|
||||
|
||||
## Access Control
|
||||
|
||||
|
||||
|
||||
Permission groups let administrators control what features and integrations are available to different teams within an organization. This isn't just UI filtering—restrictions are enforced at the execution layer.
|
||||
|
||||
### Model Provider Restrictions
|
||||
|
||||
|
||||
|
||||
Allowlist specific providers while blocking others. Users in a restricted group see only approved providers in the model selector. A workflow that tries to use an unapproved provider won't execute.
|
||||
|
||||
This is useful when you've approved certain providers for production use, negotiated enterprise agreements with specific vendors, or need to comply with data residency requirements that only certain providers meet.
|
||||
|
||||
### Integration Controls
|
||||
|
||||
|
||||
|
||||
Restrict which workflow blocks appear in the editor. Disable the HTTP block to prevent arbitrary external API calls. Block access to integrations that haven't completed your security review.
|
||||
|
||||
### Platform Feature Toggles
|
||||
|
||||
|
||||
|
||||
Control access to platform capabilities per permission group:
|
||||
|
||||
- **[Knowledge Base](https://docs.sim.ai/integrations/knowledge)** — Disable document uploads if RAG workflows aren't approved
|
||||
- **[MCP Tools](https://docs.sim.ai/agents/mcp)** — Block deployment of workflows as external tool endpoints
|
||||
- **Custom Tools** — Prevent creation of arbitrary HTTP integrations
|
||||
- **Invitations** — Disable self-service team invitations to maintain centralized control
|
||||
|
||||
Users not assigned to any permission group have full access, so restrictions are opt-in per team rather than requiring you to grant permissions to everyone.
|
||||
|
||||
---
|
||||
|
||||
## Bring Your Own Keys
|
||||
|
||||
|
||||
|
||||
When you configure your own API keys for model providers—OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock, or any supported provider—your prompts and completions route directly between Sim and that provider. The traffic doesn't pass through our infrastructure.
|
||||
|
||||
This matters because LLM requests contain the context you've assembled: customer data, internal documents, proprietary business logic. With your own keys, you maintain a direct relationship with your model provider. Their data handling policies and compliance certifications apply to your usage without an intermediary.
|
||||
|
||||
BYOK is available to everyone, not just enterprise plans. Connect your credentials in workspace settings, and all model calls use your keys. For self-hosted deployments, this is the default—there are no Sim-managed keys involved.
|
||||
|
||||
A healthcare organization can use Azure OpenAI with their BAA-covered subscription. A financial services firm can route through their approved API gateway with additional logging controls. The workflow builder stays the same; only the underlying data flow changes.
|
||||
|
||||
---
|
||||
|
||||
## Self-Hosted Deployments
|
||||
|
||||
|
||||
|
||||
Run Sim entirely on your infrastructure. Deploy with [Docker Compose](https://docs.sim.ai/platform/self-hosting/docker) or [Helm charts](https://docs.sim.ai/platform/self-hosting/kubernetes) for Kubernetes—the application, WebSocket server, and PostgreSQL database all stay within your network.
|
||||
|
||||
**Single-node** — Docker Compose setup for smaller teams getting started.
|
||||
|
||||
**High availability** — Multi-replica Kubernetes deployments with horizontal pod autoscaling.
|
||||
|
||||
**Air-gapped** — No external network access required. Pair with [Ollama](https://docs.sim.ai/platform/self-hosting/ollama) or [vLLM](https://docs.sim.ai/platform/self-hosting/vllm) for local model inference.
|
||||
|
||||
Enterprise features like access control, SSO, and organization management are enabled through environment variables—no connection to our billing infrastructure required.
|
||||
|
||||
---
|
||||
|
||||
## On-Prem Copilot
|
||||
|
||||
Copilot—our context-aware AI assistant for building and debugging workflows—can run entirely within your self-hosted deployment using your own LLM keys.
|
||||
|
||||
When you configure Copilot with your API credentials, all assistant interactions route directly to your chosen provider. The prompts Copilot generates—which include context from your workflows, execution logs, and workspace configuration—never leave your network. You get the same capabilities as the hosted version: natural language workflow generation, error diagnosis, documentation lookup, and iterative editing through diffs.
|
||||
|
||||
This is particularly relevant for organizations where the context Copilot needs to be helpful is also the context that can't leave the building. Your workflow definitions, block configurations, and execution traces stay within your infrastructure even when you're asking Copilot for help debugging a failure or generating a new integration.
|
||||
|
||||
---
|
||||
|
||||
## SSO & SAML
|
||||
|
||||
|
||||
|
||||
Integrate with your existing identity provider through SAML 2.0 or OIDC. We support Okta, Azure AD (Entra ID), Google Workspace, OneLogin, Auth0, JumpCloud, Ping Identity, ADFS, and any compliant identity provider.
|
||||
|
||||
Once enabled, users authenticate through your IdP instead of Sim credentials. Your MFA policies apply automatically. Session management ties to your IdP—logout there terminates Sim sessions. Account deprovisioning immediately revokes access.
|
||||
|
||||
New users are provisioned on first SSO login based on IdP attributes. No invitation emails, no password setup, no manual account creation required.
|
||||
|
||||
This centralizes your authentication and audit trail. Your security team's policies apply to Sim access through the same system that tracks everything else.
|
||||
|
||||
---
|
||||
|
||||
## Whitelabeling
|
||||
|
||||
Customize Sim's appearance to match your brand. For self-hosted deployments, whitelabeling is configured through environment variables—no code changes required.
|
||||
|
||||
**Brand name & logo** — Replace "Sim" with your company name and logo throughout the interface.
|
||||
|
||||
**Theme colors** — Set primary, accent, and background colors to align with your brand palette.
|
||||
|
||||
**Support & documentation links** — Point help links to your internal documentation and support channels instead of ours.
|
||||
|
||||
**Legal pages** — Redirect terms of service and privacy policy links to your own policies.
|
||||
|
||||
This is useful for internal platforms, customer-facing deployments, or any scenario where you want Sim to feel like a native part of your product rather than a third-party tool.
|
||||
|
||||
---
|
||||
|
||||
## Compliance & Data Retention
|
||||
|
||||
|
||||
|
||||
Sim maintains **SOC 2 Type II** certification with annual audits covering security, availability, and confidentiality controls. We share our SOC 2 report directly with prospective customers under NDA.
|
||||
|
||||
**Data Retention** — Configure how long workflow execution traces, inputs, and outputs are stored before automatic deletion. We work with enterprise customers to set retention policies that match their compliance requirements.
|
||||
|
||||
We provide penetration test reports, architecture documentation, and completed security questionnaires (SIG, CAIQ, and custom formats) for your vendor review process.
|
||||
|
||||
---
|
||||
|
||||
## Admin API
|
||||
|
||||
Manage Sim programmatically through the Admin API. Every operation available in the UI has a corresponding API endpoint, enabling infrastructure-as-code workflows and integration with your existing tooling.
|
||||
|
||||
**User & Organization Management** — Provision users, create organizations, assign roles, and manage team membership. Integrate with your HR systems to automatically onboard and offboard employees.
|
||||
|
||||
**Workspace Administration** — Create workspaces, configure settings, and manage access. Useful for setting up isolated environments for different teams or clients.
|
||||
|
||||
**Workflow Lifecycle** — Deploy, undeploy, and manage workflow versions programmatically. Build CI/CD pipelines that promote workflows from development to staging to production.
|
||||
|
||||
The API uses standard REST conventions with JSON payloads. Authentication is via API keys scoped to your organization.
|
||||
|
||||
---
|
||||
|
||||
## Import & Export
|
||||
|
||||
Move workflows between environments, create backups, and maintain version control inside or outside of Sim.
|
||||
|
||||
**Workflow Export** — Export individual workflows or entire folders as JSON. The export includes block configurations, connections, environment variable references, and metadata. Use this to back up critical workflows or move them between Sim instances.
|
||||
|
||||
**Workspace Export** — Export an entire workspace as a ZIP archive containing all workflows, folder structure, and configuration. Useful for disaster recovery or migrating to a self-hosted deployment.
|
||||
|
||||
**Import** — Import workflows into any workspace. Sim handles ID remapping and validates the structure before import. This enables workflow templates, sharing between teams, and restoring from backups.
|
||||
|
||||
**Version History** — Each deployment creates a version snapshot. Roll back to previous versions if a deployment causes issues. The Admin API exposes version history for integration with your change management processes.
|
||||
|
||||
For teams practicing GitOps, export workflows to your repository and use the Admin API to deploy from CI/CD pipelines.
|
||||
|
||||
---
|
||||
|
||||
## Get Started
|
||||
|
||||
Enterprise features are available now. Check out our [self-hosting](https://docs.sim.ai/platform/self-hosting) and [enterprise](https://docs.sim.ai/platform/enterprise) docs to get started.
|
||||
|
||||
*Questions about enterprise deployments?*
|
||||
|
||||
<ContactButton href="https://form.typeform.com/to/jqCO12pF">Contact Us</ContactButton>
|
||||
@@ -0,0 +1,196 @@
|
||||
---
|
||||
slug: executor
|
||||
title: 'Inside the Sim Executor - DAG Based Execution with Native Parallelism'
|
||||
description: 'How we built a DAG-based execution engine with native parallel processing, intelligent edge routing, and stateful pause/resume capabilities'
|
||||
date: 2025-11-10
|
||||
updated: 2025-11-10
|
||||
authors:
|
||||
- sid
|
||||
readingTime: 12
|
||||
tags: [Executor, Architecture, DAG, Orchestration]
|
||||
ogImage: /blog/executor/cover.jpg
|
||||
ogAlt: 'Sim Executor technical overview'
|
||||
about: ['Execution', 'Workflow Orchestration']
|
||||
timeRequired: PT12M
|
||||
canonical: https://www.sim.ai/blog/executor
|
||||
featured: false
|
||||
draft: false
|
||||
---
|
||||
|
||||
Modern workflows aren't just linear automations anymore. They involve a variety of APIs and services, loop over a model's output, pause for human decisions, and resume hours or days later exactly where they left off.
|
||||
|
||||
We designed the Sim executor to make these patterns feel natural. This post shares the architecture we ended up with, the challenges we ran into along the way, and what it enables for teams building agentic systems at scale.
|
||||
|
||||
## Laying the Foundation
|
||||
|
||||
There's a single guiding philosophy we use when designing the executor: workflows should read like the work you intend to do, not like the mess of cables behind a TV.
|
||||
The complexity of wiring and plumbing should be abstracted away, and building a performant workflow end to end should be easy, modular, and seamless.
|
||||
|
||||
That's why the Sim executor serves as both an orchestrator and a translation layer, turning user-friendly workflow representations into an executable DAG behind the scenes.
|
||||
|
||||
## Core engine
|
||||
|
||||
At its heart, the executor figures out which blocks can run, runs them, then repeats. It sounds simple in theory, but can become surprisingly complex when you factor in conditional routing, nested loops, and true parallelism.
|
||||
|
||||
### Compiling Workflows to Graphs
|
||||
|
||||
Before execution starts, we compile the visual workflow into a directed acyclic graph (DAG). Every block becomes a node and every connection becomes an edge. Loops and parallel subflows expand into more complex structures (sentinel nodes for loops, branch-indexed nodes for parallels) that preserve the DAG property while enabling iteration and concurrency.
|
||||
|
||||
This upfront compilation pays off immediately: the entire topology is concretely defined before the first block ever executes.
|
||||
|
||||
### The Execution Queue
|
||||
|
||||
Once we have the DAG, execution becomes event‑driven. We maintain a ready queue: nodes whose dependencies are all satisfied. When a node completes, we remove its outgoing edges from downstream nodes' incoming edge sets. Any node that hits zero incoming edges goes straight into the queue. At it's core, topological sort.
|
||||
|
||||
The key difference here from traditional workflow execution approaches: we don't wait for a "layer" to finish. If three nodes in the queue are independent, we launch all three immediately and let the runtime handle concurrency.
|
||||
|
||||
### Dependency Resolution
|
||||
|
||||
In our earlier prototypes, we scanned the connection array after every block execution to see what became ready. However, as the number of nodes and edges scale, performance takes a hit.
|
||||
|
||||
The DAG flips that model. Each node tracks its own incoming edges in a set. When a dependency completes, we remove one element from the set. When the set hits zero, the node is ready. No scanning, no filtering, no repeated checks.
|
||||
|
||||
This optimization compounds when you have many parallel branches or deeply nested structures. Every node knows its own readiness without asking the rest of the graph.
|
||||
|
||||
### Variable Resolution
|
||||
|
||||
Blocks reference data from different sources: loop items (`<loop.iteration>`, `<loop.item>`), parallel branch indices (`<parallel.index>`), upstream block outputs (`<blockId.output.content>`), workflow variables (`<workflow.variableName>`), and environment variables (`${API_KEY}`). The resolver tries each scope in order—loop first, then parallel, then workflow, then environment, then block outputs. Inner scopes shadow outer ones, matching standard scoping semantics. This makes variables predictable: the context you're in determines what you see, without name collision or manual prefixes.
|
||||
|
||||
### Multiple Triggers and Selective Compilation
|
||||
|
||||
A workflow can have multiple entry points. Webhooks listen at different paths, schedules run on different cadences, and some triggers can fire from the UI. Each represents a valid starting point, but only one matters for any given execution.
|
||||
|
||||
The DAG builder handles this through selective compilation. When a workflow executes, we receive a trigger block ID. The builder starts from that node and builds only the reachable subgraph. Blocks that aren't downstream from the trigger never make it into the DAG.
|
||||
|
||||
This keeps execution focused. A workflow with five different webhook triggers doesn't compile all five paths every time. The topology adapts to the context automatically.
|
||||
|
||||
### Executing from the Client
|
||||
|
||||
The executor lives server-side. Users build workflows in the client. As they iterate and test, they need to see block inputs and outputs, watch execution progress in real time, and understand which paths the workflow takes.
|
||||
|
||||
Polling adds latency. Duplicating execution logic client‑side creates drift. We needed a way to stream execution state as it happens.
|
||||
|
||||
The executor emits events at key execution points—block starts, completions, streaming content, errors. These events flow through SSE to connected clients. The client reconstructs execution state from the stream, rendering logs and outputs as blocks complete.
|
||||
|
||||
## Parallelism
|
||||
|
||||
When a workflow fans out to call multiple APIs, compare outputs from different models, or process items independently, those branches should run at the same time. Not interleaved, not sequentially—actually concurrent.
|
||||
|
||||
Most workflow platforms handle branches differently. Some execute them one after another (n8n's v1 mode completes branch 1, then branch 2, then branch 3). Others interleave execution (run the first node of each branch, then the second node of each branch). Both approaches are deterministic, but neither gives you true parallelism.
|
||||
|
||||
The workarounds typically involve triggering separate sub-workflows with "wait for completion" disabled, then manually collecting results. This works, but it means coordinating execution state across multiple workflow instances, handling failures independently, and stitching outputs back together.
|
||||
|
||||
### How we approach it
|
||||
|
||||
The ready queue gives us parallelism by default. When a parallel block executes, it expands into branch‑indexed nodes in the DAG. Each branch is a separate copy of the blocks inside the parallel scope, indexed by branch number.
|
||||
|
||||
All entry nodes across all branches enter the ready queue simultaneously. The executor launches them concurrently—they're independent nodes with satisfied dependencies. As each branch progresses, its downstream nodes become ready and execute. The parallel orchestrator tracks completion by counting terminal nodes across all branches.
|
||||
|
||||
When all branches finish, we aggregate their outputs in branch order and continue. No coordination overhead, no manual result collection—just concurrent execution with deterministic aggregation.
|
||||
|
||||
### What this enables
|
||||
|
||||
A workflow that calls fifty different APIs processes them concurrently. Parallel model comparisons return results as they stream in, not after the slowest one finishes.
|
||||
|
||||
The DAG doesn't distinguish between "parallel branches" and "independent blocks that happen to be ready at the same time." Both execute concurrently. Parallelism simply emerges from workflow structure.
|
||||
|
||||
### Parallel subflows for cleaner authoring
|
||||
|
||||
For repetitive parallel work, we added parallel subflows. Instead of duplicating blocks visually for each branch on the canvas, you define a single subflow and configure the parallel block to run it N times or once per item in a collection.
|
||||
|
||||
Behind the scenes, this expands to the same branch‑indexed DAG structure. The executor doesn't distinguish between manually authored parallel branches and subflow-generated ones—they both become independent nodes that execute concurrently. Same execution model, cleaner authoring experience.
|
||||
|
||||
## Loops
|
||||
|
||||
### How loops compile to DAGs
|
||||
|
||||
Loops present a challenge for DAGs: graphs are acyclic, but loops repeat. We handle this by expanding loops into sentinel nodes during compilation.
|
||||
|
||||
|
||||
*Loops expand into sentinel start and end nodes. The backward edge only activates when the loop continues, preserving the DAG's acyclic property.*
|
||||
|
||||
A loop is bookended by two nodes: a sentinel start and a sentinel end. The sentinel start activates the first blocks inside the loop. When terminal blocks complete, they route to the sentinel end. The sentinel end evaluates the loop condition and returns either "continue" (which routes back to the start) or "exit" (which activates blocks after the loop).
|
||||
|
||||
The backward edge from end to start doesn't count as a dependency initially—it only activates if the loop continues. This preserves the DAG property while enabling iteration.
|
||||
|
||||
### Iteration state and variable scoping
|
||||
|
||||
When a loop continues, the executor doesn't re-execute blocks from scratch. It clears their execution state (marking them as not-yet-executed) and restores their incoming edges, so they become ready for the next pass. Loop scope updates: iteration increments, the next item loads (for forEach), outputs from the previous iteration move to the aggregated results.
|
||||
|
||||
Blocks inside the loop access loop variables through the resolver chain. `<loop.iteration>` resolves before checking block outputs or workflow variables, so iteration context shadows outer scopes. This makes variable access predictable—you always get the current loop state.
|
||||
|
||||
## Conditions and Routers
|
||||
|
||||
Workflows branch based on runtime decisions. A condition block evaluates expressions and routes to different paths. A router block lets an AI model choose which path to take based on context. Both are core to building adaptive workflows.
|
||||
|
||||
### LLM-driven routing
|
||||
|
||||
Router blocks represent a modern pattern in workflow orchestration. Instead of hardcoding logic with if/else chains, you describe the options and let a language model decide. The model sees the conversation context, evaluates which path makes sense, and returns a selection.
|
||||
|
||||
The executor treats this selection as a routing decision. Each outgoing edge from a router carries metadata about which target block it represents. When the router completes, it returns the chosen block's ID. The edge manager activates only the edge matching that ID; all other edges deactivate.
|
||||
|
||||
This makes AI-driven routing deterministic and traceable. You can inspect the execution log and see exactly which path the model chose, why (from the model's reasoning), and which alternatives were pruned.
|
||||
|
||||
### Edge selection and path pruning
|
||||
|
||||
When a condition or router executes, it evaluates its logic and returns a single selection. The edge manager checks each outgoing edge to see if its label matches the selection. The matching edge activates; the rest deactivate.
|
||||
|
||||
|
||||
*When a condition selects one path, the chosen edge activates while unselected paths deactivate recursively, preventing unreachable blocks from executing.*
|
||||
|
||||
Deactivation cascades. If an edge deactivates, the executor recursively deactivates all edges downstream from its target—unless that target has other active incoming edges. This automatic pruning prevents unreachable blocks from ever entering the ready queue.
|
||||
|
||||
The benefit: wasted work drops to zero. Paths that won't execute don't consume resources, don't wait in the queue, and don't clutter execution logs. The DAG reflects what actually ran, not what could have run.
|
||||
|
||||
### Convergence and rejoining paths
|
||||
|
||||
Workflows often diverge and reconverge. Multiple condition branches might lead to different processing steps, then merge at a common aggregation block. The executor handles this through edge counting.
|
||||
|
||||
When paths converge, the target block has multiple incoming edges—one from each upstream path. The edge manager tracks which edges activate. If a condition prunes one branch, that edge deactivates, and the target's incoming edge count decreases. The target becomes ready only when all remaining active incoming edges complete.
|
||||
|
||||
This works for complex topologies: nested conditions, routers feeding into other routers, parallel branches that reconverge after different amounts of work. The dependency tracking adapts automatically.
|
||||
|
||||
## Human in the loop
|
||||
|
||||
AI workflows aren't fully automated. They pause for approvals, wait for human feedback, or stop to let someone review model output before continuing. These pauses can happen anywhere—mid‑branch, inside a loop, across multiple parallel paths at once.
|
||||
|
||||
### Pause detection and state capture
|
||||
|
||||
When a block returns pause metadata, the executor stops processing its outgoing edges. Instead of continuing to downstream blocks, it captures the current execution state: every block output, every loop iteration, every parallel branch's progress, every routing decision, and the exact topology of remaining dependencies in the DAG.
|
||||
|
||||
Each pause point gets a unique context ID that encodes its position. A pause inside a loop at iteration 5 gets a different ID than the same block at iteration 6. A pause in parallel branch 3 gets a different ID than branch 4. This makes resume targeting precise—you can resume specific pause points independently.
|
||||
|
||||
The executor supports multiple simultaneous pauses. If three parallel branches each hit an approval block, all three pause, each with its own context ID. The execution returns with all three pause points and their resume links. Resuming any one triggers continuation from that specific point.
|
||||
|
||||
### Snapshot serialization
|
||||
|
||||
The snapshot captures everything needed to resume. Block states, execution logs, loop and parallel scopes, routing decisions, workflow variables—all serialize to JSON. The critical piece: DAG incoming edges. We save which dependencies each node still has outstanding.
|
||||
|
||||
When you serialize the DAG's edge state, you're freezing the exact moment in time when execution paused. This includes partially‑completed loops (iteration 7 of 100), in‑flight parallel branches (12 of 50 complete), and conditional paths already pruned.
|
||||
|
||||
### Resume and continuation
|
||||
|
||||
Resuming rebuilds the DAG, restores the snapshot state, and queues the resume trigger nodes. The executor marks already‑executed blocks to prevent re‑execution, restores incoming edges to reflect remaining dependencies, and continues from where it stopped.
|
||||
|
||||
If multiple pause points exist, each can resume independently. The first resume doesn't invalidate the others—each pause has its own trigger node in the DAG. When all pauses resume, the workflow continues normally, collecting outputs from each resumed branch.
|
||||
|
||||
### Coordination and atomicity
|
||||
|
||||
The executor uses a queue lock to prevent race conditions. When a node completes with pause metadata, we acquire the lock before checking for pauses. This ensures that multiple branches pausing simultaneously don't interfere with each other's state capture.
|
||||
|
||||
The lock also prevents a resumed node from racing with other executing nodes. When a resume trigger fires, it enters the queue like any other node. The ready queue pattern handles coordination—resumed nodes execute when their dependencies clear, just like nodes in the original execution.
|
||||
|
||||
### Example
|
||||
|
||||
|
||||
*A common pattern: agent generates output, pauses for human review, router decides pass/fail based on feedback, saves to workflow variable, and loop continues until approved.*
|
||||
|
||||
A while loop runs an agent with previous feedback as context. The agent's output goes to a human‑in‑the‑loop block, which pauses execution and sends a notification. The user reviews the output and provides feedback via the resume link.
|
||||
|
||||
When resumed, the feedback flows to a router that evaluates whether the output passes or needs revision. If it fails, the router saves the feedback to a workflow variable and routes back to continue the loop. The agent receives this feedback on the next iteration and tries again. If it passes, the router exits the loop and continues downstream.
|
||||
|
||||
The while loop's condition checks the workflow variable. As long as the status is "fail," the loop continues. When the router sets it to "pass," the loop exits. Each piece—loops, pause/resume, routing, variables—composes without glue because they're all first‑class executor concepts.
|
||||
|
||||
Multiple reviewers approving different branches works the same way. Each branch pauses independently, reviewers approve in any order, and execution continues as each approval comes in. The parallel orchestrator collects the results when all branches complete.
|
||||
|
||||
— Sid @ Sim
|
||||
@@ -0,0 +1,140 @@
|
||||
---
|
||||
slug: mothership
|
||||
title: 'Introducing Mothership'
|
||||
description: 'Sim v0.6 introduces Mothership—a central intelligence layer for orchestrating your AI agents—alongside Tables, Files, Knowledge Base Connectors, and Scheduled Tasks.'
|
||||
date: 2026-03-17
|
||||
updated: 2026-03-17
|
||||
authors:
|
||||
- emir
|
||||
readingTime: 10
|
||||
tags: [Release, Mothership, Tables, Knowledge Base, Connectors, RAG, Sim]
|
||||
ogImage: /blog/mothership/cover.jpg
|
||||
ogAlt: 'Introducing Mothership airship illustration'
|
||||
about: ['AI Agents', 'Workflow Automation', 'Developer Tools']
|
||||
timeRequired: PT10M
|
||||
canonical: https://www.sim.ai/blog/mothership
|
||||
featured: true
|
||||
draft: false
|
||||
---
|
||||
|
||||
I often wonder why AI agents don't already do everything for me today. Why don't they take my meetings for me? Why can't they send follow-ups to customers? Why can't they track the progress of our product launches and just start solving problems for us?
|
||||
|
||||
It seems like this is an engineering challenge more than a scientific one. Models today are already remarkably capable at solving complex problems. Look at how far AI coding has come in just two years.
|
||||
|
||||
|
||||
|
||||
In 2023, the best models could solve around 5% of real-world GitHub issues. By early 2025, that number crossed 70%. Today we're approaching 80%. These aren't toy benchmarks—they're actual pull requests on open-source repositories that require multi-file reasoning, debugging, and testing.
|
||||
|
||||
If a model can navigate a codebase, diagnose a bug, and write a working fix, why can't it update my CRM after a sales call? Why can't it pull last week's metrics from three different tools and post a summary to Slack every Monday?
|
||||
|
||||
The answer isn't intelligence. It's infrastructure. Models need the right workspace around them—persistent data, access to your tools, knowledge from your documents, and the ability to act on a schedule without you in the loop.
|
||||
|
||||
That's what we built.
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Mothership
|
||||
|
||||
|
||||
|
||||
Mothership is the control plane for your entire workspace. It's not a chatbot—it's an orchestrator with full context over your workflows, tables, knowledge bases, files, and every integration you've connected.
|
||||
|
||||
Ask it to "create a CRM table, seed it with my existing leads data, build a self-healing sync workflow, and schedule it to run daily"—and it does exactly that. It creates the table, writes the rows, wires up the workflow blocks, configures the integrations, tests it, and deploys it. One prompt, end to end.
|
||||
|
||||
Mothership can call any of your 100+ integration tools directly—query a CRM, send a Slack message, search a knowledge base, create a Linear issue—all from a single conversation. It can read, write, and edit files in your workspace. It can build entire workflows from a description and deploy them as APIs, chat interfaces, or MCP tools.
|
||||
|
||||
When something breaks, it debugs. When you need a report, it writes one. When you describe a workflow in plain English, it builds it, tests it, and ships it.
|
||||
|
||||
|
||||
|
||||
You can even email your workspace. Enable a Sim inbox, and Mothership reads incoming messages, executes tasks using your integrations and data, and replies. Your workspace becomes an email-driven automation layer—send it a request, and it handles the rest.
|
||||
|
||||
This is the difference between an assistant that answers questions and one that actually runs things.
|
||||
|
||||
---
|
||||
|
||||
## Tables
|
||||
|
||||
For agents to do real work, they need somewhere to put things. Not ephemeral context that disappears after a conversation—persistent, structured data they can read, write, and query over time.
|
||||
|
||||
Tables give your workspace a database. Create tables with typed columns—string, number, boolean, date, JSON—insert and update rows, query with filters and sorting, and use them as the state layer for any automation. 10+ operations are available as workflow blocks: query, insert, upsert, batch insert, update, delete, get row, get schema.
|
||||
|
||||
The Mothership can manage tables directly—creating schemas, seeding data, and querying results as part of a larger task. It's not just storage. It's memory.
|
||||
|
||||
A customer support workflow writes new tickets to a table. A lead enrichment pipeline upserts contact data after every sync. A reporting agent queries last week's rows and generates a summary. Tables are how your agents remember things and build on previous work.
|
||||
|
||||
Think about why this matters. An agent that forgets everything between runs can't track a product launch. An agent with a table can see what happened yesterday, what's overdue, and what needs attention—and act on it.
|
||||
|
||||
---
|
||||
|
||||
## Files
|
||||
|
||||
|
||||
|
||||
Your workspace has a built-in file system. Upload documents, create new files, and use them across your workflows and the Mothership.
|
||||
|
||||
Upload PDFs, spreadsheets, Markdown, JSON, YAML, CSV, HTML, SVG, audio, video—up to 100MB per file. Each format gets a rich preview: Markdown renders with syntax highlighting, HTML and SVG render inline, CSVs display as scrollable data tables, and media files play with native controls.
|
||||
|
||||
Edit files directly in the browser with a split-view editor—write on the left, see the rendered preview on the right. The Mothership can also create and edit files programmatically. Ask it to "write a report summarizing last week's metrics" and it creates the Markdown file, populates it, and shows you the preview inline.
|
||||
|
||||
CSV files can be imported directly into Tables. Sim auto-detects delimiters, infers column types from the data, and batch-inserts up to 1,000 rows. One click from a raw export to a queryable, workflow-ready table.
|
||||
|
||||
Files give agents the ability to produce real artifacts. Not just chat responses—actual documents, reports, configs, and exports that you and your team can use.
|
||||
|
||||
---
|
||||
|
||||
## Knowledge Base
|
||||
|
||||
|
||||
|
||||
Agents need access to what your team already knows—docs, wikis, meeting notes, support articles, design specs. But that knowledge lives scattered across dozens of tools. Without it, agents hallucinate or give generic answers. With it, they're grounded in your actual business context.
|
||||
|
||||
Knowledge Base Connectors bring it all together. Connect a source—Google Docs, Notion, Confluence, Slack, GitHub, Jira, Linear, HubSpot, Salesforce, Zendesk, Dropbox, OneDrive, Gmail, Discord, and 15+ more—and Sim handles the rest. Documents are fetched, chunked, embedded, and indexed automatically. Incremental sync keeps everything up to date on a schedule.
|
||||
|
||||
The pipeline handles PDFs with OCR, Markdown, JSON, YAML, and plain text. Chunking is configurable—size, overlap, minimum size. Embeddings use OpenAI's text-embedding-3-small with BYOK support. The result is a vector-searchable knowledge base that's instantly available to any workflow block or to Mothership directly.
|
||||
|
||||
This is RAG without the setup. Connect a source, and within minutes your agents can search your team's knowledge, retrieve relevant context, and ground their responses in real information. A support agent that can search your actual help docs. A sales assistant that pulls from your real product specs and competitive intel. A research workflow that synthesizes information from your actual documents.
|
||||
|
||||
---
|
||||
|
||||
## Scheduled Tasks
|
||||
|
||||
Everything above means agents can orchestrate, store data, manage files, and access knowledge. The last piece is autonomy—the ability to act without you in the loop.
|
||||
|
||||
Scheduled Tasks let you tell Mothership what you need done and when. Set up recurring or one-time jobs that execute on a cron schedule, with full access to your integrations, tables, and knowledge bases.
|
||||
|
||||
Two modes: **persistent** tasks run indefinitely on schedule, and **until_complete** tasks poll until a success condition is met, then stop automatically. Configurable max runs, 40+ timezone support, and automatic failure tracking that disables a task after 3 consecutive failures.
|
||||
|
||||
**"Every morning at 9am, check my Gmail for new support tickets and create rows in my Tickets table."** A persistent task that runs daily, searches Gmail, and writes structured data to a Table.
|
||||
|
||||
**"Every hour, poll the Stripe API for failed payments and send a Slack summary to #billing."** Recurring monitoring across two integrations in a single prompt.
|
||||
|
||||
**"Check if the Q1 report has been uploaded to Google Drive. When it appears, summarize it and email the team."** An until_complete task that polls until the file exists, then acts and stops.
|
||||
|
||||
**"Every Monday at 8am, pull this week's Linear issues, cross-reference with our product roadmap in Notion, and post a status update to Slack."** Multi-step reasoning across three integrations on a weekly schedule.
|
||||
|
||||
Each run tracks execution history, so the Mothership has context about what it did previously—making each run smarter.
|
||||
|
||||
This is the part that closes the gap. You described a task. It runs on schedule. You're not in the loop. The agent is just doing its job.
|
||||
|
||||
---
|
||||
|
||||
## It All Connects
|
||||
|
||||
None of these features exist in isolation. They compose into something larger.
|
||||
|
||||
Mothership queries your Tables, searches your Knowledge Bases, reads and writes your Files, calls your integrations, and runs on a schedule through Scheduled Tasks. A user emails your workspace and the Mothership reads the message, researches the answer across synced Notion docs, stores the result in a Table, and triggers a Slack notification workflow. One control plane, all your data, all your tools.
|
||||
|
||||
The reason AI agents can't run your life today isn't that they aren't smart enough. It's that they don't have the right workspace. They need persistent memory, access to your knowledge, the ability to act across your tools, and the autonomy to do it on a schedule.
|
||||
|
||||
That's what v0.6 is.
|
||||
|
||||
---
|
||||
|
||||
## Get Started
|
||||
|
||||
Sim v0.6 is available now at [sim.ai](https://sim.ai). Check out our [documentation](https://docs.sim.ai) for detailed guides on Mothership, Tables, Connectors, and more.
|
||||
|
||||
*Questions? [help@sim.ai](mailto:help@sim.ai) · [Discord](https://sim.ai/discord)*
|
||||
@@ -0,0 +1,181 @@
|
||||
---
|
||||
slug: multiplayer
|
||||
title: 'Realtime Collaboration'
|
||||
description: A high-level explanation into Sim realtime collaborative workflow builder - from operation queues to conflict resolution.
|
||||
date: 2025-11-11
|
||||
updated: 2025-11-11
|
||||
authors:
|
||||
- vik
|
||||
readingTime: 12
|
||||
tags: [Multiplayer, Realtime, Collaboration, WebSockets, Architecture]
|
||||
ogImage: /blog/multiplayer/cover.jpg
|
||||
canonical: https://www.sim.ai/blog/multiplayer
|
||||
draft: false
|
||||
---
|
||||
|
||||
When we started building Sim, we noticed that AI workflow development looked a lot like the design process [Figma](https://www.figma.com/blog/how-figmas-multiplayer-technology-works/) had already solved for. Product managers need to sketch out user-facing flows, engineers need to configure integrations and APIs, and domain experts need to validate business logic—often all at the same time. Traditional workflow builders force serial collaboration: one person edits, saves, exports, and notifies the next person. This creates unnecessary friction.
|
||||
|
||||
We decided multiplayer editing was the right approach, even though workflow platforms like n8n and Make do not currently offer it. This post explains how we built it. We'll cover the operation queue, conflict resolution, how we handle blocks/edges/subflows separately, undo/redo as a wrapper around this, and why our system is a lot simpler than you'd expect.
|
||||
|
||||
## Architecture Overview: Client-Server with WebSockets
|
||||
|
||||
Sim uses a client-server architecture where browser clients communicate with a standalone Node.js WebSocket server over persistent connections. When you open a workflow, your client joins a "workflow room" on the server. All subsequent operations—adding blocks, connecting edges, updating configurations—are synchronized through this connection.
|
||||
|
||||
### Server-Side: The Source of Truth
|
||||
|
||||
The server maintains authoritative state in PostgreSQL across three normalized tables:
|
||||
|
||||
- `workflow_blocks`: Block metadata, positions, configurations, and subblock values
|
||||
- `workflow_edges`: Connections between blocks with source/target handles
|
||||
- `workflow_subflows`: Loop and parallel container configurations with child node lists
|
||||
|
||||
This separation is deliberate. Blocks, edges, and subflows have different update patterns and conflict characteristics. By storing them separately:
|
||||
|
||||
1. **Targeted updates**: Moving a block only updates `positionX` and `positionY` fields for that specific block row. We don't load or lock the entire workflow.
|
||||
2. **Query optimization**: Different operations hit different tables with appropriate indexes. Updating edge connections only touches `workflow_edges`, leaving blocks untouched.
|
||||
3. **Separate channels**: Structural operations (adding blocks, connecting edges) go through the main operation handler with persistence-first logic. Value updates (editing text in a subblock) go through a separate debounced channel with server-side coalescing—reducing database writes from hundreds to dozens for a typical typing session.
|
||||
|
||||
The server uses different broadcast strategies: position updates are broadcast immediately for smooth collaborative dragging (optimistic), while structural operations (adding blocks, connecting edges) persist first to ensure consistency (pessimistic).
|
||||
|
||||
### Client-Side: Optimistic Updates with Reconciliation
|
||||
|
||||
Clients maintain local copies of workflow state in [Zustand](https://github.com/pmndrs/zustand) stores. When you drag a block or type in a text field, the UI updates immediately—this is optimistic rendering. Simultaneously, the client queues an operation in a separate operation queue store to send to the server.
|
||||
|
||||
The client doesn't wait for server confirmation to render changes. Instead, it assumes success and continues. If the server rejects an operation (permissions failure, conflict, validation error), the client reconciles by either retrying or reverting the local change.
|
||||
|
||||
This is why workflow editing feels instantaneous—you never wait for a network round-trip to see your changes. The downside is added complexity around handling reconciliation, retries, and conflict resolution.
|
||||
|
||||
## The Operation Queue: Reliability Through Retries
|
||||
|
||||
At the heart of Sim's multiplayer system is the **Operation Queue**—a client-side abstraction that ensures no operation is lost, even under poor network conditions.
|
||||
|
||||
### How It Works
|
||||
|
||||
Every user action that modifies workflow state generates an operation object:
|
||||
|
||||
```typescript
|
||||
{
|
||||
id: 'op-uuid',
|
||||
operation: {
|
||||
operation: 'update', // or 'add', 'remove', 'move'
|
||||
target: 'block', // or 'edge', 'subblock', 'variable'
|
||||
payload: { /* change data */ }
|
||||
},
|
||||
workflowId: 'workflow-id',
|
||||
userId: 'user-id',
|
||||
status: 'pending'
|
||||
}
|
||||
```
|
||||
|
||||
Operations are enqueued in FIFO order. The queue processor sends one operation at a time over the WebSocket, waiting for server confirmation before proceeding to the next. Text edits (subblock values, variable fields) are debounced client-side and coalesced server-side—a user typing a 500-character prompt generates ~10 operations instead of 500.
|
||||
|
||||
Failed operations retry with exponential backoff (structural changes get 3 attempts, text edits get 5). If all retries fail, the system enters offline mode—the queue is cleared and the UI becomes read-only until the user manually refreshes.
|
||||
|
||||
### Handling Dependent Operations
|
||||
|
||||
The operation queue's real power emerges when handling conflicts between collaborators. Consider this scenario:
|
||||
|
||||
**User A** deletes a block while **User B** has a pending subblock update for that same block in their operation queue.
|
||||
|
||||
```
|
||||
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
|
||||
│ User A │ │ Server │ │ User B │
|
||||
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
|
||||
│ │ │
|
||||
│ Delete Block X │ │
|
||||
├─────────────────────────────────>│ │
|
||||
│ │ │
|
||||
│ │ Persist deletion │
|
||||
│ │ ────────────┐ │
|
||||
│ │ │ │
|
||||
│ │<─────────────┘ │
|
||||
│ │ │
|
||||
│ │ Broadcast: Block X deleted │
|
||||
│ ├─────────────────────────────────>│
|
||||
│ │ │
|
||||
│ │ Cancel all ops for X │
|
||||
│ │ (including subblock) │
|
||||
│ │ ────────┤
|
||||
│ │ │
|
||||
│ │ Remove Block X │
|
||||
│ │ ────────┤
|
||||
│ │ │
|
||||
```
|
||||
|
||||
Here's what happens:
|
||||
|
||||
1. User A's delete operation reaches the server and persists successfully
|
||||
2. The server broadcasts the deletion to all clients, including User B
|
||||
3. User B's client receives the broadcast and **immediately cancels all pending operations** for Block X (including the subblock update)
|
||||
4. Then User B's client removes Block X from local state
|
||||
|
||||
No operations are sent to the server for a block that no longer exists. The client proactively removes all related operations from the queue—both block-level operations and subblock operations. User B never sees an error because the stale operation is silently discarded before it's sent.
|
||||
|
||||
This is more efficient than server-side validation. By canceling dependent operations locally when receiving a deletion broadcast, we avoid wasting network requests on operations that would fail anyway.
|
||||
|
||||
## Conflict Resolution: Timestamps and Determinism
|
||||
|
||||
In line with our goal of keeping things simple, Sim uses a **last-writer-wins** strategy with timestamp-based ordering. Every operation carries a client-generated timestamp. When conflicts occur, the operation with the latest timestamp takes precedence.
|
||||
|
||||
This is simpler than Figma's operational transform approach, but sufficient for our use case. Workflow building has lower conflict density than text editing—users typically work on different parts of the canvas or different blocks.
|
||||
|
||||
**Position conflicts** are handled with timestamp ordering. If two users simultaneously drag the same block, both clients render their local positions optimistically. The server persists both updates based on timestamps, broadcasting each in sequence. Clients receive the conflicting positions and converge to the latest timestamp.
|
||||
|
||||
**Value conflicts** (editing the same text field) are rarer but use last-to-arrive wins. Subblock updates are coalesced server-side within a 25ms window—whichever update reaches the server last within that window is persisted, regardless of client timestamp.
|
||||
|
||||
## Undo/Redo: A Thin Wrapper Over Sockets
|
||||
|
||||
Undo/redo in multiplayer environments is notoriously complex. Should undoing overwrite others' changes? What happens when you undo something someone else modified?
|
||||
|
||||
Sim takes a pragmatic approach: **undo/redo is a local, per-user stack that generates inverse operations sent through the same socket system as regular edits.**
|
||||
|
||||
### How It Works
|
||||
|
||||
Every operation you perform is recorded in a local undo stack with its inverse:
|
||||
|
||||
- **Add block** → Inverse: **Remove block** (with full block snapshot)
|
||||
- **Remove block** → Inverse: **Add block** (restoring from snapshot)
|
||||
- **Move block** → Inverse: **Move block** (with original position)
|
||||
- **Update subblock** → Inverse: **Update subblock** (with previous value)
|
||||
|
||||
When you press Cmd+Z:
|
||||
|
||||
1. Pop the latest operation from your undo stack
|
||||
2. Push it to your redo stack
|
||||
3. Execute the inverse operation by queuing it through the operation queue
|
||||
4. The inverse operation flows through the normal socket system: validation, persistence, broadcast
|
||||
|
||||
This means **undo is just another edit**. If you undo adding a block, Sim sends a "remove block" operation through the queue. Other users see the block disappear in real-time, as if you manually deleted it.
|
||||
|
||||
### Coalescing and Snapshots
|
||||
|
||||
Consecutive operations of the same type are coalesced. If you drag a block across the canvas in 50 small movements, only the starting and ending positions are recorded—pressing undo moves the block back to where you started dragging, not through every intermediate position.
|
||||
|
||||
For removal operations, we snapshot the complete state of the removed entity (including all subblock values and connected edges) at the time of removal. This snapshot travels with the undo entry. When you undo a deletion, we restore from the snapshot, ensuring perfect reconstruction even if the workflow structure changed in the interim.
|
||||
|
||||
### Multiplayer Undo Semantics
|
||||
|
||||
Undo stacks are **per-user**. Your undo history doesn't include others' changes. This matches user expectations: Cmd+Z undoes *your* recent actions, not your collaborator's.
|
||||
|
||||
The system prunes invalid operations from your stack when entities are deleted by collaborators. If User B has "add edge to Block X" in their undo stack, but User A deletes Block X, that undo entry becomes invalid and is automatically removed since the target block no longer exists.
|
||||
|
||||
An interesting case: you add a block, someone else connects an edge to it, and then you undo your addition. The block disappears along with their edge (because of foreign key constraints). This is correct—your block no longer exists, so edges referencing it can't exist either. Both users see the block and edge vanish.
|
||||
|
||||
During execution, undo operations are marked in-progress to prevent circular recording—undoing shouldn't create a new undo entry for the inverse operation itself.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Building multiplayer workflow editing required rethinking assumptions about how workflow builders should work. By applying lessons from Figma's collaborative design tool to the domain of AI agent workflows, we created a system that feels fast, reliable, and natural for teams building together.
|
||||
|
||||
If you're building collaborative editing for structured data (not just text), consider:
|
||||
|
||||
- Whether OT/CRDT complexity is necessary for your conflict density
|
||||
- How to separate high-frequency value updates from structural changes
|
||||
- What guarantees your users need around data persistence and offline editing
|
||||
- Whether exposing operation status builds trust in the system
|
||||
|
||||
Multiplayer workflow building is no longer a technical curiosity—it's how teams should work together to build AI agents. And the infrastructure to make it reliable and fast is more approachable than you might think.
|
||||
|
||||
---
|
||||
|
||||
*Interested in how Sim's multiplayer system works in practice? [Try building a workflow](https://sim.ai) with a collaborator in real-time.*
|
||||
@@ -0,0 +1,63 @@
|
||||
---
|
||||
slug: series-a
|
||||
title: '$7M Series A'
|
||||
description: We’re excited to share that Sim has raised a $7M Series A led by Standard Capital to accelerate our vision for agentic workflows.
|
||||
date: 2025-11-12
|
||||
updated: 2025-11-12
|
||||
authors:
|
||||
- waleed
|
||||
- emir
|
||||
readingTime: 4
|
||||
tags: [Announcement, Funding, Series A, Sim, YCombinator]
|
||||
ogImage: /blog/series-a/cover.jpg
|
||||
ogAlt: 'Sim team photo in front of neon logo'
|
||||
about: ['Artificial Intelligence', 'Agentic Workflows', 'Startups', 'Funding']
|
||||
timeRequired: PT4M
|
||||
canonical: https://www.sim.ai/blog/series-a
|
||||
featured: true
|
||||
draft: false
|
||||
---
|
||||
|
||||
|
||||
|
||||
## Why we’re excited
|
||||
|
||||
Today we’re announcing our $7M Series A led by Standard Capital with participation from Perplexity Fund, SV Angel, YCombinator, and notable angels like Paul Graham, Paul Bucheit, Ali Rowghani, Kaz Nejatian, and many more.
|
||||
This investment helps us double‑down on our mission: make it simple for teams to build, ship, and scale agentic workflows in production.
|
||||
|
||||
## How we got here
|
||||
|
||||
We started earlier this year in our apartment in San Francisco.
|
||||
The goal was to rebuild our entire previous company (if you can call it that) from scratch on a visual framework.
|
||||
We figured that if we could at least build an AI sales and marketing operation solely using building blocks on a canvas, then anyone could build anything.
|
||||
Soon after, we'd built the foundation of what would become Sim.
|
||||
We were hellbent on being Open Source from day one, and we're proud that we've stuck to that commitment.
|
||||
|
||||
## Progress so far
|
||||
|
||||
In just a short few months, Sim has grown from 0->18k Github stars, 60,000+ developers on the platform, and 100+ companies ranging from startups to large enterprises using Sim in production.
|
||||
We've processed over 10M+ workflows and are growing rapidly.
|
||||
We've built a stellar team of engineers who are passionate about building the future of agentic workflows.
|
||||
|
||||
## Our vision
|
||||
|
||||
We believe the next wave of software is agentic.
|
||||
Teams will compose specialized agents that reason, retrieve, and act—safely and reliably—across their business.
|
||||
Our focus is to provide the infrastructure and UX that make this practical at scale: from prototyping to production, from single‑agent flows to complex multi‑agent systems.
|
||||
|
||||
On one end of the spectrum, there are SDKs and frameworks that are complex and require a lot of code to build and manage, and on the other end of the spectrum, there are platforms that are easy to use but severely limit in what you can build.
|
||||
Sim offers a platform that is both easy to use and powerful enough to build complex agentic workflows.
|
||||
|
||||
If you strip away the applications, workflows are all that's left. They're the foundation of the software industry, and they're the foundation of the future powered by Sim.
|
||||
|
||||
## What’s next
|
||||
|
||||
We’ll invest in building the community around Sim, and we'll continue to be relentlessly focused on building the best platform for agentic workflows.
|
||||
|
||||
## We’re hiring
|
||||
|
||||
If you’re excited about agentic systems and want to help define the future of this space, we’d love to talk. We’re hiring across engineering, engineering, and more engineering. Oh, and design. [Apply here](https://sim.ai/careers)
|
||||
|
||||
— Team Sim
|
||||
|
||||
|
||||
@@ -0,0 +1 @@
|
||||
export { DiffControlsDemo } from './components/diff-controls-demo'
|
||||
@@ -0,0 +1,111 @@
|
||||
'use client'
|
||||
|
||||
import { useState } from 'react'
|
||||
|
||||
export function DiffControlsDemo() {
|
||||
const [rejectHover, setRejectHover] = useState(false)
|
||||
const [acceptHover, setAcceptHover] = useState(false)
|
||||
|
||||
return (
|
||||
<div style={{ display: 'flex', justifyContent: 'center', margin: '24px 0' }}>
|
||||
<div
|
||||
style={{
|
||||
position: 'relative',
|
||||
display: 'flex',
|
||||
height: '30px',
|
||||
overflow: 'hidden',
|
||||
borderRadius: '4px',
|
||||
isolation: 'isolate',
|
||||
}}
|
||||
>
|
||||
{/* Reject button */}
|
||||
<button
|
||||
onClick={() => {}}
|
||||
onMouseEnter={() => setRejectHover(true)}
|
||||
onMouseLeave={() => setRejectHover(false)}
|
||||
title='Reject changes'
|
||||
style={{
|
||||
position: 'relative',
|
||||
display: 'flex',
|
||||
height: '100%',
|
||||
alignItems: 'center',
|
||||
border: '1px solid #e0e0e0',
|
||||
backgroundColor: rejectHover ? '#f0f0f0' : '#f5f5f5',
|
||||
paddingRight: '20px',
|
||||
paddingLeft: '12px',
|
||||
fontWeight: 500,
|
||||
fontSize: '13px',
|
||||
color: rejectHover ? '#2d2d2d' : '#404040',
|
||||
clipPath: 'polygon(0 0, calc(100% + 10px) 0, 100% 100%, 0 100%)',
|
||||
borderRadius: '4px 0 0 4px',
|
||||
cursor: 'default',
|
||||
transition: 'color 150ms, background-color 150ms, border-color 150ms',
|
||||
}}
|
||||
>
|
||||
Reject
|
||||
</button>
|
||||
{/* Slanted divider - split gray/green */}
|
||||
<div
|
||||
style={{
|
||||
pointerEvents: 'none',
|
||||
position: 'absolute',
|
||||
top: 0,
|
||||
bottom: 0,
|
||||
left: '66px',
|
||||
width: '2px',
|
||||
transform: 'skewX(-18.4deg)',
|
||||
background: 'linear-gradient(to right, #e0e0e0 50%, #238458 50%)',
|
||||
zIndex: 10,
|
||||
}}
|
||||
/>
|
||||
{/* Accept button */}
|
||||
<button
|
||||
onClick={() => {}}
|
||||
onMouseEnter={() => setAcceptHover(true)}
|
||||
onMouseLeave={() => setAcceptHover(false)}
|
||||
title='Accept changes (⇧⌘⏎)'
|
||||
style={{
|
||||
position: 'relative',
|
||||
display: 'flex',
|
||||
height: '100%',
|
||||
alignItems: 'center',
|
||||
border: '1px solid rgba(0, 0, 0, 0.15)',
|
||||
backgroundColor: '#33C482',
|
||||
paddingRight: '12px',
|
||||
paddingLeft: '20px',
|
||||
fontWeight: 500,
|
||||
fontSize: '13px',
|
||||
color: '#ffffff',
|
||||
clipPath: 'polygon(10px 0, 100% 0, 100% 100%, 0 100%)',
|
||||
borderRadius: '0 4px 4px 0',
|
||||
marginLeft: '-10px',
|
||||
cursor: 'default',
|
||||
filter: acceptHover ? 'brightness(1.1)' : undefined,
|
||||
transition: 'background-color 150ms, border-color 150ms',
|
||||
}}
|
||||
>
|
||||
Accept
|
||||
<kbd
|
||||
style={{
|
||||
marginLeft: '8px',
|
||||
borderRadius: '4px',
|
||||
border: '1px solid rgba(255, 255, 255, 0.2)',
|
||||
backgroundColor: 'rgba(255, 255, 255, 0.1)',
|
||||
paddingLeft: '6px',
|
||||
paddingRight: '6px',
|
||||
paddingTop: '2px',
|
||||
paddingBottom: '2px',
|
||||
fontWeight: 500,
|
||||
fontFamily:
|
||||
'ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"',
|
||||
fontSize: '10px',
|
||||
color: '#ffffff',
|
||||
}}
|
||||
>
|
||||
⇧⌘<span style={{ display: 'inline-block', transform: 'translateY(-1px)' }}>⏎</span>
|
||||
</kbd>
|
||||
</button>
|
||||
</div>
|
||||
</div>
|
||||
)
|
||||
}
|
||||
@@ -0,0 +1,204 @@
|
||||
---
|
||||
slug: v0-5
|
||||
title: 'Introducing Sim v0.5'
|
||||
description: 'This new release brings a state of the art Copilot, seamless MCP server and tool deployment, 100+ integrations with 300+ tools, comprehensive execution logs, and realtime collaboration—built for teams shipping AI agents in production.'
|
||||
date: 2026-01-22
|
||||
updated: 2026-01-22
|
||||
authors:
|
||||
- waleed
|
||||
readingTime: 8
|
||||
tags: [Release, Copilot, MCP, Observability, Collaboration, Integrations, Sim]
|
||||
ogImage: /blog/v0-5/cover.jpg
|
||||
ogAlt: 'Sim v0.5 release announcement'
|
||||
about: ['AI Agents', 'Workflow Automation', 'Developer Tools']
|
||||
timeRequired: PT8M
|
||||
canonical: https://www.sim.ai/blog/v0-5
|
||||
featured: true
|
||||
draft: false
|
||||
---
|
||||
|
||||
**Sim v0.5** is the next evolution of our agent workflow platform—built for teams shipping AI agents to production.
|
||||
|
||||
## Copilot
|
||||
|
||||
|
||||
|
||||
Copilot is a context-aware assistant embedded in the Sim editor. Unlike general-purpose AI assistants, Copilot has direct access to your workspace: workflows, block configurations, execution logs, connected credentials, and documentation. It can also search the web to pull in external context when needed.
|
||||
|
||||
Your workspace is indexed for hybrid retrieval. When you ask a question, Copilot queries this index to ground its responses in your actual workflow state. Ask "why did my workflow fail at 3am?" and it retrieves the relevant execution trace, identifies the error, and explains what happened.
|
||||
|
||||
Copilot supports slash commands that trigger specialized capabilities:
|
||||
|
||||
- `/fast` — uses a faster model for quick responses when you need speed over depth
|
||||
- `/research` — performs multi-step web research on a topic, synthesizing results from multiple sources
|
||||
- `/actions` — lets Copilot directly use your connected integrations as tools, like reading your Gmail, sending Slack messages, or querying your database—all outside the context of a workflow
|
||||
- `/search` — searches the web for relevant information
|
||||
- `/read` — reads and extracts content from a URL
|
||||
- `/scrape` — scrapes structured data from web pages
|
||||
- `/crawl` — crawls multiple pages from a website to gather comprehensive information
|
||||
|
||||
Use `@` commands to pull specific context into your conversation. `@block` references a specific block's configuration and recent outputs. `@workflow` includes the full workflow structure. `@logs` pulls in recent execution traces. This lets you ask targeted questions like "why is `@Slack1` returning an error?" and Copilot has the exact context it needs to diagnose the issue.
|
||||
|
||||
For complex tasks, Copilot uses subagents—breaking requests into discrete operations and executing them sequentially. Ask it to "add error handling to this workflow" and it will analyze your blocks, determine where failures could occur, add appropriate condition blocks, and wire up notification paths. Each change surfaces as a diff for your review before applying.
|
||||
|
||||
<DiffControlsDemo />
|
||||
|
||||
## MCP Deployment
|
||||
|
||||
|
||||
|
||||
Deploy any workflow as an [MCP](https://modelcontextprotocol.io) server. Once deployed, the workflow becomes a callable tool for any MCP-compatible agent—[Claude Desktop](https://claude.ai/download), [Cursor](https://cursor.com), or your own applications.
|
||||
|
||||
Sim generates a tool definition from your workflow: the name and description you specify, plus a JSON schema derived from your Start block's input format. The MCP server uses Streamable HTTP transport, so agents connect via a single URL. Authentication is handled via API key headers or public access, depending on your configuration.
|
||||
|
||||
Consider a lead enrichment workflow: it queries Apollo for contact data, checks Salesforce for existing records, formats the output, and posts a summary to Slack. That's 8 blocks in Sim. Deploy it as MCP, and any agent can call `enrich_lead("jane@acme.com")` and receive structured data back. The agent treats it as a single tool call—it doesn't need to know about Apollo, Salesforce, or Slack.
|
||||
|
||||
This pattern scales to research pipelines, data processing workflows, approval chains, and internal tooling. Anything you build in Sim becomes a tool any agent can invoke.
|
||||
|
||||
## Logs & Dashboard
|
||||
|
||||
|
||||
|
||||
Every workflow execution generates a full trace. Each block records its start time, end time, inputs, outputs, and any errors. For LLM blocks, we capture prompt tokens, completion tokens, and cost by model.
|
||||
|
||||
The dashboard aggregates this data into queryable views:
|
||||
|
||||
- **Trace spans**: Hierarchical view of block executions with timing waterfall
|
||||
- **Cost attribution**: Token usage and spend broken down by model per execution
|
||||
- **Error context**: Full stack traces with the block, input values, and failure reason
|
||||
- **Filtering**: Query by time range, trigger type, workflow, or status
|
||||
- **Execution snapshots**: Each run captures the workflow state at execution time—restore to see exactly what was running
|
||||
|
||||
This level of observability is necessary when workflows handle production traffic—sending customer emails, processing payments, or making API calls on behalf of users.
|
||||
|
||||
## Realtime Collaboration
|
||||
|
||||
|
||||
|
||||
Multiple users can edit the same workflow simultaneously. Changes propagate in real time—you see teammates' cursors, block additions, and configuration updates as they happen.
|
||||
|
||||
The editor now supports full undo/redo history (Cmd+Z / Cmd+Shift+Z), so you can step back through changes without losing work. Copy and paste works for individual blocks, groups of blocks, or entire subflows—select what you need, Cmd+C, and paste into the same workflow or a different one. This makes it easy to duplicate patterns, share components across workflows, or quickly prototype variations.
|
||||
|
||||
This is particularly useful during development sessions where engineers, product managers, and domain experts need to iterate together. Everyone works on the same workflow state, and changes sync immediately across all connected clients.
|
||||
|
||||
## Versioning
|
||||
|
||||
|
||||
|
||||
Every deployment creates a new version. The version history shows who deployed what and when, with a preview of the workflow state at that point in time. Roll back to any previous version with one click—the live deployment updates immediately.
|
||||
|
||||
This matters when something breaks in production. You can instantly revert to the last known good version while you debug, rather than scrambling to fix forward. It also provides a clear audit trail: you can see exactly what changed between versions and who made the change.
|
||||
|
||||
---
|
||||
|
||||
## 100+ Integrations
|
||||
|
||||
|
||||
|
||||
v0.5 adds **100+ integrations** with **300+ actions**. These cover the specific operations you need—not just generic CRUD, but actions like "send Slack message to channel," "create Jira ticket with custom fields," "query Postgres with parameterized SQL," or "enrich contact via Apollo."
|
||||
|
||||
- **CRMs & Sales**: Salesforce, HubSpot, Pipedrive, Apollo, Wealthbox
|
||||
- **Communication**: Slack, Discord, Microsoft Teams, Telegram, WhatsApp, Twilio
|
||||
- **Productivity**: Notion, Confluence, Google Workspace, Microsoft 365, Airtable, Asana, Trello
|
||||
- **Developer Tools**: GitHub, GitLab, Jira, Linear, Sentry, Datadog, Grafana
|
||||
- **Databases**: PostgreSQL, MySQL, MongoDB, [Supabase](https://supabase.com), DynamoDB, Elasticsearch, [Pinecone](https://pinecone.io), [Qdrant](https://qdrant.tech), Neo4j
|
||||
- **Finance**: Stripe, Kalshi, Polymarket
|
||||
- **Web & Search**: [Firecrawl](https://firecrawl.dev), [Exa](https://exa.ai), [Tavily](https://tavily.com), [Jina](https://jina.ai), [Serper](https://serper.dev)
|
||||
- **Cloud**: AWS (S3, RDS, SQS, Textract, Bedrock), [Browser Use](https://browser-use.com), [Stagehand](https://github.com/browserbase/stagehand)
|
||||
|
||||
Each integration handles OAuth or API key authentication. Connect once, and the credentials are available across all workflows in your workspace.
|
||||
|
||||
---
|
||||
|
||||
## Triggers
|
||||
|
||||
Workflows can be triggered through multiple mechanisms:
|
||||
|
||||
**Webhooks**: Sim provisions a unique HTTPS endpoint for each workflow. Incoming POST requests are parsed and passed to the first block as input. Supports standard webhook patterns including signature verification for services that provide it.
|
||||
|
||||
**Schedules**: Cron-based scheduling with timezone support. Use the visual scheduler or write expressions directly. Execution locks prevent overlapping runs.
|
||||
|
||||
**Chat**: Deploy workflows as conversational interfaces. Messages stream to your workflow, responses stream back to the user. Supports multi-turn context.
|
||||
|
||||
**API**: REST endpoint with your workflow's input schema. Call it from any system that can make HTTP requests.
|
||||
|
||||
**Integration triggers**: Event-driven triggers for specific services—GitHub (PR opened, issue created, push), Stripe (payment succeeded, subscription updated), TypeForm (form submitted), RSS (new item), and more.
|
||||
|
||||
**Forms**: Coming soon—build custom input forms that trigger workflows directly.
|
||||
|
||||
---
|
||||
|
||||
## Knowledge Base
|
||||
|
||||
|
||||
|
||||
Upload documents—PDFs, text files, markdown, HTML—and make them queryable by your agents. This is [RAG](https://en.wikipedia.org/wiki/Retrieval-augmented_generation) (Retrieval Augmented Generation) built directly into Sim.
|
||||
|
||||
Documents are chunked, embedded, and indexed using hybrid search ([BM25](https://en.wikipedia.org/wiki/Okapi_BM25) + vector embeddings). Agent blocks can query the knowledge base as a tool, retrieving relevant passages based on semantic similarity and keyword matching. When documents are updated, they re-index automatically.
|
||||
|
||||
Use cases:
|
||||
|
||||
- **Customer support agents** that reference your help docs and troubleshooting guides to resolve tickets
|
||||
- **Sales assistants** that pull from product specs, pricing sheets, and competitive intel
|
||||
- **Internal Q&A bots** that answer questions about company policies, HR docs, or engineering runbooks
|
||||
- **Research workflows** that synthesize information from uploaded papers, reports, or data exports
|
||||
|
||||
---
|
||||
|
||||
## New Blocks
|
||||
|
||||
### Human in the Loop
|
||||
|
||||
Pause workflow execution pending human approval. The block sends a notification (email, Slack, or webhook) with approve/reject actions. Execution resumes only on approval—useful for high-stakes operations like customer-facing emails, financial transactions, or content publishing.
|
||||
|
||||
### Agent Block
|
||||
|
||||
The Agent block now supports three additional tool types:
|
||||
|
||||
- **Workflows as tools**: Agents can invoke other Sim workflows, enabling hierarchical architectures where a coordinator agent delegates to specialized sub-workflows
|
||||
- **Knowledge base queries**: Agents search your indexed documents directly, retrieving relevant context for their responses
|
||||
- **Custom functions**: Execute JavaScript or Python code in isolated sandboxes with configurable timeout and memory limits
|
||||
|
||||
### Subflows
|
||||
|
||||
Group blocks into collapsible subflows. Use them for loops (iterate over arrays), parallel execution (run branches concurrently), or logical organization. Subflows can be nested and keep complex workflows manageable.
|
||||
|
||||
### Router
|
||||
|
||||
Conditional branching based on data or LLM classification. Define rules or let the router use an LLM to determine intent and select the appropriate path.
|
||||
|
||||
The router now exposes its reasoning in execution logs—when debugging unexpected routing, you can see exactly why a particular branch was selected.
|
||||
|
||||
---
|
||||
|
||||
## Model Providers
|
||||
|
||||
Sim supports 14 providers: [OpenAI](https://openai.com), [Anthropic](https://anthropic.com), [Google](https://ai.google.dev), [Azure OpenAI](https://azure.microsoft.com/en-us/products/ai-services/openai-service), [xAI](https://x.ai), [Mistral](https://mistral.ai), [Deepseek](https://deepseek.com), [Groq](https://groq.com), [Cerebras](https://cerebras.ai), [Ollama](https://ollama.com), and [OpenRouter](https://openrouter.ai).
|
||||
|
||||
New in v0.5:
|
||||
|
||||
- **[AWS Bedrock](https://aws.amazon.com/bedrock)**: Claude, Nova, Llama, Mistral, and Cohere models via your AWS account
|
||||
- **[Google Vertex AI](https://cloud.google.com/vertex-ai)**: Gemini models through Google Cloud
|
||||
- **[vLLM](https://github.com/vllm-project/vllm)**: Self-hosted models on your own infrastructure
|
||||
|
||||
Model selection is per-block, so you can use faster/cheaper models for simple tasks and more capable models where needed.
|
||||
|
||||
---
|
||||
|
||||
## Developer Experience
|
||||
|
||||
**Custom Tools**: Define your own integrations with custom HTTP endpoints, authentication (API key, OAuth, Bearer token), and request/response schemas. Custom tools appear in the block palette alongside built-in integrations.
|
||||
|
||||
**Environment Variables**: Encrypted key-value storage for secrets and configuration. Variables are decrypted at runtime and can be referenced in any block configuration.
|
||||
|
||||
**Import/Export**: Export workflows or entire workspaces as JSON. Imports preserve all blocks, connections, configurations, and variable references.
|
||||
|
||||
**File Manager**: Upload files to your workspace for use in workflows—templates, seed data, static assets. Files are accessible via internal references or presigned URLs.
|
||||
|
||||
---
|
||||
|
||||
## Get Started
|
||||
|
||||
Available now at [sim.ai](https://sim.ai). Check out the [docs](https://docs.sim.ai) to dive deeper.
|
||||
|
||||
*Questions? [help@sim.ai](mailto:help@sim.ai) · [Discord](https://sim.ai/discord)*
|
||||
Reference in New Issue
Block a user