From 1c15440e1f04437b9eba4f0df3c9c5a8e49e02ce Mon Sep 17 00:00:00 2001 From: Waleed Latif Date: Tue, 13 Oct 2026 15:16:34 -0700 Subject: [PATCH] chore(docs): remove the academy --- apps/docs/app/[[...slug]]/page.tsx | 19 +- .../components/docs-layout/docs-sidebar.tsx | 1 - apps/docs/components/footer/footer.tsx | 3 +- apps/docs/components/navbar/navbar.tsx | 10 +- apps/docs/components/ui/video-chapters.tsx | 73 --- apps/docs/components/ui/video-placeholder.tsx | 221 -------- .../components/ui/what-you-will-learn.tsx | 33 -- .../academy-video-workflows.ts | 504 ------------------ .../content/docs/academy/agents/block.mdx | 86 --- .../content/docs/academy/agents/intro.mdx | 93 ---- .../content/docs/academy/agents/memory.mdx | 91 ---- .../content/docs/academy/agents/skills.mdx | 85 --- .../docs/academy/agents/tool-calling.mdx | 85 --- .../content/docs/academy/chat/building.mdx | 90 ---- apps/docs/content/docs/academy/chat/intro.mdx | 89 ---- .../docs/content/docs/academy/files/intro.mdx | 86 --- .../content/docs/academy/files/object.mdx | 82 --- apps/docs/content/docs/academy/index.mdx | 53 -- .../academy/knowledge-bases/connectors.mdx | 75 --- .../docs/academy/knowledge-bases/intro.mdx | 92 ---- apps/docs/content/docs/academy/meta.json | 39 -- .../content/docs/academy/tables/intro.mdx | 89 ---- .../docs/academy/tables/operations.mdx | 83 --- .../docs/academy/tables/workflow-columns.mdx | 87 --- .../academy/use-cases/document-extraction.mdx | 29 - .../academy/use-cases/monitoring-research.mdx | 32 -- .../use-cases/sales-data-enrichment.mdx | 34 -- .../academy/use-cases/slack-it-triage.mdx | 31 -- .../docs/academy/workflows/branching.mdx | 84 --- .../docs/academy/workflows/deployment.mdx | 91 ---- .../content/docs/academy/workflows/intro.mdx | 93 ---- .../content/docs/academy/workflows/logs.mdx | 83 --- .../content/docs/academy/workflows/loops.mdx | 85 --- .../docs/academy/workflows/subworkflows.mdx | 82 --- apps/docs/lib/academy-captions.test.ts | 41 -- apps/docs/lib/redirects.ts | 1 + apps/docs/lib/utils.ts | 4 - .../captions/academy/agents-block.en.vtt | 119 ----- .../captions/academy/agents-intro.en.vtt | 89 ---- .../captions/academy/agents-memory.en.vtt | 116 ---- .../captions/academy/agents-skills.en.vtt | 85 --- .../academy/agents-tool-calling.en.vtt | 130 ----- .../captions/academy/chat-building.en.vtt | 81 --- .../public/captions/academy/chat-intro.en.vtt | 67 --- .../captions/academy/files-intro.en.vtt | 111 ---- .../captions/academy/files-object.en.vtt | 101 ---- .../captions/academy/kb-connectors.en.vtt | 111 ---- .../captions/academy/knowledge-bases.en.vtt | 120 ----- .../captions/academy/tables-operations.en.vtt | 91 ---- .../academy/tables-workflow-columns.en.vtt | 182 ------- .../public/captions/academy/tables.en.vtt | 92 ---- .../captions/academy/what-is-sim.en.vtt | 114 ---- .../academy/workflows-branching.en.vtt | 81 --- .../academy/workflows-deployments.en.vtt | 87 --- .../captions/academy/workflows-intro.en.vtt | 117 ---- .../captions/academy/workflows-logs.en.vtt | 74 --- .../captions/academy/workflows-loops.en.vtt | 78 --- .../academy/workflows-subworkflows.en.vtt | 69 --- .../best-ai-agents-for-slack/index.mdx | 4 +- .../sim/lib/compare/data/competitors/tines.ts | 2 +- apps/sim/lib/compare/data/sim.ts | 10 +- .../remote-sandbox/e2b-session.test.ts | 1 + apps/sim/next.config.ts | 8 +- scripts/README.md | 4 +- scripts/check-explicit-any.baseline.json | 1 - 65 files changed, 19 insertions(+), 4985 deletions(-) delete mode 100644 apps/docs/components/ui/video-chapters.tsx delete mode 100644 apps/docs/components/ui/video-placeholder.tsx delete mode 100644 apps/docs/components/ui/what-you-will-learn.tsx delete mode 100644 apps/docs/components/workflow-preview/academy-video-workflows.ts delete mode 100644 apps/docs/content/docs/academy/agents/block.mdx delete mode 100644 apps/docs/content/docs/academy/agents/intro.mdx delete mode 100644 apps/docs/content/docs/academy/agents/memory.mdx delete mode 100644 apps/docs/content/docs/academy/agents/skills.mdx delete mode 100644 apps/docs/content/docs/academy/agents/tool-calling.mdx delete mode 100644 apps/docs/content/docs/academy/chat/building.mdx delete mode 100644 apps/docs/content/docs/academy/chat/intro.mdx delete mode 100644 apps/docs/content/docs/academy/files/intro.mdx delete mode 100644 apps/docs/content/docs/academy/files/object.mdx delete mode 100644 apps/docs/content/docs/academy/index.mdx delete mode 100644 apps/docs/content/docs/academy/knowledge-bases/connectors.mdx delete mode 100644 apps/docs/content/docs/academy/knowledge-bases/intro.mdx delete mode 100644 apps/docs/content/docs/academy/meta.json delete mode 100644 apps/docs/content/docs/academy/tables/intro.mdx delete mode 100644 apps/docs/content/docs/academy/tables/operations.mdx delete mode 100644 apps/docs/content/docs/academy/tables/workflow-columns.mdx delete mode 100644 apps/docs/content/docs/academy/use-cases/document-extraction.mdx delete mode 100644 apps/docs/content/docs/academy/use-cases/monitoring-research.mdx delete mode 100644 apps/docs/content/docs/academy/use-cases/sales-data-enrichment.mdx delete mode 100644 apps/docs/content/docs/academy/use-cases/slack-it-triage.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/branching.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/deployment.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/intro.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/logs.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/loops.mdx delete mode 100644 apps/docs/content/docs/academy/workflows/subworkflows.mdx delete mode 100644 apps/docs/lib/academy-captions.test.ts delete mode 100644 apps/docs/public/captions/academy/agents-block.en.vtt delete mode 100644 apps/docs/public/captions/academy/agents-intro.en.vtt delete mode 100644 apps/docs/public/captions/academy/agents-memory.en.vtt delete mode 100644 apps/docs/public/captions/academy/agents-skills.en.vtt delete mode 100644 apps/docs/public/captions/academy/agents-tool-calling.en.vtt delete mode 100644 apps/docs/public/captions/academy/chat-building.en.vtt delete mode 100644 apps/docs/public/captions/academy/chat-intro.en.vtt delete mode 100644 apps/docs/public/captions/academy/files-intro.en.vtt delete mode 100644 apps/docs/public/captions/academy/files-object.en.vtt delete mode 100644 apps/docs/public/captions/academy/kb-connectors.en.vtt delete mode 100644 apps/docs/public/captions/academy/knowledge-bases.en.vtt delete mode 100644 apps/docs/public/captions/academy/tables-operations.en.vtt delete mode 100644 apps/docs/public/captions/academy/tables-workflow-columns.en.vtt delete mode 100644 apps/docs/public/captions/academy/tables.en.vtt delete mode 100644 apps/docs/public/captions/academy/what-is-sim.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-branching.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-deployments.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-intro.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-logs.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-loops.en.vtt delete mode 100644 apps/docs/public/captions/academy/workflows-subworkflows.en.vtt diff --git a/apps/docs/app/[[...slug]]/page.tsx b/apps/docs/app/[[...slug]]/page.tsx index 3ae36a2e477..3eccaa4d778 100644 --- a/apps/docs/app/[[...slug]]/page.tsx +++ b/apps/docs/app/[[...slug]]/page.tsx @@ -122,25 +122,14 @@ export default async function Page(props: { params: Promise<{ slug?: string[] }> } const isOpenAPI = '_openapi' in data && data._openapi != null const isApiReference = slug?.some((s) => s === 'api-reference') ?? false - // Academy lessons are video-first: drop the "On this page" TOC and go full - // width so the lesson hero/video gets the room (chapters live in-page instead). - const isAcademy = slug?.[0] === 'academy' const isCli = slug?.[0] === 'cli' const isMcp = slug?.[0] === 'mcp' const rawNeighbours = findNeighbour(source.pageTree, page.url) - // Academy, API Reference, CLI, and MCP are self-contained sections; keep prev/next + // API Reference, CLI, and MCP are self-contained sections; keep prev/next // inside the section instead of spilling into the main documentation tree. // Match both the section's pages (`//...`) and its index (`/`). - const sectionSlug = isApiReference - ? 'api-reference' - : isAcademy - ? 'academy' - : isCli - ? 'cli' - : isMcp - ? 'mcp' - : null + const sectionSlug = isApiReference ? 'api-reference' : isCli ? 'cli' : isMcp ? 'mcp' : null const inSection = (url?: string) => url != null && (url.includes(`/${sectionSlug}/`) || url.endsWith(`/${sectionSlug}`)) const neighbours = sectionSlug @@ -254,18 +243,16 @@ export default async function Page(props: { params: Promise<{ slug?: string[] }> role='main' tabIndex={-1} toc={data.toc.filter(isContentHeading)} - full={data.full || isAcademy} + full={data.full} breadcrumb={{ enabled: false, }} tableOfContent={{ style: 'clerk', - enabled: !isAcademy, single: false, }} tableOfContentPopover={{ style: 'clerk', - enabled: !isAcademy, }} footer={{ enabled: true, diff --git a/apps/docs/components/docs-layout/docs-sidebar.tsx b/apps/docs/components/docs-layout/docs-sidebar.tsx index c9d062c2e09..1c8b890b6c7 100644 --- a/apps/docs/components/docs-layout/docs-sidebar.tsx +++ b/apps/docs/components/docs-layout/docs-sidebar.tsx @@ -104,7 +104,6 @@ export function DocsSidebar() { ['API Reference', '/api-reference/getting-started'], ['CLI', '/cli'], ['MCP', '/mcp/overview'], - ['Academy', '/academy'], ].map(([label, href]) => ( setOpen(false)}> {label} diff --git a/apps/docs/components/footer/footer.tsx b/apps/docs/components/footer/footer.tsx index 8ed44b21d40..7add64f6597 100644 --- a/apps/docs/components/footer/footer.tsx +++ b/apps/docs/components/footer/footer.tsx @@ -8,7 +8,7 @@ import { SIM_SITE_URL } from '@/lib/urls' * footer (`apps/sim/app/(landing)/components/footer`), ported here so both * apps share one consistent footer. Links that live on sim.ai are absolute * (docs.sim.ai is a different origin); links that live on docs.sim.ai itself - * (Academy, API Reference, blocks, integrations guides, …) stay relative. + * (API Reference, blocks, integrations guides, …) stay relative. */ const LINK_CLASS = @@ -34,7 +34,6 @@ const PRODUCT_LINKS: FooterItem[] = [ const RESOURCES_LINKS: FooterItem[] = [ { label: 'Blog', href: `${SIM_SITE_URL}/blog`, external: true }, - { label: 'Academy', href: '/academy' }, { label: 'Compare', href: `${SIM_SITE_URL}/comparison`, external: true }, { label: 'Careers', href: `${SIM_SITE_URL}/careers`, external: true }, { label: 'Changelog', href: `${SIM_SITE_URL}/changelog`, external: true }, diff --git a/apps/docs/components/navbar/navbar.tsx b/apps/docs/components/navbar/navbar.tsx index ce61485d0ea..e918b9983ed 100644 --- a/apps/docs/components/navbar/navbar.tsx +++ b/apps/docs/components/navbar/navbar.tsx @@ -11,10 +11,10 @@ import { cn } from '@/lib/utils' /** * Sections that own a tab, in reading order: the main docs, then the three - * reference surfaces, then Academy. `Documentation` matches by exclusion, so + * reference surfaces. `Documentation` matches by exclusion, so * every section listed here is one it must not claim. */ -const SECTION_TABS = ['api-reference', 'academy', 'cli', 'mcp'] as const +const SECTION_TABS = ['api-reference', 'cli', 'mcp'] as const /** * Whether a pathname is inside a section, matched on its first path segment. @@ -51,12 +51,6 @@ const NAV_TABS = [ match: (p: string) => isInSection(p, 'mcp'), external: false, }, - { - label: 'Academy', - href: '/academy', - match: (p: string) => isInSection(p, 'academy'), - external: false, - }, ] as const export function Navbar() { diff --git a/apps/docs/components/ui/video-chapters.tsx b/apps/docs/components/ui/video-chapters.tsx deleted file mode 100644 index 4d8850dd50d..00000000000 --- a/apps/docs/components/ui/video-chapters.tsx +++ /dev/null @@ -1,73 +0,0 @@ -'use client' - -import { useEffect, useState } from 'react' -import { cn } from '@/lib/utils' - -/** Parse a chapter timestamp ("M:SS" or "H:MM:SS") into seconds. */ -function parseTime(time: string): number { - const parts = time.split(':').map(Number) - if (parts.some(Number.isNaN)) return 0 - return parts.reduce((acc, n) => acc * 60 + n, 0) -} - -interface Chapter { - /** Chapter label. */ - title: string - /** Timestamp, e.g. "0:45". */ - time?: string -} - -interface VideoChaptersProps { - /** Panel heading. Defaults to "Chapters". */ - title?: string - chapters: Chapter[] - className?: string -} - -/** - * Right-rail list of the current video's chapters — flat and borderless to - * match the docs' "On this page" TOC (small muted label, hover-highlighted - * rows). Rows are skip-to controls; they activate once the lesson's video is - * recorded. - */ -export function VideoChapters({ title = 'Chapters', chapters, className }: VideoChaptersProps) { - // Chapters only seek when a VideoPlaceholder with a real video is on the page. - // Handshake so the rows stay inert (not falsely clickable) on video-less lessons. - const [hasVideo, setHasVideo] = useState(false) - useEffect(() => { - const onReady = () => setHasVideo(true) - window.addEventListener('academy:video-ready', onReady) - window.dispatchEvent(new Event('academy:video-query')) - return () => window.removeEventListener('academy:video-ready', onReady) - }, []) - - return ( - - ) -} diff --git a/apps/docs/components/ui/video-placeholder.tsx b/apps/docs/components/ui/video-placeholder.tsx deleted file mode 100644 index 3490e13ca0f..00000000000 --- a/apps/docs/components/ui/video-placeholder.tsx +++ /dev/null @@ -1,221 +0,0 @@ -'use client' - -import { useEffect, useRef, useState } from 'react' -import { cn, getAssetUrl } from '@/lib/utils' - -interface VideoPlaceholderProps { - /** Large title shown on the hero. */ - title?: string - /** Small italic eyebrow above the title, e.g. a module name. */ - eyebrow?: string - /** Pill in the top-right corner. Defaults to "Coming soon" (shown only until a video is set). */ - label?: string - /** - * Self-hosted video source. Accepts an absolute URL, a root-relative path - * (`/static/...`), or a bare asset name resolved through the Blob CDN. When - * set, the play button loads the video; otherwise the card is "coming soon". - */ - src?: string - /** Same-origin WebVTT captions, generated from the lesson narration. */ - captionsSrc?: string - className?: string -} - -/** Resolve a video source: pass absolute/root-relative through, send bare names to the Blob CDN. */ -function resolveVideoSrc(src: string): string { - if (/^https?:\/\//.test(src) || src.startsWith('/')) return src - return getAssetUrl(src) -} - -/** The sim logotype, drawn with currentColor so the theme can tint it. */ -function SimWordmark({ className }: { className?: string }) { - return ( - - - - - - - ) -} - -/** - * A 16:9 lesson hero used across the Academy. Always shows the design-system - * video card (title, blueprint grid, theme-aware dark/light). When a `src` is - * provided the play button loads the self-hosted video inline; otherwise the - * card reads "Coming soon" and the play button is muted. - */ -export function VideoPlaceholder({ - title, - eyebrow, - label = 'Coming soon', - src, - captionsSrc, - className, -}: VideoPlaceholderProps) { - const hasVideo = Boolean(src) - const [playing, setPlaying] = useState(false) - const videoRef = useRef(null) - const pendingSeek = useRef(null) - - // Chapter rows (VideoChapters) dispatch `academy:seek` with a time in seconds. - // Start the video if it isn't playing yet, then jump there. We also announce - // that a video exists (and answer a chapters-side query) so the chapter rows - // only become interactive when there's actually something to seek. - useEffect(() => { - if (!src) return - const onSeek = (e: Event) => { - const time = (e as CustomEvent<{ time: number }>).detail?.time - if (typeof time !== 'number') return - const video = videoRef.current - if (video) { - video.currentTime = time - void video.play() - } else { - pendingSeek.current = time - setPlaying(true) - } - } - const announce = () => window.dispatchEvent(new Event('academy:video-ready')) - window.addEventListener('academy:seek', onSeek) - window.addEventListener('academy:video-query', announce) - announce() - return () => { - window.removeEventListener('academy:seek', onSeek) - window.removeEventListener('academy:video-query', announce) - } - }, [src]) - - useEffect(() => { - if (playing) videoRef.current?.focus() - }, [playing]) - - if (playing && src) { - return ( -
- -
- ) - } - - return ( -
- {/* Blueprint grid — faint, fading to atmosphere at the edges */} -
- - {/* Corner plus-marks, 20px inset */} - {['top-5 left-5', 'top-5 right-5', 'bottom-5 left-5', 'right-5 bottom-5'].map((pos) => ( - - + - - ))} - - {/* Top-right status pill — only until a video is wired up */} - {!hasVideo && ( - - - {label} - - )} - - {/* Heading: eyebrow + title, bottom-left (design: left:40 bottom:40) */} -
- {eyebrow && ( - - {eyebrow} - - )} - {title && ( - - {title} - - )} -
- - {/* Wordmark, bottom-right (design: right:40 bottom:40, svg height 22) */} - - - - - {/* Centered play button — active when a video is wired, muted otherwise */} -
- {hasVideo ? ( - - ) : ( - - - - - - )} -
-
- ) -} diff --git a/apps/docs/components/ui/what-you-will-learn.tsx b/apps/docs/components/ui/what-you-will-learn.tsx deleted file mode 100644 index c6439288b4d..00000000000 --- a/apps/docs/components/ui/what-you-will-learn.tsx +++ /dev/null @@ -1,33 +0,0 @@ -import { cn } from '@/lib/utils' - -interface LearnItem { - title: string - body: string -} - -interface WhatYouWillLearnProps { - items: LearnItem[] - className?: string -} - -/** - * "What you will learn" — a flat callout matching the docs' flat/divider - * language. A quiet muted label (like the TOC heading) sits above the - * takeaways; dividers fall only between items, so the label reads as a marker - * rather than an underlined heading and never competes with the item titles. - */ -export function WhatYouWillLearn({ items, className }: WhatYouWillLearnProps) { - return ( -
-

What you will learn

-
- {items.map((item) => ( -
-

{item.title}

-

{item.body}

-
- ))} -
-
- ) -} diff --git a/apps/docs/components/workflow-preview/academy-video-workflows.ts b/apps/docs/components/workflow-preview/academy-video-workflows.ts deleted file mode 100644 index 2f28ffc4989..00000000000 --- a/apps/docs/components/workflow-preview/academy-video-workflows.ts +++ /dev/null @@ -1,504 +0,0 @@ -import type { PreviewWorkflow } from '@/components/workflow-preview/workflow-data' - -/** - * Workflows shown in the academy videos, reproduced block-for-block so each - * page's written supplement shows the same machine the video builds. Rows and - * operation labels match the videos (which match the block registry). - */ - -/** files/intro + files/object — the invoice intake machine. */ -export const AV_INVOICE_INTAKE_WORKFLOW: PreviewWorkflow = { - id: 'av-invoice-intake', - name: 'Invoice intake', - blocks: [ - { - id: 'gmailtrigger', - name: 'Gmail Email Trigger', - type: 'gmail', - typeLabel: 'Gmail', - isIntegration: true, - sentence: ['Run on Gmail Email Trigger'], - bgColor: '#E0E0E0', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Include Attachments', value: 'Enabled' }], - }, - { - id: 'file', - name: 'File', - type: 'file', - typeLabel: 'File', - sentence: ['Parse', { subBlockId: 'Files', noun: 'file' }], - bgColor: '#40916C', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Operation', value: 'Read' }, - { title: 'Files', value: '' }, - ], - }, - { - id: 'agent', - name: 'Agent', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ], - bgColor: '#33C482', - position: { x: 680, y: 0 }, - rows: [ - { title: 'Messages', value: 'Extract the invoice fields' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - { title: 'Files', value: '' }, - ], - }, - { - id: 'supabase', - name: 'Supabase', - type: 'supabase', - typeLabel: 'Supabase', - isIntegration: true, - sentence: ['Create a Row', 'in', { subBlockId: 'Table' }, 'with', { subBlockId: 'Data' }], - bgColor: '#1C1C1C', - position: { x: 1020, y: 0 }, - rows: [ - { title: 'Operation', value: 'Create a Row' }, - { title: 'Table', value: 'invoices' }, - { title: 'Data', value: '' }, - ], - }, - ], - edges: [ - { id: 'trigger-file', source: 'gmailtrigger', target: 'file' }, - { id: 'file-agent', source: 'file', target: 'agent' }, - { id: 'agent-supabase', source: 'agent', target: 'supabase' }, - ], -} - -/** agents/block — the Qualify agent the camera rides through. */ -export const AV_QUALIFY_WORKFLOW: PreviewWorkflow = { - id: 'av-qualify', - name: 'Qualify a lead', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Lead' }], - }, - { - id: 'qualify', - name: 'Qualify', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ], - bgColor: '#33C482', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Messages', value: 'Qualify this lead: ' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - ], - }, - { - id: 'response', - name: 'Response', - type: 'response', - typeLabel: 'Response', - sentence: ['Return', { subBlockId: 'Data', noun: 'response' }], - bgColor: '#2F55FF', - position: { x: 680, y: 0 }, - rows: [{ title: 'Data', value: '' }], - }, - ], - edges: [ - { id: 'start-qualify', source: 'start', target: 'qualify' }, - { id: 'qualify-response', source: 'qualify', target: 'response' }, - ], -} - -/** agents/memory — the Support agent with Memory set to Conversation. */ -export const AV_MEMORY_WORKFLOW: PreviewWorkflow = { - id: 'av-memory', - name: 'Support agent with memory', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Customer message' }], - }, - { - id: 'support', - name: 'Support', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ], - bgColor: '#33C482', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Messages', value: '' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - { title: 'Memory', value: 'Conversation · user-123' }, - ], - }, - ], - edges: [{ id: 'start-support', source: 'start', target: 'support' }], -} - -/** tables/operations — the Table block with a filtered query. */ -export const AV_TABLE_OPS_WORKFLOW: PreviewWorkflow = { - id: 'av-table-ops', - name: 'Query the tickets table', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Run' }], - }, - { - id: 'table', - name: 'Table 1', - type: 'table', - typeLabel: 'Table', - sentence: [ - 'Query rows from', - { subBlockId: 'Table', noun: 'table' }, - ', where', - { subBlockId: 'Filter Conditions' }, - ], - bgColor: '#10B981', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Operation', value: 'Query Rows' }, - { title: 'Table', value: 'tickets' }, - { title: 'Filter Conditions', value: 'priority equals high' }, - ], - }, - ], - edges: [{ id: 'start-table', source: 'start', target: 'table' }], -} - -/** agents/tool-calling — the Qualify agent with research tools attached. */ -export const AV_TOOLS_WORKFLOW: PreviewWorkflow = { - id: 'av-tools', - name: 'Qualify with tools', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Lead' }], - }, - { - id: 'qualify', - name: 'Qualify', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ', using', - { subBlockId: 'Tools' }, - ], - bgColor: '#33C482', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Messages', value: 'Qualify this lead: ' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - ], - tools: [ - { type: 'exa', name: 'Search', bgColor: '#1F40ED' }, - { type: 'github', name: 'GitHub', bgColor: '#181717' }, - { type: 'hubspot', name: 'CRM', bgColor: '#FF7A59' }, - ], - }, - { - id: 'response', - name: 'Response', - type: 'response', - typeLabel: 'Response', - sentence: ['Return', { subBlockId: 'Data', noun: 'response' }], - bgColor: '#2F55FF', - position: { x: 680, y: 0 }, - rows: [{ title: 'Data', value: '' }], - }, - ], - edges: [ - { id: 'start-qualify', source: 'start', target: 'qualify' }, - { id: 'qualify-response', source: 'qualify', target: 'response' }, - ], -} - -/** agents/skills — the same agent with a skill attached. */ -export const AV_SKILLS_WORKFLOW: PreviewWorkflow = { - id: 'av-skills', - name: 'Qualify with a skill', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 0 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Lead' }], - }, - { - id: 'qualify', - name: 'Qualify', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ', using', - { subBlockId: 'Tools' }, - ], - bgColor: '#33C482', - position: { x: 340, y: 0 }, - rows: [ - { title: 'Messages', value: 'Qualify this lead: ' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - { title: 'Skills', value: 'answer-with-citations' }, - ], - tools: [{ type: 'exa', name: 'Search', bgColor: '#1F40ED' }], - }, - ], - edges: [{ id: 'start-qualify', source: 'start', target: 'qualify' }], -} - -/** chat/intro — the support-desk workflow the chat operates. */ -export const AV_SUPPORT_DESK_WORKFLOW: PreviewWorkflow = { - id: 'av-support-desk', - name: 'support-desk', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 60 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Ticket' }], - }, - { - id: 'triage', - name: 'Triage', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ', using', - { subBlockId: 'Tools' }, - ], - bgColor: '#33C482', - position: { x: 320, y: 60 }, - rows: [ - { title: 'Messages', value: '' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - ], - tools: [{ type: 'knowledge', name: 'Help Center', bgColor: '#00B0B0' }], - }, - { - id: 'condition', - name: 'Urgent?', - type: 'condition', - typeLabel: 'Condition', - bgColor: '#FF752F', - position: { x: 660, y: 60 }, - rows: [], - branches: [ - { id: 'condition-if', label: 'If', value: '' }, - { id: 'condition-else', label: 'else' }, - ], - }, - { - id: 'escalate', - name: 'Escalate', - type: 'slack', - typeLabel: 'Slack', - isIntegration: true, - sentence: ['Send a message to', { subBlockId: 'Channel', noun: 'channel' }], - bgColor: '#611F69', - position: { x: 1000, y: -40 }, - rows: [{ title: 'Channel', value: '#support-urgent' }], - }, - { - id: 'reply', - name: 'Reply', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ], - bgColor: '#33C482', - position: { x: 1000, y: 160 }, - rows: [{ title: 'Messages', value: 'Draft the reply' }], - }, - { - id: 'log', - name: 'Log', - type: 'table', - typeLabel: 'Table', - sentence: ['Insert Row', { subBlockId: 'Table', noun: 'table' }], - bgColor: '#10B981', - position: { x: 1340, y: 60 }, - rows: [ - { title: 'Operation', value: 'Insert Row' }, - { title: 'Table', value: 'tickets' }, - ], - }, - ], - edges: [ - { id: 'start-triage', source: 'start', target: 'triage' }, - { id: 'triage-condition', source: 'triage', target: 'condition' }, - { - id: 'condition-escalate', - source: 'condition', - target: 'escalate', - sourceHandle: 'condition-if', - }, - { id: 'condition-reply', source: 'condition', target: 'reply', sourceHandle: 'condition-else' }, - { id: 'escalate-log', source: 'escalate', target: 'log' }, - { id: 'reply-log', source: 'reply', target: 'log' }, - ], -} - -/** chat/building — the content-agent the chat builds: candidates drafted in - * parallel, media generated, an evaluator scoring, results kept. */ -export const AV_CONTENT_AGENT_WORKFLOW: PreviewWorkflow = { - id: 'av-content-agent', - name: 'content-agent', - blocks: [ - { - id: 'start', - name: 'Start', - type: 'start_trigger', - typeLabel: 'Start', - sentence: ['Start the workflow', 'with', { subBlockId: 'Input' }], - bgColor: '#2FB3FF', - position: { x: 0, y: 95 }, - hideTargetHandle: true, - rows: [{ title: 'Input', value: 'Idea' }], - }, - { - id: 'candidates', - name: 'Candidates', - type: 'parallel', - typeLabel: 'Parallel', - bgColor: '#1D1C1A', - position: { x: 320, y: 30 }, - size: { width: 480, height: 300 }, - rows: [], - }, - { - id: 'writer', - name: 'Writer', - type: 'agent', - typeLabel: 'Agent', - sentence: [ - 'Prompt', - { subBlockId: 'Model', noun: 'model' }, - 'with', - { subBlockId: 'Messages' }, - ], - bgColor: '#33C482', - position: { x: 150, y: 64 }, - parentId: 'candidates', - rows: [ - { title: 'Messages', value: '' }, - { title: 'Model', value: 'claude-sonnet-4-6' }, - ], - }, - { - id: 'evaluator', - name: 'Evaluator', - type: 'evaluator', - typeLabel: 'Evaluator', - sentence: [ - 'Score', - { subBlockId: 'Content', noun: 'content' }, - 'against', - { subBlockId: 'Metrics', noun: 'metrics' }, - ], - bgColor: '#8B5CF6', - position: { x: 890, y: 95 }, - rows: [ - { title: 'Metrics', value: 'Voice · Hook' }, - { title: 'Content', value: '' }, - ], - }, - { - id: 'scores', - name: 'Scores', - type: 'table', - typeLabel: 'Table', - sentence: ['Insert Row', { subBlockId: 'Table', noun: 'table' }], - bgColor: '#10B981', - position: { x: 1230, y: 95 }, - rows: [ - { title: 'Operation', value: 'Insert Row' }, - { title: 'Table', value: 'scores' }, - ], - }, - ], - edges: [ - { id: 'start-candidates', source: 'start', target: 'candidates' }, - { - id: 'candidates-writer', - source: 'candidates', - target: 'writer', - sourceHandle: 'parallel-start-source', - }, - { id: 'candidates-evaluator', source: 'candidates', target: 'evaluator' }, - { id: 'evaluator-scores', source: 'evaluator', target: 'scores' }, - ], -} diff --git a/apps/docs/content/docs/academy/agents/block.mdx b/apps/docs/content/docs/academy/agents/block.mdx deleted file mode 100644 index 003abd49647..00000000000 --- a/apps/docs/content/docs/academy/agents/block.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: The Agent Block -description: "Inside the Agent block, a run becomes a conversation: a message stack the model reads, a swappable brain, and an output bundle every later block can use." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_QUALIFY_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -On the canvas, an Agent block looks like any other step: a run arrives at its input handle, and a result leaves on the other side. Inside, it's a conversation machine. This video follows the data in, station by station. - - - -
- - - -
- -Here is the workflow the video rides through: the Qualify agent between its input and its result: - - - -## What's inside the block - -Configure the **system message** with standing instructions, add any **user and assistant history**, and pass the newest **user message** through a connection tag. Choose the provider and model in the **Model** field. You can change the model without recreating the block. - -## What a run costs and returns - -When the run reaches the model, every message on the stack ships as input tokens; the reply streams back as output tokens. If tools are attached, the model can call them mid-run. Everything the run did, the content it wrote, the model that ran, the token bill, the tool calls, lands in the block's outputs, where any later block can read it. - -## Where it fits - -The Agent block runs a language model with the messages and tools you configure. A workflow can combine several Agent blocks with integrations and control-flow blocks. Other blocks, such as Router, can also use a model. - -." }, -]} /> - -## Related documentation - -- [Agent block](/workflows/blocks/agent) -- [Custom tools](/agents/custom-tools) diff --git a/apps/docs/content/docs/academy/agents/intro.mdx b/apps/docs/content/docs/academy/agents/intro.mdx deleted file mode 100644 index 26d4c3926e9..00000000000 --- a/apps/docs/content/docs/academy/agents/intro.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Agents -description: "An AI agent is a Sim workflow that uses Agent blocks: the reasoning engine you shape, parameterize, and compose into intelligent processes." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, CLASSIFY_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -In Sim, you build AI agents as **workflows that use the Agent block**. There's no separate "agent" object to learn: an AI agent *is* a workflow, and the Agent block is where it thinks. - - - -
- - - -
- -## An agent is a workflow - -The trigger, connections, and outputs work as described in [Workflows](/academy/workflows/intro). In this example, the Agent block classifies the incoming message: - - - -## Inside the Agent block - -The Agent block is **a chat with a model, spawned programmatically**. Picture a conversation in ChatGPT or Claude: the block's **Messages** parameter is exactly those messages, except you set them, you decide what instructions, context, and earlier outputs go in. The model reasons over that and returns a result the rest of the workflow can read. - -The Agent block is where it *thinks*, the reasoning engine of your agent. You design the blocks *around* it to shape how the agent processes data: what it reads before it reasons, what it does with the result after. - -## Tools and skills - -Two parameters extend the Agent block, and both fit the chat-box picture: - -- **Tools** are the functions and blocks the agent can decide to call while answering, search the web, send an email, run another workflow. They're the tool calls the model makes mid-response. -- **Skills** are prompt modules the model loads on demand, like a manual it looks up only when a task calls for it, instead of stuffing everything into every prompt. - -## Make a workflow agentic - -The clearest way to see an agent isn't to build one from nothing, it's to take a **deterministic workflow and let an agent into it**. Replace a fixed rule with an agent that *decides* the path (routing), or *augment* a step with real reasoning, or both. Same workflow, now with judgment in it. - -## Combining Agent blocks - -Use separate Agent blocks when steps need different instructions, tools, or models. For example, one block can classify a request and another can draft a reply. Use a [subworkflow](/academy/workflows/subworkflows) when several workflows need the same sequence. - - - -## Related documentation - -- [Agents overview](/agents) -- [Choosing a model](/agents/choosing) -- [Custom tools](/agents/custom-tools) -- [MCP](/agents/mcp) -- [Skills](/agents/skills) diff --git a/apps/docs/content/docs/academy/agents/memory.mdx b/apps/docs/content/docs/academy/agents/memory.mdx deleted file mode 100644 index f8908ae383e..00000000000 --- a/apps/docs/content/docs/academy/agents/memory.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Memory -description: "One setting gives an agent memory: a conversation ID under which every turn is kept, so the next run starts from the conversation so far." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_MEMORY_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -By default, an agent keeps nothing between runs: every conversation starts completely fresh. The Memory setting changes that: choose Conversation, give it a conversation ID, and the agent saves the conversation under that key. Later runs load history according to the memory mode and the model's context limits. - -When durable tool history is enabled for your workspace, that history also includes completed tool calls and their results or errors. The agent can remember what it did, such as looking up an order, even when the run failed before giving its final answer. See the [Agent block's memory settings](/workflows/blocks/agent#memory) for tool-history and retry behavior. - -Uploaded attachments stay linked to the message that included them. Memory stores file references; each later run reads the accessible files again and prepares them for the selected provider. Attachments follow the selected memory window and the source file's storage retention. A replay can include up to 20 attachment references; use a smaller memory window for longer file-heavy conversations. Files omitted by older versions of memory need to be attached again. - - - -
- - - -
- -Here is the agent from the video with Memory set on the block: - - - -## The same agent, with and without memory - -The video runs the same agent twice, side by side: once with no memory and once with the conversation ID. The same follow-up question arrives in both. Without the key, the agent starts from zero and has to ask for everything again; with it, the earlier conversation supplies the context needed to answer the follow-up. - -## When conversations grow - -Memory can also be a sliding window, keeping the most recent messages, or the most recent tokens, while the oldest quietly fall away. The stored transcript keeps every turn; the window controls how much of it rides into the model on each run. - -Tool exchanges stay together when history is selected. They do not each count as a message in a message window, but their contents still use input tokens. Large results may appear as previews, and history is not automatically summarized. A token window gives more direct control over recalled context than a message count; neither setting caps the total cost of a run that makes further model or tool calls. - -## When to use memory - -Enable memory when a follow-up needs earlier conversation context, such as a support ticket or sales conversation. Keep classification and extraction stateless when each input contains everything the task needs. - - - -## Related documentation - -- [Agent block](/workflows/blocks/agent) diff --git a/apps/docs/content/docs/academy/agents/skills.mdx b/apps/docs/content/docs/academy/agents/skills.mdx deleted file mode 100644 index 00fbefa0cc1..00000000000 --- a/apps/docs/content/docs/academy/agents/skills.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Skills -description: A skill is a written method the agent reads when it decides it's relevant, turning a vague guess into a sourced, repeatable procedure without crowding the prompt. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_SKILLS_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -A **skill** is a written procedure an agent can load when it is relevant to a task. This lesson compares the same research task with and without a skill that instructs the agent to find and cite sources. - - - -
- - - -
- -Here is the agent from the video with the skill attached: - - - -## The same run, with and without the skill - -The video runs the same lead-qualification task twice. Without a skill, the agent searches once and guesses: "probably Series B, maybe a hundred people." With Exa's `answer-with-citations` skill attached, it loads the method mid-run, turns each claim into a specific factual question, pulls a sourced answer for every one, and returns a verdict where each figure carries its citation. - -## Why not just a longer prompt? - -Skills keep procedure out of the prompt. Only the name and one-line description stay in view; the full method loads only when the agent judges it relevant: so you can attach many skills without bloating context, and the agent picks the right manual for the moment. - -## Ready to use - -Adding a skill is the same motion as adding a tool: pick it in the block's Skills section and it shows on the block. Choose an available skill or add one you have written; workspace skills can be reused by other agents. - - - -## Related documentation - -- [Skills](/agents/skills) -- [Custom tools](/agents/custom-tools) diff --git a/apps/docs/content/docs/academy/agents/tool-calling.mdx b/apps/docs/content/docs/academy/agents/tool-calling.mdx deleted file mode 100644 index 04d09253d37..00000000000 --- a/apps/docs/content/docs/academy/agents/tool-calling.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Tool Calling -description: Give an agent tools and it works in a loop, deciding, calling, reading results, and converging on an answer you can audit call-by-call in the logs. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_TOOLS_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -A plain Agent block is text in, one model pass, text out, it can't look anything up. Give it tools, and it starts working in a **loop**: deciding which tool it needs, calling it (several at once when it can), reading what comes back, and calling again with better arguments until it has enough to answer. - - - -
- - - -
- -Here is the agent from the video with its tools attached: - - - -## What tools change - -Without tools, an agent has only its prompt and its training, asked to qualify a lead, it can only say it has no way to look anything up. With tools attached, the same block plans: research the company, check the funding, read the careers page. It calls tools in parallel when the calls don't depend on each other, revises its plan as results land, and answers only when its context holds enough. - -## Configuring tools - -Add supported integration operations, workflows, or custom tools in the Agent block's **Tools** section. Set parameters that should stay fixed and let the model supply the remaining task-specific inputs. Custom tools define an input schema and a description; MCP connects external toolsets. - -## The audit trail - -Every agent run records its tool calls in order. Open the log and walk them: the name of each tool, the exact arguments the model chose, the result that returned into context. Debugging an agent is reading that sequence, not guessing at what the model was thinking. - - - -## Related documentation - -- [Custom tools](/agents/custom-tools) -- [MCP](/agents/mcp) -- [Logs & debugging](/logs-debugging) diff --git a/apps/docs/content/docs/academy/chat/building.mdx b/apps/docs/content/docs/academy/chat/building.mdx deleted file mode 100644 index b5adb9525cd..00000000000 --- a/apps/docs/content/docs/academy/chat/building.mdx +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Building with Chat -description: Describe the system you want in plain language, and Sim builds it, then tests it, debugs it, shows you the evidence, and deploys it, all inside one conversation. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_CONTENT_AGENT_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -You can build a whole workflow without dragging a single block. Describe the system you want: an agent that turns an idea into a finished post, with a draft, a hero image, a slide deck, and a voiceover, and Sim lays out every block, wired and parameterized, in front of you. - - - -
- - - -
- -## From description to blocks - -Sim turns your description into real structure: a parallel container drafting candidate posts, generation blocks for the image, the deck, and the voiceover, an evaluator scoring the results, and a table keeping every score. Nothing about the result is special, it's a normal workflow you could have built by hand, which means you can open it, read it, and change it. - -Here is the shape of the workflow Sim builds in the video, candidates drafted in parallel, an evaluator scoring them, and the scores kept in a table: - - - -## Test and inspect the workflow - -In the video, the first test fails because the image block is missing an aspect ratio. Sim reads the error, updates that parameter, and runs the workflow again. Ask Chat to test your workflow, then inspect the logs and outputs before deploying it. - -## Inspecting the run - -The run record shows every step with its timing and output: the draft, the image, the deck, the audio. When you test it on a real idea, the candidates fan out in parallel, the evaluator scores each one, and the table records what was promoted and what was pruned. - -## Deploying - -After testing the workflow, ask Chat to deploy it as an API endpoint. Review the deployment settings and test a request against the endpoint. The workflow remains editable in your workspace. - - - -## Related documentation - -- [Building workflows from Chat](/chat/workflows) -- [Deployment](/workflows/deployment) diff --git a/apps/docs/content/docs/academy/chat/intro.mdx b/apps/docs/content/docs/academy/chat/intro.mdx deleted file mode 100644 index abba743ff13..00000000000 --- a/apps/docs/content/docs/academy/chat/intro.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Chat -description: "Chat is your AI command center: one conversation that queries your tables, searches your docs, runs and schedules workflows, researches the outside world, and composes it all into new systems." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_SUPPORT_DESK_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -Chat can use the workflows, tables, knowledge bases, files, and integrations available to you in the workspace. Ask it to find information, run a workflow, or build a new one. - - - -
- - - -
- -## Work across workspace resources - -Name the resources you want Chat to use, such as a tickets table, help-center knowledge base, or support-desk workflow. Chat can combine information from those resources to answer a request. - -The video uses this support-desk workflow to triage a ticket, reply or escalate, and record the result: - - - -## Asking it to act - -Telling Sim to *do* something is the same motion as asking it something. Run the backlog through the support desk, ship the weekly digest, put it on a schedule for Friday mornings: each lands as a real operation, confirmed with a toast, with the run's log available the moment it finishes. - -## Research beyond the workspace - -Sim can research beyond your workspace: search X and Reddit for this week's conversations, pull the rising themes, and file them as a new document. What it learns becomes a resource like any other, ready for the next ask. - -## Composing a new workflow - -One sentence can compose what Sim just touched into a new workflow. A watcher that reads the trends file on a schedule, matches them against your tickets, and calls your support-desk workflow when something hits. You described it, and Sim assembled it from the resources you already have. - - - -## Related documentation - -- [Chat overview](/chat) -- [Operating workflows from Chat](/chat/workflows) -- [Research from Chat](/chat/research) diff --git a/apps/docs/content/docs/academy/files/intro.mdx b/apps/docs/content/docs/academy/files/intro.mdx deleted file mode 100644 index bca5dabeb1e..00000000000 --- a/apps/docs/content/docs/academy/files/intro.mdx +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Files -description: Sim natively supports files, store, reference, and pass around documents and media so workflows can read and produce real assets like PDFs, images, audio, and video. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_INVOICE_INTAKE_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -Sim has native support for **files**, a way to store, reference, and pass around documents, media, and generated outputs, so your workflows can read and produce real assets: PDFs, images, audio, video. - - - -
- - - -
- -## Read a document - -The video follows an email attachment through a File block and an Agent block, then writes the extracted fields to a database: - - - -## Files in and out - -Workflows **consume** files and **produce** them, and hand them between blocks like any other value. A file goes in, a block reads it; a block creates one, the next step uses it. - -## What you can build - -The point isn't a new concept to learn, it's recognizing that the file-based operations you already picture are supported here: - -- Attach a generated report to an email. -- Transcribe an audio clip that came in through a trigger. -- Read an uploaded image and describe it with a vision model. -- Extract structured fields from a batch of PDFs. -- Produce a rendered document, chart, or audio file as a workflow's output. - - - - - -## Related documentation - -- [Files overview](/files) -- [Using files in workflows](/files/using-in-workflows) -- [Generating files](/files/generating) diff --git a/apps/docs/content/docs/academy/files/object.mdx b/apps/docs/content/docs/academy/files/object.mdx deleted file mode 100644 index 20556bc0232..00000000000 --- a/apps/docs/content/docs/academy/files/object.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: The File Object -description: Every file in Sim, whatever made it, travels as the same object, so producers and consumers compose without special handling. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_INVOICE_INTAKE_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -Your workflows make files from very different places: an email attachment, a generated image, synthesized speech, a parsed document. Inside the workflow, every one of them travels as the same thing: a file object. - - - -
- - - -
- -## The common shape - -A file object identifies a file through fields such as `id`, `name`, `url`, `size`, and `type`. The bytes may be stored separately; content is not always included inline. Pass the file object to a compatible block, or use the File block to read its content. See [Passing files between blocks](/files/passing-files). - -The video follows an invoice attachment through parsing and extraction: - - - -## Passing files between blocks - -Use a connection tag such as `` in a compatible block's file input. The shared object format lets blocks pass file references without copying the file's content into every parameter. The receiving block still determines which file types it can read. - -. The agent reads the document content directly." }, - { question: "Do generated files work the same as uploaded ones?", answer: "Yes. An image from a generator, an audio clip from text-to-speech, and an email attachment all travel as the same object, so downstream blocks treat them identically." }, -]} /> - -## Related documentation - -- [Files overview](/files) diff --git a/apps/docs/content/docs/academy/index.mdx b/apps/docs/content/docs/academy/index.mdx deleted file mode 100644 index 4a6c5abd01f..00000000000 --- a/apps/docs/content/docs/academy/index.mdx +++ /dev/null @@ -1,53 +0,0 @@ ---- -title: What is Sim? -description: Sim is a unified workspace for building and operating AI systems, data, workflows, and the integrations that connect them to the outside world. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { FAQ } from '@/components/ui/faq' - - - -Sim is a unified workspace for **building and operating AI systems**. Everything you make lives in one place, and everything connects. - - - -## The workspace - -A **workspace** is a collection of shared resources and the workflows that use them. - -- **Resources** are your data: [tables](/academy/tables/intro) (structured records), [knowledge bases](/academy/knowledge-bases/intro) (searchable memory), and [files](/academy/files/intro) (documents and media). -- **Workflows** are your processes: the agents and automations that read those resources, act, and write results back. - -Workflows can use workspace resources they have access to: read a table, search a knowledge base, or produce a file for another workflow. - -## Integrations connect you to the outside world - -**Integrations** are plugins. They let your resources and workflows reach services beyond Sim, send a Slack message, read a Gmail inbox, write a row to a CRM, call any API. Connect an account and share access with the people or workflows that need it. - -So the whole picture is small: a workspace is **data + processes**, integrations plug it into **everything else**, and the rest of this course is just learning each piece and watching them compose. - -## Related documentation - -- [Introduction](/introduction) -- [Getting started](/getting-started) - - diff --git a/apps/docs/content/docs/academy/knowledge-bases/connectors.mdx b/apps/docs/content/docs/academy/knowledge-bases/connectors.mdx deleted file mode 100644 index 0768b6c4ebb..00000000000 --- a/apps/docs/content/docs/academy/knowledge-bases/connectors.mdx +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Connectors -description: A connector keeps a knowledge base in sync with the tool where your documents actually live, first import, steady re-sync, changes and removals included. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' - - - -
-
- -You can upload documents to a knowledge base by hand, but your documents usually live somewhere that keeps changing. A connector links the knowledge base to that source, imports everything in scope, and then keeps it current on a schedule. - - - -
- - - -
- -## The lifecycle - -The video follows one connector through its whole life: picking Notion as the source, authorizing the account, scoping which pages sync, and choosing the frequency. The first import brings everything in scope into the knowledge base as chunks. From then on the connector re-syncs on schedule: a page edited at the source is re-imported, and a page deleted at the source leaves the knowledge base. - -## Check sync status - -After changing a source document, check that the next sync succeeds before testing an answer that depends on the change. Choose a sync frequency that matches how often the source changes. - - - -## Related documentation - -- [Knowledge bases](/knowledgebase) diff --git a/apps/docs/content/docs/academy/knowledge-bases/intro.mdx b/apps/docs/content/docs/academy/knowledge-bases/intro.mdx deleted file mode 100644 index 78dd8a67b42..00000000000 --- a/apps/docs/content/docs/academy/knowledge-bases/intro.mdx +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Knowledge Bases -description: Knowledge bases give your workflows searchable memory, large volumes of text an agent can search by meaning and use to ground its answers. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, SUPPORT_KB_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -A **knowledge base** gives your workflows searchable memory. You put in large volumes of text, and an agent retrieves just the parts that matter, by meaning, not keywords. - - - -
- - - -
- -## The context problem - -The naive way to give a model knowledge is to paste everything into its context. That breaks down fast, too much text, too much cost, too much noise. A knowledge base is the answer: store the corpus once, and at run time pull back only the passages that bear on the question. - -Here's the shape of it: a workflow that searches a knowledge base and grounds the answer in what comes back: - - - -## Inside a knowledge base - -A knowledge base is a resource that lives in your workspace, you can have several. Open one and it holds **documents**, plus **connectors** that bring in and keep documents in sync from outside sources. - -Sim automatically **indexes and embeds** every document into searchable **chunks**, so the contents become queryable by meaning, you don't manage any of that yourself. - -## Searching by meaning - -Use a Knowledge block with a query and it returns the most relevant chunks, each with a **similarity score**, how closely it matches the *meaning* of the query, not its words. So "refund timelines" can match a passage that says "we process returns within 14 days," even with no shared words. - -## Grounding an answer - -Pass the retrieved chunks into an [Agent](/academy/agents/intro) block and instruct it to answer from that material and cite its sources. Review the retrieved passages and final answer in the logs. The answer can only reflect documents that have been added or successfully synced. - - - -## Related documentation - -- [Knowledge Bases overview](/knowledgebase) -- [Using a knowledge base in workflows](/knowledgebase/using-in-workflows) -- [Connectors](/knowledgebase/connectors) diff --git a/apps/docs/content/docs/academy/meta.json b/apps/docs/content/docs/academy/meta.json deleted file mode 100644 index e395214b76c..00000000000 --- a/apps/docs/content/docs/academy/meta.json +++ /dev/null @@ -1,39 +0,0 @@ -{ - "title": "Academy", - "root": true, - "pages": [ - "---Get Started---", - "index", - "---Workflows---", - "workflows/intro", - "workflows/logs", - "workflows/branching", - "workflows/loops", - "workflows/subworkflows", - "workflows/deployment", - "---Chat---", - "chat/intro", - "chat/building", - "---Agents---", - "agents/intro", - "agents/block", - "agents/tool-calling", - "agents/skills", - "agents/memory", - "---Tables---", - "tables/intro", - "tables/operations", - "tables/workflow-columns", - "---Files---", - "files/intro", - "files/object", - "---Knowledge Bases---", - "knowledge-bases/intro", - "knowledge-bases/connectors", - "---Use Cases---", - "use-cases/slack-it-triage", - "use-cases/document-extraction", - "use-cases/monitoring-research", - "use-cases/sales-data-enrichment" - ] -} diff --git a/apps/docs/content/docs/academy/tables/intro.mdx b/apps/docs/content/docs/academy/tables/intro.mdx deleted file mode 100644 index 9ff7d1bfb24..00000000000 --- a/apps/docs/content/docs/academy/tables/intro.mdx +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Tables -description: Tables store structured data, columns as types, rows as entries, a spreadsheet or lightweight database your workflows read, write, and operate on at scale. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, TABLE_ENRICH_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -A **table** stores structured data: columns are the types, rows are the entries. Think of it as giving your workflows a spreadsheet, or a lightweight database, for tracking and maintaining records. - - - -
- - - -
- -## A familiar shape - -If you've used a spreadsheet, you already understand a table: columns with types, rows of entries. Your workflows read rows to work on, write rows they produce, and update rows in place. - -Here's the shape of it: a workflow that reads a table, operates on each record, and writes the result back: - - - -## Operations over data - -A surprising amount of real business work decomposes into a few operations over structured records: - -- **A query**, "which leads are still unprocessed?" -- **An update**, "mark these rows handled." -- **A combination with logic**, "for each new signup, score it, then write the score back." - -Once you see a use case that way, building it in Sim is mostly wiring those operations together. - -## Run workflows from rows - -[Workflow columns](/academy/tables/workflow-columns) map row values to workflow inputs and write results to output columns. Run selected rows, inspect their traces, and enable auto-run when new or changed rows should trigger the workflow. - - - -## Related documentation - -- [Tables overview](/tables) -- [Using tables in workflows](/tables/using-in-workflows) -- [Workflow columns](/tables/workflow-columns) diff --git a/apps/docs/content/docs/academy/tables/operations.mdx b/apps/docs/content/docs/academy/tables/operations.mdx deleted file mode 100644 index f443b2e2863..00000000000 --- a/apps/docs/content/docs/academy/tables/operations.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Table Operations -description: The Table block works across two surfaces, a panel where you describe the operation, and the live table that answers it, with one shape shared by query, insert, update, and delete. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview } from '@/components/workflow-preview' -import { AV_TABLE_OPS_WORKFLOW } from '@/components/workflow-preview/academy-video-workflows' - - - -
-
- -Workflows work with tables through the Table block. Everything the block can do starts from its Operation dropdown, and every operation follows the same shape: you describe it in the panel, run the block, and read the result in the table. - - - -
- - - -
- -Here is the block from the video, configured for the first query: - - - -## One shape for every operation - -The panel describes what you mean: an operation, a table, and, depending on the operation, a filter, row data, or both. A filter is conditions stacked together (priority equals high, and status equals open), each one narrowing the match. Queries read without touching the table; Delete Rows by Filter removes what matches; Insert Row lands a payload as a new row; Update Rows by Filter picks rows and changes them in place. - -## Reading the result - -The live table answers every run: matched rows highlight, deleted rows leave, inserted rows land, and updated cells flip where they sit. The block's output carries the same result back into the workflow for the next block to use. - - - -## Related documentation - -- [Tables overview](/tables) -- [Using tables in workflows](/tables/using-in-workflows) diff --git a/apps/docs/content/docs/academy/tables/workflow-columns.mdx b/apps/docs/content/docs/academy/tables/workflow-columns.mdx deleted file mode 100644 index 8957129b1d4..00000000000 --- a/apps/docs/content/docs/academy/tables/workflow-columns.mdx +++ /dev/null @@ -1,87 +0,0 @@ ---- -title: Workflow Columns -description: Attach a workflow to a table column and the table fills itself, and every value it writes carries the full trace of the run that produced it. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' - - - -
-
- -A workflow column stores a workflow output for each row. Configure a workflow group to map row values to inputs and select one or more output columns. Run rows manually, or enable **Auto-run workflow** to process new and changed rows. - - - -
- - - -
- -## Configure a workflow group - -Select the workflow, map row values to its inputs, and choose the columns that receive its outputs. A single row run can write several columns. If a later group depends on those outputs, configure **Run after** and enable **Auto-run workflow** for the stages that should run automatically. - -![Configure workflow dialog with three output columns selected, Auto-run enabled, and Run after dependencies](/static/tables/workflow-columns/configure-workflow.png) - -## Watching it run - -Run a single row and the cell reports the run as it moves, queued, then running, then the value. Turn on auto-run and the whole column fills in a cascade; type a new company into a blank row and the pipeline runs it end to end, the domain first, then the score, without a single click. - -## Every cell records its run - -Take one value: a lead score of 75. The cell remembers the run that wrote it: open its menu and view the execution, a real trace where every block is a span, with its timing and cost. Output cells from the same workflow group can share a row run. When a row fails, the cell says so, its trace shows which block failed and why, and re-running the cell re-runs the workflow for just that row. - - - -## Related documentation - -- [Tables overview](/tables) -- [Workflow columns](/tables/workflow-columns) -- [Logs & debugging](/logs-debugging) diff --git a/apps/docs/content/docs/academy/use-cases/document-extraction.mdx b/apps/docs/content/docs/academy/use-cases/document-extraction.mdx deleted file mode 100644 index 44f1f1b2ba7..00000000000 --- a/apps/docs/content/docs/academy/use-cases/document-extraction.mdx +++ /dev/null @@ -1,29 +0,0 @@ ---- -title: Document Intake & Extraction -description: A pipeline that takes incoming documents, extracts the fields you care about, and writes structured rows you can act on. ---- - -Build an invoice intake workflow that reads a file, extracts a fixed set of fields, and writes a row to a table. Start with one document before adding batch processing. - -## Prepare the inputs - -Create a table with columns for `source_file`, `invoice_number`, `vendor`, `invoice_date`, `total`, and `review_status`. Choose column types that match the values you want to store. Keep the source file reference so you can check an extraction against the original. - -## Build the workflow - -1. Pass an invoice into the workflow through an upload or an integration attachment. Use the [File block](/files/using-in-workflows) to read it, or pass it to an Agent model that supports the file type. -2. Configure an [Agent block](/workflows/blocks/agent) to extract the table fields. Define a structured output and instruct it to leave missing fields empty instead of inferring a value. -3. Add a [Condition](/workflows/blocks/condition) to check required fields before writing. Route incomplete results to a review path. -4. Use the [Table block](/tables/using-in-workflows) to insert the extracted values, source reference, and review status. - -## Check the result - -Run one complete invoice and compare the stored values with the original. Then test a document missing its invoice number and a document the reader cannot parse. Confirm that those cases reach the review path instead of creating a complete-looking row. - -Once the single-file workflow behaves as expected, use a [Loop or Parallel block](/academy/workflows/loops) to process a collection. Inspect the [logs](/logs-debugging) for each document. - -## Continue learning - -- [Passing files between blocks](/files/passing-files) -- [The File Object](/academy/files/object) -- [Table Operations](/academy/tables/operations) diff --git a/apps/docs/content/docs/academy/use-cases/monitoring-research.mdx b/apps/docs/content/docs/academy/use-cases/monitoring-research.mdx deleted file mode 100644 index 5120b01be34..00000000000 --- a/apps/docs/content/docs/academy/use-cases/monitoring-research.mdx +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Monitoring & Automated Research -description: A scheduled agent that watches sources you care about, researches what changed, and reports back, on its own. ---- - -Build a scheduled research workflow that checks a defined set of sources and saves a report. To report what changed, give each run the previous findings as a baseline. - -## Define the report - -Choose the sources, the questions to answer, and the schedule. For example: review three competitors each weekday and report product announcements with a source URL and publication date. - -Create a table or file for the previous report. The first run establishes the baseline; later runs compare new findings with it. - -## Build the workflow - -1. Add a [Schedule trigger](/workflows/triggers/schedule) and configure the frequency and timezone. -2. Read the previous report from a table or file. -3. Give an [Agent](/academy/agents/tool-calling) the search and page-reading tools it needs. Include the source list, research questions, and previous findings in its instructions. -4. Ask for a report that separates new findings from previously reported items and includes the supporting URLs. When nothing relevant changed, return a short no-change result. -5. [Save the report as a file](/files/generating) or send it to a configured [Slack](/integrations/slack) channel. Store the successful report as the baseline for the next run. - -## Check the result - -Run the workflow manually before enabling the schedule. Check that each claim is supported by its linked source and that a second run does not present the same findings as new. Test an unavailable source and confirm that the report identifies the gap. - -Review the [logs](/logs-debugging) to see which sources were searched and whether the report was saved or delivered. - -## Continue learning - -- [Tool Calling](/academy/agents/tool-calling) -- [Generating files](/files/generating) -- [Deployment](/academy/workflows/deployment) diff --git a/apps/docs/content/docs/academy/use-cases/sales-data-enrichment.mdx b/apps/docs/content/docs/academy/use-cases/sales-data-enrichment.mdx deleted file mode 100644 index e762edb588f..00000000000 --- a/apps/docs/content/docs/academy/use-cases/sales-data-enrichment.mdx +++ /dev/null @@ -1,34 +0,0 @@ ---- -title: Sales Data Management & Enrichment -description: A table-backed system that takes thin lead records, enriches them in parallel, scores them, and writes the results back. ---- - -Build a lead table that runs a workflow for each row, enriches the company record, and writes a fit score with supporting evidence. - -## Prepare the table and workflow - -Create input columns such as `company_name` and `domain`, plus output columns such as `industry`, `fit_score`, `fit_reason`, and `source_urls`. - -Build a workflow that accepts the input values, looks up the company with your chosen integration or research tools, and returns a structured result. Give the [Agent](/academy/agents/intro) explicit scoring criteria. For example, define which industries qualify and how missing evidence should affect the result. - -## Connect the workflow to rows - -1. Add a [workflow group](/tables/workflow-columns) to the table and select the enrichment workflow. -2. Map the row's company name and domain to the workflow inputs. -3. Select and map the output columns. One row run can fill several columns. -4. Run a single row and compare the values and cited sources with the company you intended to enrich. -5. Run a small selection of rows. Enable **Auto-run workflow** only when new or changed rows should run automatically. - -![Configure workflow dialog with multiple output columns, Auto-run, and Run after settings](/static/tables/workflow-columns/configure-workflow.png) - -## Check the result - -Test a company with a known domain, an ambiguous company name, and a row missing both. Confirm that uncertain matches are identified instead of receiving an unsupported score. - -Open an output cell's menu to inspect the row's execution trace. If a run fails, inspect the failed block and rerun that row after fixing the cause. When one enrichment stage depends on another, configure **Run after** dependencies. - -## Continue learning - -- [Workflow Columns](/academy/tables/workflow-columns) -- [Table Operations](/academy/tables/operations) -- [Logs](/academy/workflows/logs) diff --git a/apps/docs/content/docs/academy/use-cases/slack-it-triage.mdx b/apps/docs/content/docs/academy/use-cases/slack-it-triage.mdx deleted file mode 100644 index 0a686884ee3..00000000000 --- a/apps/docs/content/docs/academy/use-cases/slack-it-triage.mdx +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Slack IT Triage Bot -description: An agent that watches a Slack channel, classifies incoming IT requests, answers what it can from your docs, and routes the rest. ---- - -Build an IT triage workflow that reads messages from a configured Slack channel, searches your support documentation, and either drafts a supported reply or sends the request for human review. - -## Prepare the sources - -Connect the [Slack integration](/integrations/slack) and choose a test channel. Create a [knowledge base](/knowledgebase) containing the IT procedures the workflow should use, such as password reset and device setup instructions. - -Define the outcomes before building: answer from a documented procedure, escalate to a person, or create a ticket. Choose the destination for each path. - -## Build the workflow - -1. Configure a Slack trigger for the channel and pass the message into the workflow. Exclude the bot's own replies so they do not trigger another reply. -2. Use an [Agent](/academy/agents/intro) to classify the request and search the knowledge base. Ask it to return a structured decision, draft reply, source references, and an escalation reason when the documentation is insufficient. -3. Use a [Condition or Router](/academy/workflows/branching) to choose the outcome. Send the supported reply to Slack, or route the request and context to the configured person or ticketing integration. -4. Keep the incoming message reference with the outcome so reviewers can find the original request. - -## Check the result - -In the test channel, try a question answered by the docs, an unfamiliar request, and a message sent by the bot itself. Check that the supported answer cites the relevant procedure, the unfamiliar request reaches the review path, and the bot's reply does not create a loop. - -Inspect the [logs](/logs-debugging) for the retrieved passages, classification, chosen branch, and delivery result before moving the workflow to the intended channel. - -## Continue learning - -- [Knowledge Bases](/academy/knowledge-bases/intro) -- [Branching](/academy/workflows/branching) -- [Slack integration](/integrations/slack) diff --git a/apps/docs/content/docs/academy/workflows/branching.mdx b/apps/docs/content/docs/academy/workflows/branching.mdx deleted file mode 100644 index 43c4ceee3f1..00000000000 --- a/apps/docs/content/docs/academy/workflows/branching.mdx +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Branching -description: "Split a workflow into different paths based on the result of a step: the Condition block decides with a rule, the Router lets a model decide." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, CONDITION_ROUTE_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -Branching is how a workflow **splits into different paths based on the result of a step**. Sim gives you two blocks for it: the **Condition** block, which decides with an explicit rule, and the **Router**, which lets a model decide from intent. - - - -
- - - -
- -## A fork in the flow - -Most workflows you've seen run in a line. Branching adds a **fork**: at some point the run looks at the result of a step and takes one path or another. The paths can do completely different work. - -Here's the shape of a fork: one step decides, and the run takes one path or the other: - - - -## The Condition block, decide with a rule - -The **Condition** block branches on an **explicit rule**, a comparison over an earlier block's output, like priority equals "high". The matching branch runs; the others don't. It's deterministic and predictable. - -## The Router block, let a model decide - -Sometimes the rule is fuzzy: "send billing questions one way, everything else another." The **Router** block hands the decision to a **model**: it reads the input, picks the branch that matches the intent, and the run continues down it. Same fork, but the decider is reasoning instead of a fixed rule. - -## Still one workflow - -Whichever way it forks, it's **still one workflow**, and every run is recorded. Open the logs and you can see exactly which path a given run took, and why. - - - -## Related documentation - -- [How workflows run](/workflows/how-it-runs) -- [Condition block](/workflows/blocks/condition) -- [Router block](/workflows/blocks/router) diff --git a/apps/docs/content/docs/academy/workflows/deployment.mdx b/apps/docs/content/docs/academy/workflows/deployment.mdx deleted file mode 100644 index 8b0984f697c..00000000000 --- a/apps/docs/content/docs/academy/workflows/deployment.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Deployment -description: "Deploying gives a workflow an address so the outside world can run it: the same Start block answers calls as an API, a chat, or an MCP tool." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, RESPONSE_API_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -Deploying publishes a workflow and gives it an **address**, so something other than the editor can run it. Nothing inside the workflow changes, the same blocks, the same Start block, but now an external request can reach it and start a run. - - - -
- - - -
- -## A working workflow - -Before deploying, you have a workflow that runs when *you* run it, in the editor. Deploying is the step that lets anything else run it too. - -Here's the shape of the workflow you'll deploy: a Start block, a chain, and a response back to the caller: - - - -## Publish a version - -A deployment publishes a snapshot of the workflow. Requests use that version while you continue editing; publish a new version when the changes are ready, or roll back when needed. - -## A call from outside - -An external request comes in, hits that address, and flows straight into the **Start block**, the same entry you tested with in the editor. From there the run is identical: the chain executes and the response goes back to whoever called it. An external call is just a run; the only difference is where it came from. - -## The same workflow, three surfaces - -The one deployed workflow can be reached three ways, and you choose which: - -- **API**, other systems POST to an endpoint and get the response back. -- **Chat**, a hosted chat page with the access settings you configure; each message becomes the workflow's input. -- **MCP**, the workflow becomes a tool that other AI agents (like Cursor or Claude) can call. - -Same blocks underneath, same Start, just different doors in. - - - - - -## Related documentation - -- [Deployment overview](/workflows/deployment) -- [Deploy as an API](/workflows/deployment/api) -- [Deploy as a chat](/workflows/deployment/chat) -- [Deploy as an MCP server](/workflows/deployment/mcp) diff --git a/apps/docs/content/docs/academy/workflows/intro.mdx b/apps/docs/content/docs/academy/workflows/intro.mdx deleted file mode 100644 index b5eeb524c23..00000000000 --- a/apps/docs/content/docs/academy/workflows/intro.mdx +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Workflows -description: "A workflow is a visual program made of blocks: where you compose data, operations, integrations, and AI agents into a process." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, CLASSIFY_REPLY_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -A **workflow** is a visual program made of blocks. It's where you compose everything else in Sim, data, operations, integrations, and AI agents, into a process, and bind it to a trigger so it runs. - - - -
- - - -
- -## The pieces - -- A workflow is a **visual program**, you build it by placing and wiring blocks, not by writing a script. -- It's made of **blocks**, each one a step. Some blocks are **triggers**: they decide what starts the run and what it receives. -- **Connections** link blocks together. They set the order: a block runs after the blocks wired into it finish. -- Blocks have **parameters** that configure how they work. A Fetch Webpage block takes a URL; an Agent block takes a model and a prompt. -- When a workflow runs, Sim records what each block produced. Any later block can read an earlier block's output through a **connection tag**, like ``. -- Everything that happened is saved in the **logs**, the trigger, every block, and each block's input and output, so you can see exactly where a value came from. - -Here's a small workflow you can read top to bottom, blocks wired in order, each one a step. The highlighted block reads an earlier block's output through a connection tag: - - - -## How execution flows - -A block waits only for the blocks it depends on, nothing else. - -So if `A` feeds both `B` and `C`, then `B` and `C` start at the same moment `A` finishes; they don't wait for each other. And if `B` and `C` both feed `D`, then `D` waits for both before it runs. The shape of the connections *is* the execution plan. - -## Branches, loops, and parallel - -From those primitives you get expressive control flow: **branch** down one path or another with a Condition or Router, **loop** over a list, run work in **parallel** across many items. These are the expressive core of what you'll build, and they're all just blocks and connections. - - - -: a block's parameter references the output of an earlier block, and the value resolves when the run reaches it." }, - { question: "When does a block run?", answer: "When every block it depends on has finished. Independent branches run in parallel automatically, and a block waits for all of its inputs." }, -]} /> - -## Related documentation - -- [Workflows overview](/workflows) -- [How workflows run](/workflows/how-it-runs) -- [Data flow](/workflows/data-flow) -- [Connections](/workflows/connections) diff --git a/apps/docs/content/docs/academy/workflows/logs.mdx b/apps/docs/content/docs/academy/workflows/logs.mdx deleted file mode 100644 index 86c1763a32a..00000000000 --- a/apps/docs/content/docs/academy/workflows/logs.mdx +++ /dev/null @@ -1,83 +0,0 @@ ---- -title: Logs -description: A log is the complete record of one workflow run, and debugging is reading that record backwards, from a wrong value to the block that produced it. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, ROUTER_TRIAGE_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -Every time a workflow runs, Sim writes down exactly what happened: the trigger, every block in the order it ran, and for each block its input, its output, its timing, and any error. That record is a **log**, the ground truth for understanding and debugging a run. - - - -
- - - -
- -## Every run leaves a record - -When a workflow runs, the run isn't a black box. Sim records the **trigger** that started it, every **block** in the order it executed, and for each block its **input**, its **output**, its **timing**, and an error message if it failed. Use these recorded fields to compare the run with what you expected. - -Here's the kind of workflow whose runs you'll read: a trigger, an agent, and the branches it routes between: - - - -## The record - -Open a run and the log lists every block in the order it ran, each with its **duration**. So when a run is slow, you can see exactly where the time went, which block took the seconds, instead of guessing. - -## What each block did - -Selecting a block shows everything it actually did: the **input** it received, the **output** it returned, and, for an agent, the **tool calls** it made and the **tokens** it used. From the outside a step can look instant; the log keeps everything that happened inside it. - -## Read it backwards - -The log also shows where every value came from. A block's input names the block that produced it: a connection tag like ``. So to debug, you start from the **wrong value** and step **backwards**: which block produced it, what that block read, and on back through the chain until you reach the source. Debugging a workflow is reading its log backward from the symptom. - - - - - -## Related documentation - -- [Logs & debugging overview](/logs-debugging) -- [The Logs page](/logs-debugging/logging) diff --git a/apps/docs/content/docs/academy/workflows/loops.mdx b/apps/docs/content/docs/academy/workflows/loops.mdx deleted file mode 100644 index f804158be10..00000000000 --- a/apps/docs/content/docs/academy/workflows/loops.mdx +++ /dev/null @@ -1,85 +0,0 @@ ---- -title: Loops & Parallel -description: "Repeat the same steps over a collection: the Loop block runs them one item at a time, the Parallel block runs items in concurrent batches." ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, LOOP_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -Repeating the same steps across a whole collection is one of the most fundamental ideas in programming. Sim gives you two blocks for it: the **Loop** block and the **Parallel** block. They do the same job and differ only in *how* they run. - - - -
- - - -
- -## A block that holds blocks - -A Loop (or Parallel) is a **container**, a block you drop other blocks inside. You hand it a collection, and it runs whatever's inside once for every item in that collection, turning a single step into many. - -Here's the shape of it: a container wrapping the blocks it repeats over the collection: - - - -## What each run knows - -Inside the container, every iteration gets the **current item** to work on (and its index). That's how one lane of blocks becomes a run per lead, per row, or per file: the steps stay the same, the data changes each pass. - -## Sequential or concurrent - -- **Loop** runs items sequentially: one finishes before the next begins. Use it when an iteration depends on the previous one or the calls need to stay in order. -- **Parallel** runs independent items in concurrent batches. Set **Batch Size** from 1 to 20; larger collections run in successive batches. Choose a size that fits the service you are calling. - -## Swapping the container - -Because the two blocks share the same shape, you can **swap a Loop for a Parallel** (or back) without rewiring anything inside. Same logic, different execution, sequential or concurrent, chosen by which container you wrap it in. - - - -## Related documentation - -- [How workflows run](/workflows/how-it-runs) -- [Loop block](/workflows/blocks/loop) -- [Parallel block](/workflows/blocks/parallel) diff --git a/apps/docs/content/docs/academy/workflows/subworkflows.mdx b/apps/docs/content/docs/academy/workflows/subworkflows.mdx deleted file mode 100644 index 731b33bbff2..00000000000 --- a/apps/docs/content/docs/academy/workflows/subworkflows.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Subworkflows -description: Call one workflow from another, the way you'd call a function in code, reuse logic and compose small workflows into larger systems. ---- - -import { VideoPlaceholder } from '@/components/ui/video-placeholder' -import { WhatYouWillLearn } from '@/components/ui/what-you-will-learn' -import { VideoChapters } from '@/components/ui/video-chapters' -import { FAQ } from '@/components/ui/faq' -import { WorkflowPreview, WORKFLOW_CALL_WORKFLOW } from '@/components/workflow-preview' - - - -
-
- -Once you've built a workflow that does something well, you can **call it from another workflow**, the way you'd call a function in code. The Workflow block turns any workflow into a reusable step. - - - -
- - - -
- -## The workflow you already know - -Start with a workflow you've built and trust, say one that classifies a message. On its own it's a complete process you can run. - -Here's the shape of it: one workflow invoked as a single block inside another: - - - -## It becomes a block - -Any workflow can be used as a **block** inside another. You drop a **Workflow block**, point it at the workflow you want, and pass it an input, just like calling a function. You don't rebuild its logic; you reuse it. - -## Call, run, return - -When the parent run reaches the Workflow block, the **child workflow runs** start to finish, its own blocks, its own logic, and its **result comes back** into the parent, where the next block reads it. The parent doesn't need to know how the child works, only what it returns. - -## Workflows all the way up - -This is how big systems stay manageable: factor shared logic into focused subworkflows and **compose** them. Each workflow you build becomes a building block for the next, small, tested pieces assembling into larger processes, without turning into a mess. - - - -## Related documentation - -- [Workflow block](/workflows/blocks/workflow) -- [Workflows overview](/workflows) diff --git a/apps/docs/lib/academy-captions.test.ts b/apps/docs/lib/academy-captions.test.ts deleted file mode 100644 index 93579ce0766..00000000000 --- a/apps/docs/lib/academy-captions.test.ts +++ /dev/null @@ -1,41 +0,0 @@ -import { readdirSync, readFileSync } from 'node:fs' -import path from 'node:path' -import { describe, expect, it } from 'vitest' - -const docsDir = path.resolve(import.meta.dirname, '..') -const academyDir = path.join(docsDir, 'content/docs/academy') -const lessons = readdirSync(academyDir, { recursive: true, encoding: 'utf8' }) - .filter((file) => file.endsWith('.mdx')) - .flatMap((file) => { - const content = readFileSync(path.join(academyDir, file), 'utf8') - return [...content.matchAll(//g)] - .filter(([tag]) => /\bsrc="/.test(tag)) - .map(([tag]) => ({ file, tag })) - }) - -describe('Academy captions', () => { - it('provides a local caption track for every published lesson video', () => { - expect(lessons.length).toBeGreaterThan(0) - for (const { file, tag } of lessons) { - const source = tag.match(/\bcaptionsSrc="([^"]+)"/)?.[1] - expect(source, file).toMatch(/^\/captions\/academy\/[a-z-]+\.en\.vtt$/) - const track = readFileSync(path.join(docsDir, 'public', source!), 'utf8') - expect(track.startsWith('WEBVTT\n'), file).toBe(true) - const cues = track.matchAll( - /(\d{2}):(\d{2}):(\d{2}\.\d{3}) --> (\d{2}):(\d{2}):(\d{2}\.\d{3})\n([\s\S]*?)(?=\n\n|$)/g - ) - let previousEnd = 0 - let cueCount = 0 - for (const cue of cues) { - const start = Number(cue[1]) * 3600 + Number(cue[2]) * 60 + Number(cue[3]) - const end = Number(cue[4]) * 3600 + Number(cue[5]) * 60 + Number(cue[6]) - expect(start, file).toBeGreaterThanOrEqual(previousEnd) - expect(end, file).toBeGreaterThan(start) - expect(cue[7].trim(), file).not.toBe('') - previousEnd = end - cueCount++ - } - expect(cueCount, file).toBeGreaterThan(0) - } - }) -}) diff --git a/apps/docs/lib/redirects.ts b/apps/docs/lib/redirects.ts index f79577ebc80..a3274ba9142 100644 --- a/apps/docs/lib/redirects.ts +++ b/apps/docs/lib/redirects.ts @@ -20,6 +20,7 @@ type DocsRedirect = Awaited>>[nu * modules would make match order an emergent property of two files. */ const PATH_REDIRECTS: DocsRedirect[] = [ + { source: '/academy/:path*', destination: '/introduction', permanent: true }, ...Object.entries(integrationNavigation.redirects).map(([from, to]) => ({ source: `/integrations/${from}`, destination: `/integrations/${to}`, diff --git a/apps/docs/lib/utils.ts b/apps/docs/lib/utils.ts index a7b128a8254..3e9313bb3d1 100644 --- a/apps/docs/lib/utils.ts +++ b/apps/docs/lib/utils.ts @@ -17,10 +17,6 @@ export { cn } from '@sim/emcn' * - Otherwise falls back to local static assets served from root path */ export function getAssetUrl(filename: string) { - // Absolute URLs (e.g. blob-hosted academy videos) are already complete. - if (/^https?:\/\//.test(filename)) { - return filename - } const cdnBaseUrl = process.env.NEXT_PUBLIC_BLOB_BASE_URL if (cdnBaseUrl) { return `${cdnBaseUrl}/${filename}` diff --git a/apps/docs/public/captions/academy/agents-block.en.vtt b/apps/docs/public/captions/academy/agents-block.en.vtt deleted file mode 100644 index 73a1dcbb8f4..00000000000 --- a/apps/docs/public/captions/academy/agents-block.en.vtt +++ /dev/null @@ -1,119 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.500 -The agent block is the part of the -workflow where language model reasoning - -00:00:05.500 --> 00:00:11.100 -happens. But to make it reliable, it's -helpful to understand what you're actually - -00:00:11.100 --> 00:00:15.640 -giving the model. The messages it starts -from, the model you choose, the tools and - -00:00:15.640 --> 00:00:21.220 -skills it can reach for, and the output -other blocks will use afterwards. Once you - -00:00:21.220 --> 00:00:26.700 -see those pieces clearly, agents become -much easier to design and debug. Let me - -00:00:26.700 --> 00:00:31.580 -show you how the agent block works. On the -canvas, an agent block looks like any - -00:00:31.580 --> 00:00:35.760 -other step. A run arrives at its input -handle and a result leaves on the other - -00:00:35.760 --> 00:00:41.760 -side. But this block has more going on -inside than any other block in Sim. So - -00:00:41.760 --> 00:00:47.000 -this time, let's follow the data in. -Inside, the agent block is a conversation - -00:00:47.000 --> 00:00:51.900 -machine with a station for the messages, a -station for the model, and a station for - -00:00:51.900 --> 00:00:56.560 -what comes out. The first station is the -message stack, and it starts with your - -00:00:56.560 --> 00:01:01.180 -system message, the standing instructions -that tell the agent who it is and how to - -00:01:01.180 --> 00:01:06.060 -judge. You can preload the stack with -earlier user and assistant messages, so - -00:01:06.060 --> 00:01:11.340 -every run starts with that history already -in place. And the data we followed in - -00:01:11.340 --> 00:01:15.960 -lands at the bottom of the stack, as the -newest user message, filled in from the - -00:01:15.960 --> 00:01:21.100 -start block's input. The second station is -the model, and this is where you choose - -00:01:21.100 --> 00:01:26.620 -the brain that will read the whole stack. -Here, it's Claude Sonnet. And the brain is - -00:01:26.620 --> 00:01:31.320 -swappable. Sim supports all the frontier -providers, and the block around it never - -00:01:31.320 --> 00:01:35.380 -changes, so you could hand this exact -stack to any of them without rebuilding - -00:01:35.380 --> 00:01:40.480 -the step. When the run reaches the model, -every message on the stack is sent in, and - -00:01:40.480 --> 00:01:45.100 -you are billed for what it reads, measured -in tokens. If tools are attached to the - -00:01:45.100 --> 00:01:49.480 -block, the model can reach out from right -here, calling them mid -run when it needs - -00:01:49.480 --> 00:01:54.620 -more than the stack contains. Then it -writes, The reply streams out word by - -00:01:54.620 --> 00:01:59.800 -word, and the output side of the bill -counts those tokens, too. Everything the - -00:01:59.800 --> 00:02:04.200 -run produced gets packed into the block's -output, the content, the model it used, - -00:02:04.460 --> 00:02:09.400 -the token counts, and any tool calls it -made. And with that, we are back on the - -00:02:09.400 --> 00:02:13.620 -canvas. The output flows onto the next -block, which reads the agent's content - -00:02:13.620 --> 00:02:19.000 -like any other value. So that's the agent -block, one step on the canvas, and a whole - -00:02:19.000 --> 00:02:20.580 -conversation running inside. diff --git a/apps/docs/public/captions/academy/agents-intro.en.vtt b/apps/docs/public/captions/academy/agents-intro.en.vtt deleted file mode 100644 index d6ea0d0b021..00000000000 --- a/apps/docs/public/captions/academy/agents-intro.en.vtt +++ /dev/null @@ -1,89 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.840 --> 00:00:05.300 -Agents. Everybody's talking about them, -but nobody really seems to agree on what - -00:00:05.300 --> 00:00:10.940 -they actually are. In Sim, the answer is -pretty simple. An agent is just a workflow - -00:00:10.940 --> 00:00:15.880 -that can reason through agent blocks. That -means everything you already know about - -00:00:15.880 --> 00:00:20.540 -building workflows still applies. You're -just giving them the ability to think for - -00:00:20.540 --> 00:00:25.220 -themselves. And once that clicks, you'll -see how workflows can be more than basic - -00:00:25.220 --> 00:00:30.020 -automations and power AI systems that -genuinely think and adapt. Let me show you - -00:00:30.020 --> 00:00:35.680 -what I mean. Here's a workflow that runs -the same way every time. It scores a lead, - -00:00:35.780 --> 00:00:41.600 -then writes the result to a table. -Deterministic and predictable. Swap the - -00:00:41.600 --> 00:00:46.400 -scoring step for an agent block, and that -one step starts to think, reasoning about - -00:00:46.400 --> 00:00:51.760 -each lead instead of following a fixed -rule. An agent block is where it thinks. - -00:00:52.080 --> 00:00:56.560 -Running it spins up a fresh chat, like -ChatGPT or Claude, but driven by your - -00:00:56.560 --> 00:01:00.340 -workflow. And it works in a loop, calling -tools, reading what comes back, and - -00:01:00.340 --> 00:01:03.980 -changing course when it has to. The -homepage had no pricing, so it just opened - -00:01:03.980 --> 00:01:05.140 -the pricing page itself. - -00:01:07.840 --> 00:01:11.360 -Compose blocks around it, and a -deterministic pipeline becomes an - -00:01:11.360 --> 00:01:16.020 -intelligent one. And each agentic workflow -you build becomes a block for the next. - -00:01:16.620 --> 00:01:21.480 -And these systems only get more capable -over time. As the models improve, the same - -00:01:21.480 --> 00:01:22.760 -workflows improve with them. - -00:01:24.660 --> 00:01:29.120 -Sim keeps up to date with the latest -models, patterns, and AI techniques, so - -00:01:29.120 --> 00:01:33.780 -the newest capabilities are always -available. As you get more familiar with - -00:01:33.780 --> 00:01:38.480 -Sim, you'll see how serious agentic -systems are assembled from the same simple - -00:01:38.480 --> 00:01:39.560 -blocks and workflows. diff --git a/apps/docs/public/captions/academy/agents-memory.en.vtt b/apps/docs/public/captions/academy/agents-memory.en.vtt deleted file mode 100644 index f45d0eb0dd8..00000000000 --- a/apps/docs/public/captions/academy/agents-memory.en.vtt +++ /dev/null @@ -1,116 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.700 -Agentic workflows often need to build on -what happened earlier. A support agent may - -00:00:05.700 --> 00:00:10.520 -need the last few messages before it -replies, or a research agent may need to - -00:00:10.520 --> 00:00:15.120 -remember what it already found before the -next step. But agent blocks don't - -00:00:15.120 --> 00:00:20.640 -automatically carry that context from one -run to the next. Memory is what gives the - -00:00:20.640 --> 00:00:24.920 -workflow a place to keep the relevant -history so that the agent can continue - -00:00:24.920 --> 00:00:29.200 -with the right context instead of starting -from scratch. Let's see how to add memory - -00:00:29.200 --> 00:00:34.140 -to an agent. Here's a support agent in the -middle of a conversation, and the customer - -00:00:34.140 --> 00:00:40.140 -has just explained who she is, what plan -she's on, and what's going wrong. By - -00:00:40.140 --> 00:00:45.680 -default, the agent keeps none of this. -Every run starts completely fresh. So when - -00:00:45.680 --> 00:00:51.320 -she follows up the next day, the agent has -to ask for everything all over again. The - -00:00:51.320 --> 00:00:55.360 -fix is one setting on the agent block, -open memory, and choose conversation. - -00:00:56.820 --> 00:01:01.820 -Then give it a conversation ID, a key you -choose, and everything said under that key - -00:01:01.820 --> 00:01:08.020 -is kept. Now the conversation runs exactly -as before, but as each turn lands, it's - -00:01:08.020 --> 00:01:09.160 -saved under the key. - -00:01:11.160 --> 00:01:15.880 -The next morning, run the same agent twice -side by side, once with no memory, and - -00:01:15.880 --> 00:01:20.700 -once with the key. Before the model even -sees the new message, everything stored - -00:01:20.700 --> 00:01:25.640 -under the key is loaded back into the -conversation. Then the same question - -00:01:25.640 --> 00:01:26.640 -arrives in both. - -00:01:29.520 --> 00:01:34.020 -Without the key, the agent starts from -zero, and with it, it answers like no time - -00:01:34.020 --> 00:01:35.020 -has passed. - -00:01:37.420 --> 00:01:41.980 -Each conversation ID is its own separate -thread, so one agent can hold a different - -00:01:41.980 --> 00:01:46.880 -conversation with every customer at the -same time. From here, the thread just - -00:01:46.880 --> 00:01:50.380 -keeps going, every run picking up exactly -where the last one stopped. - -00:01:52.300 --> 00:01:56.420 -Memory can also be a sliding window, -keeping the most recent messages, while - -00:01:56.420 --> 00:02:02.440 -the oldest quietly fall away. Here is that -window on the stored transcript itself. - -00:02:02.440 --> 00:02:07.560 -The older turns are still there, but only -the last 10 messages ride into the model, - -00:02:07.720 --> 00:02:13.980 -or if you prefer, the most recent tokens. -So that's agent memory. One setting and a - -00:02:13.980 --> 00:02:17.880 -key, the agent remembers each turn, -recalls the whole thread, and every - -00:02:17.880 --> 00:02:20.000 -conversation picks up where it left off. diff --git a/apps/docs/public/captions/academy/agents-skills.en.vtt b/apps/docs/public/captions/academy/agents-skills.en.vtt deleted file mode 100644 index 7afc21830f6..00000000000 --- a/apps/docs/public/captions/academy/agents-skills.en.vtt +++ /dev/null @@ -1,85 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.180 -You probably know by now that agents work -better when they have the right context - -00:00:05.180 --> 00:00:10.300 -and instructions. The hard part is giving -them that guidance without stuffing every - -00:00:10.300 --> 00:00:16.260 -prompt full of repetitive details that may -not matter for the current task. That's - -00:00:16.260 --> 00:00:21.320 -what skills are for. A skill is like a -playbook or a manual the agent can pull in - -00:00:21.320 --> 00:00:26.040 -when it needs it, so the detailed -instructions show up at the right moment - -00:00:26.040 --> 00:00:29.700 -instead of sitting in the way. Let me show -you how that works. - -00:00:32.000 --> 00:00:36.640 -This is the same agent from before with -its web tools. Ask it to qualify a lead - -00:00:36.640 --> 00:00:42.360 -and with no method to follow, it just runs -a quick search. So the answer it gives is - -00:00:42.360 --> 00:00:43.960 -a guess, vague and unsourced. - -00:00:46.640 --> 00:00:51.760 -A skill fixes that. It's a written method -the agent can read, a playbook for how to - -00:00:51.760 --> 00:00:52.760 -do the job well. - -00:00:55.660 --> 00:00:59.620 -You attach the skill to the agent -alongside the tools it already has. - -00:01:04.700 --> 00:01:09.400 -Now, run the same request again. This -time, the agent reaches for the skill mid - -00:01:09.400 --> 00:01:13.080 --run, loading it right in the -conversation, the way it would call a - -00:01:13.080 --> 00:01:18.360 -tool. Following the method, it turns each -claim into a question and pulls a sourced - -00:01:18.360 --> 00:01:19.620 -answer for every one. - -00:01:25.160 --> 00:01:29.400 -The result is a detailed, cited answer, -where before there was only a guess. - -00:01:34.020 --> 00:01:38.780 -And the playbook never clogs the agent's -context. Only its name and description - -00:01:38.780 --> 00:01:43.520 -stay in view. And the full method loads -only when the agent decides it's relevant. - -00:01:44.320 --> 00:01:48.400 -You don't even have to write them. Every -integration ships with ready -to -use - -00:01:48.400 --> 00:01:50.800 -skills that give your agents instant -expertise. diff --git a/apps/docs/public/captions/academy/agents-tool-calling.en.vtt b/apps/docs/public/captions/academy/agents-tool-calling.en.vtt deleted file mode 100644 index f96bf66c661..00000000000 --- a/apps/docs/public/captions/academy/agents-tool-calling.en.vtt +++ /dev/null @@ -1,130 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.060 -The agent block lets you call a language -model, but most useful agents don't just - -00:00:05.060 --> 00:00:10.980 -answer a question and then stop. They need -to look things up, call services, check - -00:00:10.980 --> 00:00:17.100 -what came back, decide what to do next. -Tool calling is what gives an agent that - -00:00:17.100 --> 00:00:21.880 -loop, a way to choose actions, get -feedback from the world, and keep going - -00:00:21.880 --> 00:00:26.120 -until it has enough to return something -useful. Let me show you how it works. - -00:00:27.300 --> 00:00:31.900 -Here's a plain agent block with a simple -prompt and no tools. Text goes in, the - -00:00:31.900 --> 00:00:36.520 -model runs, and text comes out. It can't -really qualify the lead the way we want - -00:00:36.520 --> 00:00:40.820 -because it lacks the context it needs. In -the worst case, it might even hallucinate - -00:00:40.820 --> 00:00:46.780 -a response. We can give the agent some -tools, and now it works in a loop. Each - -00:00:46.780 --> 00:00:51.040 -turn, the model decides whether it needs a -tool and which one, and it can even call - -00:00:51.040 --> 00:00:56.120 -several at once. It reads what comes back, -revises its plan, and calls again with - -00:00:56.120 --> 00:00:57.120 -different arguments. - -00:00:58.620 --> 00:01:05.100 -Every tool call gets added to its context, -and each step builds on the last. The - -00:01:05.100 --> 00:01:08.200 -agent repeatedly calls tools to converge -towards a solution. - -00:01:09.460 --> 00:01:14.060 -Once the agent decides it's done, it -synthesizes an answer from the context - -00:01:14.060 --> 00:01:19.320 -accumulated from all the tool calls. You -can add tools to an agent block in the - -00:01:19.320 --> 00:01:23.480 -tools section of the block's parameters. -Any block you'd normally bring as a - -00:01:23.480 --> 00:01:28.440 -workflow step can be a tool. When -selecting tools for an agent block, you - -00:01:28.440 --> 00:01:32.980 -can fill in block parameters to fix their -values. The model will fill in the tool - -00:01:32.980 --> 00:01:38.340 -arguments you leave empty intelligently -based on the task. Sometimes a model might - -00:01:38.340 --> 00:01:43.860 -not choose to use a tool, but you can -guarantee it does by choosing force. If no - -00:01:43.860 --> 00:01:48.220 -block does quite what you need, you can -write your own tool. You give it a schema - -00:01:48.220 --> 00:01:52.300 -and a description, and that description is -how the model knows when to reach for it. - -00:01:52.460 --> 00:01:58.520 -You can also connect a whole external tool -set at once over MCP. You can see exactly - -00:01:58.520 --> 00:02:03.800 -which tools the agent decided to use by -reading back the run. The content field is - -00:02:03.800 --> 00:02:09.380 -the model's final answer, written after it -worked through all the tools. Open up the - -00:02:09.380 --> 00:02:12.180 -tool calls, and you get every call it made -in order. - -00:02:13.660 --> 00:02:16.200 -Each one shows the name of the tool it -called. - -00:02:17.580 --> 00:02:20.620 -The arguments the model filled in to -invoke it. - -00:02:23.600 --> 00:02:26.320 -And the result that came back into its -context. - -00:02:28.680 --> 00:02:32.900 -The calls are kept in order, so you can -trace each step and see why the agent - -00:02:32.900 --> 00:02:34.000 -answered the way it did. diff --git a/apps/docs/public/captions/academy/chat-building.en.vtt b/apps/docs/public/captions/academy/chat-building.en.vtt deleted file mode 100644 index 643152d5041..00000000000 --- a/apps/docs/public/captions/academy/chat-building.en.vtt +++ /dev/null @@ -1,81 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.640 --> 00:00:05.940 -Building a workflow usually starts with a -blank canvas, but sometimes the idea is - -00:00:05.940 --> 00:00:10.920 -clearer in your head than on the screen. -Chat gives you a different starting point. - -00:00:11.100 --> 00:00:15.660 -You describe the system you want in plain -language, and Sim can turn that into - -00:00:15.660 --> 00:00:21.460 -blocks, test the result, fix what breaks, -and keep refining it with you. It's a more - -00:00:21.460 --> 00:00:26.160 -conversational way to get from idea to -working automation. Let me show you how it - -00:00:26.160 --> 00:00:30.720 -works. You can build a whole workflow -without dragging a single block. You just - -00:00:30.720 --> 00:00:35.840 -open a chat and describe what you want. -Say you want an agent that turns an idea - -00:00:35.840 --> 00:00:40.360 -into a finished post, a written draft, a -hero image, a slide deck, and a voiceover. - -00:00:40.520 --> 00:00:46.580 -You ask for it, and the whole thing builds -itself, every block wired up. Before you - -00:00:46.580 --> 00:00:50.200 -even ask, it runs the whole thing itself -just to see if it holds together. - -00:00:52.760 --> 00:00:57.900 -The image step fails. It was missing an -aspect ratio. It catches that on its own, - -00:00:58.040 --> 00:00:59.640 -fixes it, and runs again. Clean. - -00:01:04.900 --> 00:01:09.780 -Then it shows you what it made. Every step -that ran. The draft, the image, the deck, - -00:01:10.000 --> 00:01:12.580 -the audio, so you can check it before you -trust it. - -00:01:14.880 --> 00:01:19.260 -You hand it a real idea, and it drafts a -few versions at once, scores each one, and - -00:01:19.260 --> 00:01:20.260 -keeps the best. - -00:01:22.800 --> 00:01:27.260 -One more message, and it's deployed. A -live endpoint ready for whatever you send - -00:01:27.260 --> 00:01:28.260 -it. - -00:01:30.800 --> 00:01:35.220 -You went from a blank canvas to a working -system without leaving the conversation. - -00:01:35.400 --> 00:01:37.220 -Open a new chat and see what you can -build. diff --git a/apps/docs/public/captions/academy/chat-intro.en.vtt b/apps/docs/public/captions/academy/chat-intro.en.vtt deleted file mode 100644 index d408a23d830..00000000000 --- a/apps/docs/public/captions/academy/chat-intro.en.vtt +++ /dev/null @@ -1,67 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:04.620 -In Sim, chat is the fastest way to work -with your workspace when you know what you - -00:00:04.620 --> 00:00:09.780 -want, but not necessarily what clicks it -will take to get there. Instead of jumping - -00:00:09.780 --> 00:00:14.960 -between workflows, tables, files, and -knowledge bases yourself, you can ask from - -00:00:14.960 --> 00:00:20.780 -one place and let chat reach across the -workspace for you. It can answer, operate, - -00:00:20.840 --> 00:00:26.340 -and help shape the system around the task. -Let me show you what that feels like. This - -00:00:26.340 --> 00:00:29.900 -is the chat in Sim. Everything in your -workspace is within its reach. - -00:00:31.720 --> 00:00:36.220 -Ask a question, and Sim queries your -tables and searches your documents at the - -00:00:36.220 --> 00:00:39.740 -same time, then answers from both in one -reply. - -00:00:42.720 --> 00:00:47.340 -Tell it to act, and it runs your -workflows. Here, the whole backlog streams - -00:00:47.340 --> 00:00:51.260 -through the support desk, while the weekly -digest goes out and lands on a schedule. - -00:00:54.660 --> 00:00:59.400 -It can reach outside the workspace, too, -searching this week's conversations on X - -00:00:59.400 --> 00:01:02.500 -and Reddit. And filing what it learns back -in as a document. - -00:01:04.680 --> 00:01:08.940 -And the pieces compose, one sentence -builds a new workflow that reads those - -00:01:08.940 --> 00:01:12.420 -trends on a schedule, and calls your -support desk when something matches. - -00:01:16.960 --> 00:01:20.920 -That's the chat in Sim. Open it. Ask for -what you need, and the workspace you've - -00:01:20.920 --> 00:01:22.460 -already built does the work. diff --git a/apps/docs/public/captions/academy/files-intro.en.vtt b/apps/docs/public/captions/academy/files-intro.en.vtt deleted file mode 100644 index e2fcf866a86..00000000000 --- a/apps/docs/public/captions/academy/files-intro.en.vtt +++ /dev/null @@ -1,111 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.620 --> 00:00:04.720 -Workflows don't just pass around text and -numbers. They can also work with real - -00:00:04.720 --> 00:00:10.800 -documents, PDFs, reports, images, even -video. Files are how your workspace - -00:00:10.800 --> 00:00:16.040 -holds onto those. Some you upload, others -your workflows can generate. And any block - -00:00:16.040 --> 00:00:21.800 -can read a file in as a single object or -write a new one back out. If your process - -00:00:21.800 --> 00:00:26.100 -involves managing content, it'll probably -run through files. Let's see an example. - -00:00:28.300 --> 00:00:33.800 -A lot of the work your team handles starts -as a document, an invoice, a report, notes - -00:00:33.800 --> 00:00:39.800 -from a call. In Sim, those documents live -in your workspace as files. A file can - -00:00:39.800 --> 00:00:44.540 -arrive in several ways. You can upload one -in a chat, post one to the API, or pull - -00:00:44.540 --> 00:00:49.600 -one off an email as an attachment. However -it arrived, inside the workspace, every - -00:00:49.600 --> 00:00:54.860 -document becomes the same thing. A file -object with an ID, a name, a URL, a size, - -00:00:54.980 --> 00:00:59.680 -and a type. Here's a workflow that -processes them. A Gmail trigger hands its - -00:00:59.680 --> 00:01:05.640 -attachment to a file block. An agent reads -it, and Supabase stores the result. When - -00:01:05.640 --> 00:01:10.340 -an email arrives, the trigger starts a -run. It downloads the invoice and makes it - -00:01:10.340 --> 00:01:15.520 -available as an output that any block can -reference. The file block points at the - -00:01:15.520 --> 00:01:19.560 -trigger's first attachment. And when the -run reaches it, that reference resolves - -00:01:19.560 --> 00:01:24.960 -into the invoice itself. The agent reads -the document directly and extracts the - -00:01:24.960 --> 00:01:28.860 -fields you asked for. The vendor, the -total, and the date. You can see them in - -00:01:28.860 --> 00:01:29.860 -the run's output. - -00:01:31.520 --> 00:01:35.940 -Supabase writes those fields into the -invoices table as a new row. From here, - -00:01:36.080 --> 00:01:41.300 -they're data that any of your tools can -query. Files go out the same ways they - -00:01:41.300 --> 00:01:45.700 -come in. A run can email a document, -upload one to drive, or write a new file - -00:01:45.700 --> 00:01:51.260 -back into the workspace. That was one -document. The trigger fires for every - -00:01:51.260 --> 00:01:55.540 -email that arrives during the day. And -each invoice is read and written to the - -00:01:55.540 --> 00:02:01.340 -table the same way. After the run, the -document is still in your workspace as a - -00:02:01.340 --> 00:02:05.320 -file. And the values it carried are rows -in the table. You can go back to either - -00:02:05.320 --> 00:02:10.700 -one. That's files in Sim. Documents come -in, workflows read them, and the results - -00:02:10.700 --> 00:02:13.220 -land where the rest of your tools can use -them. diff --git a/apps/docs/public/captions/academy/files-object.en.vtt b/apps/docs/public/captions/academy/files-object.en.vtt deleted file mode 100644 index 81d167be4f7..00000000000 --- a/apps/docs/public/captions/academy/files-object.en.vtt +++ /dev/null @@ -1,101 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:06.100 -Files can look completely different on the -outside. A PDF from Gmail, an image from a - -00:00:06.100 --> 00:00:12.080 -generation, an audio clip, a document from -a parser. But for workflows to use them - -00:00:12.080 --> 00:00:18.380 -reliably, they need a common shape. This -is the file object. It gives Sim one - -00:00:18.380 --> 00:00:24.120 -consistent interface to pass files between -blocks so producers and consumers can work - -00:00:24.120 --> 00:00:29.840 -together without every file source needing -special handling. Let me show you how the - -00:00:29.840 --> 00:00:35.520 -files object works. Your workflows make -files from very different places. An email - -00:00:35.520 --> 00:00:39.980 -arrives carrying an attachment. One block -generates an image, another turns text - -00:00:39.980 --> 00:00:45.800 -into speech, and another reads a document. -Wire them all into one agent, and every - -00:00:45.800 --> 00:00:51.140 -lane feeds the same reader. The Gmail -trigger fires first, and its attachment - -00:00:51.140 --> 00:00:56.580 -lands in the workflow as a file object. -Then the image, the audio clip, and the - -00:00:56.580 --> 00:01:00.660 -parsed document arrive, each one delivered -exactly the same way. - -00:01:02.380 --> 00:01:07.040 -Look at what's settled underneath. Four -very different payloads, and the identical - -00:01:07.040 --> 00:01:11.920 -package around every one of them. Run it -at full speed, and whatever a lane - -00:01:11.920 --> 00:01:14.720 -produces, the agent simply reads the next -file object. - -00:01:16.740 --> 00:01:18.760 -Catch one mid -run and look closer. - -00:01:20.780 --> 00:01:26.180 -Every file object carries the same fields, -an ID, a name, a URL, where the bytes - -00:01:26.180 --> 00:01:31.560 -live, a size, a type, and the content -itself. A couple more fields exist under - -00:01:31.560 --> 00:01:36.600 -the hood, but this shape never changes, no -matter which block made the file. Put it - -00:01:36.600 --> 00:01:38.280 -back, and the machine keeps moving. - -00:01:40.120 --> 00:01:44.420 -Because every producer speaks the same -format, you can swap which one feeds the - -00:01:44.420 --> 00:01:46.680 -agent, and the agent side never changes. - -00:01:47.940 --> 00:01:52.840 -It works downstream, too. The same object -can ride to any consumer, into an agent, - -00:01:53.000 --> 00:01:58.920 -out as an email attachment, or straight -into storage. This is a real template. An - -00:01:58.920 --> 00:02:03.740 -invoice lands in Gmail, gets parsed, an -agent pulls out the fields, and the result - -00:02:03.740 --> 00:02:07.680 -settles in your database. One object -riding the whole way through. diff --git a/apps/docs/public/captions/academy/kb-connectors.en.vtt b/apps/docs/public/captions/academy/kb-connectors.en.vtt deleted file mode 100644 index ba9c56e40f9..00000000000 --- a/apps/docs/public/captions/academy/kb-connectors.en.vtt +++ /dev/null @@ -1,111 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.820 -A knowledge base is only as good as the -documents inside it. If those documents - -00:00:05.820 --> 00:00:11.560 -live somewhere else, in Drive, Notion, -GitHub, or another source, uploading them - -00:00:11.560 --> 00:00:16.880 -once is not enough. The source changes, -and your agent's knowledge needs to change - -00:00:16.880 --> 00:00:22.160 -with it. Connectors keep the knowledge -base tied to where the work already lives, - -00:00:22.300 --> 00:00:27.700 -so that answers stay grounded in the -current material. Let me show you how - -00:00:27.700 --> 00:00:32.880 -connectors work. This knowledge base holds -17 documents, and every one of them was - -00:00:32.880 --> 00:00:37.260 -uploaded by hand. The moment a source -changes, the copy in here starts to drift. - -00:00:38.160 --> 00:00:42.320 -Instead of re -uploading, you add a -connector, and Sim opens a picker of - -00:00:42.320 --> 00:00:43.780 -sources it can sync from. - -00:00:45.120 --> 00:00:48.300 -Pick Notion, and the connector asks how to -read your workspace. - -00:00:52.140 --> 00:00:56.640 -You authorize the account once, and Sim -keeps the connection alive from there. - -00:00:58.040 --> 00:01:02.800 -Then you choose what to sync, the whole -workspace, one database, or a single page, - -00:01:02.920 --> 00:01:07.600 -and its children. Here, the docs page. And -you choose how often it checks. From every - -00:01:07.600 --> 00:01:10.640 -hour down to manual only, this one syncs -daily. - -00:01:12.200 --> 00:01:16.600 -Connect and sync, and the connector lands -beside your knowledge base and starts its - -00:01:16.600 --> 00:01:17.600 -first import. - -00:01:19.080 --> 00:01:25.060 -12 pages stream in from Notion. The base -grows from 17 documents to 29, and the - -00:01:25.060 --> 00:01:30.820 -first sync is written into the history. -Synced pages are processed exactly like - -00:01:30.820 --> 00:01:33.680 -uploads, split into chunks and indexed for -search. - -00:01:36.120 --> 00:01:39.960 -From here, the connector checks on its -schedule, and most days, there is nothing - -00:01:39.960 --> 00:01:40.960 -to do. - -00:01:43.140 --> 00:01:47.460 -When someone edits a page in Notion, the -next sync catches it, and only that - -00:01:47.460 --> 00:01:48.940 -document is reprocessed. - -00:01:51.100 --> 00:01:55.640 -And when a page is deleted at the source, -it leaves the base too, so nothing stale - -00:01:55.640 --> 00:01:56.640 -is left behind. - -00:01:58.000 --> 00:02:01.980 -The payoff shows up in your workflows. -When an agent searches this base, it - -00:02:01.980 --> 00:02:04.540 -answers from the passage that's synced -this morning. - -00:02:08.120 --> 00:02:12.440 -That is what a connector buys you. A -knowledge base that keeps itself current. diff --git a/apps/docs/public/captions/academy/knowledge-bases.en.vtt b/apps/docs/public/captions/academy/knowledge-bases.en.vtt deleted file mode 100644 index 18e6d96010f..00000000000 --- a/apps/docs/public/captions/academy/knowledge-bases.en.vtt +++ /dev/null @@ -1,120 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.320 -Out of the box, an agent only knows what -its model was trained on. Nothing about - -00:00:05.320 --> 00:00:10.740 -your company, your docs, or your product. -A knowledge base fixes that. You give it - -00:00:10.740 --> 00:00:13.860 -your documents, and it becomes a -searchable memory your workflows can pull - -00:00:13.860 --> 00:00:18.240 -from, so when an agent needs an answer, -it's grounded in your material instead of - -00:00:18.240 --> 00:00:23.120 -guessing. And when you use knowledge bases -as a component in your workflows, you can - -00:00:23.120 --> 00:00:27.720 -build AI systems that actually understand -your business. Let me show you how it - -00:00:27.720 --> 00:00:33.020 -works. Your company's knowledge is -scattered across docs, wikis, PDFs, - -00:00:33.240 --> 00:00:38.620 -spreadsheets, and inboxes. The naive fix -is to stuff it all into the prompt, but - -00:00:38.620 --> 00:00:42.800 -cram in everything and the model drowns. -Too much context and the answer falls - -00:00:42.800 --> 00:00:47.960 -apart. The fix is a knowledge base. You -collect those scattered sources into one - -00:00:47.960 --> 00:00:52.920 -place, and Sim makes everything inside it -searchable. A knowledge base is a - -00:00:52.920 --> 00:00:58.640 -resource. It lives in your workspace right -alongside your workflows. And you can have - -00:00:58.640 --> 00:01:02.520 -more than one. Separate bases for -engineering, sales, support. So each - -00:01:02.520 --> 00:01:06.820 -workflow searches only the knowledge it -should. You probably already have - -00:01:06.820 --> 00:01:10.680 -knowledge you'd like your workflows to -use. Here, a customer asks about the - -00:01:10.680 --> 00:01:14.100 -refund policy, and the question reaches -the knowledge block. - -00:01:15.360 --> 00:01:19.600 -Inside a workflow, the knowledge block -points at one of those bases. This one - -00:01:19.600 --> 00:01:21.540 -holds your product docs, 17 of them. - -00:01:24.440 --> 00:01:28.960 -Inside a knowledge base, the key unit of -information is the document. A document - -00:01:28.960 --> 00:01:33.760 -gets processed by Sim into smaller pieces -called chunks. And it's the chunks that - -00:01:33.760 --> 00:01:38.360 -get searched, not whole files. When a -question comes in, it's matched against - -00:01:38.360 --> 00:01:43.280 -every chunk by meaning. And the closest -few come back. The pieces most likely to - -00:01:43.280 --> 00:01:44.280 -hold the answer. - -00:01:47.000 --> 00:01:51.860 -Those chunks get inserted into the model's -context. So before the agent writes a - -00:01:51.860 --> 00:01:56.440 -single word, it's already looking at your -actual policy. And the answer it derives - -00:01:56.440 --> 00:01:57.920 -is grounded in your documents. - -00:02:00.920 --> 00:02:05.720 -And every search leaves a record. The -question, the chunks it pulled, and the - -00:02:05.720 --> 00:02:11.320 -answer it produced. You can always see why -it said what it said. There's no magic in - -00:02:11.320 --> 00:02:15.360 -any of this. It's your documents made -searchable and brought to the model at the - -00:02:15.360 --> 00:02:16.380 -moment it needs them. diff --git a/apps/docs/public/captions/academy/tables-operations.en.vtt b/apps/docs/public/captions/academy/tables-operations.en.vtt deleted file mode 100644 index 199470a6c38..00000000000 --- a/apps/docs/public/captions/academy/tables-operations.en.vtt +++ /dev/null @@ -1,91 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.100 -Tables become much more useful when -workflows can act on them directly. Maybe - -00:00:05.100 --> 00:00:10.440 -you need to find every new lead, add a row -when something happens, update a status - -00:00:10.440 --> 00:00:15.200 -after an agent finishes, or clean up -records you no longer need. The table - -00:00:15.200 --> 00:00:20.020 -block is what connects those structured -records to the rest of your workload, so - -00:00:20.020 --> 00:00:24.460 -data can move in and out of tables as the -process runs. Let me show you how the - -00:00:24.460 --> 00:00:25.480 -table block works. - -00:00:27.180 --> 00:00:31.980 -The table block works across two surfaces. -A panel where you describe the operation - -00:00:31.980 --> 00:00:33.960 -and the live table that answers it. - -00:00:35.540 --> 00:00:39.840 -Everything the block can do to a table -starts from the operation dropdown, and it - -00:00:39.840 --> 00:00:40.900 -opens on query rows. - -00:00:43.220 --> 00:00:47.940 -A query is shaped by its filter, so we -build one condition, priority equals high. - -00:00:52.280 --> 00:00:56.980 -Run it, and three rows match. The table -itself is untouched because a query only - -00:00:56.980 --> 00:00:57.980 -reads. - -00:00:59.240 --> 00:01:03.380 -Now change just the operator to not -equals, and the same run selects the - -00:01:03.380 --> 00:01:04.380 -opposite rows. - -00:01:07.500 --> 00:01:12.020 -Conditions stack, so adding status equals -open narrows the match to a single ticket. - -00:01:15.420 --> 00:01:20.240 -Delete rows by filter takes the same -shape, one filter, and the matching row - -00:01:20.240 --> 00:01:21.240 -leaves the table. - -00:01:23.420 --> 00:01:28.520 -Insert row swaps the filter for row data, -and every key in the payload lands as a - -00:01:28.520 --> 00:01:29.600 -cell in the new row. - -00:01:33.420 --> 00:01:38.060 -Update rows by filter combines both. The -filter picks the open tickets, and the row - -00:01:38.060 --> 00:01:39.880 -data flips each one to resolved. - -00:01:43.820 --> 00:01:47.800 -Each operation follows the same shape. You -describe it in the panel, run the block, - -00:01:48.020 --> 00:01:49.220 -and read the result in the table. diff --git a/apps/docs/public/captions/academy/tables-workflow-columns.en.vtt b/apps/docs/public/captions/academy/tables-workflow-columns.en.vtt deleted file mode 100644 index eb8c887a119..00000000000 --- a/apps/docs/public/captions/academy/tables-workflow-columns.en.vtt +++ /dev/null @@ -1,182 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:04.400 -Tables are useful when they hold the state -of your work, but sometimes a column - -00:00:04.400 --> 00:00:09.280 -shouldn't be typed in by hand. It should -be produced by workflow. Workflow columns - -00:00:09.280 --> 00:00:14.520 -let a table run your logic row by row, -write the result back into the right cell, - -00:00:14.660 --> 00:00:20.720 -and then keep going as new rows become -ready. So a table stops being just the - -00:00:20.720 --> 00:00:25.520 -place to store results and becomes a -pipeline that fills itself. Let me show - -00:00:25.520 --> 00:00:26.520 -you how it works. - -00:00:27.860 --> 00:00:33.060 -Alongside your workflows, a workspace can -hold tables. This one tracks AI startup - -00:00:33.060 --> 00:00:38.660 -leads, and so far, only the company column -has been typed in. A workflow column is - -00:00:38.660 --> 00:00:42.780 -different. Instead of typing its values -in, you attach one of your workflows, and - -00:00:42.780 --> 00:00:48.440 -that workflow fills the column for you. -Everything that defines it lives in one - -00:00:48.440 --> 00:00:52.240 -panel, starting with which of your -workflows runs. Here, it's a small - -00:00:52.240 --> 00:00:57.700 -workflow that finds a company's website. -Its inputs are bound to columns. On every - -00:00:57.700 --> 00:01:03.180 -row, the workflow will read that row's -company value as its input. And its output - -00:01:03.180 --> 00:01:08.040 -is bound to the column it fills. So each -run writes one cell right beside its - -00:01:08.040 --> 00:01:13.200 -source. You can run a single row to watch -it work. The cell reports the run as it - -00:01:13.200 --> 00:01:19.100 -moves, queued first, then running. Under -that badge is a real workflow run. The - -00:01:19.100 --> 00:01:23.140 -row's company value lands at the start -block, and the agent picks it up as its - -00:01:23.140 --> 00:01:28.740 -input. When the run finishes, the output -is written back into the row. One row in, - -00:01:28.900 --> 00:01:34.240 -one run, one value back. You can attach -more than one group to the same table. - -00:01:34.480 --> 00:01:38.320 -This one scores each lead, and it reads -the domain column that the first group - -00:01:38.320 --> 00:01:43.220 -fills. That dependency is called run -after. The row that already has a domain - -00:01:43.220 --> 00:01:49.200 -queues up immediately, and the empty rows -simply wait. Turn on auto run, and you - -00:01:49.200 --> 00:01:55.340 -stop clicking altogether. Every row that's -ready fires on its own all at once. Now - -00:01:55.340 --> 00:02:00.600 -watch the cascade. The moment a row's -domain lands, its score becomes eligible - -00:02:00.600 --> 00:02:06.800 -and starts running. Each row moves through -the stages on its own. Runs finish in - -00:02:06.800 --> 00:02:10.700 -their own time, and every result settles -in next to the data that produced it. - -00:02:13.700 --> 00:02:18.100 -From here, the table takes care of itself. -Type in a new company, and the whole - -00:02:18.100 --> 00:02:22.120 -pipeline runs it. The domain first, then -the score, without a single click. - -00:02:23.660 --> 00:02:28.860 -And that's the finished table. But every -value in these workflow columns was - -00:02:28.860 --> 00:02:34.860 -produced by a real workflow. One run for -every row. So take one value. Where did - -00:02:34.860 --> 00:02:36.720 -this 75 actually come from? - -00:02:38.720 --> 00:02:44.560 -The cell remembers. Open its menu, and you -can view the execution behind it. What - -00:02:44.560 --> 00:02:48.640 -opens is the trace of a real run, finished -in under two seconds, for one credit. - -00:02:50.120 --> 00:02:54.740 -Every block that ran is a span. Start -handed the row in, and the lead scorer - -00:02:54.740 --> 00:03:00.040 -agent spent nearly all of the time -producing the score. The cell is simply - -00:03:00.040 --> 00:03:01.760 -where that run wrote down its answer. - -00:03:03.480 --> 00:03:08.320 -And that is true all the way down. Every -cell in the column is its own run, with - -00:03:08.320 --> 00:03:09.720 -its own trace behind it. - -00:03:11.720 --> 00:03:15.840 -Rows that are still working just show -their state, and when a run completes, the - -00:03:15.840 --> 00:03:20.420 -badge becomes the value. One row failed, -and the cell says so. - -00:03:24.220 --> 00:03:27.260 -Its own trace shows exactly which block -failed, and why. - -00:03:31.160 --> 00:03:36.680 -So fixing it is one click. Rerun the cell, -and the workflow runs again, for just this - -00:03:36.680 --> 00:03:37.680 -row. - -00:03:38.420 --> 00:03:41.620 -The new value replaces the badge, with a -fresh trace behind it. - -00:03:43.260 --> 00:03:48.660 -That is what a workflow column really is. -A column of runs, where every answer comes - -00:03:48.660 --> 00:03:49.660 -with its receipt. diff --git a/apps/docs/public/captions/academy/tables.en.vtt b/apps/docs/public/captions/academy/tables.en.vtt deleted file mode 100644 index ebcba5168c6..00000000000 --- a/apps/docs/public/captions/academy/tables.en.vtt +++ /dev/null @@ -1,92 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.460 -Most of what your workflows produce is -structured data. Statuses, scores, results - -00:00:05.460 --> 00:00:10.240 -you want to keep and act on later. That's -what tables are for. They're like a - -00:00:10.240 --> 00:00:14.720 -database built right into your workspace -with rows and columns your workflows can - -00:00:14.720 --> 00:00:20.080 -read from and write back to, run after -run. Anything you want to track, process - -00:00:20.080 --> 00:00:25.380 -in batches, or build on over time should -live in a table. Let me show you how they - -00:00:25.380 --> 00:00:30.300 -work. Every business runs on small facts -like this one, a company name someone - -00:00:30.300 --> 00:00:31.300 -wrote down. - -00:00:32.140 --> 00:00:37.480 -In a table, that fact lives inside a row, -one record that keeps everything about - -00:00:37.480 --> 00:00:39.000 -this lead in one place. - -00:00:40.220 --> 00:00:45.140 -Each column gives its values, a type, -text, numbers, dates, so every record - -00:00:45.140 --> 00:00:46.800 -keeps the same reliable shape. - -00:00:49.240 --> 00:00:54.400 -Zoom out, and this is a table, typed -columns over rows, where each row is one - -00:00:54.400 --> 00:00:55.400 -real record. - -00:00:57.220 --> 00:01:01.320 -New leads keep arriving, and each one -lands as another clean row. - -00:01:04.180 --> 00:01:09.140 -And the shape can grow. A new column -starts from a type, text, number, boolean, - -00:01:09.340 --> 00:01:14.840 -date, or JSON, and a column can even be -filled by a workflow. Pick boolean, and a - -00:01:14.840 --> 00:01:18.520 -qualified column lands with a real -checkbox on every record, matching the - -00:01:18.520 --> 00:01:19.520 -status beside it. - -00:01:21.460 --> 00:01:26.340 -The table stays current as work happens. -The moment a deal moves, its status moves - -00:01:26.340 --> 00:01:27.340 -with it. - -00:01:28.460 --> 00:01:32.900 -And the same shape works for anything you -track, support tickets, orders, any - -00:01:32.900 --> 00:01:34.680 -structured record your team keeps. - -00:01:37.460 --> 00:01:41.960 -A table is a home for your records, -alongside the workflows that will put them - -00:01:41.960 --> 00:01:42.960 -to work. diff --git a/apps/docs/public/captions/academy/what-is-sim.en.vtt b/apps/docs/public/captions/academy/what-is-sim.en.vtt deleted file mode 100644 index 347fd57b02c..00000000000 --- a/apps/docs/public/captions/academy/what-is-sim.en.vtt +++ /dev/null @@ -1,114 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:04.460 -Welcome to Sim. My name is Will, and I'll -be your instructor throughout Sim Academy. - -00:00:04.780 --> 00:00:08.880 -In this series, we'll go over the -fundamentals of how Sim works and get you - -00:00:08.880 --> 00:00:13.520 -comfortable with the building blocks. The -platform has so much to offer that it's - -00:00:13.520 --> 00:00:17.580 -easy to get overwhelmed, but once you -master the basics, you'll be able to build - -00:00:17.580 --> 00:00:22.800 -your own agents and AI systems beyond -basic automations and chatbots. I'm - -00:00:22.800 --> 00:00:24.120 -excited. Let's get started. - -00:00:25.520 --> 00:00:30.360 -Sim is a workspace where everything you -build lives, your data, your workflows, - -00:00:30.720 --> 00:00:33.660 -all in one place, and your whole team can -work in it together. - -00:00:35.660 --> 00:00:40.380 -Everything in a workspace is one of two -kinds. Resources hold what your system - -00:00:40.380 --> 00:00:44.800 -knows, your knowledge bases, tables, and -files. Workflows do the work, the agents - -00:00:44.800 --> 00:00:49.940 -that turn that data into action. -Everything you build in Sim is made from a - -00:00:49.940 --> 00:00:53.640 -few main object types. These are the seven -you'll work with. Let's walk through them - -00:00:53.640 --> 00:00:55.720 -quickly and see what each one is for. - -00:00:57.580 --> 00:01:02.340 -The first is the workflow, an executable -process. Each block is one step. This one - -00:01:02.340 --> 00:01:07.340 -classifies a customer message and drafts a -reply. Your system's steps live here. - -00:01:08.340 --> 00:01:13.440 -Tables hold your structured data, rows, -and columns of statuses, scores, and - -00:01:13.440 --> 00:01:19.540 -outputs. Anything you want to inspect or -process repeatedly belongs in a table. A - -00:01:19.540 --> 00:01:24.600 -knowledge base is searchable memory over -your documents. You ask it a question, and - -00:01:24.600 --> 00:01:30.780 -it finds the most relevant material. Here, -the quarterly report. Files are the - -00:01:30.780 --> 00:01:35.080 -documents and artifacts your workspace -holds onto. Some you upload, like this - -00:01:35.080 --> 00:01:39.800 -report, and workflows can generate new -ones, like this summary. Integrations - -00:01:39.800 --> 00:01:43.980 -connect your workflows and agents to the -outside world. Services like Gmail, - -00:01:43.980 --> 00:01:49.020 -Notion, and Airtable. A workflow can read -from these integrations and act through - -00:01:49.020 --> 00:01:53.880 -them. Every time something runs, Sim -records what happened. That record is a - -00:01:53.880 --> 00:01:59.440 -log. It lists each step that ran with its -timing and the output it produced. A - -00:01:59.440 --> 00:02:04.460 -deployment makes a workflow usable outside -the editor. Publish it as a tool, and - -00:02:04.460 --> 00:02:09.180 -other AI systems, like Cursor or Claude -Code, can call your workflow on demand - -00:02:09.180 --> 00:02:14.200 -over MCP. And it all comes together in the -workflow. Let's open one up. diff --git a/apps/docs/public/captions/academy/workflows-branching.en.vtt b/apps/docs/public/captions/academy/workflows-branching.en.vtt deleted file mode 100644 index 59ee5070ed8..00000000000 --- a/apps/docs/public/captions/academy/workflows-branching.en.vtt +++ /dev/null @@ -1,81 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:04.520 -Branching is how a workflow can split into -different paths based on the result of a - -00:00:04.520 --> 00:00:09.460 -step. Say one step checks an incoming -offer. If it's over a certain amount, the - -00:00:09.460 --> 00:00:14.540 -workflow routes it for review, and if not, -it just continues on. In Sim, that split - -00:00:14.540 --> 00:00:20.080 -can come from a simple rule you set, -written code, or be handed off to an agent - -00:00:20.080 --> 00:00:22.800 -to decide. Let me show you how it works. - -00:00:24.340 --> 00:00:28.720 -A workflow doesn't have to be a straight -line. It can fork. The fork is one block, - -00:00:28.880 --> 00:00:34.120 -and every branch row on it is its own -output port. A condition block picks the - -00:00:34.120 --> 00:00:38.580 -branch with a rule. The priority field -resolves to high, the check passes - -00:00:38.580 --> 00:00:43.600 -instantly with no model involved, and the -workflow takes the top lane. The bottom - -00:00:43.600 --> 00:00:49.100 -lane never runs. Branches are checked from -top to bottom, and the first one that's - -00:00:49.100 --> 00:00:53.540 -true wins. This ticket matches nothing -above it, so the else branch fires - -00:00:53.540 --> 00:00:57.740 -instead. When the rule is too hard to -write, when the decision depends on - -00:00:57.740 --> 00:01:02.340 -meaning, you swap in a router. It takes a -context to read, a model to read it, and a - -00:01:02.340 --> 00:01:03.340 -set of named routes. - -00:01:04.940 --> 00:01:09.500 -Now a model makes the choice. The router -reads the ticket, thinks for a moment, and - -00:01:09.500 --> 00:01:12.980 -that pause is a real model call, then it -picks the support route. - -00:01:16.580 --> 00:01:21.360 -The run's log shows five blocks, but only -three rows ran. The branch that wasn't - -00:01:21.360 --> 00:01:27.180 -taken, never executed at all. It left no -log entry and no output. It's still one - -00:01:27.180 --> 00:01:30.960 -workflow. Reach for a rule when you can -write one, and reach for a model when you - -00:01:30.960 --> 00:01:31.960 -can't. diff --git a/apps/docs/public/captions/academy/workflows-deployments.en.vtt b/apps/docs/public/captions/academy/workflows-deployments.en.vtt deleted file mode 100644 index 29a00db35b7..00000000000 --- a/apps/docs/public/captions/academy/workflows-deployments.en.vtt +++ /dev/null @@ -1,87 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.240 -So far, your workflow runs only when you -run it inside the editor. Deploying - -00:00:05.240 --> 00:00:09.800 -changes that. It gives your workflow a -real address so the outside world can - -00:00:09.800 --> 00:00:15.580 -reach it. As an API, other systems can -call, a chat people can talk to, or a tool - -00:00:15.580 --> 00:00:20.760 -other AI agents can use. The same -workflow, now live and running on demand. - -00:00:21.260 --> 00:00:27.040 -Let's show how to ship one. This is your -working workflow. You type, I want a - -00:00:27.040 --> 00:00:31.800 -refund. It lands on the start block, the -agent classifies it, and the response - -00:00:31.800 --> 00:00:35.900 -comes back, billing. But it only runs when -you run it right here in the editor. - -00:00:36.940 --> 00:00:40.580 -Deploying publishes that workflow and -gives it an address. Nothing inside - -00:00:40.580 --> 00:00:45.480 -changes, the same blocks, the same start. -Now an external request can reach that - -00:00:45.480 --> 00:00:51.320 -address and flow straight into the start -block, and the workflow runs. A request - -00:00:51.320 --> 00:00:57.540 -comes in from somewhere else, a refund -from customer 4821. It lands on the same - -00:00:57.540 --> 00:01:02.060 -input row. The agent runs, the answer -comes back billing, and the reply goes - -00:01:02.060 --> 00:01:07.820 -back out. An external call is just a run. -The only difference is where it came from. - -00:01:08.560 --> 00:01:13.500 -You can also deploy the same workflow as a -chat. Deploying as a chat gives it a chat - -00:01:13.500 --> 00:01:17.840 -page, and anyone who opens it gets a -conversation. Each message they send flows - -00:01:17.840 --> 00:01:22.320 -into the same start block as its input. -The agent thinks, and the reply that comes - -00:01:22.320 --> 00:01:28.640 -back is whatever output you selected. -Here, billing. Underneath the - -00:01:28.640 --> 00:01:35.100 -conversation, it's the same ordinary run. -Every time. That's a deployment. The - -00:01:35.100 --> 00:01:40.020 -same workflow you built, now running as an -operational system. A call arrives, the - -00:01:40.020 --> 00:01:44.040 -chain settles in order, and the reply goes -back out whenever they call it, with no - -00:01:44.040 --> 00:01:45.040 -one in the editor. diff --git a/apps/docs/public/captions/academy/workflows-intro.en.vtt b/apps/docs/public/captions/academy/workflows-intro.en.vtt deleted file mode 100644 index c90e32bb540..00000000000 --- a/apps/docs/public/captions/academy/workflows-intro.en.vtt +++ /dev/null @@ -1,117 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.640 -In Sim, workflows are the repeatable -processes that power your workspace's AI - -00:00:05.640 --> 00:00:10.260 -systems. They're where your business's -logic, automations, and agents are - -00:00:10.260 --> 00:00:15.520 -defined, where data and resources get -converted into action. Almost everything - -00:00:15.520 --> 00:00:21.140 -you'll make will use them. Whether it's a -support agent that triages tickets, or a - -00:00:21.140 --> 00:00:25.940 -pipeline that enriches your leads, or a -monitoring process that runs on a - -00:00:25.940 --> 00:00:30.840 -schedule, these functions are all -expressed through workflows. Let's open - -00:00:30.840 --> 00:00:35.600 -one up. This is a workflow, a visual -program, a process laid out as connected - -00:00:35.600 --> 00:00:39.100 -blocks, each one a step. Here it is, -running once, start to finish. - -00:00:42.640 --> 00:00:47.380 -Some blocks can act as triggers, which -start the workflow. And Sim offers - -00:00:47.380 --> 00:00:51.540 -thousands of integrations with other -services, a library of third -party - -00:00:51.540 --> 00:00:56.800 -actions and triggers that's actively -maintained and always growing. Each block - -00:00:56.800 --> 00:01:01.260 -is configured by its parameters. Open one -up and you can see them. The operation it - -00:01:01.260 --> 00:01:05.200 -performs, the query it searches for, and -how many results to bring back. - -00:01:07.820 --> 00:01:13.100 -A parameter can hold a fixed value, or use -the result of a previous block via a - -00:01:13.100 --> 00:01:17.400 -connection tag. The answer's message -inserts the excerpts that retrieve context - -00:01:17.400 --> 00:01:21.980 -found. A connection tag names the block -and the field, enclosed in angle brackets, - -00:01:22.140 --> 00:01:27.840 -and points right at that block's output. -You can follow any tag back to where its - -00:01:27.840 --> 00:01:32.040 -value came from. This one reads from the -block right beside it, and this one - -00:01:32.040 --> 00:01:33.500 -reaches much further back. - -00:01:36.080 --> 00:01:41.020 -When it runs, each block starts the moment -the blocks feeding it are done. So once - -00:01:41.020 --> 00:01:45.640 -retrieve context returns, the answer and -the log both run at the same time. - -00:01:47.060 --> 00:01:51.380 -And when several feed into one, it waits -for all of them. The log finishes - -00:01:51.380 --> 00:01:56.000 -instantly, but the result holds until the -answer is done too, then runs once with - -00:01:56.000 --> 00:01:57.000 -both ready. - -00:01:59.340 --> 00:02:03.980 -That's the whole model. A trigger starts -it. Each block runs as soon as its inputs - -00:02:03.980 --> 00:02:07.920 -arrive. Data moves through connection -tags, and the run ends at the result. - -00:02:10.140 --> 00:02:14.960 -And the same rules apply no matter how big -a workflow gets. Add more blocks, more - -00:02:14.960 --> 00:02:19.760 -branches, loops, even whole sub workflows -nested inside. And it all still runs the - -00:02:19.760 --> 00:02:20.760 -same way. diff --git a/apps/docs/public/captions/academy/workflows-logs.en.vtt b/apps/docs/public/captions/academy/workflows-logs.en.vtt deleted file mode 100644 index 6f697ddd19f..00000000000 --- a/apps/docs/public/captions/academy/workflows-logs.en.vtt +++ /dev/null @@ -1,74 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:05.740 -When a workflow runs, the output only -tells you where it ended up. The log tells - -00:00:05.740 --> 00:00:10.360 -you how it got there. It shows which -blocks ran, what each one received, what - -00:00:10.360 --> 00:00:15.360 -it returned, how long it took, where a -value originally came from. That matters - -00:00:15.360 --> 00:00:19.600 -when something looks wrong because -debugging a workflow usually means tracing - -00:00:19.600 --> 00:00:24.880 -one bad result backwards until you find -the step that caused it. Let's take a look - -00:00:24.880 --> 00:00:30.500 -at a real run and read the log. Here's a -workflow processing a support ticket. Four - -00:00:30.500 --> 00:00:35.180 -blocks start to finish. Every time a -workflow runs, Sim records exactly what - -00:00:35.180 --> 00:00:37.300 -happened. That record is called a log. - -00:00:38.560 --> 00:00:43.360 -The log lists every block in the order it -ran, along with its timing, so you can see - -00:00:43.360 --> 00:00:46.240 -exactly where the 12 seconds of this run -were spent. - -00:00:48.820 --> 00:00:53.800 -Selecting a block shows everything it -actually did. This agent made three tool - -00:00:53.800 --> 00:00:57.500 -calls, a customer lookup, and two -knowledge searches, and the log records - -00:00:57.500 --> 00:01:03.220 -each call, along with the tokens it used. -The log also shows where every value came - -00:01:03.220 --> 00:01:07.320 -from. This row was built from the -function's result. The function read the - -00:01:07.320 --> 00:01:11.760 -agent's answer, and the agent read the -customer's message. To debug a workflow, - -00:01:12.020 --> 00:01:16.540 -you read the log backwards from the wrong -value step -by -step to its source. - -00:01:20.660 --> 00:01:25.480 -Every run produces a log automatically. -When a workflow does something unexpected, - -00:01:25.800 --> 00:01:27.540 -the log is the first place to look. diff --git a/apps/docs/public/captions/academy/workflows-loops.en.vtt b/apps/docs/public/captions/academy/workflows-loops.en.vtt deleted file mode 100644 index ce17c66cab4..00000000000 --- a/apps/docs/public/captions/academy/workflows-loops.en.vtt +++ /dev/null @@ -1,78 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.740 --> 00:00:05.360 -Loops are one of the most fundamental -ideas in programming, a way to repeat the - -00:00:05.360 --> 00:00:10.460 -same step across a whole set of items. Sim -gives you two blocks for this, the loop - -00:00:10.460 --> 00:00:15.520 -block and the parallel block. They do the -same job, running whatever's inside once - -00:00:15.520 --> 00:00:20.980 -for every item in a collection, but they -go about it in very different ways. Let me - -00:00:20.980 --> 00:00:25.980 -walk you through how each one works and -when to reach for one over the other. Some - -00:00:25.980 --> 00:00:30.360 -jobs are a list. The same steps need to -run for every item. For that, Sim has the - -00:00:30.360 --> 00:00:34.640 -loop, a block that holds other blocks. -Whatever you place inside it runs once per - -00:00:34.640 --> 00:00:39.660 -item. The loop is configured with a -collection to iterate over. Three items - -00:00:39.660 --> 00:00:42.440 -here, so everything inside will run three -times. - -00:00:43.800 --> 00:00:48.500 -Watch the current item reference. On the -first pass, it resolves to X, the same - -00:00:48.500 --> 00:00:53.240 -steps run again with Y and then Z. A loop -takes the items strictly in order. - -00:00:57.700 --> 00:01:02.700 -After the last pass, the loop exits once. -Downstream, the loop results value is an - -00:01:02.700 --> 00:01:08.020 -array holding every pass's output in -order. Now swap the container to parallel. - -00:01:08.020 --> 00:01:12.900 -The steps inside don't change. Only the -schedule does. References follow the name - -00:01:12.900 --> 00:01:18.360 -so the tags update on their own. A -parallel block runs one copy of the inside - -00:01:18.360 --> 00:01:23.200 -for every item, all at the same time. They -finish together and the same results array - -00:01:23.200 --> 00:01:24.200 -comes out. - -00:01:27.360 --> 00:01:32.040 -One shape, two schedules. Use a loop when -the order matters and parallel when it - -00:01:32.040 --> 00:01:33.040 -doesn't. diff --git a/apps/docs/public/captions/academy/workflows-subworkflows.en.vtt b/apps/docs/public/captions/academy/workflows-subworkflows.en.vtt deleted file mode 100644 index 59da476a9e7..00000000000 --- a/apps/docs/public/captions/academy/workflows-subworkflows.en.vtt +++ /dev/null @@ -1,69 +0,0 @@ -WEBVTT - -NOTE -Automatic English captions. Generated locally and checked with additional audio decodes; not fully audited by listening. - -00:00:00.000 --> 00:00:04.060 -Once you've built a workflow that does -something well, you don't want to rebuild - -00:00:04.060 --> 00:00:09.020 -it every time you need it. In Sim, any -workflow can become a block inside another - -00:00:09.020 --> 00:00:13.600 -one. You build it once, then call it from -anywhere, the same way you'd call a - -00:00:13.600 --> 00:00:18.460 -function in code. It's how small, focused -workflows compose into bigger systems - -00:00:18.460 --> 00:00:23.800 -without turning into a mess. Let me show -you what I mean. This is a workflow you've - -00:00:23.800 --> 00:00:27.940 -already built. It classifies customer -messages end -to -end on its own. - -00:00:30.280 --> 00:00:35.700 -That whole workflow can fold into a single -block inside another one. You pick which - -00:00:35.700 --> 00:00:39.320 -workflow it calls and what input it -receives, and then you build around it - -00:00:39.320 --> 00:00:44.020 -like any other block. When the run reaches -the workflow block, it hands over the - -00:00:44.020 --> 00:00:46.060 -value, and then it waits for the answer. - -00:00:47.920 --> 00:00:52.600 -The call holds at the top, while the child -workflow runs underneath. The value the - -00:00:52.600 --> 00:00:56.680 -parent passed in is the child's start -input, and the child runs end -to -end - -00:00:56.680 --> 00:00:58.700 -with it, the same way it runs on its own. - -00:01:01.900 --> 00:01:06.420 -When the child finishes, its answer comes -back as the block's result, and the parent - -00:01:06.420 --> 00:01:08.520 -continues with it like any other value. - -00:01:11.800 --> 00:01:17.160 -And the parent can become a block inside -something bigger. Keeping workflows small - -00:01:17.160 --> 00:01:20.920 -and calling them from each other is how -large systems stay manageable. diff --git a/apps/sim/content/library/best-ai-agents-for-slack/index.mdx b/apps/sim/content/library/best-ai-agents-for-slack/index.mdx index 505ea25c21f..32ba8138fa0 100644 --- a/apps/sim/content/library/best-ai-agents-for-slack/index.mdx +++ b/apps/sim/content/library/best-ai-agents-for-slack/index.mdx @@ -135,7 +135,7 @@ A production deployment normally follows this sequence: ## How can Sim build a custom AI agent for Slack? -[Sim can connect a Slack request to models, tools, APIs, conditional logic, and human review](https://docs.sim.ai/academy/use-cases/slack-it-triage) in one visual agent workflow. +[Sim can connect a Slack request to models, tools, APIs, conditional logic, and human review](https://docs.sim.ai/integrations/slack) in one visual agent workflow. A typical Sim architecture is: @@ -211,7 +211,7 @@ MCP is not automatically safer than an API. The MCP server still needs narrow to ## How can a Slack AI agent answer questions from a knowledge base? -[Dust](https://dust.tt/home/solutions/knowledge), [Sim](https://docs.sim.ai/academy/use-cases/slack-it-triage), [Botpress](https://www.botpress.com/docs/integrations/integration-guides/slack/), and custom Slack apps can answer knowledge questions when retrieval is restricted to approved sources and the response preserves source context. +[Dust](https://dust.tt/home/solutions/knowledge), [Sim](https://docs.sim.ai/integrations/slack), [Botpress](https://www.botpress.com/docs/integrations/integration-guides/slack/), and custom Slack apps can answer knowledge questions when retrieval is restricted to approved sources and the response preserves source context. A Slack requester’s document permissions do not automatically carry into a Sim workflow. Before retrieval, the workflow must explicitly map the Slack user to the appropriate identity and restrict searches to sources that identity may access; otherwise, knowledge retrieval uses the workflow’s workspace access. diff --git a/apps/sim/lib/compare/data/competitors/tines.ts b/apps/sim/lib/compare/data/competitors/tines.ts index 348a1813fd8..34d5d1fd1f3 100644 --- a/apps/sim/lib/compare/data/competitors/tines.ts +++ b/apps/sim/lib/compare/data/competitors/tines.ts @@ -42,7 +42,7 @@ export const tinesProfile: CompetitorProfile = { { title: 'Tines University certification ladder', description: - 'Tines University pairs free foundational courses with instructor-led and self-paced Bootcamps and two certification tiers, Core and Advanced, that builders can share on LinkedIn. Sim Academy is a structured docs section without a formal certification path.', + 'Tines University pairs free foundational courses with instructor-led and self-paced Bootcamps and two certification tiers, Core and Advanced, that builders can share on LinkedIn. Sim provides product documentation without a formal certification path.', shortDescription: 'Core and Advanced certifications builders can share on LinkedIn.', source: { url: 'https://www.tines.com/get-certified/', diff --git a/apps/sim/lib/compare/data/sim.ts b/apps/sim/lib/compare/data/sim.ts index ac649c26161..5c1020972af 100644 --- a/apps/sim/lib/compare/data/sim.ts +++ b/apps/sim/lib/compare/data/sim.ts @@ -1260,14 +1260,14 @@ export const simProfile: CompetitorProfile = { }, academy: { value: - 'Yes: Sim Academy is a dedicated structured-learning section of the docs site, separate from reference documentation and the API reference', - shortValue: 'Sim Academy: dedicated structured-learning docs section', + 'No: Sim provides product documentation and API reference guides without a dedicated academy or certification program', + shortValue: 'Product docs and API reference; no dedicated academy', confidence: 'verified', sources: [ { - url: 'https://docs.sim.ai/academy', - label: 'Sim Docs: Academy', - asOf: '2026-07-02', + url: 'https://docs.sim.ai/introduction', + label: 'Sim Documentation', + asOf: '2026-10-13', }, ], }, diff --git a/apps/sim/lib/execution/remote-sandbox/e2b-session.test.ts b/apps/sim/lib/execution/remote-sandbox/e2b-session.test.ts index 7a5e5037194..55b5f05660d 100644 --- a/apps/sim/lib/execution/remote-sandbox/e2b-session.test.ts +++ b/apps/sim/lib/execution/remote-sandbox/e2b-session.test.ts @@ -331,6 +331,7 @@ describe('E2B session recovery', () => { }) it('searches paused workbenches and all pages before choosing the canonical session', async () => { + vi.spyOn(Date, 'now').mockReturnValue(Date.now()) let pages = 2 list.mockReturnValue({ nextItems, diff --git a/apps/sim/next.config.ts b/apps/sim/next.config.ts index 50a03623d4c..6566e825859 100644 --- a/apps/sim/next.config.ts +++ b/apps/sim/next.config.ts @@ -498,15 +498,9 @@ const nextConfig: NextConfig = { permanent: true, }) - /** - * The marketing Academy course/lesson pages were removed; content is - * consolidated into the docs site instead. Old course/lesson slugs have - * no equivalent path there, so every sub-path collapses to the new - * landing page rather than forwarding to a path that may not exist. - */ redirects.push({ source: '/academy/:path*', - destination: 'https://docs.sim.ai/academy', + destination: 'https://docs.sim.ai/introduction', permanent: true, }) diff --git a/scripts/README.md b/scripts/README.md index 460fbb9e237..1d303eff5cc 100644 --- a/scripts/README.md +++ b/scripts/README.md @@ -81,8 +81,8 @@ matching spot in the freshly generated structure. Section labels link to their `index.mdx` overview; the adjacent arrow expands their children. Keep `index` out of a non-root folder's `meta.json` pages array so Fumadocs -uses it as the folder link instead of a duplicate child. Root tabs such as CLI and -Academy still list `index` because their root label is not a sidebar row. +uses it as the folder link instead of a duplicate child. Root tabs such as CLI still +list `index` because their root label is not a sidebar row. Register hand-written integration guides under `guides` in `apps/docs/content/integration-navigation.json`. The key is the existing MDX filename diff --git a/scripts/check-explicit-any.baseline.json b/scripts/check-explicit-any.baseline.json index a3d1cc029b9..a93ad5bc1a9 100644 --- a/scripts/check-explicit-any.baseline.json +++ b/scripts/check-explicit-any.baseline.json @@ -1101,7 +1101,6 @@ "apps/desktop/src/main/local-files.test.ts": 2, "apps/desktop/src/preload/browser/forms.test.ts": 2, "apps/desktop/src/preload/browser/forms.ts": 1, - "apps/docs/lib/academy-captions.test.ts": 1, "apps/docs/lib/integration-navigation.test.ts": 2, "apps/realtime/src/database/operations.ts": 1, "apps/realtime/src/handlers/file-doc-store.test.ts": 57,