Key facts
| API compatibility | One client for every agent, model as a parameter (live) |
| Runtime features | Streaming, JSON mode and function calling (live) |
| Models | 30+ models behind one endpoint for per-agent routing |
| Handoffs | Typed JSON payloads validated between agents |
| Budgeting | Turn and tool caps enforced per agent in your code |
| Observability | Per-agent traces with model and tool metadata |
| Deployment | Region-locked planes, VPC, on-prem and air-gapped options |
| Free tier | plugsky-micro and plugsky-lite on the free plan, no card required |
TL;DR
- Use one client and swap the model parameter per agent — no per-vendor adapters.
- Define handoff schemas before writing prompts; interfaces prevent most agent bugs.
- Route workers to small models and planners to stronger ones.
- Cap turns, tools and tokens per agent so one worker cannot stall the run.
- Trace every turn so failures map to a specific agent and step.
How it works, step by step
- Design the decomposition and handoff contracts on paper, naming each agent and its inputs and outputs.
- Create one shared client pointed at the Plugsky base URL, with model names resolved per agent from configuration.
- Implement each agent as a function-calling loop over chat completions with its own tool list and system prompt.
- Validate handoff payloads with schemas; reject malformed messages rather than passing them downstream.
- Set budgets per agent — maximum turns, tool calls and tokens — and let the orchestrator decide when to stop.
- Emit a trace per agent turn with model, tools, arguments and result sizes, and export traces for analysis.
- Evaluate the pipeline on fixed tasks, compare routing configurations, then widen usage.
Try it yourself
Open the multi-agent workflow generator →
One client, many agents
Compatibility removes the integration tax from agent architectures. With one OpenAI-shaped client, the planner, the workers and the synthesiser are the same code path with different prompts, tool lists and model names. That means orchestration logic is written once and model routing becomes a table you can edit.
Plugsky's live endpoint supports streaming, JSON mode and function calling, which covers the primitives agents need: structured decisions, tool execution and responsive output. Roadmap items such as assistants-style endpoints are coming soon, so thread and run management stays in your orchestration layer — which is where budgets and guardrails belong anyway.
Handoffs and structured messages
Agent-to-agent communication should be typed, versioned and validated. A handoff is a JSON object with a defined schema: task, inputs, evidence references and constraints. Validation at every boundary catches the most common failure — a worker returning prose where the orchestrator expected structure.
- Schemas first: write the handoff contract before the prompt that fills it.
- Validate: reject or repair deterministically, never forward malformed payloads.
- Minimise: pass references and summaries rather than full transcripts.
- Concurrency: run independent workers in parallel, then synthesise once.
Budgets, traces and rollout
Multi-agent systems fail expensively when loops are unbounded. Enforce turn caps, tool-call limits, token budgets and wall-clock timeouts per agent in your orchestration code. If a worker exceeds its budget, fail that branch and let the planner decide whether to retry, reroute or degrade gracefully to a simpler answer.
Tracing is the other half of control: per-agent records of model, prompt version, tools, arguments, latency and token usage. Those traces show whether a poor result came from decomposition, a tool, or synthesis, and they feed a regression suite as the system grows. Because every agent uses the same client, moving from a pilot to region-locked or on-prem deployment changes configuration, not architecture.
Honest comparison
| Concern | Plugsky | Multi-provider setup | Managed agent platform |
|---|---|---|---|
| Client code | One compatible client for all agents | An adapter per provider | Vendor SDK |
| Model routing | 30+ models, per-agent parameter | Framework-specific config | Vendor catalogue |
| Streaming and tools | Live on chat completions | Varies | Vendor features |
| Budgets | Enforced in your orchestration layer | Your code | Vendor limits |
| Deployment | Region choice, VPC, on-prem, air-gapped | Mixed per provider | Usually cloud-only |
Frequently asked questions
Can different agents use different providers?
They can, but it multiplies adapters, auth and billing. An OpenAI-compatible endpoint with 30+ models keeps one client while still letting each agent run a different model tier.
How do agents communicate?
Through typed JSON handoffs validated by your orchestration code. Schemas catch malformed payloads early and keep prompts small because only needed fields travel.
Is streaming useful across agents?
Streaming matters most for user-facing agents; internal workers can return structured results without streaming. Both patterns use the same live chat completion endpoint.
How do we control runaway cost?
Set turn, tool-call, token and time budgets per agent, and route routine work to small models. Budgets are enforced in code, not requested in prompts.
Do we need managed agent endpoints?
No. Assistants-style endpoints are coming soon, but owning orchestration gives better control over state, retention and permissions — which matters in enterprise deployments.
How should we evaluate the system?
Use fixed tasks scored end to end, plus per-agent traces to attribute failures. Compare routing configurations to confirm that cheaper models hold quality on worker roles.
Can it run inside our network?
Yes. Plugsky supports region-locked cloud planes plus VPC, on-prem and air-gapped deployment, and orchestration remains yours either way.