A recurring point of confusion in enterprise AI architecture is the difference between an orchestration and governance layer versus a model hosting platform.
Kimss AI is a Secure Enterprise Agent Control Plane — a model-agnostic API gateway. Customers bring their own agents, model providers, and infrastructure. Kimss governs and audits the traffic path; it does not host foundation models or resell compute.
That distinction matters operationally, financially, and from a security perspective.
It also changes how teams think about orchestration systems like Hermis.
The common misconception
Many AI platforms combine several responsibilities into one product:
- Model hosting
- GPU compute resale
- Agent execution
- Governance
- Prompt tooling
- Chat interfaces
That can work for small teams, but enterprise platform teams often want separation of concerns.
Security teams want authoritative control at the gateway.
Infrastructure teams want ownership of provider accounts and keys.
Application teams want flexibility across OpenAI, Azure OpenAI, Anthropic, and OpenAI-compatible endpoints.
Procurement teams want direct vendor relationships instead of layered compute markup.
Kimss AI was designed around that separation.
You keep your infrastructure and provider relationships. Kimss governs the request path.
What Hermis actually is
Hermis is a multi-step agent orchestration capability operating on the Kimss gateway path.
That means orchestration occurs within a governed control plane rather than inside an opaque application runtime.
The important architectural point is this:
Hermis coordinates requests between agents and providers, but the underlying model inference still executes on the customer's connected infrastructure and provider accounts.
Kimss does not become your model host.
A simplified request path looks like this:
Agent → Kimss Gateway → Customer-connected provider → Response
Not:
Agent → Kimss-hosted model cluster
That difference affects compliance scope, billing ownership, and operational visibility.
Why platform teams prefer BYOI governance
Enterprise AI programs increasingly standardize around BYOI (Bring Your Own Infrastructure).
The reasons are practical:
- Existing Azure commitments
- Regional data residency requirements
- Direct provider billing visibility
- Existing Key Vault and IAM patterns
- Internal approval requirements for model vendors
- Multi-model resilience strategies
Kimss AI fits into that model with a gateway approach.
Customer provider credentials remain under customer control, including Azure Key Vault scenarios via the BYOI Provider Vault pattern. Kimss governs the request path, inventories routed agents, and enforces controls at the gateway layer.
That architecture also avoids a common operational problem: migrating application code every time governance requirements change.
OpenAI-compatible routing with a base_url change
For many teams, adoption starts with a single routing change.
Kimss exposes an OpenAI-compatible inbound endpoint at:
https://api.kimss.ai/v1
That means existing SDK-based applications can often route through the gateway with minimal changes.
Example using the OpenAI Python SDK:
from openai import OpenAI
import os
client = OpenAI(
api_key=os.environ["KIMSS_API_KEY"],
base_url="https://api.kimss.ai/v1"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "user",
"content": "Summarize today's deployment changes."
}
]
)
print(response.choices[0].message.content)
Environment configuration:
export OPENAI_BASE_URL=https://api.kimss.ai/v1
export KIMSS_API_KEY=your_kimss_key
The underlying model execution still occurs on the connected provider infrastructure configured by the customer.
Kimss governs the traffic path and audit layer.
Governance without replacing providers
One of the biggest operational advantages of a gateway architecture is that governance can evolve independently from application code.
Examples include:
- Gateway kill switch for routed traffic
- SSO identity mapping
- Gateway-verified audit
- MCP RBAC
- Per-endpoint token caps
- Agent inventory
- Controlled orchestration flows
Because the gateway sits in the request path, enforcement occurs consistently across routed agents.
This differs from relying entirely on application-level conventions or SDK annotations.
Kimss also supports zero-annotation agent discovery for routed traffic. Existing traffic routed through the gateway creates inventory rows automatically, even before teams formally register agents.
Unattributed calls are labeled by model until explicitly named with X-Kimss-Agent-Id.
That matters because many enterprises already have active AI usage before governance programs mature.
A useful framing for discovery conversations is:
Count the agents your teams are running. Now count the rows in your agent inventory.
The gap between those two numbers is usually larger than organizations expect.
Why “we don’t host models” is operationally important
Some teams initially interpret “not hosting models” as a limitation.
In practice, many platform engineers see it as a benefit.
When governance and inference are separated:
- Provider outages remain provider-specific
- Customers retain direct commercial relationships
- Existing observability pipelines stay intact
- Procurement approvals stay simpler
- Security review scope is narrower
- Multi-provider routing becomes easier
This also prevents governance tooling from becoming a hard infrastructure dependency for inference hosting.
Kimss governs the path. Customers retain ownership of the compute layer.
Hermis orchestration in enterprise workflows
Hermis orchestration becomes useful when teams need governed multi-step agent behavior without introducing another standalone runtime platform.
Typical patterns include:
- Retrieval + synthesis workflows
- Policy-aware tool execution
- Multi-agent escalation chains
- Approval-gated automation
- Structured task decomposition
- Internal API orchestration
Because orchestration occurs on the governed gateway path, auditability improves compared to disconnected local orchestrators.
That does not mean Kimss claims universal visibility into every AI process in an organization.
Kimss inventories and governs traffic routed through the gateway. It does not scan endpoints, DNS traffic, SaaS estates, or internal networks for AI usage.
That boundary is important to state clearly.
Developer onboarding without a platform migration
One reason gateway adoption works well operationally is that teams can start incrementally.
Common onboarding pattern:
- Route existing OpenAI-compatible traffic through Kimss
- Observe inventory and audit events
- Register known agents
- Add SSO identity mapping
- Introduce orchestration and governance controls
- Expand coverage gradually
This avoids “stop everything and rewrite the stack” migration projects.
Kimss also does not require teams to move into a proprietary chat application environment. The Playground is a stateless proxy simulator for gateway routes, not a hosted chat workspace.
Pricing model: governed requests, not compute resale
Because Kimss is not reselling inference compute, pricing is based on governed requests through the control plane.
Current public plans include:
- Developer: 25,000 governed requests/month free, no credit card required, 14-day retention
- Production: 100,000 included, $16/100k overage, 30-day retention
- Scale: 1,000,000 included, $8/100k overage, 90-day retention
Developer includes a hard HTTP 429 at the monthly cap.
This structure keeps provider billing separate from governance billing.
Your model provider invoices remain with your chosen infrastructure vendors.
Final takeaway
Hermis orchestration and model hosting solve different problems.
Hermis coordinates and governs workflows on the gateway path.
Your providers still execute the underlying inference.
Your infrastructure ownership remains intact.
That separation is increasingly attractive for enterprise platform teams that want governance consistency without surrendering provider flexibility or commercial control.
If your organization already has multiple agent frameworks, providers, and internal AI teams, treating governance as a control plane rather than a compute platform can reduce migration friction significantly.
Get Free API Key at https://kimss.ai
FAQ
Does Kimss AI host foundation models?
No. Kimss AI is a Secure Enterprise Agent Control Plane and model-agnostic API gateway. Customers bring their own providers and infrastructure.
What does Hermis orchestration do?
Hermis coordinates multi-step agent workflows on the Kimss gateway path while underlying model inference executes on customer-connected providers.
Can I use existing OpenAI SDK applications with Kimss?
Yes. Kimss provides an OpenAI-compatible inbound endpoint at https://api.kimss.ai/v1, allowing many applications to route traffic through the gateway with a base_url change.
Top comments (0)