Pricing · scoped by workflow

Price the workflow. Keep access open.

Nodes pricing is built around a named workflow from trigger through approved action and evidence. There is no seat, user, token, model-call, or credit meter.

Scope a workflow See a full workflow

Commercial unit

Named workflow

Access

Unlimited operators and reviewers

Meter

No tokens, calls, or credits

Expansion

Add or broaden a workflow

How pricing works

The commercial boundary follows the work.

We map the complete workflow first, including its trigger, systems, decisions, approval gate, actions, and expected outcome. The proposal then prices that workflow as a whole.

Step 01

Name the workflow

Start with a repeated decision that matters.

One owner · one outcome · one approval path

We document

The business trigger and desired outcome
The systems and data the workflow may use
The human responsible for the final decision

Result A workflow boundary both teams can evaluate before commercial terms are drafted.

Step 02

Define the operating envelope

Set the systems, throughput, controls, and deployment.

Designed around the workflow, not a license count

We account for

Integration and data-boundary requirements
Expected decision volume and service levels
Cloud, customer VPC, or on-premises deployment

Result A delivery plan sized for the work the workflow must perform.

Step 03

Quote and expand

Receive one proposal for the agreed workflow.

Access remains open across the buying team

The proposal states

The complete workflow and delivery boundary
The implementation and operating responsibilities
How scope changes when another workflow is added

Result Commercial terms a buyer can trace directly to delivered work.

Full workflow example

Candidate intake to approved shortlist.

This example shows what a single workflow includes. The quote covers the connected path from the first system event to the approved action and its evidence record.

Illustrative workflow. Systems, rules, and approval roles are fixed in the customer agreement.

01 · Trigger

A requisition is approved in the ATS.

The workflow begins from an agreed system event. No person has to copy the request into another tool.

02 · Ingest

Nodes reads approved context in place.

Role requirements, candidate records, historical outcomes, and policy constraints are resolved across the ATS, HRIS, and approved data sources.

03 · Process

Agents evaluate the decision against the shared model.

The workflow applies the agreed objective, policies, calibration, and evidence rules to the available context.

04 · Propose

Nodes drafts the shortlist and next action.

The proposal includes its rationale, supporting evidence, expected business effect, and the systems that would change.

05 · Human gate

The named reviewer approves, edits, or declines.

Nodes cannot execute the regulated decision until the responsible human completes the approval step.

06 · Act

The approved decision moves across systems.

Nodes writes the approved disposition to the ATS, opens the agreed follow-up, and keeps connected records consistent.

07 · Evidence and outcome

The decision remains reviewable after execution.

A signed Decision Trace records the evidence, versions, human input, action, and later outcome so the workflow can be audited and improved.

What sets the quote

Five boundaries make the workflow commercially concrete.

The working session produces these inputs. Adding users does not reopen the quote. Adding or materially broadening a workflow does.

Boundary 01

Workflow and outcome

The trigger, decision, approved action, accountable owner, and result the workflow is designed to change.

Boundary 02

Systems and data

The source systems, destination systems, integration work, and data permitted to enter the workflow.

Boundary 03

Operating envelope

Expected throughput, business units, role families, geographies, and service levels required to run the workflow reliably.

Boundary 04

Deployment and controls

Cloud boundary, security review, approval roles, model-risk controls, and any customer-specific operating constraints.

Boundary 05

Implementation and support

Delivery responsibilities, acceptance criteria, monitoring, support, and the path from the first workflow into production.

Included in every workflow agreement

No separate access meter

Access

Operators and reviewers

Add the people the workflow needs.

Context

Approved integrations

Read and write within the agreed boundary.

Intelligence

Agent orchestration

Process context and draft the decision.

Control

Human approval gate

Approve, edit, or decline before action.

Action

Cross-system execution

Apply the approved change where work happens.

Evidence

Decision Trace

Retain the inputs, versions, approval, and result.

Pricing FAQ

Questions a buying team asks before the quote.

01How do we get a price?+

Bring one repeated decision, the systems it crosses, the expected operating envelope, the required approval gate, and the outcome you want to change. We map the workflow and return a proposal tied to that scope.

Pricing unitNamed workflow

02Do you charge per seat or per user?+

No. Operators, reviewers, administrators, and approvers can participate without creating a new license charge. Access is part of the workflow agreement.

AccessIncluded

03Do tokens, model calls, actions, or credits appear on the invoice?+

No. We use expected activity to size the deployment and service boundary, but the commercial unit is the named workflow. Buyers do not reconcile an internal usage currency.

Usage meterNone on the invoice

04What counts as one workflow?+

A workflow has a named trigger, approved context, a defined decision, a human approval path, a bounded action across systems, and an outcome record. If one of those boundaries changes materially, we document the change before updating commercial scope.

DefinitionTrigger through outcome

05Does adding another team change the price?+

Adding people to an existing workflow does not create a seat charge. A quote changes when the workflow itself expands, such as new decisions, systems, business units, geographies, or service requirements.

Scope changeWorkflow boundary

06Can we begin with one workflow?+

Yes. The first engagement can be scoped around one workflow and its acceptance criteria. Expansion follows only after your team has reviewed the evidence and chosen the next workflow to add.

Starting pointOne workflow

Scope one workflow

Bring the decision that keeps crossing systems.

We will map the full path, identify the operating boundary, and return a proposal tied to the workflow your team wants Nodes to run.

Start the workflow review See how Nodes acts

BringThe repeated decision, source systems, and accountable owner

MapTrigger, context, proposal, human gate, action, and outcome

LeaveA clear workflow boundary and the inputs required for a proposal

One moment.

Price the workflow. Keep access open.

Nodes pricing is built around a named workflow from trigger through approved action and evidence. There is no seat, user, token, model-call, or credit meter.

Commercial unit

Named workflow

Access

Unlimited operators and reviewers

Meter

No tokens, calls, or credits

Expansion

Add or broaden a workflow