Overview
Describe a workflow in plain language, and Builder plans it, generates it, validates it, and fixes what breaks. It works on new workflows, workflows built in the Workflow Designer, and failed executions. It also builds and edits AI Agents.
Builder runs in two modes. Plan shapes the approach. Build generates the workflow.
Scope
Builder operates at two levels.
Workflow scope: Builder generates a new workflow, edits an existing one, or creates nested sub-workflows. It handles steps, conditions, triggers, error handling, and the integration instance each step uses.
Workspace scope: Builder is aware of the build-relevant state of your workspace, including integrations, credential status, existing workflows, and execution history. It uses that context to make changes across workflows. For example, ask it to swap a Slack integration for every step in every workflow, and it processes each one.
Builder works within a single workspace and focuses on building and maintenance. It does not extend to other workspaces in your organization or to operational data such as active cases and Auto Triage configurations. For investigation and case work, use Investigator.
What Builder can do
Generate workflows from natural language: Describe the use case, and Builder creates the steps, conditions, triggers, error handling, and integration configurations. Workflows can range from a single step to a multi-step process with branching logic and enrichment from several sources.
Edit existing workflows: Load a workflow by name or ID, describe the changes, and Builder applies them. Complex workflows may need manual correction after loading.
Create nested workflows: Builder extracts reusable logic into sub-workflows and references them from a parent workflow.
Build multi-workflow systems: Builder can create several workflows in one chat to cover a complete use case, identifying the components required and building each one.
Create and edit AI Agents: Builder configures an AI agent's model, instructions, parameters, tools, and output schema. It can also migrate legacy workflow agents to AI Agents. See Build an AI Agent with Socrates below.
Write custom logic to shape data: Builder writes JQ transformations, Transform Data logic, and conditional and loop logic to route data between steps. It can also generate formatted output such as HTML.
Handle unfamiliar integrations: For vendors without a native integration, Builder constructs HTTP request steps against the vendor's API. Provide the API documentation or payload format.
Operate across your workspace: Builder can apply a change that spans multiple workflows, processing each one in turn.
Analyze failed executions: Builder explains what went wrong and can apply fixes directly. Ask it to review recent executions across the workspace, for example, "review all failed executions from the past 24 hours," and it finds and triages them. This works on any workflow, including ones built in the Workflow Designer.
Upload files and screenshots: Click Attach file to add up to 3 files per message, each up to 5 MB.
Known limitations
Set up integrations before starting a chat: Builder generates workflows and steps, but cannot create or configure integrations. If you connect a new integration mid-chat, Builder may not detect it.
Use HTTP request steps for missing vendor steps: Builder works with the steps in its catalog. If a vendor step is unavailable, ask Builder to use an HTTP request step instead.
Start a fresh chat for long or complex use cases: For use cases with many iterations, a fresh chat helps Builder stay accurate. See Hand off to a new chat below.
Grant write access for the workflow entry points: The entry points in the Workflow Designer and the Workflows list require Builder write permissions, not just read. A user without access to Builder does not see them.
Changes made outside the chat are not picked up immediately: Builder works from the version it last read and re-syncs periodically. If you edit a workflow elsewhere mid-chat, tell Builder so it re-reads the current version.
How to use
For chat access, collaborators, and the chat list, see Socrates: Chat with AI Agents.
Open Builder
Open Socrates: Click Socrates at the top of the left sidebar.
Select the agent: Select Builder from the agent picker.
To start from the Workflows list instead, click Create > Build with Socrates for a new workflow, or open an existing workflow's three-dot menu and click Build with Socrates to load it into a new chat.
Work on a workflow from the Workflow Designer
When a workflow is open in the Workflow Designer, hand it to Builder without describing it first. Builder opens in a new browser tab with the workflow in context, so the prompt only needs to cover what you want changed. Unsaved changes are saved as a draft first, so Builder works from the version on your screen.
The first time you do this, a notice explains that Socrates uses AI Credits.
Add to or change the workflow
Click Build with Socrates on the toolbar at the bottom of the Workflow Designer, then describe what you want. To scope the request more narrowly:
One step: Click the Socrates icon in the Step Properties header, labeled Build this step with Socrates.
A specific point in the flow: Click the + between two steps, then click Build with Socrates at the bottom of the Add Steps popover.
Investigate a run that failed
When a run fails while you are working on the workflow, a notification appears at the bottom of the Workflow Designer. Click Solve with Socrates. Builder opens with that execution in context, explains what went wrong, and can apply a fix.
To work from one step instead, or if you dismissed the notification, open the step's Execution Log tab and select the failed execution. Solve with Socrates appears beside the error message.
Shape the request in Plan mode
Set the mode in the composer. A chat you start yourself begins in Plan. A chat opened from a workflow may start in either mode, depending on the entry point. The composer shows the current mode, and you can change it.
Starting in Plan mode is recommended, especially for complex use cases. In Plan mode, Builder:
Asks clarifying questions about intent, trigger type, integrations, and expected behavior.
Identifies the integrations and credentials required.
Proposes a workflow structure for review.
The more the first prompt covers, the fewer rounds of clarification it takes. Include:
The trigger type, such as webhook, scheduled, on-demand, or internal event.
The integrations to use, by name.
The expected input format or data source.
What to do with the results, such as create a case, send a notification, or generate a report.
Any thresholds, conditions, or branching logic.
For example: "Build a scheduled workflow that checks for open cases with no assignee every five minutes. If a case has been unassigned longer than the SLA threshold, change its severity to High, assign it to the on-call analyst using the PagerDuty integration, and send a notification to #soc-escalations in Slack with the case ID, title, and time since creation."
Builder asks about anything left out, so a high-level prompt such as "I need a workflow that escalates unassigned cases" also works. It takes more back-and-forth.
Plan mode also helps when the scope is still unclear. Ask, for example, "What integrations in my workspace could I use for a daily threat intel digest?" Builder answers from your workspace, not from a generic list. Review the proposed structure, push back on anything that doesn't align with your intent, and switch to Build when the plan looks right.
Generate and validate in Build mode
Switch to Build in the composer, and Builder generates the workflow from the plan. Track progress in the chat as it builds, validates, and saves. In Build mode, Builder has read and write access to your workspace.
Select the model in the composer:
Claude Sonnet 5: Balance of speed and intelligence for most tasks.
Claude Haiku 4.5: Fastest responses, for simple and repetitive tasks.
Claude Opus 5.5: Long-running agentic work.
How Builder validates
During generation, Builder runs an automated validation cycle. It checks for structural issues, verifies integration references, and confirms the workflow is configured correctly. When it detects a problem, it analyzes the error, applies a fix, and re-validates. The cycle repeats until the workflow passes.
Validation confirms the workflow is structurally sound. To verify end-to-end behavior, save and test it. No action is needed during validation. If Builder cannot resolve an issue after several attempts, it explains what went wrong and may suggest simplifying the request.
Refine through chat
Before saving, keep refining:
Add or remove steps.
Change integrations, for example, swap VirusTotal for AbuseIPDB.
Adjust conditional logic or error handling.
Wrap reusable patterns as nested workflows.
Modify the trigger type or configuration.
When requesting a change, describe what you see, what you want instead, and where. For example: "The Slack notification is going to #general. Change it to #soc-alerts, and include the case ID and severity in the message body." Feedback such as "fix the logic" does not give Builder enough to act on.
Build complex workflows in stages
For larger use cases with several integrations or branching logic, start with the core workflow, verify it, then add one layer at a time:
Start with the core logic: "Build a workflow with a webhook trigger that extracts URLs from the payload body and enriches each one with VirusTotal."
Add conditions: "If the VirusTotal score is above 70, create a case. Otherwise, log the result and continue."
Add error handling: "If the VirusTotal call fails, skip that URL, log the error, and continue with the next one."
Add notifications: "Send a Slack summary to #soc-alerts after all URLs are processed."
Each stage produces a testable result, so a failure points to the change that caused it. For use cases that need several workflows, build and verify the primary workflow first, then the supporting ones.
Save the workflow
After generation and validation, Builder asks how to proceed:
Save as draft (recommended): Saves the workflow as a draft so you can inspect it in the Workflow Designer or review it with your team.
Save and test: Saves the draft and runs it immediately to verify behavior.
Both options create a draft. Neither publishes the workflow.
Test the workflow
To test a workflow, Builder runs it. A test run executes the workflow's steps against the integration instances configured for the workflow, exactly as a normal run does, and Builder reports the results. Each test run appears in the workflow's execution history.
You can also select Test with Socrates from the Test Run dropdown in the Workflow Designer.
Ask for specific scenarios rather than general checks. For example:
"Test what happens if the webhook payload is missing the sender field."
"Run the workflow with a URL that returns a VirusTotal score of 0. Verify that no case is created."
"Test with a payload that contains 50 URLs. Does the loop handle all of them?"
Test runs use your connected integrations and can have real effects on the systems they reach, such as creating tickets, sending messages, or changing records. Before testing a workflow that writes to production systems, check which steps will run, or point them to a test instance.
Review before publishing
Validation confirms a workflow is structurally sound, and testing confirms it runs. Neither guarantees it does what you intended. Review is especially important for:
Complex conditional logic: Branching, loops, or multiple decision points. Verify each path handles the expected scenarios.
Sensitive operations: Workflows that create cases, send notifications, modify records, or touch production systems. Confirm the channels, recipients, and thresholds.
Vendor-specific details: Rate limits, custom payload formats, or authentication requirements specific to your environment.
Nested workflows: Verify that the parent references sub-workflows correctly, and each sub-workflow behaves as expected on its own.
Publish the workflow
Saving creates a draft. Publishing is a separate, deliberate step. Publish in one of two ways:
Ask Builder to publish it, for example, "publish this workflow."
Publish it yourself from the Workflow Designer after reviewing the draft.
Once published, the workflow responds to its configured trigger and runs automatically.
Hand off to a new chat
Chats are saved, but a long chat with many pivots can carry over old decisions. When Builder keeps referencing steps or logic you already removed, start a new chat with a short handoff summary:
The workflow ID or name, so Builder can import it.
What the workflow currently does.
What to change or add next.
For example: "Import workflow <name>. It currently receives a webhook, enriches URLs with VirusTotal, and creates cases for anything that scores above 70. I want to add CISA KEV correlation before the case-creation step."
Build an AI Agent with Socrates
Create an agent: In a Builder chat, describe the agent you need, for example, "Build an AI Agent that enriches IOCs from phishing alerts with VirusTotal and returns a verdict." Refine it through chat until it does what you need. Builder configures the agent's role, instructions, parameters, tools, and output, then saves and publishes it. To start from the AI Agents page or a workflow instead, see Build an AI Agent with Socrates.
Edit a published agent: Open the agent on the AI Agents page and click Edit With Socrates.
Security and data privacy
Reference credentials by name
Builder sees which integrations and credentials are connected and references secrets by name. It does not access or read credential values such as API keys, tokens, or secrets. Secrets are resolved at runtime.
Track changes in the Activity Log
Workflows Builder creates or modifies and are recorded in the Activity Log.
How permissions are enforced
Builder operates entirely within the permissions of the user running it. It has no separate or elevated access, and cannot perform an action you are not authorized to perform or bypass your workspace's access controls. When Builder encounters a permission-denied error, it surfaces it in the chat. To give Builder broader access, assign the user a custom role with the additional permissions.
Troubleshooting
Builder generated a workflow, but publishing fails.
Describe the error to Builder in chat. It attempts to diagnose and fix the issue.
Builder does not recognize a connected integration.
Verify the integration is connected and its credentials are active. If you connected it after starting the chat, Builder may not detect it. Connect integrations before you start.
Builder cannot resolve a generation failure after retries.
Simplify the request. Break complex workflows into smaller pieces, or build in stages.
Builder cannot complete an action because of a permissions error.
Builder never exceeds your own permissions. Ask your workspace admin for a custom role with the access you need.
Additional documentation
Socrates: Chat with AI Agents: Select an agent, manage chats, and control access.
Socrates Investigator: Investigate Threats Outside a Case: Investigate threats and take action without opening a case.
Build an AI Agent with Socrates: Create and configure an AI Agent using Builder.
AI Agents: Bring Adaptive Intelligence Across Torq: Build, publish, and manage AI Agents.