Agent Factory

TL;DR

• The Agent Factory is where new AI agents get built in FlowRunner.
• The agents the factory produces know when to stop and ask a human for help. The pause-and-escalate pattern that makes agents production-ready is built in, not bolted on. Builders get it by default.
• Two modes, same factory: a visual editor for assembling agents step by step, and a Conversational AI for describing the agent in plain language. The chat sits on top of the visual editor and can hand off to manual fine-tuning at any point.
• Agents compose from four kinds of building blocks: connectors, MCP services, other agents, and existing flows. Business logic wires them together. An agent assembled in the factory can include triggers, actions, conditions, and variables, in addition to the agentic capabilities the platform adds on top.
• The factory’s job is to make a deployable, production-ready agent cheap enough to build that operations teams stop treating agent creation as a special project.

What it means

Building an agent used to mean writing Python, wiring tools to a framework, and testing in a notebook. That changed fast. Most business software vendors now ship some kind of agent builder, and the visual-builder experience is table stakes. What separates platforms today is what the agents that come out of them can actually do.

The Agent Factory’s answer is that the agents you build here know when to stop and ask a human for help. Every agent the factory produces has the same escalation pattern built in: pause at uncertainty, route the decision to a human through the right channel, resume on response. The builder does not have to remember to add it; it is there by default. That is what “production-ready” means in the FlowRunner sense, and it is what most other agent builders leave to the builder to figure out.

The factory assembles agents from four kinds of building blocks:

• Connectors. Reusable bridges between FlowRunner and third-party services (Salesforce, QuickBooks, Slack, Acumatica, and many more). Each connector exposes the actions a third-party system offers in a form an agent can call. New connectors enter the catalog as integration needs surface; a connector to a new system typically takes 30 minutes or less to produce.
• MCP services. Model Context Protocol servers. The MCP standard is how the AI industry is converging on a portable way for AI systems to call tools and access data. Agents in the factory consume MCP services directly, the same way they consume native connectors.
• Other agents. An agent assembled in the factory can call other agents as tools. A specialist agent (extract data from a PDF) becomes a building block for a coordinator agent (handle the whole vendor invoice intake process).
• Existing flows. A complete FlowRunner workflow can be invoked from inside an agent as if it were a function. A flow that handles vendor onboarding becomes one step in a larger procurement agent’s job.

Business logic wires these together. Where to branch. When to call a human. What to do on error. Agents in FlowRunner can be substantial structures with triggers, actions, conditions, and variables in addition to the agentic capabilities the platform adds on top. The result is a deployable agent that can be published to the Agent Directory or used directly.

Two modes sit on top of the same factory. The visual editor is for builders who prefer to drag and drop. The Conversational AI is for builders who prefer to describe the agent in plain language; the chat sits on top of the visual editor, so a conversation can hand off to manual fine-tuning at any point. The agent produced is the same regardless of which doorway you walked in through, and the two modes are complementary rather than exclusive.

What it is not

The Agent Factory is not a chatbot builder. Chatbot builders produce conversational interfaces as the deliverable; the chatbot is what the customer ships. The Agent Factory uses a conversational interface (the Conversational AI) as one way to build agents, but what gets built is an agent that takes actions in business systems, not a chatbot. The chat is how you tell the factory what to build, not what the factory builds for you.

The Agent Factory is not a pure workflow builder either, though there is real overlap. An agent assembled in the factory can include triggers, actions, conditions, and variables the same way a traditional workflow does. The factory composes those workflow primitives with agentic capabilities: the agent makes decisions, calls tools, asks for help when it needs to, and can be called by other agents in turn. The unit is an agent that contains workflow logic, not a workflow that contains nothing else.

The Agent Factory is not a code generator. It does not produce Python or TypeScript for the builder to maintain. The agent is a first-class FlowRunner entity, deployed and run by the platform.

The Agent Factory is not a thin wrapper over LangChain or another agent framework. The agent the factory produces is native to FlowRunner’s orchestration model, including human-in-the-loop as a callable tool and the Code of Conduct governance the platform enforces.

How FlowRunner implements it

The factory operates in two layers.

The first layer is connectors. Each connector is a discrete, reusable bridge to an external service. Connector production is fast because the factory’s connector-creation tooling does much of the integration work that engineers would otherwise do by hand: reading the third-party API surface, mapping its actions, wiring authentication. 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 second layer is agents. An agent assembled in the factory bundles connectors, MCP services, other agents, and existing flows together with business logic. The bundle becomes a single deployable unit.

The unit composes. An agent built today can be a building block in another agent tomorrow. A flow that handles a specific business process can be invoked from any agent that needs that process as a step. This composability is what makes the factory more than a faster way to build one agent. It is a way to grow a library of capabilities that build on each other.

Agents the factory produces are published to the Agent Directory for reuse, or deployed directly into a customer’s environment.

Where the term comes from

The factory metaphor is deliberate. Factories produce instances of a designed product, repeatably, at a cost that scales. The naming signals that agent creation in FlowRunner is high-volume and routine, not an artisanal one-off.

The naming also reflects what makes the FlowRunner approach different from the agent builders most business platforms now offer. Single-vendor agent builders (the ones inside CRM, ERP, or marketing platforms) tend to produce agents that work inside that vendor’s walls. The Agent Factory produces agents that work across systems, compose with each other, and run under the same governance regardless of which vendor’s data they touch. The unit (a deployable agent) is the same; the orchestration environment it lives in is different.

The Agent Factory is one of three pillars of Orchestration as a Service. It is where agents enter the orchestration environment. The other two pillars, the Agent Directory and the Code of Conduct, handle what happens to agents once they exist.