7/24 Office: A 10,000-Line Python Agent That Writes Its Own Tools

The problem 7/24 Office solves is tool sprawl, not conversation

Most agent projects start with a chat loop and then bolt on capabilities. 7/24 Office starts from the opposite end. The README describes a system that grew by adding tools until it reached 36 built-in tools across seven domain modules, and the successor note says this explicitly: where 7/24 Office grew by adding tools, v2 converges. So the project is really an answer to a specific operational question. How do you keep a long-running personal agent from becoming a pile of scripts that each need their own deployment, their own restart, and their own failure handling? The answer here is a single process with a router in front of it, a tool registry inside it, and a scheduler that survives restarts. The audience is narrow and identifiable: someone running a personal or small-team agent against a messaging platform, willing to host it themselves, and willing to read Python to change behaviour. If you want a hosted product or a library you import into an existing service, the architecture is pointed the wrong way.

The tool-use loop, the nudge system, and what happens when the model ignores its tools

The core is llm.py, described as the Tool Use Loop using OpenAI-compatible function calling with automatic retry and up to 20 iterations per conversation. Around it sit two mechanisms that are more interesting than the loop itself. The first is the nudge system, five rules in nudge.py that auto-detect when the model has tools available but does not use them. That is a real failure mode in agent systems: the model answers from parametric memory instead of calling the function that would give it current data. A structural hint injected by the harness is a blunt fix, but it is a fix. The second is the circuit breaker, which disables tools after three consecutive failures per session. Combined with dynamic tool filtering across five context profiles (voice, scheduler, group, diagnostic, default), the design assumes that sending all 36 tool schemas on every turn wastes tokens and invites wrong selection. That assumption is reasonable and the mitigation is concrete. What the README does not give is the false-positive rate on nudges or the token savings from filtering. Treat both as design intent, not measured outcomes.

Three-layer memory: a 40-message window, cosine dedup at 0.92, and budget-aware injection

Memory is split into three layers with explicit thresholds. Layer 1 keeps the last 40 messages per session as JSON files, triggers compression on overflow, and auto-archives sessions larger than 100KB. Layer 2 uses an LLM to extract structured facts from evicted messages, deduplicates them by cosine similarity with a threshold of 0.92, and stores the results as vectors in LanceDB. Layer 3 embeds the incoming user message, runs a vector search, and injects the top-K memories into the system prompt under a token budget. The 0.92 threshold is the most opinionated number in the project. Set it lower and you merge facts that are merely related; set it higher and near-duplicates accumulate until retrieval returns three versions of the same preference. Because it is a named constant in the material, it is also the first thing to tune for your own data. The budget-aware injection is the second constraint worth noting: retrieval competes with the system prompt for context, so a large memory hit can crowd out instructions. The README describes tracking token usage during assembly but does not say what happens when the budget is exhausted.

Runtime tool creation is the feature that should make you pause

The agent can write, save, and load new Python tools at runtime through create_tool. This is the self-evolving claim in the title, and it is the sharpest edge in the system. A tool that persists across restarts is code execution with a memory. The README presents it as a feature alongside MCP plugins and hot-reload, with no stated sandbox, no review step, and no mention of a signing or approval gate. The successor note hints at where the author's thinking went: v2 lists approval gates and idempotency among the deterministic five that the harness should own, with the model doing only fuzzy routing. Read that as an admission that the v1 approach needed hardening. If you run 7/24 Office with create_tool enabled and the agent has exec, you have given a language model write access to its own tool directory on a machine that also runs your messaging integration. That may be acceptable on a dedicated host. It is not acceptable on a host with credentials you care about.

Getting it running: router, containers, and the config surface you actually touch

The entry path is router.py, which handles multi-tenant routing, auto-provisioning, group routing, and health checking, and which reconciles missing containers from the routing table on startup. Behind it, xiaowang.py runs an HTTP server for callbacks, handles debounce, downloads media, and tracks inactivity. The README's architecture diagram shows a Docker-based deployment with one container per user, which means the practical setup is: configure the messaging platform credentials, start the router, and let it provision a container for each user it sees. Two operational details matter more than the rest. First, the inactivity guard auto-skips cron tasks for users dormant for three days, so a scheduler that appears broken may simply be idle by design. Second, messaging API calls retry three times with 2, 4, and 8 second delays, which means a failing platform endpoint produces a 14-second stall before the error surfaces. MCP servers are connected through mcp_client.py over JSON-RPC on stdio or HTTP, with auto-reconnect and hot-reload, so plugin changes do not require a restart. The README does not list the concrete config keys or environment variable names, and I will not guess them. Read the source for the actual names before you write a deployment file.

Where it breaks: group chat, dormant users, and the successor problem

Three limitations are visible in the material. Group chat runs in an independent container with @-mention gating and a context buffer of the last 20 messages, which is a small window for a busy group and will drop earlier context silently. The inactivity guard is convenient but means scheduled work for a returning user does not backfill. And the largest issue is not technical: the README states that the next generation lives in xiaowang-v2, a single Node process with a single WAL SQLite database and a hand-written agentic loop, and that its docs are in Chinese. A repository that announces its successor in its own README is telling you where maintenance attention goes. That does not make 7/24 Office unusable. It makes it a fixed target. Fork it, read it, change it, and expect upstream to move elsewhere.

How it differs from LangChain-style orchestration

The README opens by naming what it avoids: no LangChain, no LlamaIndex, no CrewAI, just the standard library plus a few small packages. That is the real comparison. A framework like LangChain gives you abstractions for chains, retrievers, and tool calling, plus a large dependency surface and version churn that you inherit. 7/24 Office gives you a hand-written loop in llm.py, a hand-written memory stack in memory.py, and a hand-written scheduler in scheduler.py, all in roughly 10,000 lines you can read in an afternoon. The difference in approach is who owns the control flow. With a framework, the library decides when tools are called, how memory is retrieved, and how errors propagate, and you configure around it. Here, the nudge rules, the 20-iteration cap, the 0.92 dedup threshold, and the three-failure circuit breaker are all local code you can edit. The cost is that you also own every bug, every retry policy, and every migration. There is no plugin ecosystem to lean on beyond MCP.

Maintenance, licensing, and what to check before you deploy

The licence is MIT, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are retained. That is a permissive starting point for a fork, and it is the reason the successor-in-a-subdirectory arrangement is workable: you can keep using and changing v1 without asking anyone. It is not legal advice, and if you ship this inside a product you should have someone confirm the notice requirements. On maintenance, the material supports a clear reading. There are no retrieved releases, the last push is 2026-07-31, and the README directs future work to xiaowang-v2. Budget for reading the source rather than waiting for patches. The upgrade path, if you want one, is the Node rewrite, which is a different runtime and a different database, not a version bump. Before deploying, check three things in your own copy: that the messaging adapter targets the platform you run, that LanceDB backups restore cleanly alongside the JSON session files, and that create_tool writes only where you intend.

Editorial conclusion

Adopt 7/24 Office only if you want to read and modify the agent loop itself: the tool-use iteration cap, the nudge rules, the cosine dedup threshold of 0.92, and the 40-message session window are all in your hands, and the MIT licence lets you fork them. Do not adopt it if you need a maintained upstream or a stable plugin contract, because the repository states that the next generation lives in xiaowang-v2 and that its docs are in Chinese. Before committing, verify three things in your own checkout: that the messaging platform adapter matches the platform you actually run, that the LanceDB vector store survives your backup and restore procedure, and that create_tool cannot write outside the directory you intend it to use.

Official sources

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