ENGINEERING CASE STUDY
A Windows application built around local tools, saved work, and AI. This is the longer account of what was built and how the pieces fit.
I directed the product and reviewed the work. AI carried out the implementation described here. See the decisions I guided.
THE WHOLE APPLICATION
These parts were built across several releases.
The testing notes below explain their recorded status.
Projects have their own saved chats and working context. Conversations can be named, pinned, moved, archived, searched, and branched without replacing the original.
Images and documents can be attached to a request and previewed locally. A project file library lets you choose which reference material belongs in a conversation.
The local agent handles file operations and permitted processes. Work is tracked as tasks and steps, with attempts, checkpoints, results, and failure state saved along the way.
Mojow includes one shared WebView2 browser. The user can see the same page the tools operate on, along with the current AI action and recent activity.
The Windows interface brings the agent, tunnel, connections, and activity into one place. Separate conversations have their own identities and ownership instead of each needing another service or browser.
You can keep writing while a reply runs, queue follow-ups, and come back to saved work. Recovery is designed to preserve the newer conversation instead of replacing it with an older backup.
A feature existing in the app and that feature being available through the new AI command system are separate things. The app already has these broader areas; the shared AI controls are being added in stages.
HOW IT DEVELOPED
A few milestones from the project records.
This isn't a complete changelog.
Local tools, the Windows control center, logical chat identities, a shared embedded browser, task tracking, the execution loop, and the application contract. These established the underlying system that the workspace uses.
Project-specific conversations, imported history, context search, saved-chat organization, and the move to the personal Codex backend. The combined release installed the context work; some full interface acceptance remained open.
Attachments and previews, saved prompts, branching, bookmarks, backups, message queues, reference files, change review, project memory, search, and continue-work notes were added through several installed updates.
Normal questions and guarded code work joined the same chat flow. A local chat API added send, results, and Stop. The first shared app-command group then brought state queries and saved-chat controls to both native AI and the local client.
A CLOSER LOOK AT RECENT WORK
Four examples from the conversation and API work.
These explain the app; they don't run it.
For this example, the request names one file in a test project. Mojow reads it before editing and saves the build and test results afterward.
The app needs the actual build and test results before it can say the job passed.
The screenshot tour shows the actual interface with sample data. A separate recording of a real code change, test results, Stop, and saved-chat continuity has not been made yet.
TECHNICAL DETAILS
The Windows interface and the local agent have different jobs.
MCP and local APIs connect AI to those existing parts.
Native Codex chat Connected MCP clients Local command-line client
Browser actions go to the existing browser host. The new app commands go to existing application handlers. The model doesn't get a separate set of file or process permissions.
Conversations, project notes, backups, tasks, execution history, and operation results
Guarded file changes
Owned build / test processes
Conversation continuity
Strict schemas and revision checks
Durable command coordinator
Existing application owners
SOME OF THE HARDER PARTS
The early connection work had to separate a conversation's identity from its MCP transport session. A client could reconnect without that being permission to become a different owner. The application contract also had to use the existing process rules instead of creating another way around them.
The workspace added a different set of problems. A branch needs a new identity while keeping the useful history. Recovering a backup should not overwrite a newer conversation. An imported chat should not silently reuse someone else's tool ownership. Those decisions sit underneath the ordinary-looking chat controls.
Release work mattered too. Installed updates checked candidate file hashes and preserved saved chats, connection records, settings, and running services where the release allowed. A passing source build and a verified installed application were recorded separately.
Each request has an ID tied to its contents. Send the same request again and you get the saved result. Use that ID for different work and the app rejects it.
Stop targets the process belonging to that job and waits for cleanup. If a file was already changed, it stays changed. Stopping doesn't undo the edit.
Restarting doesn't automatically run an interrupted command again. The saved result lets you tell the difference between a finished job and one that stopped partway through.
TESTING
Based on the September and October 2026 project reports.
The product tests weren't rerun to build this page.
The reports cover individual releases, not one final test of everything. Earlier work includes installed updates, live checks, and tests against isolated builds. Those are kept separate here.
| Area | Recorded work and verification | Limits |
|---|---|---|
| Connections and browser September 16 | Logical chat connections reached live cutover. The embedded browser's AI activity and Pause controls have a live-acceptance record. | That milestone does not certify every website or later browser interaction. |
| Execution and application contract September 17 | The execution loop records step claims, attempts, failures and uncertain work. The application contract records final verification of registration and process ownership. | Source and isolated acceptance are not a claim that every separate application is installed or in use. |
| Context and combined release September 26 | 11 packaged regression suites passed; installed files matched the release manifest. Live context search responded, and an invalid Origin was rejected. | Full Context Pack interface acceptance and some browser and connection interactions remained open. |
| Saved-chat workspace September 27 | 30 organization checks and 10 lifecycle checks passed, alongside the recorded regression suites. Installed payload hashes and retained state were checked. | That release check did not issue a live model request. |
| Daily-use features September 28 | Installed reports cover attachments, previews, prompts, branching, backups, queues, memory and change review. The final comfort update records 95 workflow checks plus transport and UI smoke checks. | Counts overlap across updates and are not added together. Much of the UI evidence comes from isolated fixtures, not live screenshots. |
The local chat API report records 11 selected suites, a clean Release rebuild, and real installed acceptance. Cancelled requests did not add successful conversation exchanges. Cancellation after a write retained the partial change.
Source: MOJOW-LOCAL-CHAT-API-2026-10-23.md
The core report records 31 app-control checks across a 12-suite selected regression run. Installed acceptance covered API create/rename/select and native rename/deferred navigation. That does not establish live acceptance of every command.
Source: MOJOW-AI-APP-CONTROL-CORE-2026-10-23.md
Many of the app's controls already exist in the interface or older MCP tools. The current work is making them available through the same shared command system used by native AI and the local client. Connections, drafts, queues, applications, memory, browser and lifecycle adapters are among the remaining areas. Full app control is not finished.
This is a Windows desktop project. The portfolio screenshots use real controls with sample data. A verified API workflow shows a guarded edit, build/test results and conversation recall; desktop footage of live AI work is still pending. The acceptance reports distinguish automated, installed, and live behavior; static quality analysis still reports structural duplication and complexity findings. The call graph and history/churn evidence are incomplete. No customer adoption, performance improvement, or business outcome is claimed here.
The broader app-control project is unfinished. More existing controls need adapters for the shared command system. A live workflow recording and a final review of the portfolio remain before publication.
I set the product direction and design, guided AI with detailed prompts, and reviewed its progress throughout the work. AI did the implementation work described in this case study. Read about my part in the project.
Back to the project overview