Skip to content

Bridge

⚙️ Core Concept: Customizing Workflow Connections

🔑 Key Concepts

  • What is a Bridge? A Bridge is a customizable connector between two blocks in a workflow. It replaces the default INTELLITHING Router Engine and allows you to explicitly define how outputs flow into inputs.

  • Why Bridges?

  • Override default routing.

  • Enable complex workflows.
  • Control data flow, formatting, and transformations.
  • Bridges appear in the Workflow tab next to the Block Editor.
  • They can be dragged into the workflow canvas and connected visually.

⚙️ Bridge Configuration

1. Input and Output Mapping

  • Connects the last node of a block (output) to the first node of another block (input).
  • Overrides default router behavior.
  • Allows multi-agent and multi-connector orchestration.

Example: SQL → Bridge → Slack SQL results are mapped directly to Slack input.

2. Input and Output Formatting & Manipulation

Bridges support lightweight transformations before passing data.

  • Placeholders:

  • {result} – output from the previous block.

  • {user query} – original user query.

  • Use cases:

  • Simple formatting.

  • JSON wrapping.
  • Rich analysis / business logic injection.

📝 Syntaxes

Bridge syntaxes let you reference the outputs of specific modules anywhere in the workflow. All syntaxes are enclosed in curly brackets {}.

There are two main forms:

  1. {output.BLOCKNAME} – The synthesized natural language output from a block.
  2. {raw.output.BLOCKNAME} – The raw data output from a block before it is synthesized.

The key difference between {result} and the above is scope:

  • {result} always refers to the output of the immediately preceding block.
  • {output} and {raw.output} allow you to pull the output from any block in the workflow, not just the previous one.

⚠️ Case Sensitivity for Agents

For agents with dynamic naming, syntaxes are case sensitive. They can be used as follows:

  1. {output.AGENTNAME} – The final synthesized natural language output from the agent.
  2. {raw.output.AGENTNAME} – The raw outputs collected from tools before the agent synthesizes them.
  3. {raw.output.AGENTNAME.TOOLNAME} – The raw data from a specific tool used by the agent.

🧩 Example Scenarios

Example 1 – Agents and Tools

Suppose you have an agent named MyNewAgent with tools MyPdfTool and MySlackTool:

  • {output.MyNewAgent} → The agent’s final synthesized response after tool use and reasoning.
  • {raw.output.MyNewAgent} → A list of raw outputs from all tools used (one or multiple).
  • {raw.output.MyNewAgent.MyPdfTool} → The raw output specifically from MyPdfTool.

Workflow Example:

sql -> bridge1 -> MyNewAgent -> bridge2 -> rag -> bridge3 -> GitHub
  • In bridge3, if you want the SQL output (instead of {result}, which only gives the RAG output), use:
{output.sql}
  • If you want the raw tool data from the agent before synthesis into natural language, use:
{raw.output.MyNewAgent}

Example 2 – Simple Formatting

Here is the output from SQL:  
{result}  

Parse this into JSON before sending to Slack.

Example 3 – Business-Aware Analysis

You are INTELLI-BOT, a proactive strategist.  

Given:  
- User Query: {user query}  
- SQL Result: {result}  

Steps:  
1. Interpret intent.  
2. Classify as 📈 Opportunity, ⚠️ Risk, 🧊 Status Quo, or ❌ Issue.  
3. Provide takeaways.  
4. Suggest next-best action.

Slack Output Example:

🎯 Intent: Analyze churn by plan.  
⚠️ Situation: Risk  
📊 Takeaways: Basic plan has highest churn.  
🛠️ Next-Best Action: Run survey for Basic-tier users.

🛠️ Best Practices

  • Keep transformations minimal to avoid complexity in debugging.
  • Use bridges for data prep, enrichment, and flow control.
  • Chain multiple bridges for layered analysis and formatting.

📌 Summary

Bridges give you precision, flexibility, and power in shaping your workflow. They transform a simple LLM-centric flow into a custom orchestration system tuned for your exact needs.