Inside AI Wingman: How We Built an AI Assistant That Actually Understands Your Workflows

If you've used AI tools for development or automation, you know the drill: copy your code into a chat window, describe what you're working on, explain the context for the tenth time, and hope the AI generates something close enough to be useful. Then you paste it back, fix the parts that don't fit, and repeat.

We built AI Wingman to eliminate that entire loop. Instead of an AI that lives in a separate window and starts from zero every time, Wingman is embedded directly inside the Falcon Builder workflow editor. It sees your nodes, your connections, your configurations, and your data flow. When you ask it to make a change, it doesn't guess — it knows exactly what your workflow looks like, and it proposes targeted modifications that you review before applying.

This post is a technical walkthrough of how we built it, why we made the architectural decisions we did, and what it means for how you build automation.

What Is AI Wingman?

AI Wingman is a chat-based assistant that lives in a floating panel inside the Falcon Builder workflow editor. You type what you want in plain English — “add an SMS notification after the AI prompt” or “why is this HTTP request returning 401?” — and Wingman responds with both an explanation and a set of proposed changes to your workflow.

Those proposed changes aren't suggestions in a chat bubble. They're structured operations — add a node, update a configuration, connect two nodes, remove an edge — each presented as a reviewable card with Apply and Dismiss buttons. You control exactly what gets applied to your workflow.

Wingman doesn't rewrite your workflow. It proposes diffs — the same way a code review shows you what changed, not the entire file.

The Core Insight: Operation Diffs, Not Rewrites

Most AI-powered workflow tools take a generative approach: describe what you want, and the AI creates an entirely new workflow. That works well for starting from scratch, but it falls apart the moment you have an existing workflow you've spent time building. You don't want the AI to regenerate everything — you want it to make a specific change while preserving everything else.

This is the same reason developers use git diff instead of rewriting entire files. A diff tells you exactly what changed. It's reviewable, reversible, and composable. We applied the same principle to workflow modifications.

When Wingman processes your request, the LLM returns a JSON array of structured operations instead of a new workflow definition. Each operation has a specific type and targets a specific part of your workflow:

• add_node — Creates a new node with a specific type, position, and configuration, optionally auto-connecting it to an existing node
• update_config — Modifies a specific configuration field on an existing node using a dot-path (e.g., config.headers.Authorization)
• add_edge / remove_edge — Creates or removes connections between nodes
• remove_node — Removes a node and all its connected edges
• explain / suggest — Display-only text for explanations and recommendations (no workflow changes)

This approach has three major advantages. First, it preserves your existing work — Wingman never touches nodes or configs it wasn't asked about. Second, it handles complex workflows gracefully — a 50-node workflow gets the same targeted treatment as a 5-node one. Third, it uses significantly fewer tokens than regenerating an entire workflow, which directly impacts cost.

Context Is Everything

The quality of any AI response depends on the quality of its context. Most AI tools require you to manually describe your setup. Wingman eliminates that friction by automatically injecting your full workflow state into the LLM's system prompt.

When you send a message to Wingman, the system prompt includes:

• Every node in your workflow — its type, label, position, and full configuration
• Every edge — which nodes are connected, and through which handles
• The workflow name and metadata for additional context
• The complete list of available node types and their configuration schemas, so Wingman knows what's possible

This means when you say “add error handling after the HTTP request,” Wingman doesn't ask “which HTTP request?” It already knows. It sees your HTTP Request node, knows its output variable name, knows what it's connected to downstream, and can propose an add_node operation with a Condition node that checks the response status code — automatically wired to the right source and target.

The AI doesn't guess at your workflow. It reads it, the same way a colleague would look at your screen before suggesting a change.

Conversation Memory

Wingman conversations are persisted per workflow. Every message — yours and the assistant's — is stored, along with any operations that were proposed. When you reopen the Wingman panel for a workflow, your last 50 messages are loaded automatically.

This means you can have an ongoing conversation about a workflow over days or weeks. Ask Wingman to add a node on Monday, come back Wednesday and ask it to modify the config, and it remembers the full context of what was discussed and what was applied. The conversation is scoped to that specific workflow, so different workflows have independent conversation histories.

When you want a fresh start, a single click clears the conversation history for that workflow. Operations that were already applied to your workflow remain — only the chat messages are removed.

Real-World Examples

