Guarded AI Customer Request Resolution

One cross-industry workflow — intelligent customer/employee request resolution with guarded actions — where the Xano orchestration stays identical and the AI reasoning step is powered by a native Xano AI agent (the default, on Xano's free built-in Gemini — no credentials), Amazon Bedrock AgentCore, Azure AI Foundry Agent Service, or Salesforce Agentforce. You pick the platform at one swap point; the privacy layer and the action guardrails are the same Xano code either way. A fresh fork gets real AI reasoning out of the box.

Teams want an AI agent to help resolve customer and employee requests — refunds, account changes, appointments, access requests — but two things block production: the model must not see raw PII, and the model must not take real actions on its own. Most "AI agent" demos fail both. They ship the customer's name, email, and account number straight to a third-party LLM, and they let the model call tools that move money or change accounts.

This template removes both risks by making Xano the deterministic spine. Before any agent call, Xano de-identifies the payload — every known sensitive field is swapped for a request-scoped, reversible token ( [NAME_1], [ACCT_1], [EMAIL_1] ), and the token↔value map never leaves Xano. The agent reasons over tokens only, and recommends next-best-actions and drafts a reply — it never executes anything. Xano then re-hydrates the draft, enforces configurable guardrails on every proposed action, executes the cleared ones through its own deterministic handlers (queuing anything over a threshold for human approval), and writes an immutable audit log that records, per request, that the agent payload was de-identified and that no raw PII crossed the boundary. Because the de-identification and the action execution are written once and are identical across all three platforms, the agent platform is a single swappable connector.

backend/
  agent/
    resolution_agent.xs
  api/
    auth/
      api_group.xs
      login_post.xs
      me_get.xs
      signup_post.xs
      users_get.xs
    resolution/
      api_group.xs
      config_get.xs
      dashboard_get.xs
      requesters_get.xs
      requests_action_approve_post.xs
      requests_action_reject_post.xs
      requests_audit_get.xs
      requests_detail_get.xs
      requests_get.xs
      requests_post.xs
    seed/
      api_group.xs
      health_get.xs
      seed_post.xs
  function/
    actions/
      execute_action.xs
    agent/
      connectors/
        agentforce.xs
        azure.xs
        bedrock.xs
        stub.xs
        xano.xs
      invoke_agent.xs
      normalize.xs
    audit/
      write.xs
    guardrails/
      evaluate_action.xs
    privacy/
      deidentify.xs
      detect_pii_text.xs
      rehydrate.xs
    resolution/
      approve_action.xs
      process_request.xs
  table/
    account.xs
    approval.xs
    audit_log.xs
    executed_action.xs
    policy.xs
    proposed_action.xs
    request_message.xs
    request.xs
    requester.xs
    token_map.xs
    user.xs
  workflow_test/
    approval_flow.xs
    privacy_guarantee.xs
    resolve_flow.xs
  workspace/
    templates.xs

Every request runs one ordered pipeline (function resolution/process_request, exposed as POST /requests):

1. Authenticate & load context. Xano loads the requester and their deterministic account context (tier, status, balance) — used by the guardrails, never sent to the agent.
2. De-identify (privacy/deidentify). Known structured PII fields are swapped for request-scoped tokens and written to the token_map (Xano-only). A best-effort pattern pass (privacy/detect_pii_text) then redacts residual PII the requester typed into the free text. Free-text detection is heuristic and review-worthy — not a guarantee.
3. Invoke the selected agent (agent/invoke_agent — the swap point). A single branch on agent_platform (per request) / $env.AGENT_PLATFORM (install-wide) dispatches to xano (default), stub, bedrock, azure, or agentforce. Every connector returns the same normalized contract, so they are drop-in interchangeable. Only the de-identified text is ever sent.
4. Re-hydrate (privacy/rehydrate). Tokens in the agent's draft and rationale are restored to real values from the token map — so the customer receives their real name while the model never saw it.
5. Enforce guardrails (guardrails/evaluate_action). Xano — not the model — reads the configurable policy row for each proposed action and decides: auto-execute, require human approval (over a money threshold or a flagged action type), or deny.
6. Execute deterministically (actions/execute_action). Cleared actions run through Xano's own handlers (refund, account_update, ticket, provision, schedule, reply). In a fork, each branch is where you wire your real system of record.
7. Audit (audit/write). Every step appends an immutable audit_log row, including the agent-boundary events that carry pii_deidentified: true and raw_pii_crossed: false.

The reasoning vs. deterministic boundary is strict: the agent interprets intent/sentiment/urgency, summarizes, recommends actions, and drafts a reply — over tokenized data. Xano owns de-identification, entitlement lookup, guardrails, execution, persistence, notification, and audit.

The point of this template: the same spine, one native option, three external platforms, and a deterministic test stub. Choose the platform at the single swap point — backend/function/agent/invoke_agent.xs — by setting $env.AGENT_PLATFORM (install-wide) or passing agent_platform on POST /requests (per request). Each connector is a self-contained function under backend/function/agent/connectors/ that returns the same shared contract, so they are drop-in interchangeable; the external ones below were verified against each vendor's official docs (2026-07).

xano — native Xano AI agent (the default). Runs a real LLM with no external credentials, on Xano's built-in free model (Gemini, type: "xano-free"). The agent is defined in backend/agent/resolution_agent.xs and invoked with ai.agent.run; it reasons over the tokenized request and returns the agent output contract. This is why a fresh fork gets genuine AI reasoning out of the box — deploy, seed, submit a request, done. Swap to a cloud platform below when you want to run your own agent there.

stub — deterministic, no LLM. Rules-based local reasoning over the tokenized text; a clearly-labeled simulation, not a language model. It exists for two jobs: it's what the workflow tests pin (so assertions are stable and unattended), and it's a fully-offline demo option. Select it with AGENT_PLATFORM=stub or agent_platform: "stub".

bedrock — Amazon Bedrock AgentCore Runtime.

• Invoke: POST {BEDROCK_AGENTCORE_ENDPOINT}/runtimes/{agentRuntimeArn}/invocations?qualifier=DEFAULT (the ARN is URL-encoded; the endpoint is the data-plane host, e.g. https://bedrock-agentcore.us-east-1.amazonaws.com).
• Auth: AWS SigV4 or a bearer token. XanoScript can't compute SigV4, so this connector uses the documented OAuth/bearer inbound-auth mode — supply $env.BEDROCK_BEARER_TOKEN. The X-Amzn-Bedrock-AgentCore-Runtime-Session-Id header must be ≥33 chars.
• Body: { prompt, context, scenario } (de-identified). Response: agent-defined JSON — your AgentCore agent should return the agent output contract.
• Setup: create an AgentCore Runtime agent, note its ARN, obtain a bearer token. Docs: https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_InvokeAgentRuntime.html · https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-oauth.html

azure — Azure AI Foundry Agent Service.

• Invoke: POST {AZURE_FOUNDRY_PROJECT_ENDPOINT}/threads/runs?api-version=2025-05-01 (create-thread-and-run), then GET {…}/threads/{thread_id}/messages?api-version=2025-05-01 to read the assistant reply.
• Auth: Microsoft Entra ID bearer token ($env.AZURE_FOUNDRY_BEARER_TOKEN; scope typically https://ai.azure.com/.default).
• Body: { assistant_id, thread: { messages: [{ role: "user", content }] } }. The assistant should reply with the agent output contract as JSON text.
• Honest limitation: a run is asynchronous. Production should poll GET {…}/threads/{thread_id}/runs/{run_id} until status == "completed" before reading messages; this connector implements create-thread-and-run + a single messages read for the documented happy path — add polling when you wire your project.
• Setup: create a Foundry project + agent, note the project endpoint and agent id, obtain an Entra token. Docs: https://learn.microsoft.com/en-us/rest/api/aifoundry/aiagents/

agentforce — Salesforce Agentforce (Agent API).

• OAuth token: POST {AGENTFORCE_MY_DOMAIN_URL}/services/oauth2/token (client-credentials) → access token.
• Start session: POST {AGENTFORCE_API_HOST}/einstein/ai-agent/v1/agents/{agentId}/sessions → sessionId.
• Send message: POST {AGENTFORCE_API_HOST}/einstein/ai-agent/v1/sessions/{sessionId}/messages with { message: { sequenceId, type: "Text", text } } → { messages: [{ message }] }. AGENTFORCE_API_HOST is https://api.salesforce.com.
• Auth: OAuth 2.0 (Einstein AI Agent scope). The agent should reply with the agent output contract as JSON text.
• Setup: build an Agentforce agent, note its id, create a connected app for client-credentials. Docs: https://developer.salesforce.com/docs/ai/agentforce/guide/agent-api.html

Agent output contract

When you wire a real platform, configure its agent (via its system prompt) to reply with this JSON so the connector can map it directly (a non-JSON reply degrades gracefully to a plain drafted response):

{
  "intent": "refund_request",
  "sentiment": "negative",
  "urgency": "high",
  "summary": "Requester [NAME_1] wants a refund on [ACCT_1].",
  "proposed_actions": [
    { "type": "refund", "rationale": "Refund requested for [ACCT_1]." },
    { "type": "reply", "rationale": "Acknowledge the refund." }
  ],
  "draft_response": "Hello [NAME_1], your refund on [ACCT_1] is being processed."
}

The agent references tokens ([NAME_1], [ACCT_1]) — never real values. Xano re-hydrates them, and Xano (not the agent) computes any money amount from the account context before executing.

The seeded demo is retail (order/refund), but the same spine generalizes — the scenario field maps a request to an industry:

• Retail — order issues, refunds, returns. (Refund over a threshold → supervisor approval.)
• Telco / SaaS — service changes, billing questions, plan cancellations. (Account changes → always human-approved.)
• Healthcare — appointment scheduling and records requests, without exposing patient identifiers to the model.
• Insurance — first-notice-of-loss / claim intake triage over de-identified narratives.
• Government — citizen service requests where PII handling and an audit trail are mandatory.

Reach for this when you want AI-assisted resolution but must guarantee that PII stays in your backend and that every real action is policy-checked and auditable — and when you want to evaluate Bedrock, Azure, and Agentforce against the same orchestration instead of rebuilding it three times.

Start with your coding agent. Paste the prompt below into a local MCP-capable coding agent — Claude Code, Cursor, Windsurf, and others. It installs the Xano CLI, connects Xano, and imports this template.

Start building in Xano: Access the prompt at https://go.xano.co/start-xano-with-template-skill and run it here with guarded-customer-request-resolution-bedrock-azurefoundry-agentforce as your template.

The agent will walk you through the setup below.

Zero-credential path (real AI out of the box — recommended first run). The default xano connector runs a real LLM on Xano's built-in free model, so the whole pipeline works end to end with no keys and no external setup.

1. Deploy the backend/ export to a Xano workspace (xano workspace push, or the agent CTA above).
2. Load the demo data: curl -X POST "$BASE/api:<seed-canonical>/seed" (idempotent). It creates operators, requesters with fake PII, accounts, and the guardrail policy.
3. Open frontend/index.html, enter your instance base URL, and fill the three __CANON_*__ api-group placeholders with the canonicals Xano assigned on push (see xano workspace pull → api/<group>/api_group.xs).
4. Sign in as the seeded supervisor priya.nair@console.demo / DemoPass1, click Load demo data, pick a requester, and submit a request. It gets de-identified, reasoned over by the native Xano agent, guardrailed, and (for over-threshold refunds) queued for your approval. The Agent platform dropdown lets you switch connectors per request.

Switch to a cloud platform. Set $env.AGENT_PLATFORM to bedrock, azure, or agentforce (or pass agent_platform on POST /requests), set that platform's environment variables (below), and configure its agent to return the agent output contract. The spine — de-identification, guardrails, action handlers, audit — does not change. Use stub for a fully-offline, deterministic run.

All endpoints except /seed and /health require Authorization: Bearer <token> from a successful login.

Auth (api/auth) — console operators:

• POST /signup — create an operator (agent or supervisor); returns a 24h token.
• POST /login — email + password; returns a 24h token.
• GET /me — the authenticated operator's profile.
• GET /users — list operators.

Resolution (api/resolution) — the spine:

• POST /requests — submit a request; runs the full de-identify → agent → guardrails → execute pipeline.
• GET /requests — the request queue.
• GET /requests/{request_id} — full detail (actions, approvals, audit trail, token map).
• GET /requesters — requesters + account summary for the console picker.
• POST /requests/{request_id}/actions/{action_id}/approve — approve a queued action (executes it deterministically).
• POST /requests/{request_id}/actions/{action_id}/reject — reject a queued action.
• GET /requests/{request_id}/audit — the immutable audit trail.
• GET /dashboard — request counts, pending approvals, actions executed, and the de-identification rate.
• GET /config — the selected agent platform, the interchangeable options, and the guardrail policy.

Seed (api/seed):

• POST /seed — idempotent demo data.
• GET /health — liveness + the selected agent platform.

• user — console operators (agent / supervisor) who review proposals and authorize actions.
• requester — the person submitting a request; holds the raw PII that is de-identified before any agent call.
• account — deterministic entitlement/account context (tier, status, balance) the guardrails read.
• request — the case: raw text, the de-identified text sent to the agent, and the agent's reasoning output.
• request_message — the conversation trail (requester message, agent draft, operator notes).
• token_map — the request-scoped PII↔token map; the reversible mapping that never leaves Xano.
• proposed_action — an action the agent recommended, with its guardrail decision and status.
• executed_action — the record of an action Xano actually executed, and how it was authorized.
• approval — a human-in-the-loop approval task for an over-threshold action.
• audit_log — the immutable, append-only trail, including proof of de-identification per agent call.
• policy — the configurable guardrail policy, one row per action type (enabled, touches-money, approval, auto-execute limit).

Tests ship in backend/ and run in a throwaway workspace:

• Unit tests (embedded test blocks): the stub and each real connector map their platform's documented example response into the shared contract (the real connectors are correct against the documented contract, mocked from the vendor docs — live calls require your credentials); privacy/detect_pii_text finds patterned PII.
• Workflow tests (backend/workflow_test/): resolve_flow (a low-value refund auto-executes with no raw PII crossing), approval_flow (an over-threshold refund is queued, then a supervisor approval executes it), and privacy_guarantee (raw email/SSN typed into a request never appear in what the agent saw; the token map and audit prove it).

Run: xano unit_test run_all -w <id> and xano workflow_test run_all -w <id>.

The workflow tests pin agent_platform: "stub" so their assertions stay deterministic (a real LLM's wording varies). The default xano agent is exercised separately against the live instance.

What's proven vs. what needs your setup: the entire spine — de-identification, guardrails, action handlers, audit — plus the deterministic stub are proven for real, unattended, on the shipped seed; the native xano agent (free Gemini) is verified running the full pipeline live. The bedrock / azure / agentforce connectors are wired and proven against each vendor's documented contract (unit-mocked from the docs); running those live requires your own platform credentials and a deployed agent, as described under Environment variables.

Only AGENT_PLATFORM is needed for the default self-contained run. The rest are required only for the connector you select.