An agent’s useful knowledge is rarely generic. It includes the project you are building, the decisions your team has made, and the exceptions that shape how work gets done. As that context accumulates, the question becomes more important: where does it live, and how do you control its use?
Minds is organized around a dedicated Mind: an Akasha instance with its own data, configuration, and endpoint. The platform manages the account and the lifecycle around it. That model gives builders a concrete unit to reason about when connecting an application, inspecting its memory, or planning how the system should grow.
Name the boundary before you store the data.
Before an application writes its first memory, it should be clear which project, customer, or agent the record belongs to. A dedicated runtime and an application’s data scopes address related but different concerns. The runtime defines an infrastructure boundary. The application still needs to decide which identities can access which records and which tools receive authority to act.
This matters even for a small prototype. A convenient development token can easily become a credential used by several unrelated processes. A customer identifier can be omitted from a query. A record can be copied into a log where it no longer follows the same access path. Careful scoping begins with the ordinary integration decisions that surround the storage engine.
One platform. Two API responsibilities.
The Minds platform API and the Akasha instance API have different jobs. The platform handles concerns around an instance: ownership, provisioning, lifecycle, usage, and billing. The instance exposes memory and engine operations. Knowing which surface owns a request helps a developer choose the right endpoint and understand the authority it requires.
For example, creating a Mind is a platform operation. Saving or recalling a record concerns the instance. A management credential should not be assumed to work as an instance credential, and an instance token should not be assumed to grant account-wide authority. The documentation separates these contracts and records where a route requires additional privileges or has an implementation limitation.
A dedicated instance also does not mean every host-administration operation should be available to every client. There is a distinction between controlling the data and services of your Mind and administering the infrastructure beneath the platform. An integration should use the documented customer-facing operation and verify the result it needs.
Capacity should not redefine the product.
Free, Pro, and Enterprise give builders different ways to size and operate a Mind. Free starts with capped dedicated capacity. Pro expands that capacity for growing projects. Enterprise supports deployment planning and separately agreed requirements. The underlying product idea stays consistent: your application has a defined home for its memory.
The intended hosted architecture uses dedicated Firecracker microVMs for both Free and Pro. Confirm the runtime and region of the instance you will use when those details are a requirement. The instance documentation records the current provisioning scope and verification notes.
For planning cost, examine compute, retained storage, and transfer in the current pricing information. Service configuration can also affect the work an instance performs. Decide which workloads you need, monitor their behavior, and check the resulting usage. An infrastructure-shaped bill should be understandable in terms of the application you are operating.
A source is part of the answer.
When an agent returns a remembered conclusion, the source can be as valuable as the text. A customer requirement, a research observation, or a financial assumption should be traceable to the material that supports it. Knowledge relationships and lineage help represent that connection, so the application can inspect how a record relates to earlier work.
Traceability has a specific purpose. It tells you where information came from and how it is connected. It does not prove that the information is true. A preserved source can still be wrong. A derivation can still contain a mistake. Keep the evidence available and apply the review appropriate to the decision, especially when an answer will influence consequential work.
Learning Isolation adds a different boundary inside the Mind: incoming information can be reviewed before acceptance. That protects the distinction between receiving a claim and choosing to rely on it. It should be wired into the intended workflow and tested, rather than assumed to apply automatically to every possible write path.
Control includes the end of a record’s life.
A persistent system needs a retention plan. Decide what should remain available, what should expire, and what needs deletion when a project ends or a customer requests it. Review how backups, exports, logs, and downstream copies interact with those decisions. A deletion reference from one operation is not evidence that every retained copy has disappeared.
The same discipline applies to recovery. An export or snapshot is useful only if it covers the intended data and can be restored through a supported path. Test the recovery procedure for your deployment and keep the results with your operating documentation. Storage durability, backup policy, and a demonstrated restore are separate considerations.
Build around a boundary you can explain.
A useful first production checklist is short: identify the Mind your application uses, document the credentials and scopes, inspect a write and a recall, confirm the runtime requirements, and understand retention and cost. Then exercise failure cases. A missing service, an expired credential, or a rejected request should produce behavior your application can handle.
A Mind of your own is a way to give accumulated context a defined home. The value comes from combining that home with clear interfaces, visible evidence, and intentional control. The more useful an agent becomes, the more those foundations matter.