The best way to understand Wingman is through concrete scenarios. Here are three common interactions:

1. Adding a Node

You have a workflow with a Webhook Trigger, a Set Fields node, and an AI Prompt node. You type: “Add an SMS notification after the AI prompt that sends the response to the user's phone number.”

Wingman returns an add_node operation for a Twilio SMS node, positioned below the AI Prompt node, with the message body pre-filled using the AI output variable (e.g., {{ai_response.text}}) and the recipient field set to {{set_fields.phone}}. It also returns an add_edge operation connecting the AI Prompt's output to the new SMS node. You review both operations and click Apply All.

2. Debugging a Configuration

Your HTTP Request node keeps returning a 401 Unauthorized error. You tell Wingman: “The HTTP request keeps returning 401. Can you check the auth config?”

Wingman examines the node's configuration, sees that the Authorization header is set to the API key value directly instead of prefixed with Bearer , and proposes an update_config operation that fixes the header value. It also explains why the 401 was happening — the API expects a Bearer token format, not a raw key.

3. Understanding a Workflow

You inherited a workflow from a colleague and aren't sure what it does. You ask: “What does this workflow do?”

Wingman returns an explain operation that walks through the workflow step by step: “This workflow triggers on incoming SMS messages via a webhook. It extracts the sender's phone number and message text, passes the message to an AI prompt configured as a customer support assistant, then sends the AI's response back to the sender via Twilio SMS. It's essentially an AI-powered SMS support bot.”

The Credit System: Transparent and Flexible

Every Wingman interaction consumes tokens — the same unit that LLM providers use for billing. We designed the credit system around three principles: every plan gets free tokens, additional tokens are affordable and never expire, and you can bypass the credit system entirely by connecting your own API key.

Here's how it breaks down:

• Free monthly tokens — Every plan includes tokens that reset monthly. Free plans get 50,000 tokens (roughly 10–25 interactions), Pro gets 250,000, Business gets 1,000,000, and Enterprise is unlimited.
• Credit packs — When you need more, purchase token packs starting at $5 for 250,000 tokens. Tokens from packs never expire. You can enable auto-replenish with a configurable monthly spending cap so you never hit a wall mid-conversation.
• Bring Your Own Key (BYOK) — Connect your own OpenAI, Anthropic, Google, or Ollama API key. Wingman uses your key directly, consuming zero platform credits. This gives you unlimited Wingman usage at whatever your LLM provider charges — we don't mark up or resell tokens.

Token consumption follows a clear priority: included tokens are used first, then purchased tokens, then you're prompted to buy more or connect BYOK. You always see your current balance in the Wingman panel footer.

Under the Hood

Here's a simplified view of what happens when you send a message to Wingman:

User types message
    |
    v
POST /api/wingman/chat
    |
    +-- Authenticate user + verify workspace access
    +-- Check token balance (included → purchased → BYOK)
    |
    v
Build system prompt
    +-- Inject full workflow context (nodes, edges, configs)
    +-- Include available node types + config schemas
    +-- Append conversation history (last 50 messages)
    |
    v
Call LLM (GPT-4o default, or user's BYOK provider)
    |
    v
Parse structured response
    +-- Extract operations (add_node, update_config, etc.)
    +-- Extract explanation text
    |
    v
Post-processing
    +-- Consume tokens from balance
    +-- Persist user + assistant messages
    +-- Log usage for analytics
    |
    v
Return operations + explanation to client

The system prompt is the most critical piece. It includes the full node and edge graph, every available node type with its configuration schema, and strict instructions for returning structured JSON operations. The LLM never sees your data or credentials — only the workflow structure and configuration metadata.

On the client side, each operation is rendered as a preview card. When you click Apply, the operation is processed by applyOperationsToWorkflow(), which handles node positioning, edge creation, and config merging. The workflow state is updated in-place through React Flow, so you see the changes immediately on the canvas.

What's Next

Wingman is the foundation for a much larger vision of AI-assisted workflow building. We're working on multi-step operation chains (where Wingman can plan a sequence of changes across multiple nodes), visual diff previews that highlight exactly what will change before you apply, and deeper integration with the workflow testing system so Wingman can analyze test results and suggest fixes.

The goal isn't to replace workflow builders with AI — it's to make every builder more productive by giving them an assistant that genuinely understands what they're working on.