Key facts
| Loop | tools array on /v1/chat/completions; model returns tool_calls with JSON arguments |
| Execution | Your code executes tools; the model never holds credentials |
| Streaming | Function calling works with streaming on live chat models |
| JSON mode | Pair strict tool schemas with JSON mode for structured output |
| Model support | Tool support varies by model; verify per model in the catalogue |
| Status | Function calling is live; assistants and responses endpoints are coming soon |
| Approvals | Execution stays behind your approval gates; agents draft and recommend |
| Audit | Tool calls logged with model, arguments, result and approver |
TL;DR
- A tools array on /v1/chat/completions; your code executes every tool call.
- Streaming and JSON mode work alongside function calling on live chat models.
- Start with read-only tools; add proposals only behind human approval.
- Validate every argument before it reaches a banking system.
- Start free with plugsky-micro and plugsky-lite; a 14-day full-access trial covers larger models.
How it works, step by step
- Write strict JSON schemas for each tool with typed fields and enums.
- Implement the loop and validate every argument before execution.
- Log model, tool name, arguments and result for each call.
- Define read-only tool schemas for lookup, status and document fetch.
- Run tools under a least-privilege service identity with idempotent writes.
- Log every call with arguments, result and approver for review.
Try it yourself
Open the function calling tester →
Function calling for banks: what changes
Banks see function calling as the bridge between models and systems of record, which makes every tool a potential control point. The safe pattern is narrow tools, least privilege and human approval for anything that changes state.
Function calling on Plugsky is a loop around /v1/chat/completions: you send a tools array of JSON schemas, the model returns tool_calls with arguments, your code executes them inside your own boundary, appends the results and calls again until the model produces a final answer. Streaming works with tools, and JSON mode pairs with strict schemas for structured output. Tool support varies by model, so verify it per model in the catalogue.
Architecture and controls
Define tools with tight schemas — account lookup, case status, document fetch — and execute them from a service identity with the minimum permissions. Keep payments, KYC outcomes and customer messaging behind approval gates, and make write tools idempotent with an audit key.
Integration pattern and rollout
Build the loop on /v1/chat/completions, log every tool call with model, arguments and result, and run a regression suite against historical cases. Start with read-only tools, then add proposals that a human approves.
Treat tool schemas as code-execution boundaries. Validate every argument against the schema before it reaches a system, scope each tool to least privilege, make write operations idempotent, and fail closed on invalid output. The model never holds credentials; your executor does. Log model, tool name, arguments and result for every call so reviewers can reconstruct decisions.
Limits, evidence and cost
Function calling does not provide governance by itself: your application enforces limits, approvals and audit. Treat model output as untrusted input, and validate arguments before they reach any banking system.
Function calling is available on live chat models across plans — see the live pricing page for current tiers. Start free with plugsky-micro and plugsky-lite and no card, then use the 14-day full-access trial to evaluate larger models against your tool scenarios.
Honest comparison
| Concern | Plugsky function calling | Vendor-locked tool platforms | Building in-house |
|---|---|---|---|
| Interface | OpenAI-style tools array on chat completions | Proprietary assistants API | Custom schema and runtime |
| Execution | Your code runs tools inside your boundary | Varies; often vendor-hosted tools | You build the executor |
| Model choice | 30+ models; tool support varies by model | Vendor catalogue only | You host each model |
| Residency | Region-locked planes; VPC, on-prem and air-gapped | Limited region choices | Wherever you deploy |
| Status | Live on chat completions | Varies by vendor | Months of engineering |
| State-changing tools | Approval gates plus idempotent writes | Varies by vendor | You build approval logic |
Frequently asked questions
How does the function calling loop work?
You send a tools array with the request, the model returns tool_calls with JSON arguments, your code executes them, appends results and calls again until the model answers.
Does the model execute tools itself?
No. Execution happens in your code, inside your boundary. The model never receives credentials, and your executor enforces permissions and validation.
Which models support function calling?
Function calling is live on chat models, but tool support varies by model. Verify per model in the catalogue and test your schemas before production.
Can an agent execute a payment?
Not through Plugsky. Your code executes tools and should keep payments behind approval gates; the model only proposes structured calls.
How do we audit agent decisions?
Log model, tool name, arguments, result and approver for every call, and export the trail to your SIEM so decisions can be reconstructed.
What tools should come first?
Read-only lookups — account status, case history, document fetch — then proposals that a human approves.