Frosty AI
AISend prompts through a Frosty AI router for multi-model routing, fallback, and observability. Agents keep working when one provider degrades and keep a record of which model answered.
What This Integration Enables
Frosty AI exposes exactly one action, and that action takes no model parameter. Both facts are deliberate. Frosty is a router. The primary model, the backup model, and the provider credentials all live in your router's configuration, so a request never names a model. What the flow controls is the Routing Rule: leave it alone to use the primary, set it to Cost to favor the cheapest configured model, or set it to Performance to favor the fastest. If the primary provider fails, the router falls back to the backup you configured.
The operational argument for that shape is stronger than it looks. In a normal setup, the model a flow uses is a string sitting inside that flow, which means the model choice is duplicated across every flow that has one, and changing vendors is a search-and-replace exercise across your automation estate. Through a router, the model choice lives in one place and every flow inherits it. Swapping providers becomes a console change rather than a release.
The half people underestimate is observability. Every completion comes back with Frosty's metadata attached, which means an agent can see which model actually answered rather than which model was supposed to. That turns an invisible failover into an event a flow can act on, and acting on it is where this connector earns its place: a fallback that nobody notices is a change in behavior nobody approved.
Without FlowRunner
With FlowRunner
Use Case Scenarios
Keeping a queue moving through a provider incident
A high-volume summarization flow runs continuously. The primary provider starts erroring. The router fails over to the configured backup and requests keep completing, so the queue does not back up while somebody investigates. The agent records the model named in the metadata on every item, so when the incident is reviewed, the exact window served by the backup is a filter on a table rather than a reconstruction from memory.
Biasing an internal workload toward cost
An internal enrichment job runs nightly and nobody reads the output until morning. Its Send Prompt step sets the Routing Rule to Cost, so the router favors the cheapest model configured on that router, while the customer-facing flow on the same router leaves the rule at its default and takes the primary. The tradeoff is expressed per flow without either flow naming a vendor.
Changing providers without touching a single flow
A better model becomes available. The team updates the router's primary in the Frosty console. Every flow calling Send Prompt picks it up on the next request with no edit, no redeploy, and no risk of one forgotten step still pointing at the old vendor. To verify the change landed, the agent watches the model named in the returned metadata and posts a confirmation to Slack once the new name appears across all live routes.
Human-in-Loop Highlight
Silent failover is the risk this connector both creates and lets you close. When the primary degrades, the router quietly hands the work to the backup, and the flow keeps producing output that reads exactly as fluent as before. If that output is customer-facing, a different provider is now writing to your customers under your name, in a different voice, with a different refusal posture, and nobody chose that. The observability metadata is what makes this catchable, so the agent watches it. The moment the model named in the response stops matching the configured primary, the agent holds the drafts instead of sending them and posts to the support lead in Microsoft Teams: "The router has been serving from the backup provider for the last 14 minutes. Eleven customer replies are drafted and held. Approve backup output for customer replies, or hold the queue until the primary returns?" Sometimes the answer is send them, and that is fine, because someone decided. What the agent will not do is let a provider change reach a customer without anyone knowing it happened. That is the digital andon cord: the line does not stop because something broke, it stops because something changed and the change matters.
Agent Capabilities
1 actionsRouting
1- Send Prompt Sends a prompt to a Frosty AI router, which selects the underlying provider and model on your behalf and returns the completion along with Frosty's observability metadata. No model is named on the request, because the primary model, backup model, and provider credentials are configured on the router itself. Use the Routing Rule to bias selection toward cheaper or faster models, and rely on the router to fall back to the configured backup when the primary provider fails. The returned metadata is what tells your flow which model actually answered.
Frequently Asked Questions
What can FlowRunner do with Frosty AI?
FlowRunner agents can run Send Prompt in Frosty AI.
Does connecting Frosty AI to FlowRunner require OAuth?
No. Frosty AI connects to FlowRunner with an API key, no OAuth flow required.
Can Frosty AI trigger a FlowRunner workflow automatically?
Frosty AI doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.
Start building with Frosty AI
$100 in credits. No card required. Connect in minutes.