See Pwas at work: 30 guided minutes on an application that already runs. Book the demo →
Compare products Pwas in your industry Book a demo
Pwas-One
ERPShopCRMDoc ManagerAI Agent
Pwas.FrameworkPwas.ClientPwas.OrchestratorPwas.Microservice
Pwas CLIAssessmefyDynamic Registry Builder
Solutions Industries Documentation Partners Request a demo Get Started
Italiano English
pwas.it — powered by pooel.it
partners · technology partners

The integrations already inside the Pwas ecosystem.

LLM providers, cloud infrastructure, complementary tools — connected via the platform's same integration primitives.

the principle

Why interchangeability is an architectural choice, not a feature.

A model provider is a declared resource, not a dependency.

In projects using AI, the choice of model provider changes more often than anything else: prices change, performance on specific tasks changes, regulatory constraints change, and sometimes the organisation's position on where data may travel changes.

So the model is treated as a declared resource, replaceable per call, not as a library embedded in the application. Replacing it is a configuration change, not a rewrite of the automation, and different projects for the same client can use different providers depending on the sensitivity of the data they handle.

The same category includes the option of models hosted within a perimeter you control, which is the choice for anyone with strict confidentiality constraints who accepts the trade-off in model capability.

Infrastructure isn't a compulsory partner.

The runtime is containerised with no dependencies on one cloud provider's managed services. That means your usual infrastructure provider — or your own server room — is fine, and there's no list of supported clouds to check before starting.

It's a choice with a cost: we don't exploit the proprietary features that would make some things simpler on a specific platform. The benefit in exchange is that moving a project means moving containers and data, and that an infrastructure decision made today doesn't bind the ones you'll make in three years.

In projects where infrastructure is a hard requirement — public sector, healthcare, utilities — that property is worth more than any optimisation.

How an integration gets added to the ecosystem.

There's no marketplace of extensions to certify, and that's not an accident: in the declarative model an external service isn't a plugin, it's a declaration. Which calls it exposes, which fields it accepts, what it returns, what to do on error.

The practical consequence is that integrating a new tool requires neither our involvement nor a certification process: whoever builds the project declares it and it works. What's worth sharing are reusable declarations for widely used services — a carrier, a payment gateway, a public portal — that different partners meet in the same sectors.

If you have a technology you think fits the platform well, the useful conversation isn't about a formal agreement but about how it's declared and what it takes to make it work reliably.

frequently asked

Technology partners: the questions.

Which model providers are supported?
The main commercial providers are supported as resources interchangeable per call, alongside the option of models hosted in your own perimeter. Because the list changes over time and also depends on what's available in your region, the useful thing to verify isn't the provider's name but that switching is a configuration change and not a project.
Can we use an internally hosted model?
Yes, and it's a frequent scenario where confidentiality constraints are strong. The trade-off to assess is capability: models you can host internally typically perform less well on complex interpretation tasks. Because in Pwas the model interprets intent but neither decides nor executes, the trade-off is often acceptable — but it should be verified against your real cases.
Which cloud does it run on?
Any environment that can run containers, including your own infrastructure. There are no dependencies on one provider's managed services, which is a deliberate choice: it keeps the project portable and the infrastructure decision reversible.
How do we integrate a tool that isn't listed?
By declaring it: which calls it exposes, which fields it wants, what it returns, how to handle errors. No certification process and no involvement from us is required. For services common in a sector it does make sense to share reusable declarations, because different partners meet the same systems.
Want to propose an integration?
The useful conversation is technical before it's commercial: how your technology is declared, what guarantees it offers on reliability and error handling, and in which real projects it would be needed. Write to us describing the use case, not the positioning.

Want to propose a technology integration?

Let's talk about how it fits with the existing primitives.