Pwas turns your domain into a shared, dynamic model — the same model your backend executes, your orchestrator plans and verifies against, and your client renders from. One intent in, one verified plan, one interactive result.
Most software hard-codes what the domain contains, what the system can do, and how people interact with the result, as three separate concerns kept in sync by hand. Pwas keeps all three in one place: a live, queryable model of your domain that the backend executes, the orchestrator plans and verifies against, and the client renders from — the same source, always in sync, changed by editing configuration instead of shipping new code.
Pwas.Framework, Pwas.Orchestrator and Pwas.Client don't integrate through rigid APIs bolted together after the fact — they're three readings of the same declarative domain, each responsible for a different translation.
Turns entities into a running API: resources, relations, constraints and allowed operations, all resolved at runtime from configuration — not compiled once into fixed code that has to be rewritten every time the domain changes.
Reconstructs the goal behind a request, checks it against what's actually available, compiles a verified logical plan, and governs its execution — confirmations, limits and a full audit trail included, not an agent freelancing tool calls.
Builds pages, forms, lists and detail views at runtime from the same metadata — a schema's fields decide a form's inputs, its relations decide its sub-sections, without a line of per-entity UI code to maintain.
One runtime-built, queryable model underneath all three interpreters — not logic re-derived independently by each layer, a single source every layer reads from and stays synchronized with.
Attributes, types, cardinality, required-ness, keys, allowed operators and access rules — per entity, per field, always current.
Reads, writes, composed pipelines, transforms and external calls, each declaring its own inputs, outputs, effects and cost.
Recognized intents, preconditions, desired outcomes, alternative strategies, and how a result should be presented.
What a client component can render, which parameters it accepts, which actions it exposes, which results it's compatible with.
Not a niche tool. The same declarative domain that describes a single entity scales to whole categories of product — these are the shapes that recur most.
Ownership-aware permissions and per-role field visibility out of the box, so tenant isolation is a config change, not a rewrite.
Every internal entity gets full CRUD and admin-grade filtering the moment it's added to entities; staff roles gate the dangerous actions.
Compiled pipelines compose category, product and payment-gateway calls into one atomic checkout flow, with async continuation for slow downstream calls.
Mark any field lang: true for an automatic companion table, per-field fallback reads and nested upserts on write.
Pwas.Orchestrator drives the whole surface through the Capability Registry, so an agent can operate the backend without ever touching the codebase.
Hooks, category-based logging and governed recursion leave a traceable, replayable record behind every automated action.
Every request moves through the same six, fully observable stages — nothing is decided by a single unverified model call.
Resolves the caller, their roles, the active environment and config version, then pulls only the entities, workflows and components actually relevant — nothing the caller can't use is ever considered.
The request becomes intents, parameters, filters and desired effects. A missing fact or an ambiguous read pauses the run with a specific question, not a guess.
Workflow knowledge ties the intent to its preconditions and effects; the planner builds a dependency graph of activities — still independent of how it will actually run.
A deterministic compiler resolves the plan against real backend capabilities, tracks every intermediate result's type and origin, and simulates reads, writes and external calls before anything executes.
Independent steps run in parallel, conflicting effects are serialized, sensitive actions stop for confirmation with already-resolved values — Pwas.Framework applies the real authorization, not the plan's assumption of it.
The result isn't just data — it's what changed, what needs attention, what's next. A presentation planner picks a component from Pwas.Client's own catalog to show it.
POST /api/exec/run/orchestrator.route_ticket Authorization: Bearer <agent-token> { "ticket_id": 4821, "signal": "refund_requested" }
{
"execs": {
"orchestrator.route_ticket": {
"role": ["SERVICE"],
"inputs": ["ticket_id", "signal"],
"endpoint": "/api/exec/run/…"
}
}
}
The pieces that make a compiled plan safe to hand to something autonomous — bounded, observable, and impossible to silently break out of.
Loops (for/foreach), conditionals, 30+ fn functions and outbound calls, composed from primitives instead of hand-written per use case.
An async_return step answers the caller immediately while the rest of a compiled pipeline keeps running, reporting completion to a webhook.
Every compiled plan runs under caps on steps, nesting depth, loop iterations and query size, and a role check on who may invoke it at all.
A pipeline can only be re-entered if it explicitly opts in — denied by default, tracked end to end so a compiled plan can never quietly loop into itself.
A static, self-contained description of every entity, pipeline and hook in the project — the same Capability Registry an agent reads, not documentation someone has to keep in sync by hand.
Palantir, Salesforce, ServiceNow and Microsoft each already ship pieces of this vision — a dynamic domain model, agents wired to real actions, governed workflows, metadata-driven UI. Google's A2UI is standardizing something very close to Pwas.Client's own approach to interfaces. None of them combine a dynamically-derived backend schema, semantic planning, verified compilation, effect governance and dynamically-built UI in one runtime.
The closest architectural relative — objects, logic, actions, security and workflows as one operational language for people and agents. Heavier and more infrastructure-bound than a runtime meant to stay compact and portable.
Shares typed action contracts and UI generated straight from them. Stays centered on Salesforce's own application model — most workflows still need to be pre-built as platform assets, not compiled fresh from primitives.
Strong on governed, multi-step workflow orchestration with real data context. Orchestrates agents and workflows that already exist, rather than compiling and verifying a new procedure from backend primitives.
Dataverse, Copilot Studio, Power Automate and Power Apps cover nearly every piece — as separate products. Planning, compilation and UI composition stay the responsibility of different tools, not one continuum.
Less a competitor than a compatible idea: an agent describes a UI declaratively, the client renders it from an approved component catalog. No backend, dynamic schema or workflow engine behind it — a natural fit alongside Pwas.Client's own component model.
| Capability | Market today | Pwas |
|---|---|---|
| Domain model | Ontologies & low-code platforms | Backend schema, interpreted directly |
| Actions | Registered tools & workflows | Composable primitives & pipelines |
| AI planning | Agents picking tools | A compiled, verified logical plan |
| Type checking | Per-action contracts | Propagated across the whole workflow |
| Dynamic UI | Metadata-driven or generative | Components derived from the same registry |
| Model portability | Usually tied to the platform | Swappable, specializable model |
| Architectural unity | A suite of connected products | One declarative continuum, end to end |
A declarative application runtime that compiles intent into verified backend workflows and coherent client experiences — powered by one shared, dynamic model of your domain.
Pwas is developed by Pooel Srl. There's no public repository to clone — reach out and we'll walk you through getting a project running on it.