Pwas.Orchestrator turns an agent from "random tool calls" into an executor of compiled, verified and governed plans — with human confirmation on sensitive actions.
Giving a language model direct access to your systems without a planning and verification layer means untraceable actions, unauthorised writes and non-reproducible behaviour. Pwas.Orchestrator inserts a deterministic compiler between intent and execution: every plan is verified against the backend's real capabilities before a single byte is written.
understanding the difference
What happens, step by step, when someone asks the agent for something.
In the architecture that currently dominates, an agent receives a request and has a list of tools available. It decides which to call, calls it, looks at the result, decides the next one. It works surprisingly well in demos, and has two problems that only surface in production.
First: there is no moment at which anyone can look at what is about to happen as a whole. Actions occur one at a time, and when the third fails the first two have already run. Second: permission checking, where it exists, lives inside each individual tool. One tool forgetting it is enough to give the agent a route to do something that user couldn't do.
What Pwas.Orchestrator does instead
The request is first reconstructed as intent: what is to be achieved, on which objects, under which constraints. Then compared against the Capability Registry — the runtime-built list, derived from the domain description, of what actually exists and what that user can actually do at that moment. If the intent requires something that doesn't exist or isn't permitted, it stops here, before touching anything.
If the intent is achievable, it's compiled into a logical plan: an explicit sequence of steps with declared inputs and effects. The plan is an inspectable object — it can be shown to a person before execution, recorded, replayed identically. Only then is it executed, under explicit limits on step count, nesting depth, iterations and query size.
Where the human comes in
Actions that modify data can require explicit human confirmation, with the exact content already visible before approval. Not a generic "do you want to proceed?": the payload that will be written, on the record that will be touched. Whoever confirms sees exactly what they're authorising.
In the example above, that means the agent sees: the warehouse change on order 4412, the notification text and the recipient. If their role doesn't allow changing the warehouse of an order already being picked, the agent doesn't propose that action: the plan doesn't compile. Not because someone wrote a check for it, but because that rule is declared in the domain and holds everywhere.
the comparison
Direct-access agent versus governed agent.
The difference doesn't show in a ten-minute demo. It shows the day something goes wrong.
Agent with direct tool access
Quick to stand up, hard to defend
Actions happen one at a time: if the third fails, the first two have already run.
Permission checking lives inside each tool and can be forgotten in one of them.
There's no moment at which a person can see the complete plan before execution.
The same prompt can produce different behaviour at different times.
The trace, where it exists, is a call log: reconstructing intent is interpretation.
Adding a new tool means reviewing that tool's security.
Agent governed by Pwas.Orchestrator
More steps, but defensible to anyone
The plan is compiled in full and verified before anything is written.
Permissions are declared in the domain and hold on every path, without exception.
The plan is inspectable and can require human confirmation with the exact content.
Execution is deterministic: the same plan produces the same result.
The trace records intent, plan, decisions and rationale, not just calls.
A new capability is born declared: it enters the registry with its permissions defined.
the cycle
The six phases, applied to your process.
Context acquisition, semantic analysis, logical plan, compilation, governance, presentation: the same cycle Pwas.Orchestrator applies to every request becomes the engine of your automation.
01
Context acquisition
The orchestrator gathers who is asking, with which permissions, what state the system is in and which capabilities are available at that moment. Context isn't an optional parameter: it's what everything else will be verified against.
02
Semantic analysis of intent
The natural-language request is reduced to an explicit goal: which entities are involved, what result is wanted, which constraints are implicit in the request. It's the only point where the language model plays a decision-making role.
03
Logical plan construction
The goal becomes an explicit sequence of steps, each with its own declared inputs, outputs and effects. Where alternative strategies exist for the same result, they're evaluated here.
04
Compilation and verification
The plan is checked against the Capability Registry: every step must correspond to an operation that genuinely exists and is permitted for that user. A plan that fails verification isn't partially executed: it isn't executed.
05
Governed execution
The compiled plan runs under explicit limits — step count, depth, iterations, query size — and with the required human confirmations on sensitive actions. Recursion is denied by default and must be enabled explicitly.
06
Result presentation
The result comes back not as free text but as structured data the client knows how to render: a list, a record, a confirmation. And the whole path — intent, plan, decisions, outcomes — stays recorded.
how an agent works
A governed AI automation, step by step.
From a plain-language request to a verified plan, a human confirmation and a traced execution — and to what happens when the action is not permitted.
the guarantees
What a Pwas agent cannot do.
These are structural constraints of the engine, not settings someone can forget to switch on.
0
actions outside the registry
If an operation isn't declared as available to that user at that moment, there is no path through which the agent can execute it.
before
verification precedes execution
The complete plan is validated against real permissions before any write occurs, not step by step as it happens.
denied
recursion, by default
A pipeline can only be re-entered if it explicitly opts in, tracked end to end: a plan cannot silently call itself.
100%
of runs traced
Tool invoked, decision taken and rationale stay recorded for every execution, in an audit trail independent of the HTTP request log.
These are properties of the orchestration engine, verifiable in a demo. They don't replace the risk assessment your organisation must still carry out on the use of AI in its own processes.
in depth
The serious objections, and the answers.
The ones that come from people who've already tried putting an agent into production.
"If the model misreads the request, the plan will be wrong anyway."
True, and it's the real limit of the approach. Compilation doesn't make the model smarter: it makes it impossible for a misinterpretation to become an action that isn't permitted. Those are two very different guarantees and it's worth not confusing them.
If the agent asks to move order 4412 and the model reads 4421, the plan will be formally valid and substantively wrong. What the system guarantees is that: order 4421 exists, that user has the right to modify it, the proposed operation is permitted, and the exact content is shown before confirmation. The error becomes visible at the moment a person looks at what they're approving.
That's why human confirmation on data-modifying actions isn't a precaution to remove once you get comfortable: it's the point at which misinterpretation gets caught. Where you do remove it — and in some low-risk flows that makes sense — it should be done deliberately, knowing what you're trading.
"What does all this verification cost in latency and tokens?"
It costs, and you should know that. Reconstructing intent and compiling a plan takes more work than a direct tool call, and on trivial requests the difference shows.
Two things change the arithmetic, though. First: the expensive part is interpretation, not verification. Checking the plan against the registry is a deterministic operation on data already in memory, in the order of milliseconds — not a second model call.
Second: a compiled plan executes without returning to the model at each step. In the successive-calls approach, every step means another model interaction to decide the next; on a six-operation flow that's six round trips. Here there's one interaction, and the six steps run as a pipeline. On non-trivial flows — which are the ones worth automating — the balance often favours compilation.
It remains true that for a single simple read the direct approach is faster. Where latency is the dominant constraint and the risk is nil, there's no reason not to use it.
"Do we have to use a specific model? And where does our data go?"
The orchestrator isn't tied to a model provider: the model is a replaceable component, and the choice is made during the project together with you, including the option of models hosted inside a perimeter you control.
On data flow, one principle greatly reduces the surface of the problem: the model needs to know what is possible, not what your records contain. The interpretation phase works on the request and the description of available capabilities — entity names, operations, constraints — not on the whole database contents. Real data is read during execution of the compiled plan, which happens inside your perimeter.
This doesn't remove every confidentiality consideration: a user's request may contain sensitive information, and presented results pass through somewhere regardless. These are aspects designed explicitly, and in particularly sensitive scenarios they lead to choosing an internally hosted model.
"Where do we actually start?"
Not with the agent. You start with what the agent will use: the domain description. A governed agent is useful to the extent that the registry it reads is rich and correct, and that registry comes from the same work any Pwas project requires.
The path that works best in practice has three stages. First: bring a narrow scope — one process, a set of entities — into the declarative model and use it without agents, simply as an application. That validates that the domain is well described. Second: enable the agent read-only, on operational questions. Zero risk, immediate value, and it exposes the limits of the description. Third: enable data-modifying actions, starting with low-impact ones and with human confirmation switched on.
Those who skip the first two stages reach the conclusion almost everyone reaches: the agent is only as good as the domain model it reads, and a badly described domain isn't compensated for by a better model.
quick check
When this approach genuinely helps.
Probably yes
You want AI to perform actions on business data, not just answer questions.
You operate where you must be able to explain why an automated action happened.
You tried a direct-access agent and stopped for security reasons.
Your permissions are intricate and you don't want to replicate them inside every tool.
You need certain actions always to pass through explicit human confirmation.
You want to be able to change model provider without rewriting the automation.
Probably not
You need a conversational assistant answering over documents, without acting on systems.
The use case is a single simple read where latency is the dominant constraint.
You're looking for a model to train on your data.
You have no described domain and don't intend to describe one.
frequently asked
AI automation: the specific questions.
Do we need Pwas.Framework already to use the orchestrator?
You need a Capability Registry, that is a declarative description of what exists and what is permitted. Pwas.Framework produces one naturally, and it's the most direct route. It's also possible to feed the registry by describing capabilities exposed by external systems, but the level of guarantee obtained depends on how far those systems allow permissions to be verified in advance: that's a case-by-case assessment.
Can the agent be used by our end customers, not just internal staff?
Yes, and the guarantee is the same: the plan is verified against the real permissions of whoever made the request. An end customer will only see plans compile that concern what they own. It is wise, though, to design explicitly which actions are exposed externally, because the risk surface changes when the user isn't an employee.
How do slow actions behave, like a call to an external service?
A plan can contain an asynchronous continuation step: the system answers the requester immediately while the rest of the pipeline continues and reports completion to a webhook. It's needed exactly where an external service takes seconds or minutes and there's no sense keeping the user waiting, without leaving the operation in an ambiguous state.
Can we always see the plan before it runs?
Yes. The compiled plan is an inspectable object, and presenting it to the user before execution is configurable per action type. The typical configuration is: reads without confirmation, low-impact writes with notification, sensitive writes with explicit confirmation and visible payload. Which actions fall into which category is your decision.
How long to a first agent in operation?
If the domain is already described, a read-only agent for operational questions is a matter of days. Starting from scratch, the timings are those of describing the domain — a few weeks for a narrow scope — because that's the real work. Enabling data-modifying actions is a later step taken gradually.
How is this different from connecting an LLM to an MCP server?
A tool server exposes operations the model can call; responsibility for verifying what is permissible stays distributed across each tool, and there's no overall plan to inspect before execution. The orchestrator adds exactly those two elements: centralised verification against real permissions, and a compiled, inspectable plan. The approaches aren't mutually exclusive — Pwas can expose capabilities to such clients too — but the guarantees differ.
We use technical cookies and, with your consent, analytics cookies (Google Analytics) to understand how the site is used. Read our Privacy & Cookie Policy.