Skip to main content
Integrate Parmana into your AI agents so a named policy decides before anything consequential executes, not the agent’s own judgment call.

The problem

Your AI customer-service agent can refund payments. Without Parmana, the naive integration looks like this:
Whatever the agent decides, happens. No policy, no audit trail, no proof, and the agent needs the vendor’s real credentials to act at all.

The solution

The agent never holds the connector’s credentials, those live server-side, resolved per-connector; see Credential isolation. Every call is evaluated against a named, versioned policy, and every outcome (approved or denied) is recorded. All four patterns below build on the same two calls: create_business_transaction() to build the proposal, and client.execution.execute() to run it.

Pattern 1: LangChain Tool

Expose Parmana as a tool the agent calls instead of calling the vendor API directly.
The LLM decides to call the tool; it never decides whether the refund is allowed, that’s the named customer-refund policy’s job, and the tool never touches the payment provider’s own credentials.

Pattern 2: CrewAI Task

Same pattern, wired as a CrewAI tool function instead of a LangChain one:

Pattern 3: FastAPI endpoint

Put Parmana behind an internal endpoint agents (or other services) call over HTTP:
An agent (or any other internal caller) then calls this endpoint instead of holding a Parmana client, or a Parmana client, of its own, which is a reasonable pattern when you want a single service owning the Parmana connection and its API key.

Pattern 4: Async

ParmanaClient is a synchronous client built on requests.Session(); use asyncio.to_thread (or a thread pool) to call it from async code without blocking the event loop:
If your workflow needs to react to what the connector does after Parmana’s own response, settlement confirmation arriving later, for instance, that’s a property of the specific connector, not the SDK; see Session credentials and the connector’s own docs (e.g. HubSpot) for what each one actually confirms and when.

Real example: a CustomerServiceAgent class

Key guarantees

  • The agent never holds the connector’s own credentials, see Credential isolation.
  • A named, versioned policy decides, not the agent’s own reasoning, see Policies and the decision.
  • A denied proposal raises before any downstream call happens, there’s no code path where the agent can override or retry around a rejection silently.
  • Every approved execution produces a signed, independently verifiable proof, see Execution Trust Records.

Next

Python SDK Production

Error handling, audit logging, monitoring, and a deployment checklist.

Write your first policy

Define the policy these examples reference instead of reusing customer-refund.

End-to-end: agent → Parmana → Paytm

The same shape, against real infrastructure, with every real error message documented.

Python SDK reference

The complete, verified API surface backing every example on this page.