Settle the roles first. Then plan the rollout.
For each capability below: what your team does with it, who owns each step and what it takes to run day to day. Process owners, approvers, IT and risk each have a defined part, from the first trial to live operation.
Scope the first process together.
Your process owner maps today's routine, or adapts one of the Studio's starter packs. The AI analyst comes back with up to five design options, each laying out steps, connected systems, approval checkpoints, and estimates for run cost plus staff hours returned. The owner shortlists one with the team leads who will work alongside it.
Rules you can rely on
This is where team policies become control points. Any policy that can be written as a rule, a spending limit for example, turns into a fixed check that needs no AI call. Such checks add nothing to model spend. Each rule lands as a draft, with its source recorded, for the process owner to accept or edit.
See the Foundation's roleBuilt around your teams
Designs start from who does the work today: the teams involved, the systems they use, the rules they follow and the targets they report on.
Pick how to brief it
The process owner can fill in the 10-step guided form, paste the company website with notes, or write a single paragraph. Eight starter packs speed things up, and files such as PDFs or spreadsheets can be uploaded. The Studio can also work from process logs or from agent code your teams already run. Anything shared is used solely to design the worker, under data-processing terms your organization approves first.
Options to compare as a team
Up to five scored options, each setting out roles, steps and connected systems, with the AI's figures for monthly running cost and staff time saved. The Studio checks each option and drops any that fail before your team reviews them.
Changes your team can request
Optional: a team lead types a change, such as “send large refunds to finance”, and an AI assistant drafts it for the process owner to accept or reject.
Before any build, the owner has picked a design, approvers are named and finance has checked the run-cost estimate.
Run trials before anyone relies on it.
Nx·Studio generates test cases from the process each worker runs, with outside systems simulated. Your team can trial individual steps or the full sequence, while approvers see the same pauses they will see in live operation. Several workers can be trialed together on accelerated time, and red-team attacks are optional. Each version shows what changed, and no live system is touched.
Rehearsal before reality
None of the trials, previews or red-team attacks requires production data. When the team evaluates using only a written outline of the process, no records change hands at all.
See the Foundation's roleCases like your own
Generated cases mirror the records each worker handles, so team leads recognize the work. Teams can also load their own samples, with up to 200,000 rows in each dataset.
Trial scorecards
Every trial run is scored on accuracy, robustness, speed and coverage, so the team can track progress from one version to the next.
Before and after
Put two or three versions through the same scenario, or step through one run's trace, before a change goes to approvers.
Hand-offs checked
Where several workers share a process, the simulation lab catches overwritten updates and dropped hand-offs before live operation. Red-team attacks are optional and return a scorecard.
Trial results become the team's go-live checklist: the process owner rules on outcomes, security on open risks, and IT on the integration work left.
Approvers named at every step.
A versioned blueprint shows what each worker does and who acts at each point, drawn either as a flow diagram or in swimlanes, one per team. Before a version goes live, the process owner and governance leads compare it with the last one, trial it and approve it. Auditors read the same blueprint, and it arrives as code your organization keeps.
Blueprints you can read
The blueprint names every action, approver and hand-off, so control rests on a design the team can read rather than on AI instructions. Engineers branch, tag, diff and merge it; process owners follow their swimlanes; auditors get a plain account of the final design.
See the Foundation's roleChanges kept as versions
Each time someone saves, the Studio records a new version the team can diff, branch or merge, and the editor keeps named checkpoints with 100 steps of undo. Test scores link back to the version they came from.
Decision rights by role
Assign each approval checkpoint to a role or a team. Exports with checkpoints include a reviewer inbox for engineers to wire into the worker; Slack can also be chosen at export.
Records for each review
Every approval is recorded, so team leads can show who decided what. Optional: a tamper-evident log of every run and field-level tracing back to source systems.
How the audit trail is specifiedConfidence thresholds
The team sets the confidence an AI result must reach. Below it, the result is flagged or, if configured, sent to an approver. The Studio warns when a sensitive action has no approval checkpoint, and each checkpoint holds the case until an approver acts.
Every team works from one record: owners see their swimlane, approvers their checkpoints, auditors the full design.
Decide who runs it day to day.
Your team receives the full software project, ready to run in an environment it operates. Integration starts from a catalog listing thousands of APIs, and IT completes each connection. Exports with approval checkpoints also carry the reviewer inbox, the test suite, and safety checks and monitoring you can switch on. Nothing in it needs a vendor runtime, charges per decision or calls home.
Code-quality evidence for your IT teamProof in every export
Exports include an AI bill of materials: a signed manifest of the models, connectors, agents and libraries inside, which engineers verify offline. It also includes a threat model for the security review and an EU AI Act Article 53 documentation template. The ownership report lists what your organization holds; a sanitized sample can be requested from the Trust Center.
See the Foundation's roleA catalog listing thousands of APIs
Salesforce, SAP, ServiceNow, Workday and Oracle EBS come as starter integration code; plan time for your engineers to finish, configure and test each one. Workers can also call any standard web API or an MCP server (a common way for AI tools to reach other software).
A manifest IT can check
The signed manifest itemizes each software and AI component, so IT can confirm the delivery without a network connection, on its own machines.
Approvals that hold the case
At each checkpoint the worker waits until an approver accepts or declines the case. Approvers decide in the reviewer inbox after engineers connect it, or through Slack when that option was chosen at export.
Risk settings
A threat model for the security review ships with every export. Your risk lead can switch on drift monitoring, which flags results shifting over time, plus personal-data redaction and rules that block disallowed actions.
Hosted by your IT
IT deploys the complete codebase to your own servers or cloud; optional templates cover Kubernetes, AWS, Azure, Google Cloud, Snowflake and Databricks. Workers use the model vendor you contract with, and running them needs no license key or Nxgyle service.
After handover, IT runs and maintains the worker, the process owner tracks results, and approvers keep their checkpoints.
Compare the work each model leaves your team.
Each route hands your team different work: building, hosting, maintaining and governing. Here is how the work splits, our own option included.
Staff a build team on open frameworks.
The code and the choice of frameworks are yours. Plan engineering time for integrations, controls, testing and every later change.
Rent a vendor's agent service.
Less to build, but your team manages the vendor: weigh setup effort, hosting, code access, usage pricing and exit terms, which vary by provider and contract.
Generate it, trial it, run it.
Nxgyle designs around your process, supports trials on synthetic data and delivers the source code. Your team then owns deployment and daily operation, with optional Managed Delivery support.
Records your team can file and show.
Each capability above produces a record for the people who check the work: procurement, risk and engineering. Both examples below are illustrative.
- Intake refund requests from the service desk queue
- Check order history, refund policy, prior claims
- Approval large refunds go to a team lead
- Approval large refunds also need finance approval
- Escalate suspected fraud goes to the risk team
Illustrative. A team lead's change request, reviewed like code: approved before it runs and traceable afterward.
How changes are approved-
Scenarios on generated cases
Single stages or whole runs, with no live system touched.
-
Red-team results, if switched on
Common attack patterns tried before any live use.
-
Checkpoints held for approvers
Each case waits until its approver decides.
-
Versions run on one scenario
Differences are marked for the process owner.
Built from a trial on generated cases, ready for your project file or request for proposal (RFP).
See the full sample report on Nx·StudioDelivered so far.
Each count is calculated from the portal and worker records listed on this site. A digital worker is an operational asset in code: it runs one defined process under your rules and approval checkpoints, and your organization holds the full source.
Who carries the daily work? Rented versus owned.
Compare what your team runs, pays for and can inspect in each model.
The vendor's service, on its terms.
Set by the vendor's price list.
Only what the vendor exposes.
Use continues only on contract terms.
Systems your IT team operates.
Your budget covers hosting, model usage and upkeep.
Your team reads the blueprint before it runs.
Your team keeps the code and keeps running it.
We bill design and delivery, never individual runs.
Your team runs it day to day; Managed Delivery is optional support, scoped to what the team needs.