Agent

The Agent block serves as the interface between your workflow and Large Language Models (LLMs). It executes inference requests against various AI providers, processes natural language inputs according to defined instructions, and generates structured or unstructured outputs for downstream consumption.

Overview

The Agent block enables you to:

Configuration Options

System Prompt

The system prompt establishes the agent's operational parameters and behavioral constraints. This configuration defines the agent's role, response methodology, and processing boundaries for all incoming requests.

You are a helpful assistant that specializes in financial analysis.
Always provide clear explanations and cite sources when possible.
When responding to questions about investments, include risk disclaimers.

User Prompt

The user prompt represents the primary input data for inference processing. This parameter accepts natural language text or structured data that the agent will analyze and respond to. Input sources include:

• Static Configuration: Direct text input specified in the block configuration
• Dynamic Input: Data passed from upstream blocks through connection interfaces
• Runtime Generation: Programmatically generated content during workflow execution

Goal

Use the optional Goal field when the Agent should achieve an outcome rather than answer a single prompt. The goal is added to the normal Agent conversation; the same Agent block still owns model selection, memory, structured output, and platform tools. Its built-in shell and file tools run inside the isolated turn, so a goal can ask the Agent to clone a repository, install dependencies, run a build, and report only results it actually observed.

Model Selection

The Agent block doesn't reference a vendor by name. It declares a need for the LLM capability and the platform's integration registry resolves the request against installed providers — first by per-call override, then by org policy, then by automatic pick across installed vendors.

Vendors that contribute the LLM capability today:

• Anthropic — Claude family via the Messages API
• OpenAI — GPT family via openai-chat-v1
• Mistral — Mistral models via openai-chat-v1
• AWS Bedrock — foundation models via bedrock-converse-v1
• Azure AI Foundry — per-org deployed models
• Google Cloud (Vertex AI) — Gemini via openai-chat-v1
• Ollama — local LLMs via OpenAI-compatible endpoint
• vLLM — self-hosted high-throughput inference

Temperature

Control the creativity and randomness of responses:

The temperature range (0-1 or 0-2) varies depending on the selected model.

Model

Choose Default to use the model configured under Settings → Platform → Defaults, or select a model to override it for this workflow. Default stores no model value. The Agent block has no connection or credential selector: the platform automatically resolves an eligible connection for the active environment on every model turn.

API keys and OAuth account identifiers never live in the Agent block or execution payload. LLM API boundaries reject caller-supplied credential fields instead of dispatching with them.

On either execution-fabric path, the Agent runner receives only execution-scoped grants. The callback forwards the credential-free turn to api-platform; credentials and provider dispatch remain outside Agentic and outside the runner. The execution trace records whether this invocation was bound to microvm or the explicitly weaker managed_process tier.

Tools

Tools extend the agent's capabilities through function calling. Tools come from vendor products — never from a flat global pool. When you click "Add tools" on the Agent block you pick from the installed vendor catalog: each product contributes its own toolset (e.g. google:gmail contributes send-mail, list-messages, …; scrydon:knowledge contributes knowledge-rag-search).

Executable blocks in the workflow's Core category also appear automatically under Blocks: A2A, API, Create Process Instance, Create Process Task, Function, Knowledge, Memory, Search (web search), SFTP, SSH, Storage, Table Write, Translate, and Workflow. Recursive and special-purpose blocks (Agent, Evaluator, Router, and Workflow Input) are intentionally omitted. MCP tools remain available through their dedicated server entries.

Every Agent also receives four sandbox tools automatically: run_shell, read_file, write_file, and list_dir. They execute inside the bound Agent runner, share one ephemeral /workdir for the duration of that turn, and return observed output to the model. The image includes common development utilities such as Git, curl, grep/ripgrep, Node.js/npm, Python, jq, archive tools, and native build tooling.

Network access remains governed by your organization's IT egress policy. Workflow authors cannot widen that policy from an Agent block. Installing a CLI does not grant it unrestricted network access, and the workspace is discarded after the turn.

