Skip to main content
Most teams start with the agent endpoint because it gives immediate coverage with the smallest code change.

​
Choose your integration path

The two combine: the endpoint checks model traffic, and the Xenovia Python SDK checks the actions around it.

​
Prerequisites

For the agent endpoint
  • A Xenovia account and workspace with at least one agent created.
  • Your agent ID (found under Agents in the platform).
  • A Xenovia API key (xe_...) for that agent.
  • An LLM client or framework (OpenAI SDK, LangChain, LlamaIndex, Vercel AI SDK, etc.).
For SDK hooks
  • Python ≥ 3.9 and xenovia-sdk 0.2.1 or later.

​
What to decide before rollout

  • Which workflow should be governed first
  • Which environment to start in dev or staging, not production
  • What should be blocked, redacted, or escalated first
  • Which metadata you want attached to traces: environment, user tier, feature, or workflow ID

​
Endpoint URL format

Every agent exposes an OpenAI-compatible base URL:
Point your client here and pass the xe_... key as the API key. Xenovia resolves the upstream provider credentials server-side.
1

Create one agent

Give it a clear owner, environment label, and scope so the traces mean something on day one.
2

Route one workflow

Start with a narrow path such as one chat endpoint, one agent runner, or one background job.
3

Verify trace headers

Confirm X-Xenovia-Session-Id and X-Xenovia-Trace-Id show up in responses and traces land in the platform.
4

Attach one simple policy

Begin with a concrete rule such as blocking a destructive tool or redacting email addresses.
5

Expand based on evidence

Use real traces to add stricter rules and guardrails.

​
Session tracking

Xenovia resolves a session automatically, but for multi-turn agents you should usually pass an explicit X-Xenovia-Session-Id header so related calls stay grouped in Sessions. Continue to Quickstart to set up an agent and send your first governed request.