NodeFox
How it works

From a recurring task
to a reusable AI process.

NodeFox is a visual canvas for AI orchestration: the steps around the model, the information each one receives, and the decisions between them. Get started locally in the browser — nothing to stand up, nothing to self-host.

Start buildingWatch the demo
Start here

Begin with the input and the result.

NodeFox is for work that keeps arriving and takes more than one step: a case that stays open, a document that returns with questions, a branch that waits on a person. Start with one of those.
  1. 01

    Input and result

    What arrives: a brief, a file, a row of data? What should come back: a review, a structured record, a draft?

  2. 02

    Connect the steps

    Add steps to read information, call a model, shape data, decide or write an output, then connect them so each receives what it needs.

  3. 03

    Include the decisions

    A model response is not a finished result: check for missing information, put the question to a person, or route the output to a reviewer.

  4. 04

    Choose how to run it

    Run it yourself, hand your team a form that starts it, or point it at a list. The logic stays in one network.

Visual builder

See how the work connects.

Model calls, files, data operations, tools and decisions sit on one canvas, connected by the information each step needs. Underneath the picture, the parts that usually take code are configured explicitly: where a run goes next, what it remembers, when branches meet, what is allowed to happen.

Routing you can point at.

A Decision node routes on ordered rules, a named default branch and a cycle limit, so a loop ends where you chose — or its Options variant puts the choice to a person.

State that lasts the length of the run.

A Buffer node stages what the process has gathered, accumulates it across cycles or merges inputs into one payload, so a long job still knows what it is working on.

Branches that converge on purpose.

A Wait node holds a branch until every condition it checks has passed, so parallel paths that finish at different times meet instead of racing.

Data and permission are separate wires.

A data route decides what a step receives; an activation route decides whether it may run — which is how a write or a send stays behind an approval.

Finished networks become single steps.

A Network node calls another network through a mapped set of inputs and outputs, so a hardened pattern is reused instead of copied into five drifting versions.
AI apps

Give people the tool, not the setup.

Put a form in front of a network: it collects what the task needs and presents the result, while the process itself stays with the people who maintain it.

A process behind the form.

Someone supplies the information the task needs; the network handles the model calls, data steps, tools and decisions behind it.

Ask for what the task actually needs.

Define the input fields that belong to the process, and say what a suitable input looks like and what comes back.

Keep the conversation connected to the run.

Where the network needs more information, the person can answer in place without opening the builder.
Batch processing

Repeat the process, not the setup.

Use one network across a set of inputs. Prepare the batch, check what will run and follow each item through the same process.

Point an automation at a network and say what changes each time: a column of a registered CSV, a list of values you type, or a numeric range.

Each run receives the current value as a global variable the network reads, while the values that apply to every run stay fixed as overrides. Run history is kept per automation.

Practical limits: a batch needs an active execution environment; closing the browser is not a background job. Concurrency depends on your plan, runtime and connected providers.

Model providers

Choose the model for the job.

Set the provider, model, instructions, available tools and output schema on the step that needs them — using your own provider credentials, inside the same network.

One process does not need one model for everything.

Pulling structured fields out of a document, drafting a section and reading an image are not the same task, so each step carries its own model configuration.

Connect your own provider credentials.

Provider access, model availability and billing sit outside your NodeFox account — confirm what your current setup allows before designing around a model.

Change a model and recheck the behavior — tool calling, supported content, output formats and limits can differ between providers.

Integrations

Connect the tools your process actually needs.

Files, APIs and external tools join the network as steps. Nothing moves into NodeFox: it sits between the systems you already run and takes on the part currently done by hand.

Use an API when you know the request.

Reader and Writer API steps, or a custom function where one is needed, carry the endpoint, authentication, request and response handling for the task.

Use MCP for configured tool access.

MCP servers expose tools a model-driven step can call — choose the ones the job needs and verify their behavior rather than treating a discoverable tool as safe.

Keep files and specialized tools in scope.

Use the file access your process requires, and ask about a specific application and action rather than assuming a logo means a complete native connector.

Test a write with safe inputs and a non-production destination: a retry is not always harmless, since the first request may already have succeeded.

Run visibility

Understand the run behind the result.

Follow a run step by step, inspect what each step received and produced, and review the captured record afterwards — which is what makes an incident answerable.

Follow the work while it runs.

Queued, running, completed, failed and stopped are distinct states — though completion is a technical outcome, not a verdict on the output.

See reported model usage in context.

Displayed costs are estimates built from reported usage and pricing data, not an invoice; providers and connected services can bill you separately.

Replay inspects what a past run recorded. It is not a re-execution, and it does not guarantee a new model response will match the old one.

For builders

Build the process. Keep the escape hatches.

Compose the structure visually and drop into code where the task has to be exact. The network is the artifact either way: readable to the person who owns the work, precise where precision is the point.

Keep exact logic exact.

Code and reusable functions handle mappings, transformations and service-specific behavior; models handle the parts where interpretation is what you actually wanted.

Design interfaces between steps.

Give each step explicit inputs and outputs, and a schema wherever the next step depends on the shape of the answer rather than its prose.

Know where it runs before you choose the workload.

Orchestration runs in your browser on a Rust and WebAssembly engine with worker-based operations, so there is nothing to stand up and nothing to self-host.

Extending past the canvas is a conversation.

Running a network headlessly, durably, or on a schedule or trigger depends on your plan and setup — tell us what yours looks like before you design around one.
normalize-brief.code.tsnetwork.json
// Code node — normalize-brief
// slot 1 in: raw brief text · slot 1 out: structured fields

const brief = inputs.get(0);
if (!brief || typeof brief !== "string") {
  throw new Error("validation_error: missing brief text");
}

const fields = {
  scope: brief.match(/Scope:(.*)/)?.[1]?.trim() ?? null,
  deadline: brief.match(/Deadline:(.*)/)?.[1]?.trim() ?? null,
};

session.set("briefLength", brief.length);
outputs.set(0, fields);

// network.json — excerpt, illustrative shape
{
  "nodes": [
    { "id": "n1", "type": "Global", "label": "Client brief" },
    { "id": "n2", "type": "Code", "label": "Normalize brief" }
  ],
  "edges": [
    { "from": "n1", "fromSlot": 1, "to": "n2", "toSlot": 1, "kind": "data" }
  ]
}

A few things to know before you begin.

Do I need to code?

You can compose the process visually. Exact transformations, custom integrations and some credentials need code or technical help.

Where does it run?

Orchestration runs in your browser. Model providers and connected services still receive what you send them, so review the data path before using sensitive information.

How should I evaluate it?

Start with representative, non-sensitive inputs and a clear definition of useful output. Include human review where the task needs it.

Does visible logic make model output predictable?

It makes the process inspectable: you can see which step produced a result and which rule sent it there. Models and external services still vary, so test representative and failure cases.

Pick one task worth repeating.

Build its steps first. Hand it to your team or point it at a list once the process holds up.

Start buildingTalk to an expert

NodeFox is in beta.