Technical Deep Dive
Under The Hood
Three engines power the Klique platform: one that orchestrates every workload, one that governs every actor, and one that connects every model. Together they form one platform for the people who run AI and the people who just use it. Most AI platforms stop at the API level and assume every user is a developer. Klique keeps going: your infrastructure team gets the control plane, your builders get compute and models, and everyone else in your organization gets governed, self-serve access to AI, the same way they’d consume it from the cloud. No tickets, no credentials, no Kubernetes expertise.
Every request takes the same three steps
One Platform. Three Engines.
Whether it’s a builder training a model, an agent running a task, or an employee asking a question, every request flows through the same three engines. Operators configure it once, everyone else just consumes.
Orchestration Engine
One resource pool. Every workload. Every user. Routed automatically.
Orchestration
AI Identity Federation
Every request, human or agent, runs against your existing IdP: SSO authentication, RBAC, resource policies, and available credentials, before it reaches compute. Org-level, team-level, and agent-level permissions are all checked at the point of entry, not after the fact.
For everyday users that means one login with the SSO they already have. No API keys, no extra credentials, no new accounts.
The Scheduler
A multi-tenant, on-demand scheduler sits between authenticated requests and compute. It classifies every workload as persistent (a service) or ephemeral (a job) and routes it accordingly, enforcing per-team and per-agent quotas, priorities, and placement rules as it goes.
Operators tune it. Builders queue against it. Everyday users never see it.
Workload Optionality
Persistent Workloads: Long-running services that stay alive across interactions: workflow orchestration, web apps, chat endpoints, database access, LLM-as-a-Service. Your production AI tier, the part the whole workforce uses.
Ephemeral Workloads: Run-to-completion jobs: training, fine-tuning, batch inference, data ETL, evaluations. The builders’ tier. Resources release the moment the job is done.
Resource Allocation
Klique augments compute across three dimensions: silicon (GPU, TPU, CPU, xPU), location (on-prem, cloud, edge), and models. Builders request capabilities, not infrastructure. Consumers just use the service. The engine resolves the rest.
No GPU sits idle and no GPU sits reserved. Dynamic fractioning securely shares a single GPU across workloads. Inactive models wait in CPU memory and load to GPU on demand, without cold starts. Auto-scaling follows response latency, not GPU metrics.
Governance Engine
Purpose-built for the agentic era. Not retrofitted. Four tiers of control, from cluster admin to everyday consumer. Every actor governed. Every action scoped.
Agents are first-class participants in Klique’s architecture. They connect to your existing SSO/IdP the same as human users but with finer granularity and control. Resource requests are routed by the same scheduler and drawn from the same resource pool, under their own credentials, their own quotas, and their own access policies. The Governance Engine applies to agents and humans identically. No special mode. No retrofitted governance. This is what makes workforce-wide self-service safe: access is broad because control is built in.
Governance
Cluster Admin
IT infrastructure team has full control over hardware pools, network policies, global security configuration, and cluster-level resource and tenant limits
Tenant Admin
IT admins can define tenant-wide policies across several areas: identity federation, cross-project governance, observability settings, cost allocation, AI services, compute resource quotas, and priorities.
AI Builder
Teams and agents building get project-scoped and group scoped control over resources, access policies, deployment configurations, and budget limits
AI Consumer
Everyone else in your organization gets governed self-serve access to internal and external AI services within the boundaries set above. No infrastructure knowledge, no additional credentials, no IT ticket. Simply pick a service and use it.
AI Engine
One gateway. Every model. Every user. Spend you can see.
Every model your teams use, in-house, open-source (HuggingFace and others), or third-party APIs (OpenAI, Anthropic), sits behind a single gateway. Klique routes each request to the model that fits, based on the policies IT sets: cost, performance, data sensitivity. None of this is visible to the user. Builders get endpoints and APIs. Everyone else picks a service and uses it: no keys, no configs, no model names to remember.
Token management and spend tracking span compute, models, and services, so you can see what AI costs and what it returns, by team, by project, by request, down to the individual user or agent. Spend is controllable, not just visible. Budgets and rate limits cap usage; content-based routing sends each request to the optimal model that can handle it.
AI Engine
Budgets and rate limits cap usage; content-based routing sends each request to the optimal model that can handle it.
Whether it is a builder training a model, an agent running a task, or an employee asking a question — the same three engines, in the same order.
The Klique Stack
Klique is the connective tissue between the infrastructure you run and the people who use AI: one platform layer over compute, data and models. You keep the bottom of the stack. Your teams keep the top. Klique is everything between.
Application gateway
AI development tooling + environments
Single policy management
LLM gateway + smart router
GPU scheduling + dynamic fractional allocation
Resource pools
The approved catalogue. They never see below.
Governed environments, not a DevOps queue.
Own the resources and the policy over them.
Agents are first-class participants: their own credentials, their own quotas, their own access policies. No special mode, no retrofitted governance.
One Policy Object. Two Kinds of Traffic.
Quota, priority and access are not configured per tool — they are one policy object. The scheduler enforces it when the traffic is a compute job. The gateway enforces the same object when the traffic is an AI request.
A training job and a chat completion are governed by the same object: the same quota, the same priority, the same access decision. The scheduler enforces it on silicon; the gateway enforces it on models. Nothing is configured twice, so nothing can drift apart.
Where Klique and Kubernetes Come Together
Your Kubernetes still handles the physical layer: fault recovery, rolling updates. Klique’s scheduler sits on top, handling the logic: which tenant gets what resources, under what policy. No writing manifests, no managing operators, no debugging scheduler configs, and no Kubernetes expertise required to operate the platform day to day. Two layers, doing two different jobs. Klique runs on top of any flavor of Kubernetes (OpenShift, Suse, Canonical, vanilla upstream and others) or plain VMs, and adds what they all stop short of: AI platform that the whole workforce can consume.
Multi-tenant from the web interface down to the silicon. Klique schedules, governs and meters across every node; Kubernetes, VMs and bare-metal keep the machines running beneath it.
For the full technical breakdown, the architecture, the API surface, and the deployment model — head to the documentation.
Ready to See Klique Running on Your Infrastructure?
Klique runs on the stack you already own: your Kubernetes, your GPU clusters, your cloud accounts, your existing models, and makes them usable by every person and agent in your organization. Deploy on-prem, air-gapped, in the cloud, or hybrid. Your data, models, and identity stay under your control.
Request A Demo
