Skip to main content
Praxa is a governed agent platform with deliberately separate developer surfaces. You can submit a narrow durable task through Execution Fabric, operate a budgeted mission through a deployment-specific Integration Gateway, register MCP tool contracts, receive signed webhooks, or query an existing memory provider without migrating it first. Each surface has its own credential and authority. See the complete use-case catalog before choosing an integration.

​
How Praxa Works

Every unit of work in Praxa is a mission. When you create a mission, you supply two things:
  • A goal specification (goalSpec) — a structured description of the task you want the agent to accomplish.
  • A resource budget (resourceBudget) — explicit limits on how many steps, tool calls, elapsed milliseconds, and parallel sub-tasks the mission may consume.
You submit the mission through the Praxa Integration Gateway using a short-lived OAuth access token scoped to the operations your application needs. The gateway validates your tenant, principal, consent record, purpose, budget, and idempotency key before any execution begins. Provider execution and verification remain entirely server-side — your application receives a runId and a stream of structured events, not raw provider output. An accepted mission request is not proof that an external effect has occurred. The gateway records your intent durably and enforces policy independently.

​
Key principles

Credential separation. Gateway mission calls never require provider API keys in your application. The optional @praxa/sdk/memory entrypoint exposes read-only adapters for clients your backend already owns; it discovers and stores no credential. The SDK, CLI, and MCP contracts contain no embedded secrets. Explicit authentication. Integration Gateway operations use short-lived, delegated OAuth tokens and operation-specific scopes. Execution Fabric uses personal-workspace API keys with a separate v1 scope vocabulary. A scope grants access to Praxa policy evaluation; it does not by itself prove that an external provider effect occurred. Idempotency. Every mutating operation requires a stable idempotency key. If you retry a createMission call with the same key, the gateway returns the existing mission rather than creating a duplicate. Safe read operations are also retried automatically by the SDK. Resource budgets. Missions cannot exceed the resourceBudget you declare at creation time. Setting explicit limits on steps, tool calls, elapsed time, and parallelism protects both your application and downstream provider resources.

​
What you need for a mission integration

To integrate with Praxa, you need three things:
  • A gateway HTTPS URL — the origin of your Praxa Integration Gateway deployment (e.g., https://api.your-praxa-gateway.example). HTTP origins are rejected by the SDK.
  • A short-lived OAuth access token — issued by your Praxa deployment for a specific tenant, principal, and scope set. Tokens are obtained through your gateway’s token issuance flow; see the Authentication guide for details.
  • Node.js 20 or newer — required by @praxa/sdk and @praxa/cli.

Mission SDK quickstart

Configure a deployment-specific Gateway connection and create a governed mission.

Choose another use case

Compare Execution Fabric, SDK, CLI, MCP, memory, webhooks, observability, and research.

Mission concepts

A deeper look at goal specifications, resource budgets, idempotency, and the event stream lifecycle.

All tutorials

Build and verify an integration in your preferred backend framework.
Last modified on August 14, 2026