Turn useful AI processes
into tools your team can use.
Connect models, business data and tools into one visual process. The people who run it get a form, not a canvas, and the logic keeps a named owner.
Move beyond a useful experiment.
A prompt that worked once is not a process a team can run. NodeFox lays the steps around a model — read the source, ask, check, write the result — into one owned process, so the work arrives assembled and a person starts at the judgment call.
Define inputs
Decide what information the process needs before it runs, and where it comes from.
Maintain instructions
Keep the logic in one place, owned by a person and changed as the work changes.
Decide when a person reviews
Set the points where a result needs someone's judgment before it moves forward.
Start with the casework that keeps coming back.
Pick a task your team already owns: a draft prepared from approved information, documents reviewed against defined criteria, research assembled from a set of inputs.
NodeFox is built for that shape of work — recurring, long-running, with branches, waiting points and state worth keeping — not a trigger in one system firing one action in another.
Keep ownership with the people who know the process.
Builders keep one visible place for instructions, data handling and custom logic. Operators get an app: a form that asks for what the task needs.
The canvas stays legible to whoever owns the work, and keeps the reliability and rigor you would normally only get from code-based infrastructure: explicit routing, typed handoffs, state that lasts a whole job.
Reuse a shared foundation.
Publish process assets to a company-scoped library where enabled and reuse shared networks, functions and schemas instead of rebuilding each one. A finished network can become one step inside another.
Organization roles — administrator, publisher, viewer — define who maintains and distributes them, and published assets carry version information. Company publishing depends on your organization’s setup.
Inspect the work, not just the final answer.
Follow run status and reported model usage. Where auditing is configured, review captured execution information and replay records to understand a past run.
Capture scope and retention are deployment decisions, and a replay shows recorded behavior — not a guarantee that a new model call returns the same answer.
Know where the process runs and where the data goes.
Getting started is local: the browser, nothing to stand up, nothing to self-host. Extending beyond it — headlessly from your own service, or on a schedule or trigger — depends on your setup; ask us what that looks like for yours.
Browser — orchestration
Rust/WASM engine · web workers
The canvas configures the process here. Workspace state and other local information stay in the browser — export what matters before changing devices or accounts.
Configured model provider
An AI step sends the configured request to its model provider. Content, tools and data handling depend on that provider.
External tools, APIs, MCP servers
APIs, OAuth-connected services and MCP servers have their own connection and credential paths, and their own boundaries.
Supporting NodeFox services
Account access, entitlements, OAuth credential storage and optional organizational publishing or audit features.
The browser orchestrates the network
Model calls go to the configured provider
External tools have their own boundaries
Supporting services remain part of the system
Local state needs deliberate care
Start with the requirements your process must meet.
Evaluate NodeFox against the data, access and operational controls your organization needs. Broad assurances are not a substitute for checking the deployment.
Identify the information involved
Describe the input, the model requests, the external actions and the output — including anything sensitive that could surface in intermediate results.
Review execution and storage separately
Browser orchestration describes where the network runs. It does not answer every question about provider transmission, account services or audit records.
Confirm the external permissions
List the services the process can call and the actions it may perform, then check credentials and scopes for each.
Design review before consequential actions
Decide what a person must verify before a process sends a message, changes a record or takes another consequential action.
Decide what records you need
Confirm availability, access, payload handling, retention and export before relying on audit capture.
What should we bring?
Can we keep people involved?
Will this replace our current systems?
Is this a privacy policy or contract?
Begin with a process, an owner and a definition of success.
Bring one recurring task. We will work through the inputs, the output, the review points and what implementation would take.
NodeFox is in beta. Validate critical processes and deployment requirements before relying on them in production.