Key facts
| Agent runtime | Function calling loop on /v1/chat/completions (live) |
| Tool surface | Docs search, ticket lookup, CRM queries and internal APIs behind typed schemas |
| Model routing | plugsky-micro and plugsky-lite for routine turns; frontier models for complex planning |
| Models | 30+ models behind one OpenAI-compatible endpoint |
| Access control | Scoped keys, RBAC and SSO/SCIM so the copilot acts as the user |
| Audit | Per-turn tool and inference logs exportable to SIEM |
| Deployment | Region-locked planes, VPC, on-prem and air-gapped options |
| Roadmap endpoints | Assistants-style managed endpoints are coming soon; the tool loop is live now |
TL;DR
- Start with one persona — support, sales or engineering — and five tools, not twenty.
- Make the copilot act as the signed-in user, with their permissions, not a superuser.
- Draft-first for writes: propose the ticket update, email or record, then let the user confirm.
- Stream responses so the copilot feels responsive while tools execute.
- Measure time saved and edit rate per workflow, and delete tools nobody uses.
How it works, step by step
- Pick one team and one recurring journey where context is scattered across three or more systems.
- Define five to eight tools with typed schemas and descriptions written for a model, not for a developer.
- Pass the signed-in user's identity into each tool so permissions and tenant scoping are enforced server-side.
- Implement the loop: send the question with a tools array, execute tool_calls, append results, and iterate until the copilot answers or drafts.
- Add a confirmation step for any write — ticket updates, CRM notes, document drafts — and require an explicit user action.
- Stream tokens to the interface and show which sources and tools contributed to each answer.
- Instrument the workflow: turns per task, tool success rate, edit rate on drafts, and user-reported usefulness.
Try it yourself
A copilot is a tool loop with a narrow scope
Internal copilots fail when they try to be everything. The ones that stick have a defined persona, a small tool surface and a clear boundary. Within that scope they are dramatically better than search: the model plans across systems, blends results, and produces the artifact the employee actually needs — a reply, a summary, an update.
Plugsky's live function calling gives you the mechanics: a tools array on /v1/chat/completions, tool_calls in the response, results appended, loop until done. OpenAI compatibility means the same code patterns from your existing stack, and streaming keeps the experience responsive while tools run.
Connecting systems without copying data
The copilot should query systems of record, not shadow them. Each tool wraps an existing API and returns a trimmed result set; nothing is bulk-copied into a new store just to make the assistant work. That keeps data governance where it already lives and avoids a second, stale copy of the truth.
- Act as the user: propagate identity through tools so permissions match exactly what the person can already see.
- Trim results: return the five most relevant fields, not the full record, to reduce prompt size and leakage risk.
- Rate and timeout: cap each tool with a timeout and a retry policy so one slow system cannot stall the loop.
- Log details: capture tool name, arguments, latency and result counts for every turn.
Observability, approvals and rollout
Treat the copilot like a production service. Emit a trace per request that links the user, the tools called, the model used and the final output, and export those traces to your SIEM or warehouse. Keep the strongest models for complex planning, and let plugsky-micro or plugsky-lite handle classification and short rewrites — 30+ models behind one endpoint means this is a configuration choice.
Roll out to one team, watch which workflows actually get used, and measure turns per task and edit rate on drafts. Tool calls that are never invoked should be removed; tools that fail often should be fixed before the copilot is promoted. For sensitive content, pin the workspace to a region-locked plane or deploy to VPC, on-prem or air-gapped, and keep a human approval gate on everything that writes.
Honest comparison
| Concern | Plugsky copilot | Enterprise search | Managed copilot product |
|---|---|---|---|
| Interaction | Plans, retrieves and drafts through tools | Returns links | Vendor-defined flows |
| Systems | Any API you expose as a tool | Indexed content only | Vendor connectors |
| Model choice | 30+ models, route per step | None | Vendor catalogue |
| Write actions | Draft with explicit user confirmation | None | Varies; check scope |
| Audit | Per-turn traces exportable to SIEM | Query logs | Vendor-controlled logs |
Frequently asked questions
How is a copilot different from enterprise search?
Search returns documents; a copilot plans across tools, combines results and drafts the artifact the employee needs. Under the hood it still uses your indexes as one of its tools.
Should the copilot use a superuser account?
No. Propagate the signed-in user's identity so every tool call is scoped to what that person may already access. Model output must never override an access decision.
Can it take actions automatically?
Draft-first is the safe pattern: the copilot proposes the action and the user confirms. Keep writes behind an explicit approval step until the trace data shows trust.
Is streaming supported?
Yes. Streaming is live, which matters for perceived speed because tool execution adds latency between turns.
What tools should we build first?
Docs search, ticket lookup and the two internal APIs that employees copy-paste from most often. Five good tools outperform twenty thin ones.
How do we control cost and latency?
Cap turns, set tool timeouts, cache frequent lookups and route routine steps to plugsky-micro or plugsky-lite. Frontier models handle only complex planning.
Can it run on-prem?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, so internal data policies can be honoured end to end.