Connectors

TL;DR

• Connectors are the bridges between FlowRunner and every third-party service your agents and workflows talk to.
• A connector is built once and used everywhere. The same QuickBooks connector serves the invoice agent, the expense agent, and the reporting agent, without separate work for each.
• New connectors enter the catalog at 30 minutes or less of measured production time. Error rate on those AI-generated integrations is 0.2 percent.
• Connectors carry the data the agents use to decide. They are the substrate that lets the agents that know when to stop and ask a human for help actually know what is happening.

What it means

An agent that handles invoices needs to read invoices from email or a document service, look up vendor records in the accounting system, post journal entries, and send Slack messages when something needs review. None of those actions are part of the AI model or the agent’s logic. They are calls to external services. The thing that lets the agent make those calls is a connector.

A connector does three things:

• Exposes the actions a third-party service offers. The QuickBooks connector exposes “create invoice,” “look up vendor,” “post journal entry,” and the rest of what QuickBooks lets you do through its API.
• Hides the integration mechanics. The agent does not handle authentication, retry logic, rate limits, schema variation between versions, or the dozens of small things that make calling a real service different from calling a documented API. The connector handles those.
• Stays reusable across the orchestration environment. The same connector is called by any agent, any workflow, any flow that needs to talk to that service. There is one connector per service, not one per use case.

The third property is the one that matters most for orchestration. As the number of agents and workflows in an environment grows, the cost of per-use-case integration work grows linearly with it unless connectors are reused. With reuse, the integration work happens once per service, not once per use case.

What it is not

A connector is not an API. The API is what the third-party service publishes. The connector is the FlowRunner-side bridge that consumes the API and exposes its actions in a form agents and workflows can call.

A connector is not an adapter pattern. Adapters in software engineering translate between two interfaces at runtime. Connectors are persistent, reusable, catalog-level entities that the platform manages, not lightweight runtime translators.

A connector is not what other workflow tools call an “integration.” Most workflow automation tools (Zapier, Make) bundle the trigger, the action, the data shape, and the use case into one integration unit. Connectors separate the bridge to the service (one connector) from the use cases that consume it (many agents and workflows).

A connector is not a single action. A connector exposes the set of actions a third-party service offers; an agent picks the actions it needs from the connector and uses them.

How FlowRunner implements it

The connector layer sits underneath the Agent Factory. Both layers are part of the same factory architecture, but they serve different roles: connectors are the bridges, agents are the capabilities composed from them.

Connector production is fast because the factory’s connector-creation tooling does most of the integration work that engineers would otherwise do by hand: reading the third-party API surface, mapping its actions, wiring authentication, handling pagination and error cases. The current measured production time for a new connector is 30 minutes or less, and the error rate on the AI-generated integrations the factory produces is 0.2 percent.

The catalog covers the services FlowRunner’s customers ask for: Salesforce, QuickBooks, NetSuite, Acumatica, Slack, HubSpot, Stripe, ShipBob, Parseur, and many more. New connectors enter the catalog as integration needs surface; a service that does not have a connector today can have one by the end of the day, not the end of the quarter.

Connectors compose with the rest of the orchestration model. A connector is one of the four kinds of building blocks the Agent Factory assembles agents from. An agent assembled from connectors operates under the Code of Conduct governance the platform enforces.

Where the term comes from

Connector is a standard term in software engineering. The choice to use the standard term rather than coining a new one is deliberate. The category we are defining (Orchestration as a Service) is built on terms operations leaders and technical buyers recognize without translation.

What FlowRunner adds to the standard idea is the production-speed expectation and the reuse contract. A connector built in 30 minutes is qualitatively different from a connector built in a month. The first one fits into a workflow where new integration needs are routine. The second one is a special project. The factory’s job is to keep the first model viable as the customer’s environment grows.