Tools And Memory
Loong’s public operator model is built around governed capability exposure. This page is the bridge between the short product story and the deeper capability-specific pages.Tools
- visible tools should reflect actual runtime availability
- higher-risk actions stay inside policy, approval, and audit boundaries
- browser and web surfaces are governed runtime tools, not scattered helper scripts
- the public story is capability-first: the assistant should not advertise tools that are compiled out, disabled, or unavailable on the current surface
Memory
The public repository keeps memory documentation focused on shipped behavior:- one session-memory model with selectable continuity profiles
- advisory continuity rather than identity override
- operator-visible setup and first-run expectations
- continuity and recall that follow the actual indexed durable corpus instead of hidden prompt-only state
- continuity that helps the operator without pretending memory is a second authority for runtime identity
Why These Two Stories Belong Together
- Tools and memory both need truthful public representation.
- Both should follow the actual runtime boundary instead of aspirational product copy.
- Both affect day-to-day operator trust more than long-range product vision statements do.
Read By Depth
Where To Go Next
- Continue to Tool Surface for the truthful visible-tool contract.
- Continue to Background Tasks for the task-first delegated async work contract.
- Continue to Skills for install, policy, and external browser automation skill setup.
- Continue to Browser And Web Boundaries for private-host, domain, and browser runtime troubleshooting.
- Continue to Memory Profiles for the public continuity contract.
- Continue to Reference if you want the supporting roadmap, reliability, and release material.