Provider and standard tool credentials stay server-side. Credential-free tools can use an isolated runner when their dispatcher supports it; credential-bearing vendor/custom tools refuse when isolation is required until they have a brokered, execution-scoped credential contract. Agent-configured MCP tools also refuse before discovery or network I/O when isolation is required. Only the standalone workflow activity for an exact administrator-allowlisted, credential-free HTTPS MCP server has a runtime-plane route today. The trace's selected isolation tier is the proof for a particular execution.

Tool integration process:

1. Open the Tools section on the Agent block
2. Pick a vendor product from the installed catalog
3. Add one or more of the product's tools and (where required) configure a credential

Where tools come from:

• Built-in: see scrydon — Knowledge, Memory, Storage, Tables, Workflow, Web, SMTP, SMS, Guardrails, A2A, SSH
• Productivity & storage: Google, Microsoft, Atlassian, GitHub, Salesforce, …
• Custom: build your own with the Integrations Authoring SDK and upload through Settings

Tool Execution Control:

• Auto: Model determines tool invocation based on context and necessity
• Required: Tool must be called during every inference request
• None: Tool definition available but excluded from model context

Response Format

The Response Format parameter drives structured output generation through JSON Schema validation, producing consistent, machine-readable responses that conform to predefined data structures.

When a Response Format is set, the runtime instructs the model to emit JSON matching your schema, tolerantly extracts the JSON from the reply (including markdown-fenced output), and — if the first reply doesn't parse — makes one automatic corrective attempt. If the model still cannot produce conforming JSON, the agent's text answer is preserved and surfaced rather than discarded, so a response is never silently lost.

{
  "name": "user_analysis",
  "schema": {
    "type": "object",
    "properties": {
      "sentiment": {
        "type": "string",
        "enum": ["positive", "negative", "neutral"]
      },
      "confidence": {
        "type": "number",
        "minimum": 0,
        "maximum": 1
      }
    },
    "required": ["sentiment", "confidence"]
  }
}

This configuration constrains the model's output to comply with the specified schema, preventing free-form text responses and ensuring structured data generation.

Accessing Results

After an agent completes, you can access its outputs:

• <agent.content>: The agent's response text or structured data
• <agent.tokens>: Token usage statistics (prompt, completion, total)
• <agent.tool_calls>: Details of any tools the agent used during execution
• <agent.cost>: Estimated cost of the API call (if available)

Advanced Features

Memory Integration

Agents can maintain context across interactions using the memory system:

// In a Function block before the agent
const memory = {
  conversation_history: previousMessages,
  user_preferences: userProfile,
  session_data: currentSession
};

Structured Output Validation

Use JSON Schema to ensure consistent, machine-readable responses:

{
  "type": "object",
  "properties": {
    "analysis": {"type": "string"},
    "confidence": {"type": "number", "minimum": 0, "maximum": 1},
    "categories": {"type": "array", "items": {"type": "string"}}
  },
  "required": ["analysis", "confidence"]
}

Error Handling

Agents automatically handle common errors:

• API rate limits with exponential backoff
• Invalid tool calls with retry logic
• Network failures with connection recovery
• Schema validation errors with fallback responses

Inputs and Outputs

Example Use Cases

Customer Support Automation

Multi-Model Content Analysis

Tool-Powered Research Assistant

Best Practices

• Be specific in system prompts: Clearly define the agent's role, tone, and limitations. The more specific your instructions are, the better the agent will be able to fulfill its intended purpose.
• Choose the right temperature setting: Use lower temperature settings (0-0.3) when accuracy is important, or increase temperature (0.7-2.0) for more creative or varied responses
• Leverage tools effectively: Integrate tools that complement the agent's purpose and enhance its capabilities. Be selective about which tools you provide to avoid overwhelming the agent. For tasks with little overlap, use another Agent block for the best results.