Key facts
| Tools shape | OpenAI-compatible tools array on /v1/chat/completions with tool_calls responses (live) |
| Matter isolation | Project-scoped keys keep each matter's retrieval, logs and limits separate |
| Determinism | tool_choice plus strict:true schemas for deposition summaries and form-heavy steps |
| Redaction | No-PII mode auto-redacts client identifiers before inference |
| Audit | Key actions logged with actor, timestamp, IP and request body hash, exportable to SIEM |
| Residency | Region pinning; VPC, on-prem and air-gapped options for privileged work |
| Retention | Uploaded RAG documents stay until you delete them; request bodies are not stored |
| Roadmap | Assistants and responses endpoints are coming soon; the chat completions tool loop is live |
TL;DR
- Expose matter search, clause fetch and deadline tools instead of trusting generated facts.
- Keep one project and key set per matter so retrieval and logs never bleed together.
- Force schema-strict tool calls wherever formatting or dates must be exact.
- Route routine extraction to free models and analysis to stronger tiers.
- Put partner or associate review in front of anything that leaves the firm.
How it works, step by step
- Map the workflow — intake, conflict checks, clause extraction, deadline calculation, drafting — and mark which steps may automate.
- Define tools that return identifiers and dates from your document management system, not prose.
- Create one Plugsky project per matter with scoped keys, then wire the tool loop into your existing review environment.
- Add redaction and retention rules before any client text reaches a prompt.
- Force tool_choice with strict schemas on steps where a malformed field would break a filing.
- Review outputs before anything is sent, filed or negotiated, and log every tool call for the matter file.
Try it yourself
Open the JSON schema validator for LLM tools →
Why matter isolation is an architecture decision
Ethical walls and privilege turn tenancy into a design constraint, not an afterthought. In Plugsky, projects and scoped API keys are the unit of isolation: retrieval collections, logs and limits hang off the key. Create a project per matter or per client group, issue keys that can only reach that project's data, and rotate them when a matter closes.
The same keys give you an audit trail that names the actor and the request, which is exactly what you need when a client asks who accessed their documents and when.
Tools that return facts, not prose
The model should never be the source of a citation or a deadline. Build tools that return verified data: search_matter returns document IDs and snippets, fetch_clause returns the clause text and version, calculate_deadline returns dates computed by your docketing logic. The model's job is deciding what to look up and how to assemble the result.
Where a format must be exact, set tool_choice to the named tool and strict: true on the schema, so arguments match your fields exactly. Treat tool errors as data, return them to the model, and let it retry with a corrected call rather than failing the task.
Review, retention and evidence
Keep the human gate where the risk is: associate or partner review before a document is sent, filed or used in negotiation. The agent drafts, checks and cites; a lawyer signs off. Pair that with retention rules that match the matter's engagement letter and with redaction for identifiers that are not needed for the task.
For privileged or client-mandated workloads, pin the workspace to one region or run it in your VPC, on-prem or air-gapped. Because the audit log records key lifecycle events and inference metadata, your compliance team can reconstruct what happened without asking a vendor.
Honest comparison
| Concern | Plugsky | Managed legal AI suite | Building in-house |
|---|---|---|---|
| Tool protocol | OpenAI-compatible on the chat completions API | Suite-specific models and APIs | Custom orchestration |
| Retrieval | Live tools over your own document systems | Vendor document store | You build and index |
| Privilege isolation | Project-scoped keys per matter | Workspace-level controls | Whatever you implement |
| Residency | Region pinning, VPC, on-prem and air-gapped | Few fixed regions | You choose |
| Review gates | Enforced in your application layer | Vendor workflow features | You build each gate |
Frequently asked questions
Will the model invent citations?
It should not, because you give it retrieval tools that return document IDs and clause text. Instruct the model to cite only tool results, and reject answers that reference anything else.
Can we keep each matter isolated?
Yes. Create one project per matter with scoped API keys so retrieval collections, logs and rate limits stay separate, then rotate or revoke keys when the matter closes.
What happens to client documents we upload?
Uploaded RAG documents remain until you delete them, request and response bodies are not stored, and prompts are not used to train models.
Does this work with our document management system?
The tools run in your environment, so the agent calls your DMS through your own service. Only the tool schemas, instructions and redacted excerpts reach the model.
Can privileged work run on-prem?
Yes. The same API runs in your VPC, on-prem or air-gapped for matters that cannot use a multi-tenant cloud.
Which models should handle legal work?
Use free or mid tiers for extraction and classification, and plugsky-pro or frontier tiers for long-document reasoning. 30+ models sit behind one endpoint, so switching is a configuration change.
How do we start without a big rollout?
Build one tool loop against a single matter on the free plan with plugsky-micro and plugsky-lite, then expand to paid tiers or the 14-day full-access trial when the evaluation holds.