Shopping assistant
A stable identity with a selected definition.
Data has an owner.
Bots have access.
An organization can have several assistants working with the same information. Each assistant gets only the access its work requires. Tokebak keeps the conversation and execution history; business systems keep authority over their records.
Who owns whatOne owner.
One owner.
Explicit sharing.
Each resource has one owning organization. Its owner can grant access to users, bots or other organizations. Sharing leaves ownership intact; replacing an assistant leaves shared data intact.
Administrative ownership
Organization
Owns bots, managed data and registrations for external resources.
↓ owns bots↓ owns resource registrations
Support assistant
Different behavior; access to some of the same resources.
Explicit grants →
Which resource? Which operations? For which caller?
Policy collection
Both assistants may read published policies.
Returns service
Only support may request a return, within the caller’s authority.
People may belong to several organizations. Membership and resource access are distinct. Company-wide knowledge can be broadly granted; team knowledge can use narrower grants. Groups, sub-organizations and organizational units are deferred until needed.
Definition: how to behave
Retained instructions, playbooks and tool implementations define the assistant’s behavior.
Binding: what it may reach
A host-controlled binding connects a tool to a resource and its permitted operations. Authored instructions cannot grant access or expose credentials.
Separate responsibilitiesKeep each kind of state
Keep each kind of state
with its authority.
Knowledge, tables and external APIs share access rules. Each keeps its own update and freshness requirements.
Ownership & access
User memberships, bot identities, resource registrations and grants.
Sources & records
Knowledge sources and managed tables, or records retained by an external application. Their owner defines updates, freshness and retention.
Conversation & execution
Sessions, operations, captured evidence and action receipts. Retain enough to resume work and explain what happened.
An API-backed assistant can have no local business data. Evidence retained for an answer is a record of what was observed, not a replacement system of record.
The boundary must holdSharing is explicit.
Sharing is explicit.
Authority stays scoped.
An organization is an ownership boundary; a bot is an execution identity. Neither proves that the person speaking may read a record or perform an action.
Data isolation
Owners grant access within or across organizations. A bot’s grant cannot extend the caller’s authority. Revocation applies to existing sessions too.
Workload isolation
Bound imports, indexing and expensive queries so one workload cannot starve another conversation. Separate files alone guarantee neither access control nor independent CPU, memory or failure behavior.
Change without losing meaningRetain what ran.
Retain what ran.
Know what was read.
Behavior versions, data revisions and current permissions answer different questions. Keep their identities distinct and connect them to the work that used them.
Prepared knowledge · outside the conversation
Continuity through change
Retain the definition and binding identity used by an operation. Declare whether data is pinned or follows the latest publication, and record the version actually read.
Recovery is part of ownership
Replacing a bot must not erase shared resources. Restore must reconnect ownership, retained behavior and execution records. Action receipts outlive disposable diagnostics so cleanup cannot make completed effects repeat.
The runtime checks whether captured evidence supports the answer and corrects errors that reach the user.
Prepare early.
Check at execution.
Prepare and index outside the conversation. Enforce grants when tools execute. An assistant using external APIs should need no local knowledge store. Database placement and process boundaries remain open.
Return to the architecture