Skip to main content
Before building a plugin, understand when plugins are the right choice versus connectors or builtins. This guide helps you make the decision.

Quick Decision Tree

Plugins: Custom Compute Logic

Use a Plugin when you need custom computation, processing, or orchestration within Noorle.

When to Use Plugins

✅ Custom data transformation algorithms ✅ Complex business logic calculations ✅ Multi-step workflows without external APIs ✅ Proprietary algorithms you want to keep isolated ✅ Processing sensitive data in a sandbox ✅ Combining multiple APIs into a single tool

Example: Text Analysis Plugin

You want agents to analyze sentiment in user messages:
1. Implement sentiment analysis algorithm
2. Compile to WebAssembly
3. Deploy as plugin
4. Agents call: my_sentiment_analyzer
5. Result: Custom logic runs safely in sandbox

Advantages

  • Complete control - Implement exactly what you need
  • Isolated execution - Runs in secure sandbox
  • No external dependencies - Pure compute
  • Low latency - In-process execution
  • Versioning - Easy to iterate and rollback

Disadvantages

  • Development overhead - Must write and test code
  • Language lock-in - Supported languages only (Rust, Python, TypeScript, Go)
  • Maintenance burden - Responsible for updates
  • Testing complexity - Need test environments

Connectors: External Services

Use a Connector when you need to integrate with external APIs or services.

When to Use Connectors

✅ Integrate with third-party SaaS (Slack, Airtable, etc.) ✅ REST API consumption ✅ Cloud service integration ✅ MCP server proxying ✅ OAuth-secured services ✅ Frequently-changing external APIs

Example: Airtable Integration

You want agents to read/write Airtable bases:
1. Create REST connector pointing to Airtable API
2. Define operations (GET /bases/{id}, PATCH /records)
3. Agents call: airtable_read_records
4. Connector handles HTTP, authentication, response parsing

Advantages

  • No code required - Configure via UI
  • Built-in auth - OAuth, API keys, bearer tokens supported
  • API abstraction - Hide complexity behind simple tools
  • Ecosystem reuse - Connect to 1000s of existing APIs
  • Dynamic updates - Update without redeployment

Disadvantages

  • External dependency - Relies on third-party API availability
  • Latency - Network round-trip required
  • Rate limits - Subject to API quotas
  • Less control - Limited customization beyond parameter mapping

Built-ins: Standard Features

Built-ins are built into Noorle and not user-installable. They include:
Built-inPurpose
FilesRead/write files, manage workspace
Web SearchSearch the internet
HTTP ClientMake HTTP requests
Code RunnerExecute Python, JavaScript, Bash
Knowledge RetrievalQuery knowledge bases with RAG
SandboxIsolated Linux VM execution
ComputerScreen capture, mouse, keyboard (agent-only)
BrowserBrowser rendering

When Built-in vs Plugin

Request a builtin if:
  • Multiple users need this feature
  • It’s a fundamental capability (like files or code execution)
  • You want Noorle to maintain and support it
Use a plugin if:
  • It’s specific to your use case
  • You need custom behavior or logic
  • You want ownership and control

Example: Should I Build or Use Existing?

Scenario: "I need to extract entities from text"

Option 1: Plugin
- Implement NER algorithm in Rust/Python
- Full control, can customize for domain
- Only you maintain it
- Ideal if: You have proprietary ML models or special domain

Option 2: Connector
- Use spaCy or similar NLP APIs
- No code needed
- Third-party maintains it
- Ideal if: Existing service meets your needs

Option 3: Built-in (Code Runner)
- Execute spaCy/transformers in Python builtin
- Quick and simple
- Limited to available libraries
- Ideal if: Standard libraries are sufficient

Comparison Matrix

AspectPluginConnectorBuilt-in
Setup ComplexityHighLowN/A
DevelopmentCode requiredConfig onlyN/A
ExecutionIn-processNetwork callIn-process
LatencyLowMediumLow
CustomizationCompleteLimitedFixed
External DepsNoneRequiredBuilt-in
MaintenanceYouYou + ProviderNoorle
Supported LanguagesRust, Python, TS, GoN/ARust
Resource ControlYes (sandbox)API limitsYes (builtin)

Common Use Cases

”I want to add data processing”

Use a Plugin
  • Custom algorithms, transformations
  • Offline processing

”I want to integrate with Salesforce”

Use a Connector
  • REST/OAuth integration
  • No code needed

”I want agents to run Python code”

Use Built-in Code Runner
  • Already available
  • Execute arbitrary Python

”I want custom Salesforce logic”

Use a Plugin
  • Complex orchestration
  • Custom business rules
  • Call Salesforce via HTTP within plugin

”I want web search integration”

Use Built-in Web Search
  • Already available
  • No configuration needed

Decision Checklist

Before building a plugin, ask yourself:
  • Does a similar builtin already exist?
  • Is there a public API I could use via connector?
  • Do I need custom compute logic?
  • Will this logic be reused across my organization?
  • Can I maintain this code long-term?
  • Do I need to keep the algorithm private/isolated?
  • Is latency critical (plugins are faster)?
  • Do I have the technical resources to develop it?
If you answered yes to 3+ of the last 6 questions, a plugin is probably the right choice.

Getting Help

Need guidance on your specific use case?

Next Steps