~2MB to give your Android app WorkBuddy-like agent powers

WorkBuddy can draft Word docs and PPT decks, generate images, ship explainer videos, and generally finish messy productivity work. If you want the same class of capability inside your product, the usual story is a year of eng and another ~100MB on the install size. That is a hard sell for an app that already ships.

I built an open-source Android SDK that aims at a different tradeoff: after you integrate it, the package grows by roughly 2MB (when the host already has OkHttp, JSON, and similar commons; about +3MB from a clean slate; core alone is on the order of 1MB+), and the app can do WorkBuddy-adjacent work on device. Almost the same idea—open enough that you can extend it for your domain. I call it Agent1. The name is secondary; what matters is that it actually completes tasks on a phone.

Screenshots below are meant to build intuition, not to sell a chatbot skin.

Start with a Word file

Prompt: “Generate a business report as a Word demo.” The agent produces a .docx, then opens it in the built-in preview:

Select a paragraph such as “Quarterly overview” with your finger and say: “Make this font twice as large.” Watch the eye icon in the preview chrome—it toggles selection mode vs preview mode.

The model edits that span only; the page re-renders. Point, speak, change.

Turn a grade sheet into a flip-through dashboard

Drop a midterm Excel workbook in and ask for an analyzed report:

You can still point-and-edit, ask the model to redesign the page, then share it as a plain HTML file others can open.

Road trip planning without a second memo app

Prompt: “Build a 5-day Zhejiang self-drive guide—interactive page with route map and photos.”

Inside: a route map, tappable place names, swipeable full map:

Further pages: a packing checklist by day so you are not maintaining a separate note:

The roadbook is HTML—tappable and shareable. Same select-and-revise loop as the Word demo.

Video walkthrough of the roadbook (travel-roadbook.mp4) is in the repo and on the project site; not embedded here.

Education: a short relativity explainer

Prompt: “Generate a short video introducing relativity.”

Short relativity demo video (relativity-demo.mp4) is in the repo and on the project site; not embedded here.

Word, grade dashboards, roadbooks, and short films look like office / education / travel products. Underneath they share one orchestration path—not four unrelated plugins bolted together.

If you want to poke at it first:

• Repo: github.com/fengshihao/agent1
• Site: fengshihao.github.io/agent1
• Reference APK: v0.1.637 (no model key baked in; configure inside the app)

Install the APK on a phone, or use the desktop twin: ./agent1 / ./agent1 ui.

Integration is intentionally boring

Hand this to Cursor / Claude (or read the docs yourself):

Integrate the open-source project Agent1 (https://github.com/fengshihao/agent1)
into my Android app. Read README, AGENTS.md, and how android_agent wires
ProductivityAgentHost. Attach java-agent-core to my existing UI. Tell me which
dependencies to add and where the model key should live.

Local build path:

./publish-java-agent-core.sh
./build-android-agent.sh

android_agent is a reference host. Your product keeps its own screens.

Demos are the floor. Cloud-updated JS skills are the point.

If Agent1 only shipped the demos above, embedding it would be a fixed feature pack—not much of an agent. The real lever is the layer behind them: you (or the model) write JavaScript on the existing kernel and grow capabilities without hanging a new Java @Tool for every business scenario, and without a store release for every tweak.

Scripts and Skills are not stuffed into the APK by default.

Rough pipeline:

1. Stay out of the package — official packages, Skills, and capability catalogs are not shipped as one fat blob.
2. CDN distribute — place JS packages / Skills under a configurable CDN base.
3. Install on demand — when the model writes import … from "weizhi:<name>", the host installs the dependency before execution.
4. Run on device — Weizhi QuickJS executes in a sandbox; results land in the workspace or WebView.
5. Iterate — change the cloud artifact; later sessions pull the new version. ROM size and release cadence stop being the bottleneck.

Same pattern for your domain: orders, device control, internal document formats. Expose the APIs you already have as scriptable bridges, add a few Skills with call examples, and let the model compose them in the sandbox while you own the bridge and the index. Demos prove the pipe works; wiring your APIs sets the ceiling.

Architecture is one thin slice

Where does the code live? One comparison diagram is enough—this is not a second README.

One-sentence-to-artifact flow:

The Java layer stays intentionally thin: workspace I/O, script execution, clarification, retrieval. Editing documents, drawing, calling external services live in scripts and indexes, not in an ever-growing system prompt. That is why “about +2MB” is a real claim—the kernel does not ship a world encyclopedia of tools.

Without Weizhi you still get the kernel tools; with Weizhi you get the full script loop, MCP, and WebView. Details live in the repo and in Weizhi.

From “I want an agent that actually does work inside my app,” through “I refuse another tens-of-MB sandbox,” to “skills update from the cloud while the UI stays mine”—that is the path I am willing to show other builders.

Latest sample APK: v0.1.637

Repo: https://github.com/fengshihao/agent1

Site: https://fengshihao.github.io/agent1/

---