Agent Directory

TL;DR

• The Agent Directory is where pre-built AI agents live, ready to deploy.
• Every agent in the directory inherits the same guarantee: it knows when to stop and ask a human for help. Installing an agent does not mean inheriting someone else’s risk.
• A directory entry is a complete agent, not a template. You install it and use it; you do not assemble it.
• Today, FlowRunner authors the directory. The forward direction is partner-authored and community-authored agents alongside.
• The reuse pattern is intentional. An agent designed once should be deployable into many customer environments with configuration rather than re-construction.

What it means

The Agent Directory is the catalog of agents available to FlowRunner customers. A directory entry has three properties that distinguish it from a template or a sample:

• It is deployable. A directory entry can be installed into a customer environment and start doing its job. No assembly required.
• It is parameterized. The same agent serves many customers because it is configurable. The customer supplies the integrations, the data sources, and the policies; the agent supplies the capability.
• It is governed. Every agent in the directory operates under the same Code of Conduct the platform enforces on agents built in the Agent Factory. The governance does not depend on who authored the agent.

The category we are defining (Orchestration as a Service) treats agents as a unit of value that should be produced once and reused many times. The directory is the place that reuse happens.

The vision is that the directory grows along three axes:

• FlowRunner-authored agents for common patterns we know our customers need. This is what exists today.
• Partner-authored agents built by consultants, system integrators, and specialist vendors. The Midnight Flow consulting arm and FlowRunner partners are the natural authors here.
• Community-authored agents built by FlowRunner customers and made available to others.

The forward-state agents (partner and community) are how the directory becomes a leverage layer for the whole ecosystem rather than a starting point library FlowRunner ships.

What it is not

The Agent Directory is not a template library. Templates require assembly. Directory entries do not. The distinction matters because the customer’s question shifts: not “how do I build this” but “which one do I deploy.”

The Agent Directory is not the integrations catalog. The integrations catalog lists what FlowRunner can talk to (Salesforce, QuickBooks, Acumatica, and so on). The directory lists agents that do specific jobs across those integrations.

The Agent Directory is not a marketplace, in the sense of a transactional storefront with buy buttons. The framing is directory deliberately. The point is discoverability and reuse, not commerce. Pricing and packaging belong to FlowRunner’s tiers, not to individual directory entries.

The Agent Directory is not the same as the Agent Factory. The factory is where agents get built. The directory is where they are kept for reuse. The two are related but separate: not every agent built in the factory has to be published to the directory, and not every agent in the directory has to be built in the factory.

How FlowRunner implements it

Today, the directory contains FlowRunner-authored agents covering common operations patterns: vendor invoice intake, expense exception routing, document extraction, sales handoff coordination, and similar jobs. A customer installs an agent from the directory, supplies the connectors and policies relevant to their environment, and runs it.

The technical mechanics:

• Parameterization. Every directory entry exposes the configuration points the customer needs to provide: which CRM, which accounting system, which Slack channel, what threshold for human review.
• Composability. A directory agent can be invoked from another agent built in the Agent Factory, the same way any agent can call any other agent.
• Versioning. Directory entries are versioned. A customer’s deployment of an agent stays on the version they installed; upgrades are explicit.
• Governance. Directory agents run under the Code of Conduct the same as any other agent in the orchestration environment.

The forward direction (partner and community authoring) is what makes the directory a leverage layer. The architecture supports it today; the authoring program and the publication pipeline mature as the customer base and partner network grow.

Where the term comes from

The choice of directory over marketplace or library is positioning work.

Library implies passive collection. The directory is more active than that. Entries are deployable, not just downloadable.

Marketplace implies transactions and storefronts. The directory does not lean on commerce as the organizing principle. Pricing is a tier-level decision in FlowRunner, not a per-entry one.

Directory sits in the middle: a curated, discoverable, organized set of capabilities that customers and partners and (eventually) community members contribute to and draw from. The closest analog is an enterprise software catalog or an enterprise app store, but stripped of the transactional and customer-acquisition framing.

The Agent Directory is one of three pillars of Orchestration as a Service. The Agent Factory is where agents come from. The directory is where they live. The Code of Conduct governs how they behave once they are deployed.