Not a service.
The base for extending Pwas.

In most platforms an extension lives at the margins: a plugin hooking into a foreseen point, with its own permission model, its own interface and its own life. It works as long as someone remembers it exists.

Here it's different, and the difference is structural. A tool built on this base declares itself as a resource — which actions it exposes, which fields it accepts, what it returns, what to do on error — and enters the Capability Registry alongside everything else. From that moment it's a capability like any other: a pipeline invokes it as it would an internal operation, the orchestrator can include it in a compiled plan, and the permissions that apply to whoever invokes it apply there too.

The consequence that really matters: what you build isn't an exception to maintain on the side. It has no authorisation layer of its own to keep aligned, it isn't invisible to the AI agent, it doesn't escape traceability. It's why extensibility here doesn't produce the technical debt it usually does.

The base provides the parts that are identical in every tool and that nobody wants to rewrite each time: the communication contract with the platform, authentication, the asynchronous queue for processing that outlasts a single request, the webhooks for reporting completion, and access to language models through interchangeable drivers.

What you write is the specific logic: how to read that document format, how to compute that thing, how to talk to that system nobody else has. In practice, your code starts where the common part ends, which is exactly where it should start.

The first tool built on this base is the document resolver: field extraction from PDFs and images via a multimodal model, document generation from data and a knowledge base, and personal data anonymisation. It's both a usable tool and a complete example of how a serious extension is structured.

The practical rule is simple and worth respecting, because forcing it either way has a cost.

• Stay in a declared pipeline when the operation expresses itself by composing steps: conditions, loops, functions, calls to external services. That's most cases, and it's the choice that keeps everything readable.
• Build a dedicated tool when real code is needed: reading particular formats, conversions, numerical computation, long-running processing, integrations with systems speaking their own protocols, complex prompts to a model.

What not to do is bend a declared pipeline until it becomes a badly written program just to stay inside the configuration. When code is needed, isolating it in a component with its own queue and declaring it is cleaner, more verifiable and easier to replace.

A tool built on this base is your code, in your repository, released with your procedures. There's no marketplace to go through and no certification to obtain for it to work: you declare it and it gets invoked.

In practice this is what lets a partner or a company with strong vertical expertise build a reusable asset: the tool that reads a sector's typical interchange format, the one that talks to a specific machine, the one that computes something only you compute. You reuse it on every project in that sector, and it doesn't belong to us.