AI App Builder

Status, October 2026: the initial design and architecture are drafted, and implementation is in its early stages.

What it is

A co-developer and I are building a personal AI assistant for long-running tasks. It’s meant to run locally, in the cloud or across both, and to take on jobs that last longer than a single chat session: for example a weekly research summary, monitoring an inbox, or a small app for managing engineering documents that an agent builds and keeps up to date. AI App Builder is the working title.

That last example is the first specialised application we plan to build. An engineering-document register keeps track of a project’s documents and the key details of each one. In the planned version, an agent builds the register over a set of project documents and keeps it current, and each field it fills in links back to its source, so a person can check the value.

More generally, the platform is meant to pick an AI model to suit each task, and to host applications that agents create, maintain and update over time, each with its own data, interface and version history. Those range from simple tools, such as research summaries and inbox monitoring, to more specialised applications for issue and document management and data processing. In the design, the agent that builds an application also writes its interface, so the interface can take whatever shape the task needs, and about a dozen trusted components, such as tables, charts and document viewers, help today’s models do that well. Agents will also be able to run scheduled tasks and, later, join meetings to help with summaries and follow-up actions.

What’s planned

The roadmap has five stages. The order is indicative and the stages can overlap; voice and computer use, for example, may be developed alongside other work. We haven’t attached dates to them.

1. Initial design and architecture (the current stage): product requirements and core workflows, the architecture and technical design, how the existing agent framework and tools fit in, and how development and validation will work.
2. Core agent framework and security (next): the agent runtime and model selection, sandboxed execution and tool integrations, permissions, approvals and usage controls, and execution history with cost tracking.
3. Persistent and hybrid execution: tasks that can recover after an interruption, running locally, in the cloud or across both with handoffs between them, desktop integration and computer use, and voice input and output.
4. Application generation and editing: persistent applications with their own data, generated by agents and edited visually, with version history, rollback and sharing, plus access controls and shared workflows for multi-user collaboration.
5. Automation and the first applications: scheduled agents, triggers and monitoring; agents with their own email inboxes that can correspond with users and outside contacts, subject to permissions and approvals; meeting assistance, such as summaries and follow-up actions; and the first applications for research, information monitoring and engineering document management.

We’d like tasks to move between local and cloud resources smoothly, without the user having to stop and restart them. We’re starting with handoffs at checkpoints between agent steps; moving a process while it’s running is a later question.

A platform for AI agents that handle long-running tasks: architecture and roadmap goes through the design and each stage in more detail.

Design principles

These principles shape the current design. They describe how the platform is meant to work once it’s built.

• The core stays small. Each feature is either a core platform capability, a thin add-on capability pack, or an application that an agent builds on top.
• Tasks persist and can resume. A chat, a scheduled agent and an email thread are all the same kind of task. Each agent step is recorded, so an interrupted task can pick up where it stopped.
• Applications are sandboxed. Each one runs in its own sandboxed frame without holding credentials. Versions are append-only, which keeps rollback cheap.
• Actions are checked against permissions. Under the proposed policy, an action is allowed, refused or sent for approval depending on its risk, and credentials are kept out of the model’s context. The details of this policy are still being worked out.
• Costs are tracked from the start. Usage is recorded for each request and priced at the time it’s made.
• Agents aren’t tied to one model or provider. doc-processing-toolkit provides the agent loop, so a task can continue on another model or with another provider, and doc-processing-std-tools provides the standard tools.

How it’s being built

The platform builds on two of my existing projects: doc-processing-toolkit, an agent framework, and doc-processing-std-tools, a library of standard tools for agents. We’re building a more general-purpose AI application platform on top of them.

We use AI coding agents (Claude Code, Codex and GitHub Copilot) for implementation, as I do on my other projects; there’s more on my process in Spec-first, test-first. We also plan to set up a task board for the project, where agents can be assigned tasks or pick them up themselves and then raise pull requests, along the lines OpenAI described in its harness-engineering write-up.

What’s next

The next priority is the core agent runtime, with sandboxing, permissions and cost tracking built in from the beginning, so that those controls are in place before agents do real work. Persistent and hybrid execution come after that, followed by the first applications.

The code will stay private until a first release. We’ll update this page as development progresses.