Use Praxa with OpenAI Agents

• remote MCP exposes governed Praxa operations to the agent;
• the read-only memory adapter recalls items from a session your backend owns.

​

Prerequisites

• the exact published Praxa package versions used by the tutorial;
• a trusted agent host with explicit tool, approval, timeout, and output policies;
• deployment-specific OAuth or backend-owned provider clients where the selected lane requires them;
• synthetic tenant, subject, prompt, and tool fixtures for positive and adversarial tests;
• an acceptance assertion that proves remote MCP and read-only session memory remain separate and both pass negative-boundary tests.

​

1. Connect remote MCP

npm install @openai/agents @praxa/sdk@0.3.0

import { Agent, hostedMcpTool, run } from "@openai/agents";

const agent = new Agent({
  name: "Praxa capability reader",
  instructions: "Use the allowed Praxa tools only for the user's request.",
  tools: [hostedMcpTool({
    serverLabel: "praxa",
    serverUrl: process.env.PRAXA_BASE_URL + "/mcp",
    authorization: process.env.PRAXA_ACCESS_TOKEN,
    allowedTools: ["aura_search_capabilities", "aura_get_mission"],
    requireApproval: "never",
  })],
});

const result = await run(agent, "Which capabilities match document review?");
console.log(result.finalOutput);

​

2. Federate an existing session

import {
  MemoryFederation,
  createOpenAIAgentsSessionSource,
} from "@praxa/sdk/memory";

const source = createOpenAIAgentsSessionSource({
  sessionForNamespace: ({ tenantId, subjectId }) =>
    sessions.get(tenantId + ":" + subjectId),
});

const memory = new MemoryFederation({ sources: [source] });
const recalled = await memory.recall({
  query: "What context matters for this turn?",
  namespace: { tenantId: "acme", subjectId: "user-42" },
  limit: 8,
});

​

3. Test both boundaries

​

Troubleshooting

​

Best practices

• Enable the smallest tool or source set needed for the workflow.
• Require approval for mutations and independently for destructive actions.
• Derive tenant, subject, purpose, and credential from trusted host context.
• Bound tool inputs, output bytes, concurrent calls, retries, and total turn time.
• Verify a run, event, trace, receipt, or source status independently of model prose.

​

Optimize for production

• Reduce tool definitions and provider sources to the relevant set before each turn.
• Use deterministic filtering and pagination before placing results in model context.
• Cache only versioned, non-sensitive contracts and read-only metadata.
• Measure tool-selection accuracy, approval rate, p50/p95 call latency, context bytes, retries, and verified completion.

​

Cleanup and next steps

1. Revoke disposable delegated grants and remove test host configuration.
2. Delete provider fixtures through the provider’s own lifecycle when applicable.
3. Disable mutation tools until their negative and approval tests pass again after upgrades.
4. Retain only redacted tool, run, trace, and receipt identifiers needed for evaluation.

​

Frequently asked questions

​

What proves this tutorial works?

​

Can a browser, mobile app, or model prompt hold the credential?

​

How should an ambiguous mutation be retried?

​

What should we monitor after release?