Agents, Plans, Workflows, Resources and Governance
Five parts, and one boundary around all of them. What each one is, and why they are separate.
Most AI platforms hand you one thing and call it everything: an assistant that answers, or an engine that runs what you already knew how to build. NeuralVantage™ keeps five parts separate on purpose, because designing work, doing work, reaching your systems and proving what happened are four different jobs with different people accountable for each.
Three of them form a sequence: a plan designs the work, a workflow executes it, and a run records what actually happened. The other two are not stages. Agents supply the intelligence and governed resources supply the access, at whatever point the work needs them.
And governance is none of those things. It is not the last step in the sequence. It is the edge of the space the whole sequence runs inside: authorized before, observable during, provable after.
Agents reason and recommend. They never decide.
An agent is not a chatbot with a job title. It is configured for one job, and everything it is allowed to know and do is decided before it runs.
What you configure. Everything, and all of it before it runs. A name and a purpose, so it is clear what this agent is for and what counts as having done it well. Instructions, written in your language rather than code, covering how to approach the job and what to avoid. Knowledge sources: the specific documents, policies and records it may read, which is a list you approve rather than the internet or everything in your company. Tools and connectors, read only, so it can look up a policy or fetch a claim but cannot write one back. A model, chosen for this job. The shape of the answer it has to return, so the next step can rely on it instead of interpreting prose. Guardrails covering what to mask, what to refuse and when to escalate. And a quality bar, meaning the confidence it has to reach before its answer counts for anything.
What happens when work reaches it. A workflow or a person hands it a task. It retrieves only from its approved sources, reasons over what it found, and returns an answer carrying its confidence and a citation for each key point, so you can check the basis rather than take its word. If confidence is low or the risk is high it escalates instead, and a person picks it up. Nothing about that path is optional or configurable away.
What it cannot do, and why that matters. An agent can be as capable as you like and still cannot release anything. It recommends. It does not decide, and it cannot act. Deciding belongs to a person who is accountable for the decision; acting belongs to a workflow, which does only what was published. Most AI failures in the enterprise are not bad answers, they are good answers that reached production without anyone agreeing to them. Keeping recommendation, decision and action in three different hands is how that stops being possible.
Where you would use one. A policy coverage advisor that reads a claim and the policy wording and says what is covered, with the clause cited. A damage estimate analyst. A fraud signal triage agent. A settlement decision reviewer. Each is narrow on purpose, because a specialist with a named source list is checkable in a way that a general assistant is not.
A plan is the design, before anything runs*
A goal broken into the work it actually requires: the tasks, what depends on what, which specialists could do each part, and where a person has to sign. You review it, change it, and approve it as a design. Approving a plan freezes it and pins the exact version of every agent in it, so what later runs is what was approved. Changing an approved plan means reopening it, which invalidates the workflow it produced.
How it goes. You describe the business objective in a sentence. The platform proposes the tasks it would take and how they depend on each other. Owners refine that: renaming steps into their own language, changing what runs in parallel, assigning which specialist does what, and marking where a person has to sign. Then it goes for approval, with risk checks. Approved items become workflows. Those workflows run, with evidence.
What approval actually does. This is the part worth understanding, because it is unusual. Approving a plan freezes it. The exact version of every agent in it is pinned at that moment, and the workflow is later built from the frozen copy rather than from whatever the plan says now. So what runs is what was approved, not a descendant of it. Changing an approved plan means reopening it, and reopening invalidates the workflow it produced. There is no path where the design quietly moves between the approval and the execution.
One plan does not have to become one workflow. It can become several, which is the normal case for anything large: a disruption response plan might produce separate workflows for passenger impact, rebooking, compensation and communications. It can produce agents and human tasks alongside workflows. It can stay research, ending in a recommendation with nothing automated at all. Or it can end in no execution, which is a legitimate outcome and one the platform will let you record.
When you should skip it. Not every process needs a plan. When the control path is already known and already authorized, a month-end close or a fraud escalation, you build the workflow directly and the plan would be ceremony. A plan earns its place when you know the outcome but not yet the shape of the work, or when several teams have to agree on that shape before anyone builds it.
A workflow is the process, exactly as it will run
Named step types, explicit dependencies, branches, retries, timeouts, approval points and governed actions. What a workflow does is fixed when it is published, so it does not drift between one run and the next.
What it is made of. A closed set of step types and nothing outside them. Steps that run an agent. Steps that call your systems, whether a REST service or a stored procedure. Steps that branch on a rule, wait for a period, or hold until an outside system reports back. A step that stops for a named person to approve. Steps that produce a document or spreadsheet, and steps that send it by email or Teams. Because the set is closed, a workflow cannot do something the platform has no step for, which is what makes it reviewable before it ever executes. The most used are shown below, and the full set is listed on the platform page.
What is checked before it can be published. The platform will not publish until every one of these holds. Every step has a defined type. Every dependency is written down rather than implied by ordering. What happens on failure is configured, for each step. Anything that writes to a system has human approval attached to it. The permissions the workflow needs actually exist, rather than being assumed. And the policies that apply are attached. This is where most of the value is created, because it happens before anything has run and while changing it is still cheap.
How a run ends. There are only three possibilities, and no others. It completes as designed. It completes partly and hands what is left to a person, which is the right outcome for anything that hit a case it was not built for. Or it fails and stops, with no half-finished side effects left behind. A run that quietly did some of a payment is not among the available outcomes.
The life of one. You design it, test it against sample data and scenarios, publish it for governed execution, run it with full visibility, monitor how it is performing and what it costs, and improve it as a new version. Old versions do not disappear when a new one is published, so a run from three months ago can still be explained by the definition that actually produced it.
Everything the work is allowed to reach, and nothing else
This is the part that separates a system connected to your enterprise from one that has been handed the keys to it.
What counts as one. Knowledge sources, meaning the documents, knowledge bases and data sets used for retrieval. Connectors and APIs into the systems where the work actually lives. Tools and actions that agents can invoke. Models and providers. Secrets and credentials, held properly and referenced at runtime rather than pasted into a configuration. And the policy packs that govern how any of it may be used. They are grouped together because they share one property: they are the surface where your platform touches your enterprise.
How one comes into being. Somebody registers it, with its classification and an initial policy. Governance reviews the access and compliance position and approves it, or does not. Only then can it be bound to a specific agent, plan or workflow. When it is used, it is used under the policy it carries and with least-privilege access. And every use is logged, so what has been touched and by which piece of work is a question with an answer.
What a resource carries with it. An owner, so there is a person answerable for it. A scope. Whether it is read-only or can be invoked. Its policy rules, which is where things like masking personal data, keeping data in a particular country, and how long to retain it are stated. And, most importantly, a named list of the agents, plans and workflows allowed to consume it. Nothing outside that list can reach it, and adding something to the list is a governed act rather than a configuration change.
Why this is a separate part rather than a setting on an agent. Because the same knowledge base and the same claims API are used by several agents, several workflows, and possibly a plan that has not been built yet. If access were a property of each consumer, the answer to "what can this system reach, and who approved that" would be scattered across dozens of places. As its own layer it is one register, one approval trail, one place to revoke.
Governance is the boundary, not the last step
This is where most platforms lose the argument. Governance applied after the work is reporting, and reporting cannot stop anything.
Human authority. Approvals, review loops, escalation paths and the checkpoints where a person has to decide. A request goes for review, someone approves it or escalates it, and the decision is recorded against their name. Approvals have service levels attached, because a control nobody can meet is not a control. And the approvals themselves are auditable, including the comments.
Runs and execution assurance. Every run keeps its full history and status. Retries and replays are tracked, and which version of the definition produced a given run is recorded. So is the provenance of every input and every step, meaning where the information came from before it was used. A run from months ago can be opened and explained without anybody reconstructing it from memory.
Evidence and outputs. Artifacts are immutable once produced. Lineage runs end to end, so an output can be traced back through the steps and sources that made it. Deliveries are recorded and confirmed, which matters more than it sounds: a report that was generated but never arrived is a different problem from one that was never generated, and the two need to be distinguishable.
Policy and quality. Policies and standards live centrally rather than being restated per workflow. Validation rules and quality gates run before anything is released. Guardrails and risk controls apply during execution, not after. And release controls decide what may actually go out.
Audit and compliance. Comprehensive audit trails, evidentiary records with their attachments, and exports built for regulators and auditors rather than for engineers. Retention, legal hold and compliance rules are enforced by the platform, so the answer to "can you still produce this from eighteen months ago" does not depend on whether anyone thought to keep it.
Identity and scope. Underneath all of it: tenant and workspace separation, role-based access, fine-grained permissions, clear ownership, and separation of duties so that the person who raises something is not the person who approves it. This is the layer that makes every claim above meaningful, because an audit trail that anyone can write to is not evidence.
Why keep them separate
Because collapsing them is how the accountability goes missing. If the thing that reasons is also the thing that acts, nobody can say who decided. If the design and the running process are the same object, approving one approves the other. If access is a property of an agent rather than a governed resource in its own right, nobody can answer what the system is allowed to reach.
Kept separate, each question has one place to look and one person answerable for it. That is the whole design.
On plans. A goal is decomposed into steps, reviewed and edited by a person, approved, frozen, and turned into a workflow. Approving one pins the exact version of every agent in it, and authorises a design rather than an action. The pictures on this page are diagrams; the screens themselves are on inside the platform.