itzshrvsh/moshi

Purpose and Entry Points

This repository appears to be a local “Moshi” agent/runtime workspace: it combines lifecycle/process management, Android and tunnel capabilities, persistent memory, and Telegram bot interfaces. There is no README content, so behavior must be confirmed from implementation.

Likely operational entry points:

• start_moshi.sh

• start_moshi.bat

• memory_server.py

• telegram/bot.py

Moshi Runtime Orchestration

The Moshi-prefixed modules form the primary runtime/control plane. They likely define startup configuration, lifecycle transitions, process execution, capability registration, and health diagnostics:

• moshi_config.py

• moshi_lifecycle.py

• moshi_process.py

moshi_manifest.py and moshi_capability.py likely provide the declared contract for enabled functions/components, separating what the runtime can expose from how each capability executes.

Device, Artifact, and Connectivity Capabilities

Android interaction, artifact handling, and external connectivity appear to be distinct capability domains:

• moshi_android.py

• moshi_artifact.py

• moshi_tunnel.py

This separation suggests the core runtime delegates infrastructure-specific work rather than embedding device or network logic directly in lifecycle management. Tunnel behavior is a material boundary because it may expose local services or connect the runtime to remote consumers.

Memory Service Boundary

Persistent or retrievable agent memory is isolated under a dedicated package and service wrapper:

• mem0/memory.py

• memory_server.py

• memory_mcp.py

mem0/memory.py is the apparent storage/domain layer. memory_server.py likely exposes it as a running service, while memory_mcp.py likely adapts memory operations to an MCP-oriented protocol or client boundary. This keeps agent memory usable independently of a specific chat interface.

Chat and Agent Interfaces

Telegram is an external-facing channel with several implementation variants:

• telegram/bot.py

• telegram/bot_agent_final.py

• telegram/bot_upgraded.py

The primary intended bot should be established before deployment; the variant names indicate iterative or backup implementations rather than a single unambiguous production entry point. The bot layer should call into the Moshi runtime and/or memory service rather than own core execution state.

Operational Validation and Diagnostics

Runtime verification is represented by dedicated orchestration and diagnostic modules:

• moshi_doctor.py

• moshi_e2e.py

• moshi_manifest.py

moshi_doctor.py likely checks environment/runtime prerequisites, while moshi_e2e.py appears to exercise integrated flows across services. moshi_manifest.py is architecturally important as the likely source of truth for what a running Moshi instance exposes.

Deployment Shape

The repository is primarily Python with platform-specific launch wrappers:

• start_moshi.sh

• start_moshi.bat

• opencode.json

Expected execution flow is: launcher initializes Moshi configuration and lifecycle management; the runtime starts required processes/capabilities; optional memory and Telegram services connect at their respective boundaries; diagnostics/e2e paths validate the assembled system.