Describe the operating model
Define the systems, relationships and rules that matter for a domain. Agents work against that explicit model instead of reconstructing one for every prompt.
The federated operational model for AI
Your systems expose data.Kubling exposes the operation.
Give AI agents and automation a bounded model of live IT and OT state. Kubling federates that state directly from its sources, so there is no central copy to build first.
Zero-copyQuery + mutateIT / OT / APIsPlatform-less topology
live operational state
4 connected sources
OpenAPI
business systems
Kubernetes
workloads
BMS / Redfish
infrastructure
Modbus
facility systems
Kubling model
federatedoperational question
Can workloads leave rack 07 without violating redundancy?
depends_onpowered_byruns_on
bounded result
Move one dependency first. The proposed sequence checks live capacity and the current maintenance window.
0 copies
4 domains
1 model
Context for agents
The agent needs a working model of the operation.
An agent can call every system and still have to reconstruct the operation for each prompt.
A typical tool or MCP integration still leaves the agent to infer the model. Kubling makes the shared entities, relationships, source ownership and valid actions explicit.
Entities
servers, workloads, alarms
Relationships
depends on, runs on, affects
Authority
ownership, policy, capability
Federation at the source
Query the operation across the systems that run it.
Plan and execute across sources
Queries and mutations cross databases, APIs and infrastructure. Each provider translates them into the source's native protocol and executes them near the system.
Leave ownership with each team
Providers retain their credentials, source logic and release cycle. Kubling handles federation, planning and policy across them.
OpenAPI, queried in place
Join an API with the rest of the operation.
Kubling's OpenAPI provider exposes API operations as relational entities. Query them alongside databases, Kubernetes and physical infrastructure. Mutations map back to the API's own HTTP operations, so the API remains authoritative.
Explore the OpenAPI provider
Distributed deployment
Grow a topology, not a central platform.
Deploy Kubling around the teams, sites and systems that already own the operation. An instance can use local providers, federate other Kubling instances, or do both. Connect them when a broader view is needed.
Platform-less does not mean architecture-less.
There is no required central instance or big-bang platform program. Start with one operational domain and connect others as the scope grows.
Example federated topology
no required centercross-domain
Cross-domain operational view
joins across the mesh
domain
Facility cluster
aggregation instance
systemRedfish
systemSwitches
systemk3s
aggregated Kubling instances
system
Application system
direct instance
OpenAPI
Postgres
Redis
source-local providers
domain
Edge cluster
aggregation instance
systemk3s
systemk3s
systemSwitches
aggregated Kubling instances
system view · domain view · cross-domain view
Provider architecture
Add providers without rebuilding the engine.
A provider is an independent service behind Kubling's public gRPC contract. It can use the source-native client and release independently from the engine. The provider language and deployment model are up to the team.
New sources do not change engine code
Providers deploy and release independently
Source-native libraries stay with the provider
Any language that supports gRPC
The provider protocol, Go SDK and official providers are open source; the engine is not. Teams can inspect the boundary and build their own providers against the same contract.
Explore provider sourceProvider boundary
separate lifecycleProviders run outside the engine.
Kubling Engine
Plans queries and cross-source execution.
modelpolicyfederation
public gRPC
Independent provider
Maps Kubling operations to the source client.
schemaquerymutation
OpenAPI
Kubernetes
Cassandra
Redis
New provider ≠ new engine release
Operational settings
The architecture stays the same. The decision changes.
Data center operations
Can workloads move without breaking redundancy?
Relate facilities, hardware, workload placement and maintenance before a local warning becomes a service incident.
Explore data centersIT & platform operations
Which deployments affect the service right now?
Resolve Kubernetes state, APIs, application inventory and ownership through one federated model.
Explore IT operationsIndustrial operations
Can this device change proceed safely?
Keep device access close to the process, add asset and maintenance context, then federate upward when needed.
Explore industrial operationsStart here
Start with one source. Keep the same execution model as you grow.
Run a query and a mutation against a small local stack. Replace the in-memory source with Kubernetes, OpenAPI or your own provider later. Kubling still plans through the same contract.