Use Cases + Implementation

How do you build support agents with AI agents?

A support agent is a chat model running in a loop with tools. It reads the ticket, calls functions to look up orders, subscriptions or policies, drafts a reply, and escalates when policy or confidence demands it. On Plugsky, function calling and agents are live behind one OpenAI-compatible endpoint, so you keep your orchestrator, session store and permission checks while the model layer stays swappable.

Key facts

EndpointOpenAI-compatible /v1/chat/completions with function calling (live)
AgentsAgents with memory, tools and orchestration are live
Models30+ models; run triage and replies on plugsky-micro or plugsky-lite, escalate complex cases
Tool safetyScoped API keys, RBAC and audit logs for agent actions
PricingFlat monthly self-serve plans with no per-token charges on self-serve
Free tierplugsky-micro and plugsky-lite on the free plan, no card required
DeploymentCloud, VPC, on-prem and air-gapped options for regulated support data
RoadmapThe moderation endpoint is coming soon; run your own input and output filters today

TL;DR

  • Build the agent as a loop: read, call tools, observe, decide, reply or escalate.
  • Keep every side-effecting tool behind server-side permission checks.
  • Cap loop iterations and tool calls so a confused agent cannot run away.
  • Escalate on policy triggers, low confidence and angry-customer signals.
  • Replay recorded tickets after every prompt or tool change.

How it works, step by step

  1. Classify ticket intents from historical data and list which intents the agent may resolve end to end.
  2. Define tools with strict JSON schemas — order lookup, subscription status, refund — and validate arguments before execution.
  3. Enforce permissions server-side per tool and per customer, never from free-text reasoning.
  4. Implement the loop with a maximum step count, timeouts and a fallback reply.
  5. Write escalation rules for policy exceptions, low confidence, high-value accounts and negative sentiment.
  6. Build an evaluation set of real tickets with expected outcomes and tool traces.
  7. Replay the set after every prompt, model or tool change, and monitor resolution rate and tool accuracy in production.
1Classify ticketintents fromhistorical data and2Define tools withstrict JSON schemas— order lookup,3Enforce permissionsserver-side pertool and per4Implement the loopwith a maximum stepcount, timeouts and5Write escalationrules for policyexceptions, low6Build an evaluationset of real ticketswith expected

Try it yourself

Open the agent workflow designer →

The support agent loop

The loop is deliberately boring: assemble context, call the model with the tool schemas, execute any requested tool after checking permissions, feed the result back, and repeat until the model answers or a limit is reached. Boring is good — the interesting failures live in context assembly and tool design, not in exotic orchestration.

Assemble context from the ticket, the customer record, recent interactions and any retrieved knowledge. Use a cheap tier for triage and routine replies; escalate when the agent hits ambiguity, a policy edge case or repeated tool failures. The agent workflow designer helps you sketch the states before you code them.

Tools, permissions and side effects

Read tools are safe to expose broadly; write tools are where support agents cause damage. Split them: lookups can run automatically, while refunds, plan changes and cancellations should require either a policy check or a human approval step. Validate every argument against your own rules — if a tool asks to refund more than the order total, your server should refuse it regardless of what the model argued.

  • Give each tool its own least-privilege credential and audit-log every call.
  • Make write tools idempotent with an operation key so retries cannot double-charge or double-refund.
  • Return compact results; dumping full API payloads into context wastes tokens and invites confusion.
  • Never let the model infer entitlements from text; read them from the customer record.

Escalation, evaluation and guardrails

Escalation is a feature, not a failure. Define triggers explicitly: policy categories the agent may not handle, confidence below a threshold, repeated tool errors, refunds above a limit, and detected frustration. A clean handoff to a human with a summary of what was tried beats a confident wrong answer every time.

Evaluate on outcomes and traces. Resolution rate alone hides bad behaviour, so also track tool accuracy, unnecessary escalations, loop lengths and safety events such as prompt-injection attempts that changed behaviour. Replay recorded tickets on every change; a prompt edit that fixes one intent can silently regress others. Build the first version on the free plan with plugsky-micro and plugsky-lite, then move to paid tiers or the 14-day full-access trial when volume and complexity grow.

Honest comparison

ConcernSupport agent on PlugskyVendor support bot platformFully custom stack
Model layer30+ models behind one OpenAI-compatible APIVendor catalogueYou host every model
ToolsFunction calling with your own permission checksPlatform-defined actionsBuild the loop yourself
EscalationYour rules, your thresholdsPlatform routing optionsCustom logic
Data controlCloud, VPC, on-prem, air-gappedVendor cloud onlyFull control, full ops cost
Time to launchWeeks with your existing stackFast but constrainedMonths

Frequently asked questions

Do I need a framework to build a support agent?

No. A support agent is a loop over chat completions with tools: call the model, execute requested tools with permission checks, feed results back, repeat. Frameworks help with tracing, but the model layer is just the OpenAI-compatible API.

Which models should handle tickets?

Route triage and routine replies to plugsky-micro or plugsky-lite, then escalate complex or high-value cases to stronger tiers. All 30+ models sit behind one endpoint, so changing the tier is a configuration change.

How do I stop the agent from issuing bad refunds?

Treat write tools as privileged: validate arguments server-side, enforce per-tool limits, make operations idempotent, and require human approval above a threshold.

How does the agent know when to escalate?

Define explicit triggers — policy categories, confidence thresholds, tool failures, high-value accounts and detected frustration — and hand the human a summary of everything tried.

Is my support data used for training?

Plugsky does not use your prompts for training and does not store request bodies; check the docs for the retention controls per workload and deployment.

Can it run inside our network?

Yes. Plugsky deploys in our cloud, your VPC, on-prem or air-gapped, so sensitive support data can stay inside your perimeter.

How do I evaluate the agent?

Use a set of real tickets with expected outcomes and check resolution rate, tool accuracy, unnecessary escalations and safety events. Replay the set after every change.

Can I start free?

Yes. The free plan includes plugsky-micro and plugsky-lite with no card, and a 14-day full-access trial unlocks stronger models for evaluation.