Scalability
The platform is built so the next deployment is always faster than the previous one. Workflows, components and agents are modular parts any team or region can reuse, so coverage compounds, helping get to superintelligence faster.
Book a demoReusable workflow components
Shared logic can be packaged into a reusable component and then imported across multiple workflows, so the next deployment starts from parts previous deployments already used. Updates to one component reflect instantly across all agents, helping dramatically scale deployments across regions and functions.
- Identity verificationUsed in 14 workflowsPrompt
- GuardrailsUsed in 22 workflowsPrompt
- TMS lookupUsed in 9 workflowsNode
- Send SMSUsed in 17 workflowsNode
- Book engineer visitUsed in 6 workflowsWorkflow
- Address lookupUsed in 12 workflowsNode
Carrier check call
- GuardrailsVersion 6
- Identity verificationVersion 8
- TMS lookupVersion 3
Nested Workflows
One workflow calls another and uses its response, so a hundred-step process runs as a handful of child workflows instead of one monolith. Each child is owned, tested and versioned by the team closest to it, helping large processes keep changing without a full retest every time.
Development environments
Development, staging and production each hold their own active version, credentials and endpoints. Several teams can build and validate at the same time without waiting for a release window or touching the process customers are using right now, so how many people can ship at once is not capped by the risk to live traffic.
Version 14
Draft
Version 13
In test
Version 12
Live
- Credentials
- TMS live key
- Endpoint
- /checks
- Deployed
- Sep 26, 11:02
- Runs today
- 2,140
Role-Based Access Control
Owner, Editor and Viewer roles decide who can edit a workflow, publish to production, or read the data behind it. A new team starts building without routing every change through one central owner, and without being able to touch the parts it does not own, so adding builders does not mean adding risk.
- Edit the workflow
- Publish to production
- Read run data
- Manage members
- Rotate credentials
Agent orchestration
Workflows can be built with an orchestrator agent that can triage and route to sub-agents, each with its own prompt, tools and knowledge, taking control back to re-triage at any point, helping the operation cover more ground without any single agent getting harder to test.
- 01Routed to Scheduling agentVisit moved to Thursday 08:00
- 02Control back to orchestratorSecond request found
- 03Routed to Billing agent over MCPInvoice question handed over
FAQs
One agent with many tools works until the instructions for different situations start competing. Splitting into specialized agents, each with its own prompt, tools, and knowledge, keeps every one of them narrow and testable, with an orchestrator triaging between them. Handoffs can also cross channels, so a voice agent can pass a conversation to a text agent, and external agents can be plugged in over MCP.
A workflow component is imported: the sequence becomes part of the workflow using it. A called workflow is invoked: it runs as its own child run, returns a response, and the parent continues. Import when you want the logic inline and shared; call when you want the child to execute, be monitored, and be versioned independently.
That's the default: update a shared prompt, node, or workflow component in one place and every agent using it reflects the change, with no hunting down individual instances. Where a workflow shouldn't move until you're ready, a called workflow can be pinned to a specific version and environment, so the parent stays on the release it was tested against.
Yes. Each child workflow carries its own timeouts and error handling, so a failure is contained rather than cascading. Every child run is separately observable and rollback-safe, which means you can trace exactly which nested run failed and roll it back without unwinding the parent process around it.
The shared layer sits at the workspace level: the same component library, the same northstars, so every region starts from one standard. Each region then keeps its own workflow versions, environments, and credentials, so local rules and integrations can differ without the deployments diverging from each other.
