Adapt it
to your case.
Have a precise need? You don't touch Pumaï's core. Creating a tool is already an extension of the app — and the agent uses it on its own, as soon as it's well defined.
A tool is an extension
Extending Pumaï isn't forking the app: it's giving it access to your systems by writing small tools. A well-described tool — a clear name, what it does, its parameters — is picked automatically by the agent when the task calls for it. You close the loop by naming the tools in the instruction, so the same schema replays exactly, every day.
Wrap an API as a tool
Your service has an API? Wrap it in a tool: fetch, create, update — whatever you need.
A processing tool
A tool that transforms data or formats content — into exactly the output shape you expect.
Connect the agent to the right tools
On demand or via an autonomous Pulz: the instruction names the tools, and the schema runs on its own.
A support desk that reports every evening
A client needs to handle the requests assigned to them, and receive an end-of-day report in a precise format. Here's how it comes together.
Access the ticketing system. Their helpdesk has an API: we build one tool that pulls the tickets assigned to them, and a second that marks a ticket "in progress" or "resolved". Both are designed and tested in the Tool Studio, no boilerplate.
Shape the output. The report must follow a precise template — sections, tone, typography. We build a formatting tool that turns raw notes into exactly that layout. (Sending email is already built into the system.)
Put it on autopilot. We create a Pulz — an autonomous mission — and give it the instruction in plain words, naming the tools to use. The same schema replays every evening, under the same governance (a sensitive send can still require your approval).
naming the tools is optional — the agent can pick them on its own — but it's sharper and more reproducible. the loop is closed: fetch → reason → format → deliver, every day.
From tool to Competence
What other frameworks call a "skill", Pumaï splits into two native pieces: the tool — the callable capability (reach an API, format, send) — and the Competence — the reusable procedure, the "how" of a recurring task (handle a quote, manage a complaint, produce a report). You create a Competence once, through a guided interview in a dedicated studio; the agent then picks it by meaning, exactly as it picks a tool, and applies it identically. The result: reliable, repeatable behavior — and a measurable gain (an "with / without" comparison quantifies the time and cost saved).
Universal by design. None of this is specific to support. You can build API access to anything, data-processing tools that emit any format, and — when a task needs raw system power — tools that lean on the filesystem and Linux commands. You extend the product by creating tools, and you steer the agent toward them in the instructions. That's it.