Feature Spotlight: How connectors let you swap tools without changing pipelines

Connectors are the bridge between Modulo pipelines and your tools. Each connector wraps an external API in a sandboxed interface that agents can call during a pipeline run. When you connect a GitHub repository, an agent can create pull requests, comment on issues, and trigger Actions workflows - all through a typed interface that validates every call. The agent never sees your API token. The pipeline never hardcodes the tool.

In short

• What it does: connectors give agents access to external tools (GitHub, GitLab, Linear, Notion, filesystems, any REST API) through a sandboxed, credential-secured interface.
• When you would use it: any pipeline that needs to read from or write to an external system - creating PRs, updating tickets, reading files, calling APIs.
• When you would not: pure computation agents that never touch external systems (classification, summarization, analysis).
• Credentials are decrypted once at run-start and never enter agent state, logs, or checkpoints.

The problem it solves

Say you run a pipeline that drafts pull request descriptions. The agent needs to read the diff from GitHub, write a description, and post it as a PR comment. Without connectors, you have two bad options: hardcode a GitHub token into the agent's prompt (a security risk that violates every credential policy), or skip the integration entirely and have a human copy-paste the diff into the agent and post the result by hand.

Both options break down at scale. Hardcoded tokens rotate quarterly and silently break pipelines. Manual copy-paste defeats the purpose of automation. The real problem is that agents need tool access, but tool access requires credentials, and credentials must not leak into agent state, logs, or checkpoints. A connector solves this by decrypting the credential once at run-start, passing it to the agent in a transient context object, and ensuring it never touches anything persistent.

How it works

Supported connectors

Modulo ships with connectors for the most common developer tools:

• GitHub - repositories, issues, pull requests, Actions workflows, labels, milestones
• GitLab - projects, merge requests, CI pipelines
• Linear - issue tracking
• Notion - databases and pages
• Filesystem - reads and writes files within a restricted base path (chrooted)
• Custom HTTP - any REST API can be wrapped as a connector

Credential security

Modulo encrypts connector credentials at rest with Fernet symmetric encryption. Credentials are decrypted once at run-start into a run-scoped context object and never written to LangGraph state, checkpoint blobs, logs, or OpenTelemetry spans. The agent receives the decrypted credential in-process only, uses it for the API call, and does not serialise it.

This matters because agents are expensive to run and their outputs persist in checkpoints. If a credential leaks into a checkpoint, it survives in the database until the checkpoint is garbage-collected. Connectors prevent this entirely.

The HTTP adapter

Any REST API can be wrapped as a connector using the HTTP adapter. You configure the base URL, authentication headers, and allowed paths. The agent can only call endpoints you have explicitly permitted - no wildcard access, no open-ended HTTP calls.

{
  "type": "http",
  "config": {
    "base_url": "https://api.example.com",
    "headers": {
      "Authorization": "Bearer ..."
    },
    "allowed_paths": ["/v1/items", "/v1/search"]
  }
}

Swapping connectors

Because every connector implements the same interface, you can swap the tool without changing the pipeline. Switch from GitHub to GitLab by changing the connector binding - the agent code stays identical. This is the principle of typed seams applied to tool access.

Journey example: before and after

Before

Imagine a platform team (led by a manager named Priya) that maintains 12 pipelines, each hardcoded with GitHub tokens. Every quarter, when the tokens rotate, Priya's team updates each pipeline individually. One pipeline uses a different token format that breaks silently. It runs for two weeks before anyone notices the PR comments stopped appearing. The team spends a day debugging before they find the stale token.

After

Priya's team configures a single GitHub connector with the token. Every pipeline that needs GitHub access binds to that connector. Token rotation happens in one place. The stale-token pipeline breaks immediately (the connector health check catches it), and the team gets a notification before any pipeline runs fail. What used to be a quarterly fire drill is now a one-click credential update.

When to use it vs. when not to

Use connectors for any pipeline step that reads from or writes to an external system. The connector gives you credential security, access control (allowed paths), and the ability to swap tools without changing agent code.

Do not use connectors for pure computation agents. A classifier that reads text and returns a label does not need tool access - adding a connector adds complexity for no benefit. Similarly, do not wrap internal APIs as connectors unless they carry sensitive credentials. If the API is on your own infrastructure with no external credentials, a direct HTTP call in the agent prompt is simpler.

Where it fits in a pipeline

Connectors sit at the tool-access layer. An agent receives a prompt, calls the connector to read or write data, and produces output. The connector handles authentication, access control, and credential lifecycle. For the governance layer that validates what the agent produces, see Feature Spotlight: How HITL gates stop bad agent output before it ships. For the broader context, see the principles of Modulo.

Go deeper

Read the Connectors docs for the full connector configuration, or the related docs on pipelines and secrets. Try the hosted demo at demo.modulo.run, or use the contact page to talk to us about connecting your tools.