An AI-assisted workspace for
development and automation.
A tool I use myself while developing and testing software. It helps with code and debugging, carries out technical research, automates repetitive workflows, and keeps the information those tasks produce in one place. It runs on a single device under controlled, task-oriented flows, with human confirmation before anything consequential. This is an evaluation build, not a public or commercial service.
The direction
Computers got an agent. Phones got a remote control.
On a desktop, an agent can read files, run commands, drive a browser and report back. On a phone — the computer most people actually carry all day — the same work still means tapping through screens by hand, or waiting until you are back at a laptop. The phone already has the sensors, the apps, the sessions and the network. What it has lacked is an agent that can genuinely operate it.
Put the agent on the device, not on someone's server
The interesting work is not another chat window. It is a phone that can be told “do this” and then actually does it: open the right app, fill the form, export the file, verify the result and report back. Running locally, under your own account, with no third party sitting in the middle of your data.
A body for the model
Screen state, browser control, system interfaces, app launching. The agent needs to see what is on the device and be able to change it — otherwise it is only talking about work instead of doing it. Partly built
Work that continues when you look away
Long tasks handed off, progress visible, results waiting when you come back. This is the difference between a tool you operate and a colleague you delegate to. Not built
One thread across apps and devices
A task rarely lives inside one app. Phone, tablet and desktop under a single queue, with the context carried along, is the shape this ends up taking. Not built
Overview
A task executor for my own dev work
I describe what I need in plain language. The tool decides what has to happen, picks one registered capability, performs the action, then reads the state back to check it actually took effect. The report is the by-product; the action is the product.
Internal first — external next
Built first for my own development and testing, and that is the only use today: no external users yet, no customers, no public sign-up. The direction is to hand the same workflow to other individual developers once it is stable; multi-user access is not implemented yet.
Human oversight by default
Each request resolves to exactly one of three branches: execute, ask for confirmation first, or ask which target is meant. Anything that changes device or external state waits for a human decision instead of guessing.
Where it helps
Run it, read the error, adjust
Scripts are executed in a real Linux userland on the device; error output is read back, the command is adjusted and re-run, and the result is verified rather than assumed. Used for small utilities, data wrangling and reproducing faults. Implemented
Read the actual page, not a snippet
A background browser fetches documentation and issue threads, extracts text and tables, and can reuse an existing session for pages behind a login. Runs without taking over the screen. Implemented
Multi-step chains that survive a restart
Tasks arrive through a message queue persisted to disk, so a restart does not lose the backlog. Chained steps include file conversion and media handling. Scheduling and proactive runs are deliberately not enabled. Implemented Scheduling: planned
Results kept where I can find them
Outputs, page extracts and run records are written to local notes and reused in later steps. A searchable index across runs is not built yet, so retrieval is still file-based. In progress
Architecture
Logical architecture. Each numbered surface maps to an entry in the capability registry; the registry — not free-form reasoning — is the entry point for execution.
Capabilities & status
| Capability | Status | Evidence / note |
|---|---|---|
| Natural-language task intake | Implemented | Local message bridge; the queue is written to disk and survives a restart. |
| Task orchestration & capability routing | Implemented | JSON capability registry, 17 registered entries; routing is deterministic rather than improvised. |
| Script execution for code work | Implemented | Python and Node scripts run in a Linux userland on the device; output and exit status are read back. |
| Fetching technical documentation | Implemented | Background browser, protocol-level control, text and table extraction; no foreground takeover. |
| Session reuse for logged-in pages | Implemented | Reads httpOnly session cookies at the protocol layer: 99 cookies across 28 domains measured, ~0.17 s per read. |
| In-page evaluation (including frames) | Implemented | Resolves the target frame's execution context, then evaluates inside it. |
| Page capture for later reference | Implemented | 3/3 captures, 68–70 KB valid PNG, OCR-verified content. |
| UI inspection & coordinate actions | Implemented | Screen-level fallback independent of the browser stack; 168 KB real hierarchy dumps. |
| File / media conversion in workflows | Implemented | Format conversion and delivery of results back to the chat thread. |
| Health state machine & self-recovery | In progress | States: ready / degraded / recovering / failed. 48-minute soak green; the 24-hour criterion is not met. |
| Long-run stability of the browser layer | In progress | Reached 9.5 h clean, then a zombie state appeared (process alive, service not listening). Two root causes identified; fix pending. |
| Searchable index of past results | In progress | Retrieval is file-based today; no cross-run index yet. |
| Scheduled / proactive runs | Planned | Passive-response only by design; proactive execution is deliberately not enabled. |
| Multi-user or team access | Planned | Single-user by design. No tenancy model, no isolation between operators. |
| Installable distribution | Planned | Evaluation build only; no packaged build for third parties. |
Evidence
Measured, not simulated — 49 samples taken from the 48-minute soak (48.4 min of wall clock). Process memory went from 138.6 MB to 131.5 MB (range 124.9–139.3), recovery generation stayed constant at 1, and no unintended rebuild occurred. Source data: the run's own CSV log.
| Test | Result | Verdict |
|---|---|---|
| 48-minute soak with repeated navigation | 49 samples. Recovery generation stayed at 1 (zero false rebuilds). Memory 138.6 → 131.5 MB (range 124.9–139.3), i.e. no upward trend. States: 39 ready / 3 degraded / 7 recovering. Injected crash escalated to failed, then recovered on the next task. | Pass |
| 24-hour soak | 9.5 h clean. At t≈34 200 s the service stopped listening while the process stayed alive; roughly 11.4 h of the window then measured an unavailable system. | Fail |
| Defects found during first real deployment | Three self-detected and fixed: a URL-encoding misjudgement causing a reload storm, a recovery counter that prevented convergence, and a non-idempotent recovery callback flooding state. | Fixed |
| Browser navigation failing on all sites | Root-caused to a request-line fragment leaking into the URL; fixed in source, rebuilt, reinstalled, re-verified on three sites. | Fixed |
| Background survivability | Scheduler-registered job survives a forced kill; priority class improved from cached to top-app level; wake lock bounded to 60 s; idle CPU 0.0 % over 30 min. | Measured |
Security, data handling & limitations
What is enforced today
- No root. Actions run through a shell granted at uid 2000 — the same ceiling a normal shell has.
- Confirmation gate. Anything that changes device or external state waits for an explicit human decision.
- No cloud backend. Task queue, session state and outputs stay on the device.
- No confidential data. No personal identity documents, no customer records, no proprietary third-party code are processed through the model.
- Verification over assertion. Reporting success requires reading the state back.
What is not there yet
- No capability sandboxing. Registered capabilities share one execution context.
- No per-capability rate limiting and no exportable audit log.
- No encrypted-at-rest store for on-device session data.
- No third-party security audit. This project does not claim to be audited or “fully secure”.
- Single-user, single-device. No isolation between operators, because there is one operator.
Development status
| Date | Milestone | State |
|---|---|---|
| 2026-09 | Task-routing layer retired; execution moved to direct agent operation over a persistent message queue. | Done |
| 2026-09-30 | Browser substrate stabilised: navigation root cause fixed, background operation toolkit added, app-level keepalive registered with the OS scheduler. | Done |
| 2026-10-01 | Health state machine deployed; three deployment defects found and fixed; first 48-minute soak passed. | Done |
| 2026-10 | 24-hour soak exposed a zombie-state defect (process alive, service not listening). Two root causes identified; fix and regression test in progress. | Open |
Roadmap
| Horizon | What it means | State |
|---|---|---|
| Now | Make “process alive” distinguishable from “service usable”: expose a listening-port signal in the health output, remove the self-reinforcing restart loop, then re-run the 24-hour window from zero. | In progress |
| Next | Widen the tool surface for development work: download handling, parallel tabs for research, and a searchable index over past results so earlier work is reusable instead of forgotten. | Planned |
| Later | Opt-in scheduling, so a task can be queued for later rather than fired by hand; and a single queue spanning more than one device. | Planned |
| Horizon | The phone as the agent's body: every app reachable as a capability, tasks delegated rather than tapped, and the same agent present across the devices a person actually uses. | Vision |
Intended use & compliance
- Personal evaluation today. This is a tool an individual developer runs on their own device. It is not offered as a public or commercial service today, and there are no external customers or public sign-up. Handing the workflow to other individual developers is the direction, not a current offering.
- Intended users: the developer today, other individual developers later. The only operator at this stage is the developer who built it.
- Task-oriented and controlled. Work is expressed as discrete, reviewable tasks; actions that need confirmation stop and wait for a human.
- No confidential inputs. No personally identifiable information, no proprietary or licensed third-party source code, and no sensitive user data are submitted or published.
- Policy compliance. Intended to be used in line with the applicable usage policies and security requirements of the model provider.
- Honest limits. Pre-release, not audited, not a promises-about-uptime product. Status labels on this page reflect that.
Contact
li4535087@gmail.com
This is a personal project without a support desk, so there is exactly one contact address and no invented alternatives: li4535087@gmail.com. Reviewers can ask through it for the source, redacted run logs or screen recordings.
The project's public reference page
This page exists as the public reference site for the project, so its claims can be checked against a real, reachable page rather than a description. Source and redacted run logs are available to a reviewer on request.