Cost
Licences that only rise
Heavy per-seat and per-core fees that climb at every renewal, for capability you already own the process knowledge for.
NextWave APX – Agentic Platform eXchange
Re-engineered by AI, for AI
Turn requirements, code, data and screens you already have into runnable, BPMN standards based applications, whether you are replacing an existing system or building a new one, with a human reviewing every step.
The problem
Building applications by hand is too slow, too costly and too risky.
Mission-critical work such as onboarding, lending, claims and case handling still runs on ageing proprietary process and platforms often on black box architecture, and new demand queues up behind them. Four things follow, and they all land on your board report.
Lock-in
Proprietary and scarce
Closed formats and a shrinking pool of expensive specialists. Your options narrow every year you stay.
Speed
The business waits
Every change is slow, so the operational change backlog stalls behind the platform, and transformation stalls with it.
Risk
Knowledge walking out
The people who understand the old application are leaving. Undocumented process knowledge leaves with them.
What you get
Not a design document. A working app you can use on day one.
Select a card to see what each outcome means for you.
What it is
What is NextWave APX – Agentic Platform eXchange?
NextWave APX builds new process applications, and converts the ones you already run, into a runnable and modern architecture.
A coordinated supervised team of specialist AI agents with Human in the loop validation
Adaptable to any process and different underlying technologies
It is not a code translator, it is a specification led process regeneration, with inbuilt governance and auditability
Rapid creation and quick deployment; adaptable to down stream consumer tools
Interrogate
Ingest
Generate
Deploy
Select a stage to read what it gives you. The Agentic Platform eXchange box links to the agent chart.
The agent team
Agent Orchestration
Two frameworks, 25 specialist agents: the Pre-Analysis and Design Framework turns raw business material into a reviewed requirements document, and the Technical Build Framework builds the runnable, BPMN standards based application from it
Framework and model flexibility can align to your architecture.
Opus
best for complex nuanced reasoning and complex tasks where quality matters more than speed or cost
Sonnet
coding, analysis and agentic workflows
Code
deterministic stages checked by tests, with no Claude call and no tokens
Pre-Analysis and Design Framework
Turns raw BA material (documents, board exports, whiteboard photos, recordings, a schema, screens and an optional legacy platform package) into a requirements document that a person reviews. Every input is optional, and a stage with nothing to read makes no API call.
Orchestrator
Requirements Profile
⇶ run concurrently
Pre-Analysis and Design Framework
From raw BA material to a reviewed document
Select an agent to see what it does, what it writes and how it runs, or select a group header to isolate that group.
Technical Build Framework
Builds the runnable, BPMN standards based application from the approved requirements: BPMN processes, CMMN cases, DMN tables, Python workers, the React web app, the dev stack, tests and a coverage summary.
Orchestrator
Orchestration Profiles
⇶ run concurrently
Legacy package only
⇶ run in parallel
Legacy package only
Web app
Technical Build Framework
Five groups, one orchestrator
Select an agent to see what it does, what it writes and how it runs, or select a group header to isolate that group.
Consistency validation
Consistency Validation
Each process is validated on its own, then checked against the others for consistent use of standards
Select any block to see what it does. The two checks are colour-coded, so each one can be followed from its first run to the validation stage.
Inputs
Existing Process
Outputs
New Process
Consistency validation
Five stages, two checks
Select any block in the diagram to see what it does. The same two checks run twice: once on the existing processes, and again on the new ones before they are released.
Why this option
Against the alternative approaches.
A manual rebuild is safe but slow. A generic AI code generator is fast but ungoverned. The point of NextWave APX – Agentic Platform eXchange is to be both fast and defensible.
Hover or focus any cell for the one-line reason. On a narrow screen, swipe the table sideways.
| Manual rebuild | Generic AI code generator | NextWave APX |
|---|
Cost model
Token Consumption Cost Model
The economics of running LLMs have split into two very different markets: premium frontier reasoning, where a completed request can still cost cents or dollars, and high-volume inference, where useful models can operate for fractions of a cent per request.
The important metric is no longer simply “price per million tokens”; output/reasoning length, caching, model routing, tool calls, and utilisation increasingly determine the real cost per completed task.
Select a term in the formula to isolate what it covers. Select it again to show all five.
Cost Consumption Model
Input Token
The cost of all text or data sent to the model such as prompts, instructions, conversation history, and retrieved documents
Output Token
The cost of the text generated by the model
Tools
Additional charges incurred when the model uses external capabilities such as web search, code execution, databases, APIs, or other services.
Cache / Storage
The cost or savings associated with storing and reusing previously processed prompt / context tokens instead of processing the same information from scratch.
Other
Any additional costs such as fine-tuning, batch processing, embeddings, image/audio processing, dedicated compute, or provider-specific services.
Input Rate and Output Rate
Input and output rates are the prices an AI provider charges for processing tokens sent into the model and generating tokens from the model, typically quoted as a cost per million tokens. Output tokens are often higher than the input rate.
Process conversion costs will differ based on complexity of process, data, and design and test iteration multiples.
Trust & control
AI does the heavy lifting.
Your people stay in control and sign off every step.
Auditable and transparent inside your boundary.
Human-in-the-loop
Nothing ships unreviewed. Each stage stops at an artefact a person reads and approves before the next stage starts.
Inspectable & resumable
Every step is written to a shared record. Pause the run, audit what happened, change your mind, resume from there.
Your data, your perimeter
Designed so sensitive inputs stay inside your boundary. Data handling is agreed in writing before the pilot starts.
Your house style
Grounded in your curated examples, so the output enforces your internal standards instead of importing someone else's.
The questions we always get
The product is designed to run against your inputs inside your own perimeter, with the model configuration chosen to fit your policy. We agree the data-handling position (what is processed, where, and by whom) in writing before a pilot begins, and your security team signs it off.
Yes. Every stage writes its output to a shared record, so you can see what was produced, by which role, in what order, and who approved it. Runs can be paused mid-flight, inspected and resumed. Each run ends with a plain-language coverage summary that tells reviewers exactly what to check.
No. It accelerates them. It removes the re-interviewing, re-typing and re-drawing that consumes most of a rebuild, and leaves your analysts, architects and engineers doing the judgement work: is this right, is it safe, does it meet our standards? They remain accountable, and they sign off.
Nothing ships without human sign-off, so a weak result is caught, not deployed. An automated tester runs against the live application and a quality reviewer checks the whole build against your standards before you see it. For a proof-of-value we agree the pass bar up front, so "good enough" is a defined, measurable thing, not an opinion.
No. You provide four things you already have: the requirements or specification, the existing code, the database schema, and screenshots of the current screens. Nobody on your side needs to learn the target platform to run a pilot. By the end of a first app your team will know it well, because building that capability is part of the point.
Yes, and this is the first thing we expect your architects to test. The result is a BPMN standards based application: it deploys, it runs, your engineers can open it in the normal tooling and maintain it without us. There is no proprietary runtime and no NextWave APX dependency at run time.