Feature × Audience

How should enterprise architects design agent platforms on Plugsky?

Design agents as a platform, not per-team projects: one OpenAI-compatible gateway, a shared tool registry with owner and risk labels, policy enforced outside the model, region-pinned workspaces and a single audit pipeline. Plugsky supplies the compatible API, scoped keys, RBAC/SSO, region-locked planes and SIEM export; your architecture supplies the control plane, tenancy model and evaluation gates that keep agent sprawl manageable.

Key facts

InterfaceOne OpenAI-compatible endpoint for all agent teams and models
Control planePolicy, tool registry, evaluation gates and budgets live in your architecture
IdentityScoped API keys per service, RBAC and SSO/SCIM for people
ResidencyEU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) region-locked planes
Deployment tiersPlugsky cloud, VPC private endpoint, on-prem and air-gapped
AuditAuthentication, key, admin and inference metadata exportable to SIEM
Model routing30+ models behind one alias system; route by step, not by team preference
Endpoint statusChat completions and function calling are live; assistants and responses endpoints are coming soon

TL;DR

  • Standardise on one gateway and one audit pipeline before the second agent ships.
  • Treat tools as governed assets with owners, risk tiers and versioned schemas.
  • Keep authorisation outside the model; the model proposes, your policy disposes.
  • Pin each workspace to a region and align log residency with data residency.
  • Route across 30+ models to match cost and latency to each step.

How it works, step by step

  1. Inventory candidate agent workflows across business units and score them by data sensitivity and reversibility.
  2. Stand up a shared model gateway in front of the OpenAI-compatible endpoint so no team calls the API with unmanaged keys.
  3. Build a tool registry: each tool gets an owner, a versioned JSON schema, a risk tier and a maximum blast radius.
  4. Define policy in code — which agent may call which tool with which identity — and enforce it in the gateway, not the prompt.
  5. Pin workspaces and log streams to the region required by each data class, and choose cloud, VPC, on-prem or air-gapped per workload.
  6. Instrument a single audit pipeline and dashboard covering agent runs, tool calls, escalations and human overrides.
  7. Set an evaluation gate: no prompt, tool or model change reaches production without passing a regression suite.
1Inventory candidateagent workflowsacross business2Stand up a sharedmodel gateway infront of the3Build a toolregistry: each toolgets an owner, a4Define policy incode — which agentmay call which tool5Pin workspaces andlog streams to theregion required by6Instrument a singleaudit pipeline anddashboard covering

Try it yourself

Open the agent workflow designer →

Reference architecture in one page

Four layers. Experience: the product surface where a user or service asks for an outcome. Orchestration: your agent loop, which owns state, retries, budgets and human approval. Gateway: a single service that authenticates to Plugsky with scoped keys, applies policy, selects the model and emits audit events. Tools: registry-backed functions with schemas, owners and risk tiers.

Plugsky contributes an OpenAI-compatible API, 30+ models, scoped keys, RBAC/SSO, region-locked planes and SIEM export. Everything above — tenancy, policy, evaluation, budgets — is yours to own. That split is deliberate: provider-neutral interfaces keep agents portable, while enterprise concerns stay where your governance already lives.

Governance that scales past the pilot

Most agent programmes fail on sprawl, not capability. Control it with artefacts: a tool registry that makes shadow functions visible, policy as code that reviewers can read, and evaluation suites that turn prompt changes into reviewable diffs. Assign each agent a named owner, a data classification and a kill switch.

  • Blast radius: default tools to read-only; write and execute tools require explicit approval and a recorded justification.
  • Budgets: cap steps and tokens per run so a looping agent cannot consume a quarter's capacity in an afternoon.
  • Review cadence: treat agent prompts and tool schemas as versioned artefacts with the same change control as code.

Residency, audit and exit

Map every data class to a plane and keep inference, embeddings and logs together: EU (Frankfurt), GCC (UAE), APAC (Singapore) or US (Virginia), with VPC, on-prem and air-gapped tiers where required. Because the interface is OpenAI-compatible, exit is a base URL change plus model mapping — a strong negotiating position and a resilience property worth testing in a game day.

Instrument once: authentication and key events, administrative changes and per-run inference metadata stream to your SIEM, so an auditor can reconstruct who asked what, which tools ran and which human approved the outcome. Prove the pipeline on a pilot agent before it becomes the organiser of record for the whole programme.

Honest comparison

Architecture concernPlugskyTypical managed agent platformBuilding in-house
InterfaceOpenAI-compatible endpoint across all modelsVendor-specific runtimeYou define and version it
Model sourcing30+ models behind one alias systemVendor catalogueYou serve each model
Policy enforcementScoped keys, RBAC/SSO; policy in your gatewayVendor controls inside its runtimeEntirely your build
ResidencyRegion-locked planes plus VPC, on-prem, air-gappedLimited region choicesWherever you deploy
AuditKey, admin and inference events exportable to SIEMVendor logs and dashboardsYour pipelines
PortabilityChange base URL and model mappingRewrite against vendor runtimeFull control

Frequently asked questions

Should every team call the API directly?

No. Put one gateway in front so keys, policy, model routing and audit events are centralised. Teams consume the gateway; they do not manage provider credentials.

How do we prevent agent sprawl?

Treat prompts, tools and evaluations as versioned artefacts with named owners. A registry plus a deployment gate surfaces shadow agents before they touch production data.

Where does authorisation belong?

Outside the model. The model proposes tool calls; your gateway and services decide whether the caller is permitted, and log the decision.

How should we choose between deployment tiers?

By data class and regulation, not convenience. Cloud for low-sensitivity workloads, VPC for most enterprise data, on-prem or air-gapped where processing must not leave your perimeter.

Can we mix models per workflow?

Yes. The same endpoint serves plugsky-micro, plugsky-lite, plugsky-pro and frontier models, so routing decisions are configuration rather than platform choices.

What makes exit realistic?

The OpenAI-compatible interface. Migrating means changing a base URL and mapping model names, so you can test portability without a rewrite.

How do we audit agent decisions?

Export authentication, key lifecycle, admin and inference metadata to your SIEM and correlate with application-level approval records. Prompt retention is configurable per workload.