Tendrl

Docs / Strand / nodes/ai-connectors

AI Connectors

Strand includes built-in AI connectors for OpenAI, Anthropic Claude, and Google Gemini. All three share the same node-level features: prompting, system instructions, MCP tool access, retries, and conversation memory. The only differences are provider-specific settings like API keys and available models.

Node Configuration

Every AI node supports these settings. Provider-specific fields (API key, default model) are configured on the connector itself; see each provider's page for those details.

Field Required Default Description
Prompt Yes `{{ payload \ tojson }}` Prompt sent to the model. Supports Jinja2 templates
System Instructions No - Instructions that set the model's persona and behavior for this node
Model No connector default Override the default model for this specific node
Temperature No connector default Override temperature for this node
Max Tokens No connector default Override max response tokens for this node
Timeout No connector default Override request timeout in seconds (10–600)
Max Retries No 2 Retries on transient errors such as rate limits and server errors (0–5)
MCP Servers No - MCP server connectors to attach as tools for this call
Memory Enabled No false Turn on conversation memory. The AI will remember prior exchanges across workflow runs
Memory TTL No 3600 Seconds to retain conversation history (60–2592000). Resets on each access
Memory Max Messages No 20 Maximum messages to keep in memory. Oldest are trimmed first (2–100)

Temperature

Temperature controls how random or creative the model's responses are. A value of 0 makes the model deterministic: it will give the same answer every time for the same input. Higher values introduce more variation and creativity. The default is 0.7, which works well for general-purpose tasks.

Temperature can be set on the connector (applies to all nodes using it) or overridden per node.

Output

All AI connectors return the same output structure:

json

{
  "success": true,
  "status": "completed",
  "data": {
    "response": "The analysis shows...",
    "model": "gpt-4o-mini",
    "provider": "openai",
    "usage": {
      "prompt_tokens": 150,
      "completion_tokens": 89,
      "total_tokens": 239
    }
  },
  "service": "ai.openai",
  "operation": "chat"
}

When memory is enabled, memory_enabled is included in data:

json

{
  "data": {
    "response": "Sure, picking up where we left off...",
    "model": "gpt-4o-mini",
    "provider": "openai",
    "memory_enabled": true,
    "usage": { ... }
  }
}

Access the response in downstream nodes:

jinja2

{{ payload.data.response }}
{{ payload.data.usage.total_tokens }}

Conversation Memory

By default, each node invocation is stateless: the model has no awareness of previous runs. Toggle Memory Enabled on and the node will remember every exchange, building on previous context the next time the workflow runs. No extra configuration needed.

Each node automatically gets its own isolated memory. Two AI nodes in the same workflow can never accidentally share or overwrite each other's history. Memory is also isolated per account.

When to enable memory:

When to leave it off:

Controlling memory size:

The Memory Max Messages setting limits how many messages are retained. Once the limit is reached, the oldest messages are dropped. Keep this number low for simple tasks and higher for workflows that need longer context.

Tip: When messages are trimmed, early context is lost. If your workflow depends on persistent instructions or rules, put them in the System Instructions field instead; system instructions are sent on every call regardless of memory state and are never trimmed.

Memory TTL:

The Memory TTL controls how long history is kept. After the TTL expires the conversation starts fresh. Use a short TTL (e.g. 3600 = 1 hour) for short-lived tasks and a longer one (e.g. 604800 = 7 days) for ongoing analysis.

Clearing memory:

Use the Clear Memory button in the node inspector to delete all stored history. The AI will start fresh on the next run. This is useful when the conversation has gone off track or accumulated stale context.

Storage note:

Conversation memory is held in fast, ephemeral storage and is not guaranteed to be durable. For critical long-running analysis, persist key findings in downstream nodes rather than relying solely on AI memory.

MCP Tool Access

AI nodes can call external tools via MCP servers. Add one or more MCP server connectors to the MCP Servers field and the model will have access to those tools during its response. Tool calls and results are included in the output when they occur.

Retries

AI nodes automatically retry on transient errors: rate limits (429), server errors (5xx), timeouts, and connection failures. The retry uses exponential backoff with jitter and respects Retry-After headers from the provider. Non-retryable errors (auth failures, bad requests) fail immediately.

Examples

Single-shot classification (no memory)

Ongoing analysis (with memory)

Each time the workflow runs, the AI sees new data along with its prior analysis. It can spot trends, reference earlier findings, and build a richer picture over time.

Multi-step analysis pipeline

Different AI nodes in the same workflow keep separate memories automatically:

Providers

← Back to Strand docs