Book a Demo
Appice for AI Agents · Same rail as humans

One decisioning API.
Governed like the humans.

Your customer-facing bots, internal copilots, MCP clients and RPA workflows call the same Appice API your marketing team uses — and inherit the same policy, consent state, audit trail and sub-200ms latency guarantee. No agent backdoor.

Open Developer Portal ↗ Book a Demo
<200ms
P95 decision latency — agents get the same SLA as human-triggered calls
1
Policy engine, one audit log — every caller subject to it, no exceptions
MCP
Native Model Context Protocol server — drop-in for Claude, Cursor, LangChain
Agent call · POST /v1/decision
POST https://api.appice.ai/v1/decision
Authorization: Bearer sk_agent_...
Content-Type: application/json

{
  "customer_id": "c_84210",
  "context": "support_chat",
  "agent_id": "claude-support-v3"
}
↓ 74 ms
{
  "action": "offer_top_up_loan",
  "reason_codes": ["salary_credited",
                    "eligible_KFS_v4"],
  "consent_ok": true,
  "audit_id": "aud_9f2a..."
}
Two callers · One rail

Whoever asks, the answer comes from the same engine.

A marketer building a segment in the console and an LLM agent handling a live support chat hit the exact same decisioning core. Same features. Same policies. Same audit log. The console is a UI over the API — not a privileged path.

Humans call it via

The Appice console

Marketers, analysts, ops teams and business owners build segments, tune models, launch journeys and read outcomes through the same UI.

Journey builder & segment studio
Model tuning & live analytics
Approval workflows & audit history
RBAC-scoped human identity
New
Agents call it via

REST · SDK · MCP

Customer chatbots, internal copilots, RPA workflows and MCP-native LLMs (Claude, Cursor, LangChain, custom) call decisioning as a service — scoped by service identity.

REST + OpenAPI 3.1 spec
Python, Node, Go, Java SDKs
Model Context Protocol server
Scoped service-identity tokens
The shared rail
Both callers hit — identically —
CDP + feature store Decision engine Policy + consent Audit log Activation
Agent Request Lifecycle

Four steps from agent call to audited action.

Every agent call — MCP tool invocation, REST POST, SDK method — moves through the same four stages. The same four stages a human triggers from the console. Same latency budget, same policy engine, same audit trail.

1

Authenticate

Agent presents a scoped service-identity token. RBAC resolves what it may read and act on.

2

Contextualise

Feature store pulls the customer 360 — behaviour, entitlements, live signals, consent state.

3

Decide

ML + rules + policy select the next best action. Response returned with reason codes.

4

Act & audit

Appice executes (or hands the action back). Every step lands in the immutable audit log.

Where Agents Plug In

Four common patterns. Same API surface.

Every agent workload we see collapses into one of four calls. Ingest a signal. Ask for a decision. Fetch context. Execute an action. Different verbs, same Appice API, same audit.

POST /v1/signals

Ingest a signal

Your customer-facing bot spots intent (“user asked about home loans”) and pushes it. Appice ingests, hashes PII, and updates the customer feature store immediately.

Use it when: your agent learns something Appice should know.
Most common
POST /v1/decision

Ask for a decision

Your MCP-native LLM needs to answer “what should we offer this customer next?” Appice returns the next best action with reason codes and consent status — in under 200ms.

Use it when: your agent needs to pick the right move.
GET /v1/customers/{id}

Fetch context

Your support copilot pulls a scoped 360 — last N events, active offers, product holdings, consent flags. RBAC controls exactly which fields the agent identity can see.

Use it when: your agent needs to ground its response in real data.
POST /v1/actions

Execute an action

Your RPA workflow tells Appice to send the message — push, SMS, WhatsApp, email, RCS, voice. Appice enforces channel-consent, quiet hours, frequency caps automatically.

Use it when: your agent needs to actually reach the customer.
Works with
Claude & MCP LangChain / LangGraph OpenAI Agents SDK Vertex Agent Builder Amazon Bedrock Agents UiPath / Automation Anywhere Custom REST / gRPC
Agent-Triggered · In Production

What agent-triggered decisioning looks like in production.

Every outcome below started with a signal — caught by a rules engine, an in-house bot, a support copilot or a background workflow — and ended with an Appice-decided action inside compliance. Different callers, same rail.

Banking · South Asia
3.2×
cross-sell acceptance at the salary-credit moment

A rules engine posts /v1/signals when salary credit hits. The bank's in-app agent calls /v1/decision — Appice returns a pre-approved personal loan offer in 64ms. Consent and frequency caps apply automatically.

View full case →
Banking · Tier-1 GCC
40%
reduction in voluntary attrition

A background scoring workflow queries /v1/decision daily for at-risk segments — 45+ behavioural signals feed the churn model. Retention action and channel are picked per value tier, under SAMA-compliant audit trails.

View full case →
Lending · SE Asia
28%
improvement in loan-application completion

An LLM-based document-help copilot detects abandonment mid-application, drafts a personalised recovery message and asks Appice for a channel-and-timing decision. Appice fires the nudge on the channel most likely to win — same session, same context.

View full case →
Conversational AI · agent-orchestrated

Two-way customer conversations — on WhatsApp, app, web, SMS — that stay inside compliance.

Customer chatbots and copilots — yours or Appice-provided — run conversational flows for KYC nudges, loan application support, statement queries, claims intimation and post-discharge care — with consent state, language localisation (English, Arabic, Hindi, Portuguese, Spanish, Chinese, French) and full audit trails preserved end to end. PII never leaves the customer's perimeter, courtesy of Appice’s hashed-ID Inform layer.

WhatsApp Business In-app messaging Web chat SMS / RCS RM alerts
Why Agent-Native

Bolted-on agent APIs vs. one governed rail.

Bolt-on agent APIs
Separate agent gateway, separate policy
Consent state re-implemented downstream
Agents get a stripped-down feature set
Audit log lives in the agent framework, not the platform
Compliance retrofitted per agent
Appice for Agents
One decisioning API for humans and agents
One consent + policy engine, applied to every caller
Full customer 360 — scoped by RBAC per identity
Every agent action lands in the same immutable audit log
Compliance is a platform property, not per-agent code
Related
Want the humans-side story? See the Allyvate agentic engine.
Same decisioning core, viewed from the operator side — Appice’s built-in agents.
Get Started

Start building today.

Grab an API key on the developer portal, or book a 30-minute session with our solution engineers to design the integration for your agent stack.

Open Developer Portal ↗ Book a Demo Explore the Platform