Flue Zero to Expert, Part 7: Operate Like an Expert

Series map

Part 1: Your First Flue Agent · Part 2: Typed Workflows · Part 3: Safe Tools · Part 4: Autonomous Agents · Part 5: Persistence and Durable Execution · Part 6: Production Routing and Deployment · Part 7: Operate Like an Expert

Part 7: Operate Like an Expert

Observe useful outcomes

Production operation starts with structured events.

Actions expose log.info(...), log.warn(...), and log.error(...). Add attributes that you may search or aggregate later. Do not hide important values inside formatted messages.

Add observe(...) to the secured src/app.ts from Part 6. Keep its authentication middleware and flue() mount unchanged.

import { observe } from '@flue/runtime';

observe((event) => {
  if (event.type === 'run_end' && event.isError) {
    console.error('Workflow failed', {
      runId: event.runId,
      error: event.error,
    });
  }

  if (event.type === 'operation' && event.durationMs > 5_000) {
    console.warn('Slow operation', {
      kind: event.operationKind,
      durationMs: event.durationMs,
    });
  }
});

Keep observers lightweight. Returned promises are monitored for rejection, but Flue does not wait for them. Each running application context observes only the activity it handles. Aggregate externally across processes or isolates.

Workflow invocations have a runId. Their run history contains results, errors, and emitted activity. Continuing agents do not create workflow runs for direct prompts or dispatched input. Inspect their session and operation activity instead.

Telemetry can contain prompts, workflow inputs, tool values, model messages, logs, and errors. Treat it as sensitive. Export only required event types. Apply your own redaction and retention policy. Do not assume image omission also sanitizes arbitrary text or metadata.

Evaluate behavior before shipping

Model output can change after an instruction, model, or tool update. Evals make those changes visible.

Flue does not include an eval runner. Its guide recommends vitest-evals, but you can use any runner through the public SDK. Add the official blueprint first:

npx flue add tooling vitest-evals

The blueprint creates the dependencies, configuration, starter case, and local harness.ts used below. The blueprint creates a complete app-specific starter case and createFlueAgentHarness(...). Each generated case gets a fresh agent instance. A custom harness must provide the same isolation.

Start Flue in one terminal:

npx flue dev

Run the generated suite in another:

npm run evals

Use direct assertions for exact behavior. Use a model judge only for qualities such as clarity. Keep the judge independent from the model under test. For workflows, build the harness around client.workflows.invoke(...) and grade the returned result.

Schedule the right lifetime

A schedule is only a trigger. Your deployment platform must provide the scheduler.

Use workflow invoke(...) for bounded work such as reports, cleanup, or synchronization. Each occurrence receives an independent runId, lifecycle, and run history. Invocation returns after admission. It does not wait for completion.

Use agent dispatch(...) when every occurrence should enter one continuing session.

import { dispatch } from '@flue/runtime';
import helloWorld from './agents/hello-world.ts';

await dispatch(helloWorld, {
  id: 'scheduled-jokes',
  input: {
    message: 'Tell one short engineering joke.',
    scheduledAt: new Date().toISOString(),
  },
});

The stable ID reuses the same agent instance and conversation. Dispatch returns a dispatchId. It does not create workflow run history.

Choose shared state deliberately. A daily report normally belongs in a workflow. A continuing assistant may need agent dispatch.

Node has no built-in cron scheduler. An in-process scheduler also stops with its process and may run in every replica. Use a persistent, coordinated scheduler when missed or duplicate occurrences are unacceptable.

Sources

• https://flueframework.com/docs/guide/observability/
• https://flueframework.com/docs/guide/evals/
• https://flueframework.com/docs/guide/schedules/

You now have the full path from a first Flue agent to operating workflows and agents with evidence.