Operating Flux

Going to production

A module carries a production mode switch that marks it as live. This page is what to check before you flip it, and how to change a running workflow without breaking it.

Production mode

Open the module, edit it, and switch on Production mode to mark it as live in production. Leaving test modules switched off is what stops half-finished workflows quietly consuming credit.

Production mode marks a module as live.

Before you switch it on

The workflow

  1. Every trigger has a matching response. The commonest silent failure is a channel with nowhere to reply to.
  2. Test through the real channel, not only the UI trigger. Channel setup fails in ways the generated UI never shows.
  3. Read a compiled log from a real run and confirm each node received what you expected.
  4. Try the unhappy paths — an empty message, a question outside the knowledge base, someone asking for a human.

The agent

  1. It can escalate. A customer-facing agent needs a Chat Transfer tool and a prompt that says when to use it.
  2. It knows what it must not do. Refunds, pricing, legal or medical advice — name the boundaries in the system prompt.
  3. The knowledge base is current. An agent will confidently quote a policy you replaced last quarter.
  4. Tool descriptions are specific. Vague DESC text is the main cause of an agent calling the wrong tool.

The account

  1. Credentials are yours, not test keys.
  2. The wallet has enough balance, or the nodes use your own provider keys.
  3. Intervals are set to what you actually want — not the one-minute value you used while testing.
The most expensive mistake in Flux is a short interval trigger left on after testing. It runs day and night whether anyone uses the agent or not, and each firing consumes tokens downstream. Check every interval before going live.

Changing a live workflow

Edits take effect on the next run, so a workflow answering customers right now will pick up your change immediately. That argues for a little ceremony:

  1. Save the working version as a template first. That is your way back.
  2. Make one change at a time. Two prompt edits and a new tool at once is not debuggable.
  3. Watch the logs afterwards. The first few real sessions tell you quickly whether it improved.
For a risky change, build it in a second module with a UI trigger and test it there. Copy the working configuration into the live module once you are happy — the live agent is never in a broken state.

After launch

  • Read chat logs daily at first. Real users find things testing does not.
  • Watch the transfer rate. Frequent escalation means the knowledge base has a gap; near-zero escalation on hard questions means the agent should be handing over and is not.
  • Check usage weekly until the shape of it is familiar.