English | 简体中文
One Resource model for domain objects, relationships, authorization, and background coordination.
KAS is a Resource-oriented application control plane. You describe what should exist; KAS stores those objects, enforces permissions, records relationships, and sends each relevant change to the Driver responsible for handling it.
It is a foundation for Agent products, automation control planes, integration
hubs, and other systems where multiple background capabilities collaborate
around shared objects. The core branch contains only this generic kernel.
KAS Studio and KAS Forge are developed on the studio and forge branches;
master aggregates all three into the complete repository.
Control plane: Manifests define Resource structure. Clients submit desired Resources to KAS; KAS persists them, selects the affected singleton Drivers, and records the status they return. Links connect any Resources.
With a recent Rust toolchain installed, run the following commands from the repository root:
cargo run -p kas-migrate
cargo run -p kas-admin -- bootstrap admin
cargo run -p kas-apiThe bootstrap command prints the admin Bearer token. KAS then listens at
http://127.0.0.1:3000 and stores its SQLite database in .data/kas.db.
From another terminal, verify that the API is ready:
curl http://127.0.0.1:3000/healthSee the Core technical reference for storage, configuration, package installation, and Driver development. For complete products and Web UIs, see KAS Studio and KAS Forge.
Everything a person or an Agent does is ultimately an interaction with a Resource.
Creating, reading, updating, deleting, sharing a file, invoking an Agent, granting permission, and approving an operation may look like different features at the product level. Underneath, each one reads, changes, relates, or acts on something that can be described, stored, and referenced. Even execution is represented as Resources: an Action describes what can be done, and a Run records one concrete invocation.
In the same way that programs ultimately operate on memory, KAS starts from the idea that an application ultimately operates on Resources. The important questions are therefore not “which special subsystem should own this feature?” but:
- What does this Resource look like, and what does it mean?
- How is it related to other Resources?
Once those two things are explicit, many higher-level capabilities follow from the same foundation:
- Sharing: people and Agents collaborate through the same addressable Resources instead of exchanging data through hidden, feature-specific stores.
- Permission and audit: reads, mutations, relationships, and executions pass through one authorization model and leave inspectable records.
- Control and orchestration: Links can express participants, dependencies, inputs, outputs, ownership, and ordering, allowing Drivers to coordinate complex Agent behavior.
- Extension without intrusion: a Link can add a new description or relationship to an existing Resource without changing the original object.
- Dynamic vocabulary: a Manifest introduces a new Resource type at runtime. With the appropriate permission, an Agent can define and create new types itself instead of waiting for the kernel to be changed.
This is why KAS does not build separate foundations for chat, tasks, identity, permissions, workflows, and plugins. They are different Resource definitions and relationships operating on one small, composable control plane.
The only public persistent primitive in KAS. Agents, Messages, Roles, Drivers,
and even Manifests are all Resources. Every Resource has a stable path,
desired data, and current status:
{
"path": "/packages/acme/agent/resources/planner",
"metadata": {
"manifest": "/packages/acme/agent/manifest",
"state": "available"
},
"spec": {
"model": "gpt-5"
},
"status": {
"metadata": {
"state": "available"
},
"spec": {
"model": "gpt-5"
}
}
}A Manifest defines the schema, states, and available capabilities of a class of Resources. It is itself a Resource, so new domain types can be installed dynamically without changing the KAS kernel.
Every Package owns a stable /packages/{publisher}/{package} sandbox. Its
Manifest, Driver, permissions, relationships, and business Resources remain
under that root; cross-Package access requires explicit RBAC permission.
A Driver makes a Resource's current state converge on its desired state. One Driver may manage several Manifests or watch additional Resources, while KAS delivers only changes that require work. All Resources of a Manifest share a singleton Driver process; KAS does not start one process per instance.
A Relation defines which relationships are valid. A Link is one concrete relationship and may connect any two Resources:
Named Link examples:
Thread → Agent(participants) ·Message → Agent(mentioned) ·Agent → Skill(uses) ·Driver → Role(role-binding).
An Action describes an operation available for a Resource. A Run records one
execution of that Action. Both are Resources, so execution history uses the
same querying, authorization, and relationship model. Clients create Runs
through POST /runs without supplying a Resource path. KAS derives a stable,
opaque path from the authenticated Subject, Action, and request ID, then records
protected Links to the Subject, target Resource, Action, and Driver.
A Package is the KAS delivery unit. It can install a Manifest, initial Resources, and a Driver together, allowing a feature to bring its own data definition, relationships, permissions, and runtime behavior.
Reconciliation loop: (1) a client changes a desired Resource; (2) KAS authorizes and persists it; (3) KAS pushes that one Resource to each affected Driver; (4) the Driver commits mutations and reports completion; (5) KAS advances status until it matches the desired document.
KAS Core implements this generic control loop without embedding product domains. Products build their domain Resources, Drivers, permissions, and user interfaces on top as independent Packages.
| Project | Responsibility |
|---|---|
| KAS Core | Resource API, Manifests, Packages, RBAC, Links, Driver runtime, and SQLite storage |
| KAS Studio | A people-and-Agent collaboration workspace maintained on the studio branch |
| KAS Forge | An Agent-native engineering control plane maintained on the forge branch |
Core lives in the root crates/, apps/, and builtins/ directories and is
developed on core. Studio-specific code stays under studio/; Forge-specific
code stays under forge/. Both product branches merge from core, while
product code never flows back into Core or sideways into the other product.
The master branch is the integration branch: it merges core, studio, and
forge so a normal checkout contains the complete distribution.