Enterprise · Workspaces and access

Give each agent the right context.

A support agent needs customer history. A finance agent needs financial context. Namespaces organize memory into separate scopes, and access controls determine which scope an agent can use. Minds customer deployments are dedicated; namespaces organize access within that environment.

Plan your deployment Read the docs
Illustrated workflowNamespace scope
One request. One namespace.

Choose the request’s scope.

recallCapability scopeNamespace A
AAcmeNamespace A
operator / organization
AgentFinance agent
SpaceQuarterly notes
Request enters here
BGlobexNamespace B
operator / organization
AgentResearch agent
SpaceMarket notes
Out of scope
CInitechNamespace C
operator / organization
AgentSupport agent
SpaceCustomer notes
Out of scope

The token selects one NamespaceId. Other namespaces stay outside this request.

Sample names · capability enforcement requires AKASHA_REQUIRE_CAPABILITY=true

Enterprise · scoped knowledge

The right context. For the right agent.

A dedicated environment can hold distinct workspaces with explicit access boundaries.

Workspace accessAcme / dedicated Mind / example

Support agent

ASSIGNED NAMESPACE
acme/workspace/support-assistant/customer-context
tenantacme
reservoirworkspace
agentsupport-assistant
dataspacecustomer-context
REQUESTED MEMORY
Within the assigned scopeIllustrative comparison

support-assistant → customer-context

Try both sides of the boundary.

Choose an agent and a requested memory below. The example compares the assigned scope with the requested scope so the difference is visible.

Choose a chapter to explore

Example workspaces within a dedicated Mind. Access depends on the verified capability assigned to each agent and the enforcement configured on the instance.

Organize your knowledge

Separate the work. Set the permissions.

Use namespaces to distinguish teams, agents, and the spaces they work in. Pair that structure with verified access tokens and encryption settings appropriate to the data.

01

Organization

Structure memory around the work

Four levels identify the owner, organization, agent, and space for a memory. Use them to define where information belongs before it is stored or retrieved.

02

Stable scope

Return to the same context

The same namespace fields produce the same identifier. Applications can reliably address the intended scope across requests.

03

Per-namespace keys

Separate encryption keys

When storage encryption is enabled, Akasha can derive separate keys for each namespace. Encryption must be configured for the deployment; it is not enabled by default.

04

Capability scope

Limit access to an assigned scope

Verified capability tokens bind requests to an agent and namespace. The daemon checks that scope before selecting the database view. Configure the instance to require those verified credentials for access.

Technical details

A consistent address for each workspace.

The engine uses four identifiers to determine a namespace. The API field names below let developers map your organization’s structure to that scope.

Namespace
Levels
4 (tenant · reservoir · agent · dataspace)
Use
Owners, organizations, agents, and spaces
Namespace ID
128-bit ID derived from SHA-256
Per-namespace KEK
HKDF-SHA256
Cipher
AES-256-GCM when storage encryption is enabled
Auth
Ed25519 capability bound to NamespaceId
Choose the right boundary

Access and learning are separate decisions.

Namespace access decides who can use a body of knowledge. Learning isolation decides whether new information is ready to join that knowledge. Configure both when your application needs clear access boundaries and a review step for incoming facts.

Keep exploring
Security
Review encryption, connections, and access controls.
On-premise
Run your dedicated environment on infrastructure you manage.
Learning Isolation
Review new information before it shapes your agent’s knowledge.