Key facts
| Agent runtime | Function calling loop on /v1/chat/completions (live) |
| Streaming | Token streaming while tools execute server-side (live) |
| Model routing | plugsky-micro and plugsky-lite for planning; plugsky-pro and plugsky-frontier for synthesis |
| Models | 30+ models behind a single OpenAI-compatible endpoint |
| Access control | Scoped API keys, RBAC and SSO/SCIM for service identity |
| Audit | Key lifecycle and inference metadata exportable to SIEM tools |
| Deployment | Cloud, VPC, on-prem or air-gapped for residency-bound content |
| Roadmap endpoints | Assistants-style managed endpoints are coming soon; build the loop yourself today |
TL;DR
- Wrap existing indexes in a tool loop instead of replacing your search stack.
- Let the agent rewrite queries and retry — that is where answer quality comes from.
- Enforce permissions inside your tools so the model only ever sees allowed documents.
- Route planning and extraction to small models, synthesis to frontier models.
- Log every tool call so relevance failures can be debugged and audited.
How it works, step by step
- Expose your search index, document fetch and metadata services as narrow tools with typed JSON schemas and clear descriptions.
- Enforce the caller's permissions inside each tool — never rely on prompting to keep results scoped.
- Implement the loop: send messages with a tools array, execute returned tool_calls, append results, and call again until the model answers.
- Add a query-rewrite step and cap the number of turns and tool calls so latency and cost stay bounded.
- Route classification and extraction steps to plugsky-micro or plugsky-lite, and final synthesis to a stronger model.
- Return answers with citations to document IDs and highlight snippets, and let users open the source in one click.
- Log every tool invocation and build an evaluation set of real employee questions to measure relevance and refusal quality.
Try it yourself
Open the agent workflow designer →
The agent loop over your existing search
Most enterprises do not need a new index; they need a better interface to the indexes they have. An agent adds planning and synthesis on top of mature search infrastructure. The model receives the employee's question plus tool definitions, decides which tool to call, reads the JSON result, and either calls another tool or writes the final answer.
Because Plugsky is OpenAI-compatible, this is the standard tools pattern: pass a tools array, read tool_calls from the response, execute them in your service, append the results as tool messages, and call again. Your service holds the credentials and enforces the boundary; the model never connects to a data source directly.
Permissions, tenancy and audit
Search agents concentrate access in one place, which makes them a governance target as much as a productivity win. Enforce the requesting user's identity and groups inside every tool call, and apply tenant filters before retrieval rather than after generation. The safest pattern is to pass signed, server-side context into tools and never accept a user ID supplied by the model.
- Identity: scoped API keys per service, with RBAC and SSO/SCIM for workforce access.
- Evidence: log tool name, arguments, result counts and latency alongside model and token metadata for each turn.
- Residency: pin the workspace to a region-locked plane, or deploy to VPC, on-prem or air-gapped when content cannot leave the building.
Routing, latency and evaluation
An agent that calls a frontier model on every turn is slow and wasteful. Split the work: small models handle intent classification, query rewriting and result extraction, while the strongest model writes the final answer. With 30+ models behind one endpoint, that routing is a model-string change, not a new integration.
Cap the loop at a small number of turns and fail gracefully to a search results page when the agent cannot answer. Then measure like a search team: relevance of retrieved documents, answer groundedness, citation accuracy and deflection rate. Keep a golden set of paraphrased employee questions, because agents are good at sounding right even when retrieval failed.
Honest comparison
| Concern | Plugsky agents | Classic search box | Managed assistant platform |
|---|---|---|---|
| Interface | Tool loop over your indexes | Keyword results list | Vendor-hosted assistant |
| Model choice | 30+ models, route per step | None | Vendor catalogue only |
| Permissions | Enforced in your tools before retrieval | Index-side ACLs | Vendor-managed connectors |
| Audit | Per-turn tool and inference logs exportable to SIEM | Query logs | Vendor-controlled logs |
| Status today | Live on chat completions with function calling | Mature but static | Varies by vendor |
Frequently asked questions
Do I need to replace my search engine?
No. Keep the index and expose it as a tool. The agent adds query planning and synthesis; relevance and permissions still come from your existing search platform.
How does the agent know what a user can see?
Your tool implementation applies the user's permissions and tenant filters server-side before querying the index. Never pass model-supplied identity into an access decision.
Is function calling live on Plugsky?
Yes. OpenAI-style function calling and streaming are live on chat completions, so you can show progress while tools run.
How do I control latency?
Cap agent turns, use small models for planning and extraction, and cache frequent queries. Fail over to a plain results page when the turn budget is exhausted.
What should I log?
Each tool call with arguments and result counts, model and token metadata per turn, and the final citation set. These logs make relevance and audit questions answerable.
Can it run inside our network?
Yes. Plugsky supports VPC, on-prem and air-gapped deployments, and region-locked planes for cloud deployments.
Where should we start?
Pick one high-volume journey such as policy lookup or service-desk search, wire two or three narrow tools, and evaluate before widening access.