# 10xProductivity's architecture diagram runs through the three layers it marks Early

> A local-first personal assistant stack that drives your own coding agent and authenticated sessions instead of asking for a Slack app, where the manifest still says 0.1.0 behind a v1.1.0 tag, the installed wheel carries only runtime and triggers, and a commented line in requirements.txt proposes a bot avoidance package.

**ZhixiangLuo/10xProductivity** — Personal AI assistant for work inside corporate constraints, built on coding agents and the tools, sessions, and permissions you already have.

- Repository: https://github.com/ZhixiangLuo/10xProductivity
- Website: https://github.com/ZhixiangLuo/10xProductivity
- Stars: 478 · Forks: 55
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/zhixiangluo-10xproductivity

## The diagram's happy path runs through the three layers marked Early

The architecture sketch has two entry points and one destination:

```
Human
  ↓
Trigger or schedule          Laptop coding-agent session
  ↓                                   ↓
Runtime host                 Workflow / skill
  ↓                                   ↓
Workflow                     Tool connections
  ↓                                   ↓
Tool connections                     |
  ↓                                   ↓
Work done in Slack, Jira, GitHub, docs, calendar, CRM, internal portals, and more
```

A human reaches a trigger or a schedule on the left, or a laptop coding-agent session on the right, and both descend through a runtime host, a workflow, and tool connections before meeting at work done in Slack, Jira, GitHub, docs, calendar, CRM and internal portals. The status table says something the sketch does not. Of the seven layers listed, three are Available today, which are tool connections, enterprise search and agent skills. Three are Early, which are triggers, runtime and reusable workflows. One is Roadmap, which is learning and memory. So the left branch of the diagram, the trigger and the schedule, is Early, and the runtime host below it is Early, and the reusable workflows that step 4 tells you to trust are Early as well. The right branch, a supervised laptop session, is the path that needs only the three layers marked available today.

## The manifest has said 0.1.0 across two release tags

The packaging metadata names the distribution `tenx-productivity` at version `0.1.0`, while the repository is called 10xProductivity and the release history carries v1.0.0 from 23 April 2026 and v1.1.0 from 27 May 2026, described as a framework for automating workflows with coding agents and then as the personal assistant agent direction. So the newest tag is a minor version ahead of what the manifest declares, and v1.0.0 was cut while the manifest already said 0.1.0. Nothing in the tree ties a tag to a manifest version, and there is no changelog file among the top-level entries to reconcile them. The homepage recorded for the project is its own repository, and the third console entry point, `10x-standup-prep`, points at `runtime.scheduling.standup_prep:main`, which is the concrete form of the stand-up prep the status table calls an example that exists today.

## Two dependency lists, one set of carets and one set of pins

The manifest requires Python 3.11 or newer and declares five runtime dependencies with lower bounds: `playwright>=1.58.0`, `python-dotenv>=1.0.0`, `requests>=2.32.0`, `msal>=1.35.0` and `PyJWT>=2.12.0`, with `pytest>=8.0.0` in a dev extra. The requirements file declares the same five with exact pins, `playwright==1.58.0`, `python-dotenv==1.2.2`, `requests==2.32.5`, `msal==1.35.1` and `PyJWT==2.12.1`, and then leaves `pytest` unpinned on a line of its own. Playwright is the only package where the two files agree exactly. The Microsoft authentication pair, `msal` and `PyJWT`, is there for the tool connections rather than for anything else, which tells you where the credential handling lives. Tests are configured to run from `tests` with quiet output as the default, so the suite is meant to be run without arguments.

## A commented line in the requirements file proposes a bot avoidance package

Under the heading for optional packages, the requirements file carries two commented lines: `pip install playwright-stealth`, described as improving bot avoidance for browser sessions. That is the project's own suggestion that a browser session can be made harder for a site to recognise as automated. The stated principle everywhere else is that no new company-wide automation platform, no admin-approved Slack app, no webhooks and no IT project are required, because the local coding agent acts as you using access you already hold. Both statements are true at once, and the combination is the part to think about. Reusing your own session means the requests carry your credentials and your cookies, and nothing about that is visible to the organisation as a new integration, which is convenient for access and unhelpful for anyone who later needs to know what automation ran. The named surfaces are ordinary enterprise ones, Slack, Jira, GitHub, Confluence, Google Drive, Outlook, Salesforce and internal portals, and the project insists any of them can be reached through an API, a CLI, a browser surface or local files. The trigger examples are modest in the same spirit, a Slack self-DM poll or a desktop notification, and the scheduling route is a plain cron or launchd job rather than a hosted scheduler.

## The installed wheel carries runtime and triggers, not the connections

