Start with identity, scope and a result
Call orient on the intended connection. Check the Mind, principal and reachable areas. Read the relevant navigation map before searching or proposing work. If the expected area is unavailable, stop that part of the task and ask for an authorised handoff. Choose an observable result, such as a source read back after a correction, rather than treating a submitted request as completion.
Start with finding and checking an answer, correcting a record, building an agent, building a loop, or inviting a teammate.
Tools, inputs and client compatibility
Tool inputs and the JSON schema snapshot describe the released source interface. Discover the actual client's schema before preparing an input. Some connectors expose fewer tools, narrower action allowlists or compatibility forms. A source-defined route and an advertised tool are different evidence from a successful installed-runtime call.
Use the current public shape, including field names and required values. Do not pass private server arguments or turn an internal function into an imagined MCP call. A schema rejection known to happen before execution is different from a timed-out response after submission. In the latter case, inspect the original request and source before retrying.
Memory, retrieval and writing
Use maps, list_files, read and the advertised search/query tools within the principal's scope. A missing search result does not prove that a record never existed or is readable. Inspect current records and their sources before stating what applies now. Earlier or superseded wording can explain a change without being current guidance.
For a correction, read the complete current record, preserve unrelated content and use the current revision/base contract where required. check_write is a dry run; propose_write submits the change. Its result can be applied, held or refused. Applied needs source readback; held needs an authorised decision. The correction procedure includes examples, review and retry handling.
Identity, access and review
Reading, proposing, approving, managing access and delegating administration are distinct powers. Inspect role, assigned profile, default profile and other applicable grants; check combined effective access as the intended person. A profile name or owner's successful read does not establish another person's access.
Review the exact object through its supported controls. get_proposal retrieves a proposal; an ordinary proposal, a bundle, a loop and a human question can have different decision routes. The owner answers a question with act queue.answer, and the agent that asked reads the answer with poll_answer. resolve_question is the asking agent’s later write: it marks an already answered question as consumed so a resume pass does not process it again. It does not answer the question and is not a substitute for file approval. Review guidance and settings explain save/review behaviour. Automatic approval does not widen authority. Do not mint, copy or reveal credentials to get around a refusal.
Tasks and runtime handoff
Use task_list and task_get before creating a duplicate. task_create allocates an ID. Preserve the current task contract, use real prerequisites and record the verified result before closing work. Where an existing checklist or body requires a comparison value, supply the value read from that task rather than reconstructing it.
A runtime opens a session, claims the task, renews before the returned renewal time and supplies the current generation fence when mutating claimed work. Expiry needs a new session and claim. A stale generation is not permission to overwrite another worker. Use the supported release/handoff route and leave source references, progress, blockers and cleanup in the canonical task. Hand work onward explains the human result these calls support.
Apps, actions and sandbox
Discover installed apps and donated actions before composing work. An installed Python app’s manifest declares identity, entry point, zones, verbs, optional narrower rules, capabilities, model budget and schedule. App code and offline tests are separate from the manifest. Review, saving the bundle, installation, grant/model configuration and a scheduled result are distinct stages.
Invoke only an advertised action with the installed app and action IDs and its input schema. An action's effects, such as a proposal or external call, still need the task's authority. A dry run may read data or incur cost; it does not establish a later scheduled result. Build an agent gives the script-capable route and a handoff for clients that cannot run tests or manage lifecycle.
Connections, ingestion and model routes
Discover list_connections and use the supported owner connection ceremony. An external service connection, a model connection and permission to read a Mind area are different grants. A provider key is a secret; do not put it in a proposal, prompt, fixture or log. OAuth browser consent stays with the entitled person and service.
An imported item needs its source and result checked. Unsupported file conversions must be reported rather than represented as complete ingestion. Model use needs an allowed route and the app's own budget. Model token/cost budgets use a rolling seven-day window and are checked before a call, so an allowed final call can cross the threshold. Subscription-backed routes can record zero priced model cost while token limits still apply. A usage display is not a universal spend cap. Model and spending settings explains the separate controls.
Automations, loops and cases
An automation composes a trigger with installed actions. A loop adds a governed workflow, cases, checks and explicit authority for unattended work. Compose only actions actually installed, and inspect the proposed specification. Loop composition starts in shadow mode; proposal approval and activation are separate decisions. Replay/check results are evidence about those tests, not proof of a normal case.
Inspect the existing loop and case before retrying a failed or interrupted step. Preserve request/case IDs and distinguish a waiting human question from a completed action. Pause recurring work before investigating repeated failures. A proposed revision is not the active version until the required review and lifecycle steps succeed. Loop procedure includes the current composition example and lifecycle handoffs.
Operating records and Views
Operating records give Decisions and Policies a defined structure and lifecycle. Native tasks have their own task interface and states. The kind's schema, authority and supersession rules matter; do not treat any Markdown file as a valid record of every kind. Discover the record types and current object before creating, replacing or reviewing one. A saved draft and an approved active policy can have different meanings.
A View is a published page over declared Mind datasets. Reading the page remains subject to the viewer's data access. Authoring a bundle, validating its manifest/datasets, proposing it, approving and installing it, then opening its page are separate stages. A static preview is not a live data or permission test. Views require the release that implements them, including the Portal route and Core dataset controls. The current guide set distinguishes opening a View from building one.
Mensara Network
Network connects separate Minds through scoped sharing. Each peer's local records, its account identity, the connection's shared area and a delivered message are distinct. Review the proposed sharing scope and content at the supported approval boundary. A delivery receipt is not proof that the receiver agreed with the content or completed a business task.
The standalone Network client has its own interface, runtime support and local authorisation. Do not substitute the Mind's broader tools or credentials for the standalone client's five-tool protocol. Installation in one named runtime does not qualify every platform. Follow Network guidance and its compatibility conditions before sending or expanding sharing.
CLI and skilled procedures
The member-facing mind CLI and owner/operator brain-gateway are different interfaces. Use the help and the shipped skill for the exact installed version. A command visible in the owner's repository is not automatically available to a connected member or hosted chat client.
Discover list_skills and retrieve the selected skill with get_skill. Some skills need local scripts, files and test tools; their chat-only route is a precise handoff. Fetch the advertised assets and references instead of rebuilding the procedure from a short description. Keep any send, install, activation or approval decision within the task's actual authority.
Installation, upgrade and recovery
Operator procedures can affect services, data, credentials and stored work. Record the installed release and the target artifact before using the supported installer or upgrade path. A backup connection, a verified separate copy, a recovery kit and a successful restore are different results. Keep keys and recovery material outside ordinary content and logs.
Do not simulate recovery by overwriting the active Mind. Follow the documented restore route with the authorised operator and target, then check both recovered information and access. Backup and ownership explains the reader-facing checks. A customer release or deployment needs its own approval and qualification.
Compatibility and changes
This input snapshot is from Core 0.20.11 with Portal 0.3.47. Existing 0.20.10 receipts remain older, scoped evidence. Source publication, catalog selection, installation, enabled features and an accepted task result are separate facts; do not assume every Mind runs the newest release.
Start from the connected environment and its advertised interface. Check prerequisites and installed dependencies, then use a recipe that fits that client and authority. If a route is absent, report the missing capability and an authorised handoff rather than claiming success from an offline fixture. Versions and changes helps choose the applicable instructions.
Related
Practical guides for people and agents