Inside NeuralVantage™
One briefing, followed the whole way through. Most AI platform pages describe what a product would do - these are our screens, doing it.
A finished piece of executive work - the thing that lands in an inbox at seven in the morning already reasoned through - is not one feature. It is the end of a chain: somebody has to state what they want, that has to become a design a person can argue with, the work has to be shaped, the agent has to be told what it may and may not use, the run has to be recorded, other agents have to check it, a person has to be able to stop it, it has to reach somebody, and it has to be kept for as long as policy says and no longer. Break any link and the last step stops being trustworthy.
So rather than list features, here is that chain, in order, as it appears on screen.
It starts with a sentence
Take the case a cruise operator actually faces: weather threatens a scheduled call, and somebody has to decide what the ship does instead. In NeuralVantage that is typed as a business goal, in the words the business already uses, and the platform decomposes it into a proposed plan - the steps, what depends on what, and who or what would do each one.
What comes back is a draft. It has a status, a version, a step count, and no workflow attached to it, because nothing has been created yet. The line under the box is the whole posture in one sentence: the generated plan starts as a draft awaiting governed review and approval.
- The goal is written in business language, not configuration
- What comes back is a draft awaiting review, not something that runs
- No workflow exists yet, and the screen says so
A plan you can argue with
The proposal opens as a map. Each step carries who would do it - an agent, or a named human role like the Disruption Operator - what it needs, and what it is allowed to become. Most read PlanningOnly or ResearchOnly: the platform's own way of saying this step is a design, not permission to act. A person can rename steps, redraw dependencies, assign a different agent, or hand a step to a human instead.
Then it is checked against the environment you actually have. In this plan, the readiness verdict is Blocked, and individual steps read Blocked or Not checked - the platform will not call a design ready until the agents, connectors and approvals behind it are actually in place. A plan is a governed object with a lifecycle of its own: steps, readiness, resources, governance, versions, and a record of which workflows it has produced.
A plan is a governed object with a lifecycle of its own: steps, readiness, resources, governance, versions, and a record of which workflows it has produced.
- Every step declares who does it, what it needs, and what it may become
- Readiness is checked against the agents and connectors you really have
- Approving a plan authorises a design, never an action
Help at the hard parts
Writing the goal was the first place the platform helped: a sentence became a structured plan. The same help returns three more times, at the points where a design is furthest from being runnable - and each time it stops at a decision rather than making one.
Create workflow turns an approved plan into a draft workflow before the agents exist. That matters more than it sounds. Most tools need every agent built and bound before they will draw you a workflow, which is precisely backwards for planning: you are designing because you do not yet know what you need. Here the steps come through unbound and visible, conditional branches are expanded into real branch logic, and what you get is a draft you can look at and argue with.
Suggest agents reads the plan and works out which of its steps still need an agent. Where your workspace already has one cleared to run, it says so. Where it does not, it proposes the agent to build: a name, a description, the instructions and the task it would carry, and the sources it would read - drawn from your own inventory, with anything it cannot find written down as an open question rather than invented. It considers all the unstaffed steps together, so a researcher and a reviewer come back sharing sources rather than duplicating them. Accepting a proposal creates a draft agent, unbound and unpublished, for you to finish. It leaves the approval steps alone, because an approval is a person's decision and does not execute through an agent.
What comes back is matched to the step rather than picked off a list. The step below is about watching for weather events and port closures, and the agent it draws is the Weather and Port Status Monitor - scored against the step's type, title, description and the system it names. Where nothing in the workspace fits, that same panel proposes the agent to build instead.
There is a third kind of help on the same page, for the work no single agent should do alone. Suggest team proposes a multi-agent team for the plan: the roles and what each is responsible for, which existing agents fill them and which are still missing, how work hands off between them, who reviews whom, and - the part that is usually left until it goes wrong - how a disagreement between two agents gets settled. Every field of it is yours to edit, and asking for another version carries your edits into the next one rather than throwing them away. Nothing is created by looking at it. When the proposal is right, you take it to the Multi-Agent Designer and build the team there.
This is the shape the platform's assistance is taking generally: it does the reading, the drafting and the joining-up, and it stops at every point where a person should be deciding. It proposes a plan, then the agents that plan needs, then the team those agents form, then the workflow that runs them - and it publishes, binds and starts none of it.
- A workflow can be drafted before a single agent exists
- Missing agents are proposed, not just reported missing
- Roles, handoffs, review and arbitration are proposed as a team, then edited
- The platform proposes; a person accepts, edits or discards
- None of it publishes, runs, approves or binds anything
- What it cannot find, it says it cannot find
The same adviser, everywhere you author something
The help on the plan is not a feature bolted to one screen. Wherever the platform asks you to author something - an agent, a team of agents, a plan, a workflow - the same card sits at the top of the page, asks what you are trying to achieve, and hands back a draft. Six places, one pattern, and the same full stop at the end of each: a draft, for you to read.
What separates it from a chat box is what it is allowed to know. Three bodies of context are assembled for every generation, and nothing outside them is available to invent from.
- What the platform can do The step types that exist, the governance rules that apply, what an agent may and may not be told. Keeps a proposal to things the platform can actually express.
- What you actually have The agents, sources, connectors and features live in your workspace right now - by their exact keys. This is why a proposal names a source you own rather than one that would be convenient.
- What your organization calls things Your systems, your vocabulary, your constraints. Optional, and switched off per generation with a single checkbox on every one of these screens.
The consequence is worth stating plainly, because it is the opposite of what people expect from a generative feature. Because the adviser is only ever shown what exists, it cannot furnish a proposal with a source, connector or role that you do not have. Where it needs something it cannot find, it writes the gap down as an open question and leaves it for you.
- One pattern across agents, teams, plans and workflows
- Grounded in what your workspace actually holds, by exact key
- Your business vocabulary is optional and switched off per generation
- Every one of them stops at a draft
The shape of the work
Real business work is not a straight line. Take an example like accounts payable. In NeuralVantage, the workflow is drawn the way the work actually happens. A new invoice arriving through a procurement webhook starts the job. A planner breaks the job into pieces. Three agents then work at once - one reading the invoice, one matching it to the purchase order, one checking it for compliance - and a reviewer waits until all three are back before forming a view. Where they disagree, arbitration settles it. Only then does it reach the AP manager, and only after that approval does anything post to the ledger. That order is a property of the design itself, not of which agent happens to run first, and the whole thing can be validated, simulated and impact-assessed before anyone hits Publish.
- Three agents work in parallel; the reviewer waits for all three before deciding
- Nothing reaches the ledger until a named manager has approved it
- A design can be simulated and impact-assessed before it is published
What the agent may and may not use
Everyone claims their AI is grounded in your data. Here is what that means in practice. Take the use case of defining a daily financial briefing. The instruction is explicit - “Use only the provided grounding sources. Do not invent facts” - and beneath it sit the sources themselves, named and addressable: CNBC Markets, MarketWatch, Federal Reserve press releases, and the US Treasury yield curve. Not a vector store somebody loaded once. Four feeds you can open in your own browser and check.
- The instruction forbidding invented facts is part of the agent, not a hope
- Each source is named, addressable and individually switchable
- Every source has a Test button, so a dead feed is found before a run, not after
It will not let you ship it half-built
Beside the form, the same page keeps a running list of everything that has to be true before an agent is allowed to run: instructions present, sources valid, output format chosen, delivery configured, provider installed and enabled, a fallback provider configured and compatible - and no raw secret values anywhere in the profile. The list is footed Server-validated, which is the part that matters: the browser is not the thing deciding.
- A fallback provider is checked as thoroughly as the primary one
- “No raw secret values” is a check the platform runs, not a policy in a document
- Validated on the server, so it cannot be bypassed from the browser
A record of what actually happened
For our Executive Daily Financial Briefing, four sources were configured and thirty-one documents retrieved in 809 milliseconds, before a prompt was built and a model was called. Every stage is stamped: queued, started, configuration validated, sources retrieved, prompt built, model called, artifact generated, output delivered. And above it the model provenance - the model requested, the one that ran, and the one that was effective, side by side, with the decision that admitted it and the provider’s own request identifier. A quiet substitution would have nowhere to hide, and a run that retrieved nothing could not pretend otherwise.
- Retrieval is a timed, counted step - not an assumption
- Requested, runtime and effective model are recorded separately
- Every stage from queued to delivered is stamped and kept
Where more than one agent is involved, each one is graded
One model answering one prompt gives you one opinion and no way to weigh it. This run passed through six specialists in turn - a planner, a researcher, a reviewer, a validator, an executor and delivery - and each one’s contribution is kept separately, with its own confidence, its own token count and its own cost. Note the validator at seventy-two per cent against five others at ninety. That is the number worth having: an average of eighty-seven would have buried it.
- Confidence recorded per agent, not averaged into a single figure
- Tokens and cost attributed to the individual step that spent them
- A low-confidence step stands out instead of being absorbed by the total
At the point that matters, it stops for a person
“A human reviews the output” is easy to say and hard to operate. When a run stops for approval it goes into a named queue with a named approver group, under a policy that says how long it may sit there and what happens when it does not move. A routine item escalates after twenty hours of its twenty-four; a high-risk one blocks as well as escalates after three of its four. Waiting is a state with a clock on it, not a gap in the process.
- Approvals route to a queue and an approver group, not to an inbox by chance
- Each policy sets a due time, an escalation point, and what expiry does
- Notifications go out by email, Teams or Slack on created, expiring and expired
It has to actually reach somebody
Work that stays inside the platform has not been delivered. This is the same briefing again, filtered to every send it has ever attempted. Most went out first time and carry the minute they landed. Three are still Pending with no delivery time against them - and two of those are on their second attempt. That is the column worth looking at: a first attempt did not land, and the platform is still trying rather than quietly dropping it. The error column is there for the day a retry runs out.
- Delivered and pending are separate states, and a pending row has no delivery time
- Attempts are counted per delivery, so a retry is visible instead of hidden
- Recipients are masked in the operational view
And this is what arrives
Everything above is machinery. This is the output: an executive briefing in the inbox at ten past ten, sent by the platform, nobody awake. Not a summary of headlines - the two-year yield up five basis points to 4.24%, tariff retaliation priced as an input-cost risk, an Nvidia server-cost warning read through to enterprise AI budgets, and a note that a consumer signal came from one survey with no aggregate spending data behind it. That last one is the tell. It was told not to invent facts, and where the evidence was thin it says so rather than rounding up.
The same briefing is also produced as a PDF - the artifact that gets retained, and the one that expires in the next screen.
- Written to a specified structure, in a specified order, every time
- Exact figures and named risks, not a digest of headlines
- Where the source data was thin, the briefing says so
Afterwards, it stops being available on a schedule
Most governance conversations are about who may do what. The harder half is what becomes of the document once the work is done. Customer-facing documents are kept for a year, machine-readable working files for ninety days, and a legal hold overrides both indefinitely. Nothing is deleted on a timer alone: every purge has to be approved, and in the queue below one document is waiting for that approval while another is refused outright because it is under hold.
That policy is not advisory. Here are six briefings from the same agent. Three are still available; on the other three the download button is simply gone, replaced by the word Expired. The record and its ownership survive; the ability to fetch the file does not.
- Retention set per tenant and per document type, not one rule for everything
- Deletion is a request that has to be approved, never an automatic sweep
- Legal hold blocks the purge, and shows as the reason it was blocked
About the figures on these screens. They come from a demonstration environment with sample tenants and sample runs, so the names, amounts and counts are illustrative rather than any customer’s real data. The screens themselves are the product, unaltered apart from cropping away the navigation column and the environment strip.
That briefing is the easy part to copy. The chain behind it is not.
Any capable model can write something that reads like the email above. What it cannot do on its own is name the sources it was allowed to use, refuse to run until its configuration is valid, record what it retrieved and which model actually answered, let a second agent mark down the weak step, stop for a named approver, prove it was delivered, and then withdraw itself when retention says so. That chain is the product. The briefing is just where you notice it.