Skip to main content
Praxa missions excel at automating discrete, goal-directed tasks that previously required direct integration with AI providers. Instead of embedding provider API keys in your codebase and wiring together model calls yourself, you describe the goal, set a resource budget, and let the Praxa Integration Gateway handle execution. Your application stays stateless with respect to provider credentials — you only ever hold a short-lived delegated access token.

Example: Automated Report Generation

The example below submits a “generate weekly sales report” mission, then streams the resulting events to collect the completed output. Notice that createMission requires an idempotency key — if your worker restarts mid-flight and submits the same key again, Praxa returns the existing mission rather than creating a duplicate.
Set maximumElapsedMs generously for report-generation tasks. If the budget is exhausted before the agent finishes, the mission transitions to failed. You can inspect the partial steps via getMission() to understand how far execution progressed.

Example: Content Summarization

Summarization missions follow the same pattern. Pass the document content or a reference to it inside goalSpec, and tune the resource budget to the expected length of the input.

Handling Results

Every mission streams a sequence of server-sent events through missionEvents(). To extract the final result, listen for mission.completed — its data field contains the agent’s output payload.
The event stream closes automatically once a terminal event (mission.completed, mission.failed, or mission.cancelled) is emitted. You do not need to explicitly close the connection.

Scheduling Missions

Praxa missions are a natural fit for cron jobs and queue workers because createMission is idempotent — submitting the same idempotency key twice returns the original mission projection rather than starting a second execution.
1

Generate a stable idempotency key

Derive the key from the job’s logical identity (for example, a combination of the task name and the time window) so that retries after worker failures submit the same key.
2

Submit the mission in your cron handler

3

Store the runId for later retrieval

Persist mission.runId in your database so you can fetch the mission status later with getMission(runId) without re-streaming the event log.
For ad-hoc or queue-driven tasks where no natural business key exists, use crypto.randomUUID() as the idempotency key. It is available globally in Node.js 20+ and all modern browsers — no import needed.