The manifest declares three console entry points, `10x-host` at `runtime.host:main`, `10x-reply` at `runtime.replies:main` and `10x-standup-prep` at `runtime.scheduling.standup_prep:main`, and the packaging section includes only `runtime*` and `triggers*`. Everything else at the top level is repository content rather than an importable package: `tool_connections/` with the agent-readable setup guides, `workflows/`, `hooks/`, `personal/`, `colleagues/` and `staging/`. The consequence is that a pip install gives you the host, the reply path and the trigger machinery, while the layer the status table calls available today, the pre-built recipes for 25 or more tools, arrives as files in a clone. Three similarly named directories, `personal/`, `colleagues/` and `staging/`, sit side by side without a note saying which one a given machine should read. The project is candid that the runtime is deliberately thin and local: triggers notice events, the runtime handles execution mechanics, workflows define the work, and tool connections fetch or update external systems, with automation reserved for workflows already trusted and everything else left in the human and AI loop. Cursor, Claude Code and Codex are named as the sessions that do the supervising, which is why agent configuration for two of them is committed at the root.

## The env sample is named env.sample while the loader looks for .env

`python-dotenv` is a declared dependency and the requirements file describes it as env file loading, and the repository ships a file called `env.sample`. The conventional name the loader reads is `.env`, so the first thing a new user does is copy one name to another, and the project does not say so anywhere in the visible instructions. `verified_connections.example.md` sits at the top level as the template for a connection that has been checked, which pairs with the two setup guides, `setup.md` and `setup-python.md`, and the contribution guide for adding a tool, `add-new-tool.md`. `LEGAL_NOTICE.md` is also at the root, next to the MIT license, and the `.claude/` and `.cursor/` directories put agent configuration for two specific coding agents in version control rather than in a user directory.

## Step 5 describes a roadmap item in the present tense

The last numbered section is titled Learn Continuously, and it describes two loops as things that happen. One scheduled loop reviews recent work, what the agent tried, where it got stuck, which tools and skills it used, what the human corrected and what patterns repeated, and turns sessions into persistent memory. Another loop broadens capability by following a guided learning skill and testing the result. The status table calls that same layer Roadmap, planned but not complete. So the document describes the intended end state in the same voice as the three layers that exist, and a reader skimming for capability will overcount by one layer. The file also carries its small roughness: the heading Star History appears twice in a row, and the final line of the last section stops mid-word at the phrase about producing evidence that the capability w

## Conclusion

Read this as a design document with a working core, not a product with a release train. The honest summary of its own status table is that tool connections, enterprise search and agent skills exist, triggers, runtime and reusable workflows are Early, and learning and memory is on the roadmap, yet the architecture diagram is drawn entirely through the Early layers and step 5 describes the roadmap item in the present tense. Two things to check before building on it. The manifest version has been 0.1.0 across two tags, so nothing identifies a build. And the whole premise is that no new infrastructure and no new approval are needed, which is true and also means the audit trail is your own browser session: the requirements file's commented line about improving bot avoidance for browser sessions is the one place the project points at working around a site's defences, and that is worth a policy conversation before an employer finds it. The last commit on main is dated 13 July 2026.

## FAQ

### What does 10xProductivity actually have available today?

Three layers: tool connections with pre-built recipes for 25 or more tools plus a playbook for internal tools, enterprise search across Slack, Confluence, Jira, GitHub, Linear and Notion, and packaged Cursor and Claude Code skills. Triggers, runtime and reusable workflows are marked Early, and learning and memory is on the roadmap.

### How is 10xProductivity installed and what does it expose?

It is a Python 3.11 or newer project with three console entry points, 10x-host, 10x-reply and 10x-standup-prep, and the packaging includes only the runtime and triggers packages. The tool connections, workflows, hooks and personal directories ship in the repository rather than in the installed distribution.

### Which Python dependencies does 10xProductivity need?

The manifest sets lower bounds on playwright, python-dotenv, requests, msal and PyJWT, with pytest in a dev extra. The requirements file pins the same five exactly and leaves pytest unpinned, so only playwright matches between the two declarations.

### How does 10xProductivity connect to workplace tools without an app registration?

By using the coding agent and authenticated sessions the user already has, across Slack, Jira, GitHub, Confluence, Google Drive, Outlook, Salesforce and internal portals, with agent-readable setup guides in tool_connections/. The requirements file also carries a commented line about installing playwright-stealth to improve bot avoidance for browser sessions.

## Sources

- [License: MIT](https://github.com/ZhixiangLuo/10xProductivity/blob/main/LICENSE)
- [Project website](https://github.com/ZhixiangLuo/10xProductivity)
- [README](https://github.com/ZhixiangLuo/10xProductivity/blob/main/README.md)
- [Releases](https://github.com/ZhixiangLuo/10xProductivity/releases)
- [ZhixiangLuo/10xProductivity on GitHub](https://github.com/ZhixiangLuo/10xProductivity)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zhixiangluo-10xproductivity