Key facts
| Tools shape | OpenAI-compatible tools array on /v1/chat/completions with tool_calls responses (live) |
| Parallel calls | Several tool calls can return in one response and execute concurrently |
| Schema control | tool_choice and strict:true keep arguments exact across large tool registries |
| Throughput | Fair-use per-minute limits scale by tier, up to 10K+ RPM on Enterprise |
| Residency | Pin workspaces or requests to GCC, EU, US or APAC regions; on-prem and air-gapped available |
| Audit | Every request logs model, tokens, latency, status, key ID, project and region; exportable to SIEM |
| Approvals | Actions that change a subscriber's service stay behind your gate |
| Roadmap | Assistants and responses endpoints are coming soon; the chat completions tool loop is live |
TL;DR
- Treat tools as versioned contracts shared across care, provisioning and assurance.
- Use parallel calls to keep care conversations inside seconds, not tens of seconds.
- Pin subscriber-data workloads to the region their regulation requires.
- Keep provisioning and billing changes behind approval gates.
- Log every routing decision and tool call for regulatory and incident review.
How it works, step by step
- Inventory the tools each domain needs and publish them in a shared registry with owners and versions.
- Define strict JSON Schemas and lock the critical ones with tool_choice so arguments cannot drift.
- Build the loop server-side, dispatching parallel tool calls and streaming progress to care agents.
- Classify each tool as read-only or change-making, and gate the change-making ones behind approvals.
- Pin workspaces to the required region and export audit events to your SIEM.
- Load-test against your peak care volume, then widen access domain by domain.
Try it yourself
Open the tool registry builder →
Tool contracts that span network domains
A telco agent rarely belongs to one system. Care needs billing and plan data, assurance needs network status, provisioning needs order state. Each of those becomes a tool, and each tool is a contract between teams. Publish schemas in a registry with a named owner and a version, then let assistants consume them.
Strictness is what makes the contract real. With strict: true, the model's arguments match your fields exactly, and with tool_choice you can pin a critical step to one named tool. That prevents the slow drift where an argument name changes in one domain and quietly breaks care workflows in another.
Scale, latency and region
Care conversations are latency-sensitive because a human is waiting. Parallel tool calls cut round trips: one model response can request balance, outage status and order state at once, and your service dispatches them concurrently. Streaming keeps the interface responsive while those calls run.
At volume, plan tiers carry fair-use per-minute request limits up to 10K+ RPM on Enterprise, with the same flat rate on every model. For subscriber data, pin the workspace to the region your regulator requires — GCC, EU, US or APAC — or run in your VPC, on-prem or air-gapped where data cannot leave the building.
Oversight for subscriber-affecting actions
Reading is cheap; changing is expensive. Keep tools that alter a subscriber's service — SIM provisioning, plan changes, credits, disconnections — behind an approval workflow with a named owner. The assistant prepares the action and shows the evidence; a human releases it.
- Audit: every request logs model, tokens, latency, status, key ID, project and region, exportable to Splunk, Sentinel, QRadar or Chronicle.
- Evaluation: replay historical care cases and measure tool selection and escalation before widening access.
- Roadmap: assistants and responses endpoints are coming soon; today's loop on chat completions already covers read-heavy care and assurance workflows.
Honest comparison
| Concern | Plugsky | Vendor telco AI suite | Building in-house |
|---|---|---|---|
| Tool protocol | OpenAI-compatible chat completions | Suite-specific APIs | Custom runtime |
| Throughput | Fair-use tiers up to 10K+ RPM Enterprise | Contract-dependent | Your GPU capacity |
| Residency | Region pinning plus on-prem and air-gapped | Few fixed regions | Wherever you deploy |
| Audit | Per-request metadata exportable to SIEM | Vendor-managed logs | Your own pipeline |
| Time to pilot | Weeks with existing SDKs | Quarters of integration | Months of platform work |
Frequently asked questions
Can this handle peak care volume?
Enterprise tiers carry fair-use limits up to 10K+ RPM with the same flat rate on every model. Load-test against your peak, and remember parallel tool calls reduce the number of model round trips per conversation.
How do we keep subscriber data in-country?
Pin each workspace or request to a region — GCC, EU, US or APAC — and use VPC, on-prem or air-gapped deployment where data must not leave your environment.
Will the assistant change subscriber plans automatically?
Only if you allow it. Model change-making tools as approval-only so a human releases provisioning, billing and disconnection actions.
Which models should handle care traffic?
Route classification and lookups to plugsky-micro or plugsky-lite, and complex diagnostics or retention offers to stronger tiers. All 30+ models share one endpoint.
Does the assistant speak Arabic and other languages?
Plugsky serves multilingual workloads across its model catalogue. Verify the specific languages and quality for your market with your own evaluation set.
How do we govern tools across teams?
Publish versioned schemas in a shared registry with named owners, and lock critical steps with tool_choice and strict schemas.
What do audits look like?
Every request is logged with model, tokens, latency, status, key ID, project, region and request ID, and key lifecycle events are exportable to your SIEM.