Socrates Builder is an autonomous agent that plans, builds, tests, fixes, and maintains production-grade AI agents and workflows on Torq (both agentic and deterministic) through chat. Describe what you need in plain language, and the Builder plans, builds, and validates it with you.
It is the Builder agent on Socrates, Torq's in-platform conversational AI surface. You reach it with the Investigator/Builder toggle at the top: Investigator is Socrates for security investigation, and Builder plans and builds AI agents and workflows.
The Builder works with your actual workspace. It reads your connected integrations, credential status, existing workflows, and execution history. It uses this context, so what it builds fits your environment rather than generic templates.
Where to find it
Open Socrates from the Socrates entry at the top of the left sidebar.
Switch to the Builder with the Investigator/Builder toggle at the top of the page.
The Builder runs in two modes, which you set yourself in the composer: Plan and Build. New chats start in Plan. Switch to Build when you are ready to generate; you control when that happens.
Scope
The Builder operates at two levels: the individual workflow and the broader workspace.
Workflow scope: The Builder can generate a new workflow from scratch, edit an existing workflow, or create nested sub-workflows. When working on a workflow (or several at once), it handles steps, conditions, triggers, error handling, and the integration instances each step uses.
Workspace scope: The Builder is aware of the build-relevant state of your workspace: integrations, credential status, existing workflows, and execution history. It uses this context both to inform Build mode and to make changes across your workspace. For example, you can ask the Builder to swap a Slack integration for every step in every workflow. It processes each workflow to apply the change.
By design, the Builder works within a single workspace and focuses on building and maintenance. It does not access other workspaces in your organization or operational data, such as active cases or Auto Triage configurations.
Prerequisites
Before using the Builder, confirm that the integrations you plan to use are connected and have active credentials. The Builder uses the integrations already connected in your workspace and cannot create or configure integrations. Set up integrations before you start.
Each Socrates chat costs 8 AI Credits, charged when you send a message that starts a chat.
What the Builder can do
This section summarizes key capabilities. For the complete list, including known limitations, see Socrates Builder: Supported Capabilities and Known Limitations.
Generate new workflows: Describe a workflow in plain language, and the Builder builds it, including steps, conditions, error handling, and the integration instances each step uses.
Edit existing workflows: Load an existing workflow, modify it in chat, then review what changed.
Create nested workflows: The Builder can extract reusable patterns into sub-workflows and reference them from a parent workflow.
Operate across your workspace: Make changes that span multiple workflows, such as swapping an integration across every workflow.
Handle unfamiliar integrations: For vendors without an out-of-the-box integration, the Builder can build workflows using HTTP requests and interpret the vendor's payload format.
Upload files and screenshots: Add files and images to provide context or for correction. For example, upload a vendor's API documentation or a screenshot of an error, and ask the Builder to build or fix the relevant workflow.
Follow best practices by default: Generated workflows use Torq best practices (error handling, naming conventions, integration patterns), and the Builder references your existing workflows to stay consistent.
The Builder may not immediately pick up changes you make to a workflow outside the chat (for example, edits in the Workflow Designer) during a session. It works from the version it last read and re-syncs periodically. If you edit a workflow elsewhere mid-session, tell the Builder so it re-reads the current version before continuing.
Plan mode: shape what you want to build
New chats start in Plan mode, and starting here is recommended, especially for complex use cases. In Plan mode, the Builder reviews and analyzes before anything is built. It has read-only access to your workspace and can reference your integrations, workflows, and configuration, but cannot make changes.
In Plan mode, the Builder:
Asks clarifying questions about your intent, trigger type, integrations, and expected behavior.
Identifies the integrations and credentials required.
Proposes a workflow structure for your review.
You can provide as much or as little detail as you want. Both of these starting points work:
High-level intent: "I need a workflow that escalates unassigned cases."
Detailed specification: "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."
With a high-level prompt, the Builder asks follow-up questions to fill in the gaps. With a detailed prompt, it moves faster toward a plan. When you are satisfied with the plan, switch to Build mode.
Build mode: generate and validate the workflow
Switch to Build in the composer, and the Builder generates the workflow based on the plan. You can track progress in the chat as the Builder works through each step: building the workflow, validating it, and saving. In Build mode, the Builder has read and write access to your workspace.
You choose the model in the composer. For the available models, see Socrates Builder: Supported Capabilities and Known Limitations.
How the Builder validates
During generation, the Builder runs an automated validation cycle that checks for structural issues, verifies integration references, and confirms the workflow is configured correctly. If the Builder detects problems, it analyzes the errors, applies fixes, and re-validates automatically. This cycle repeats until the workflow passes validation.
Validation confirms the workflow is structurally sound. To verify end-to-end behavior, you still need to save and test it. You do not need to take any action during validation. If the Builder cannot resolve an issue after multiple attempts, it explains what went wrong and may suggest simplifying the request.
Refine through chat
Before saving, you can keep refining through chat:
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.
Review before saving
When the Builder finishes building, you can review the workflow's structure before deciding how to save it.
Save options
After generation and validation, the Builder asks how you would like to proceed:
Save as draft (recommended): Saves the workflow to your workspace as a draft (not published) so you can inspect it on the Workflow Designer or review it with your team.
Save and test: Saves the draft and immediately runs it so you can verify behavior.
Both options create a draft. Neither publishes the workflow.
Best practice: Use Save and test and push the Builder to verify thoroughly: "Test edge cases," "Verify error handling," "Run additional validation scenarios." The more you push it to test after saving, the more confident you can be before publishing.
When to review manually
After testing, review the workflow before publishing. Automated validation confirms a workflow is structurally sound, and testing confirms it runs, but neither guarantees it does exactly 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 right channels, recipients, and thresholds.
Vendor-specific details: Rate limits, custom payload formats, or authentication requirements you may know about your environment.
Nested workflows: Verify the parent references sub-workflows correctly, and each sub-workflow behaves as expected on its own.
Publish a workflow
Saving creates a draft; publishing is a separate, deliberate step. You can publish it in two ways: ask the Builder to publish it (for example, “publish this workflow”), or publish it yourself from the Workflow Designer after reviewing the draft. Once published, the workflow responds to its configured trigger and runs automatically.
Chats and history
Your Socrates chats are saved and shared across your workspace. You can leave a chat and return to it later, reference what you built earlier, and keep context alive across sessions. Use the chat list to find, rename, and reopen chats, and filter it to All chats or My chats.
For very long or divergent use cases, starting a fresh chat can still help the Builder stay accurate. See Socrates Builder: Prompting and Iteration Guide for how to write a clean handoff summary.
Troubleshooting
The Builder generated a workflow, but publishing fails: Describe the error to the Builder in chat; it will attempt to diagnose and fix the issue.
The Builder does not recognize a connected integration: Verify that the integration is connected and that its credentials are active. If you connect a new integration after starting a session, the Builder may not detect it. Connect the integrations you need before you start.
The Builder cannot resolve a generation failure after retries: Try simplifying your request. Break complex workflows into smaller pieces, or generate a parent workflow and nested sub-workflows separately.