7/24 Office: a 10,000-line Python agent with no framework underneath

What 7/24 Office solves, and for whom

Most agent frameworks assume you want the framework. 7/24 Office assumes the opposite. The README states the project is roughly 10,000 lines of pure Python with zero framework dependency: no LangChain, no LlamaIndex, no CrewAI, just the standard library plus a few small packages. The problem it addresses is the one that appears after you have shipped an agent and start wondering which layer of somebody else's abstraction is eating your tokens or your error messages. Here you can read every line of the loop.

The audience is narrow and identifiable. It is for engineers who already run a messaging bot, already have an OpenAI-compatible endpoint, and want a single-tenant agent that keeps working while they sleep. The README describes it as production 24/7 across multiple users, built solo with AI co-development tools. Multi-user here means the router gives each user their own Docker container, not that one process serves everybody. If you are evaluating this for a team that needs a supported dependency with semantic versioning, the fit is poor, and the repository itself signals that by pointing at a successor.

The tool use loop, the router and the three memory layers

The data flow in the architecture diagram is linear and readable. A messaging platform posts to router.py, which handles multi-tenant routing, auto-provisioning, container reconciliation and health checking. From there xiaowang.py acts as the entry point: an HTTP server with debounce, media download, ASR and group support. It hands off to llm.py, which owns the tool use loop, session management, budget-aware system prompt assembly and memory injection.

The loop itself is OpenAI-compatible function calling with automatic retry, capped at 20 iterations per conversation. Below llm.py sit the tool modules, split by domain: tools_messaging, tools_admin, tools_search, tools_video, tools_page and tools_mirror. nudge.py watches that layer with five rules and fires an automatic hint when the model has tools available but is not calling them. That is an unusual design choice and a defensible one: the failure mode where an agent answers from memory instead of calling a tool is common and silent, so a structural detector is more reliable than a prompt instruction.

Memory is three layers. Session history keeps the last 40 messages per session as JSON files, and overflow triggers compression. Compressed long-term memory has an LLM extract structured facts from evicted messages, deduplicated by cosine similarity with a threshold of 0.92, stored as vectors in LanceDB. Retrieval embeds the incoming user message and injects the top-K relevant memories into the system prompt, tracking token usage while it does so. The 0.92 threshold is the interesting number: it is aggressive enough to merge near-duplicate facts and loose enough that paraphrases will still accumulate.

Installing 7/24 Office: examples, not a package

There is no pip install for this project. The README does not document one, and the repository layout confirms it: the top level holds Python modules directly, alongside config.example.json, docker-compose.example.yml and Dockerfile.example. The .example suffix is the instruction. You copy the examples, fill in your own values, and run the entry point.

The README documents the module names but gives no command lines, so the commands below are the obvious invocation of the files that exist at the repository root. Nothing beyond the file names is asserted here.

python xiaowang.py

That starts the entry point described in the README as an HTTP server with callback handling, debounce and media download. For a multi-user deployment, the README describes router.py as the process that auto-provisions containers, reconciles missing ones from the routing table on startup, and health-checks them.

python router.py

A first real use is a scheduled task. The README describes cron scheduling with one-shot and recurring tasks, persistence across restarts, timezone awareness and an inactivity guard that skips cron work for users dormant beyond a three-day threshold. The scheduler is driven through the agent's own tools rather than a separate CLI, so the first useful check is whether the tool list loads at all and whether the nudge system reports unused tools. If the agent answers a scheduling request without calling the scheduler, nudge.py is the component to inspect first.

Runtime tool creation is the risk you are accepting

The README lists runtime tool creation plainly: the agent can write, save and load new Python tools at runtime through create_tool. Combined with exec in tools_admin, this means the process can produce and then execute code. That is the whole point of a self-evolving system, and it is also the reason this project belongs on a machine you are willing to lose.

There are mitigations in the design, and they are worth naming precisely. A circuit breaker disables tools after three consecutive failures per session, which limits a broken tool from being retried forever. Session auto-archiving writes a daily black box recording of all conversations, so there is an audit trail after the fact. Self-repair runs a daily self-check with session health diagnostics and error log analysis, notifying on failure. None of these is a sandbox. The README does not describe resource limits on generated tools, a review step before loading, or a permission model for exec. The container boundary is the boundary.

A second limitation is operational: the README documents no releases. There is no version to pin, no changelog to diff, and no upgrade path other than reading commits. For a single-operator deployment that is tolerable. For anything with a change-control process, it is disqualifying. The repository's own answer to this is the successor, xiaowang-v2, a Node rewrite in the xiaowang-v2/ directory that the README describes as converging rather than expanding, with durable cross-day execution, layered memory with honest forgetting, turn assembly for burst messages and photo-then-caption input, and structural instruction following. Design blueprints and 330+ offline selftest assertions are included, and the README states the docs are in Chinese.

How it compares with framework-based agent stacks

The obvious alternative is an orchestration framework such as LangChain, which the README names directly as something this project avoids. The difference in approach is concrete. A framework gives you pre-built abstractions for chains, retrievers and tool calling, plus a community and a release cadence. 7/24 Office gives you the loop itself, written out, with the memory compression, deduplication threshold and prompt budget in files you can open. Debugging a token blowup means reading llm.py, not tracing through three layers of callbacks.

The cost is everything the framework would have provided. You get no plugin ecosystem beyond MCP, no hosted tracing, and no upgrade path. The project does support MCP servers over JSON-RPC via stdio or HTTP with auto-reconnect and hot-reload, which softens the ecosystem gap for external tools specifically. A second alternative is the project's own successor: xiaowang-v2 is a single Node process with a single WAL SQLite database and a hand-written agentic loop, running 24/7 over WeCom as a personal agent. The README frames the difference as growth by adding tools versus convergence on durable execution, honest forgetting and deterministic harness guarantees. If you are starting today rather than studying the design, the successor is the more current codebase, with the caveat that its documentation is in Chinese.

Licence, maintenance and what an upgrade costs

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the extent of what the repository states; it is not legal advice and the LICENSE file is the authority.

Maintenance is a real consideration. The last push to the default branch was on 2026-07-31, and the README describes the project as production-running across multiple users. There are no retrieved releases, so there is no versioned artefact to depend on. An upgrade means pulling the default branch and reading the diff, which for a system with runtime tool creation and a persistent scheduler is more than a routine operation: scheduler state and memory files live outside the code, and the README does not document a migration procedure for either.

The successor arrangement adds a maintenance question of its own. Two codebases now exist in one repository, one Python and one Node, and the README presents the Node rewrite as the next generation. Anyone adopting the Python version should decide deliberately whether they are maintaining it or reading it, because the project's own documentation points forward rather than back.

Editorial conclusion

Adopt 7/24 Office if you want to read a complete, framework-free agent implementation and are willing to stand up Docker, a messaging callback endpoint and an OpenAI-compatible API key yourself, and if you accept that the repository ships examples rather than releases. Do not adopt it if you need a supported package, a versioned upgrade path or documentation in English for the successor codebase, because the README states the v2 docs are in Chinese and the repository has published no releases. Before committing, verify what config.example.json expects for your messaging platform, check whether xiaowang-v2 already covers the features you need, and read the runtime tool creation path in tools.py closely, since an agent that writes and loads its own Python tools is the decision you are actually making.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. wangziqi06/724-office on GitHub