Spend governance for Relevance AI agents

1. Why Relevance AI tools need a spend gate

Relevance AI lets you build AI agents and workflows without writing code. Each agent is composed of tool steps — HTTP calls, LLM calls, data lookups — that fire sequentially or in parallel. When those tool steps reach out to paid external APIs, there is no built-in checkpoint that evaluates whether the spend is within budget, whether a human has approved it, or whether the vendor is on an allowlist. The agent simply fires the action whenever the LLM decides it is time.

NORNR integrates into Relevance AI as a standard HTTP tool step. Because Relevance AI supports custom HTTP requests with variable injection and response parsing, you can call the NORNR API directly from within the tool builder. The governance check happens inside the tool sequence, before the paid step, using the same no-code interface you already use to build the rest of your agent. No external server or SDK required.

2. Tool sequence overview

The governance gate sits between your trigger step and your paid tool step. The sequence looks like this:

1. Trigger — agent input, webhook, schedule, or user message
2. HTTP step: NORNR pay — POST to /api/wallets/{walletId}/pay with amount, counterparty, purpose
3. Transform step — extract status and decisionId from the response
4. Condition step — branch on status == "approved"
5. Approved branch — run your paid tool step
6. Queued branch — send a reviewer notification with the decisionId
7. Rejected branch — log the rejection reasons and stop

3. Configuring the NORNR HTTP tool step

In the Relevance AI tool builder, add a new HTTP step before your paid action. Set the method to POST and the URL to your wallet's pay endpoint. Add the Authorization header with your NORNR API key. In the body, use Relevance AI's variable syntax to inject the amount, counterparty, and purpose from earlier steps or from the agent's input schema.

Method: POST
URL:    https://nornr.com/api/wallets/{{wallet_id}}/pay

Headers:
  Content-Type:  application/json
  Authorization: Bearer {{nornr_api_key}}

Body (JSON):
{
  "amount":  {{estimated_cost}},
  "to":      "{{counterparty}}",
  "purpose": "{{tool_purpose}}"
}

Store nornr_api_key and wallet_id as Relevance AI secrets or agent variables so they are not hardcoded into the tool configuration. The estimated_cost and counterparty fields should be wired from the agent's input schema or from a prior extraction step that identifies what the next paid action will cost.

4. Parsing the decision status

After the HTTP step runs, add a Transform step to extract the fields you need from the NORNR response. Map the status field to a tool variable and do the same for decisionId. These variables will drive the Condition step in the next stage.

// NORNR response shape
{
  "status":     "approved",   // or "queued" or "rejected"
  "decisionId": "dcn_abc123",
  "reasons":    []            // populated on rejected
}

// In Relevance AI Transform step:
nornr_status     = {{http_step.output.status}}
nornr_decisionId = {{http_step.output.decisionId}}
nornr_reasons    = {{http_step.output.reasons}}

5. Branching with a Condition step

Add a Condition step that checks nornr_status == "approved". If true, the flow continues to your paid tool step. If false, branch to the appropriate handling path. Relevance AI supports multi-branch conditions, so you can route queued and rejected separately in the same condition block.

// Condition step
IF   nornr_status == "approved"  → run paid tool step
ELIF nornr_status == "queued"    → send reviewer notification
ELSE                             → log rejection, stop agent

6. The queued notification step

On the queued branch, add a notification tool step — Slack, email, or Relevance AI's built-in human handoff. Include the decisionId and a link to the NORNR control room so the reviewer can approve or reject directly from the notification. Once resolved, NORNR can send a webhook to a Relevance AI webhook trigger that resumes the agent with the original intent context.

// Slack notification template for queued path
Approval needed for agent spend

Decision ID: {{nornr_decisionId}}
Amount:      {{estimated_cost}}
Vendor:      {{counterparty}}
Purpose:     {{tool_purpose}}

Review at: https://nornr.com/app/decisions/{{nornr_decisionId}}

7. Common mistakes

• Placing the HTTP step after the paid tool step. The governance call must run before the action. Move the HTTP step earlier in the sequence if you add NORNR to an existing tool after the fact.
• Not handling the queued branch explicitly. If the Condition step only checks for approved, a queued decision will silently route to the else branch and be treated as a rejection. Add an explicit queued condition with a proper notification path.
• Hardcoding the API key in the HTTP step body. Use Relevance AI secrets or environment variables so the key is not visible in the tool configuration or in exported tool definitions.
• Not passing decisionId to the notification step. Without the decision ID, the reviewer cannot link their approval action in the NORNR control room to the paused agent run. Always include it in the notification payload.

8. Featured follow-up paths

• Human approval before a vendor API call
• Audit trail before agent spend moves
• Approved vs queued vs rejected — the core decision model
• Spend controls for Make.com scenarios
• Hosted quickstart