How do you build chatbots with AI agents?

Key facts

Endpoint	POST /v1/chat/completions with tools for lookups and account actions
State	Conversation and ticket state live in your database; the transcript is not the system of record
Models	30+ models; plugsky-lite for routine turns and plugsky-pro for complex triage
Streaming	Server-sent events on chat completions for responsive replies
Pricing model	Flat monthly self-serve plans with unlimited fair-use usage
Free tier	Free plan with 2 free AI models, no card required
Governance	Scoped keys, audit logs and usage analytics per bot
Roadmap	Assistants and responses endpoints are coming soon; manage threads yourself today

TL;DR

• Design the bot as a tool-using agent, not a prompt with a personality.
• Verify identity before any account tool runs — permissions belong in code.
• Persist conversation state in your database so the transcript is disposable.
• Bound tool loops and define an explicit human handoff trigger.
• Evaluate containment, resolution and escalation quality on real conversations.

How it works, step by step

1. Map the top intents from real support transcripts and decide which are self-serviceable.
2. Define tools for lookups (order, subscription, policy) and actions (ticket, refund request) with strict schemas.
3. Add an identity step: authenticate or verify the customer before account-scoped tools become available.
4. Implement the agent loop with streaming replies and persistence of state after every turn.
5. Set a handoff policy — repeated failure, explicit request or sensitive intent — that transfers context to a human.
6. Evaluate on recorded conversations and re-run the suite after every prompt or tool change.

Original data

Try it yourself

Open the AI agent builder →

Architecture of a tool-using chatbot

Five components, each independently testable:

• Channel adapter: web widget, app or messaging channel that normalizes inbound events.
• Session store: durable conversation and ticket records keyed by customer and channel.
• Agent loop: chat completions with tools, using a cheap alias for routine turns.
• Tool layer: read tools for lookups, write tools for actions, each with permissions and audit logging.
• Handoff: a queue and a compact summary that a human agent can pick up without rereading the transcript.

Keeping the transcript disposable is the design goal: state lives in the store, so compaction, retries and channel switches are all safe.

Implementation choices that hold up

Details that separate a demo from a production bot:

• Gate account tools behind identity verification. The model must never receive a customer id it was not entitled to see.
• Keep tools narrow: get_order_status and request_refund_review, not a generic database query.
• Stream with server-sent events for perceived speed, but cancel the upstream request when the user disconnects.
• Trim history by tokens, keeping the system prompt, verified identity facts and the last relevant turns.
• Resist prompt injection: treat user text as data, never as instructions that can change tool permissions.
• Log model, tools, latency and handoff reason per turn for evaluation and dispute handling.

Evaluating chatbot quality

Choose metrics that reflect customer outcomes:

• Containment: share of conversations resolved without a human, measured only on intents you intend to contain.
• Resolution accuracy: sampled human review of whether the stated resolution actually happened.
• Escalation precision: how often handoff was correct versus unnecessary.
• Hallucinated commitments: promises the business cannot keep — this must be near zero.
• Time to first token and turn latency: responsiveness drives abandonment more than answer length.

Build a regression set from real conversations, including angry, ambiguous and mixed-language inputs, and run it before every release.

Limitations and risks

Chatbots that take actions carry real operational risk:

• Model output is probabilistic; policy answers must be grounded in retrieved or tool-provided text, never recalled from training.
• Moderation endpoints are coming soon, so profanity and safety filtering need your own rules today.
• Identity flows vary by market; support one strong path rather than several weak ones.
• Assistants and responses endpoints are coming soon, so thread management stays in your code — which also keeps it portable.
• Handoff is a product feature, not an exception path. Design the human side before scaling the bot.

Honest comparison

Capability	Agentic chatbot on Plugsky	Prompt-only chatbot	Rules-based bot
Account actions	Typed tools with permissions and audit	None, or unsafe free text	Fixed menu flows
Knowledge	Retrieval or tools per turn	Static prompt content	Hard-coded replies
State	Durable store outside the model	Transcript only	Session variables
Model choice	30+ aliases, routed per turn	One model	None
Handoff	Explicit policy with context summary	Manual	Keyword trigger

Frequently asked questions

What makes a chatbot an agent?

It can call tools during the conversation — looking up accounts, checking policies or creating tickets — and it decides the sequence based on what the customer asks.

How do I stop the bot from making promises it cannot keep?

Ground answers in tool results or retrieved policy text, require approval for policy exceptions, and measure hallucinated commitments as a release-blocking metric.

Where should conversation history live?

In your database. Keep the model transcript as a disposable view so compaction, retries and channel changes never lose the state of a case.

Which Plugsky model should run the bot?

plugsky-lite handles routine turns, while plugsky-pro is a better fit for complex triage and multi-step troubleshooting. Route by intent rather than using one alias for everything.

How do I handle identity verification?

Verify before exposing account-scoped tools, keep customer identifiers out of the model's context unless required, and log every account access for audit.

Is there a moderation API?

Not yet — moderation is coming soon. Implement your own input and output filters until then.

Can I build the first version for free?

Yes. plugsky-micro and plugsky-lite are free with no card, and a 14-day full-access trial lets you evaluate stronger models for triage.