# A platform for AI agents that handle long-running tasks: architecture and roadmap

> The initial design of a platform for AI agents: persistent tasks, local and cloud execution, permissions and the first planned applications.

- Published: 19 Oct 2026
- Updated: 26 Oct 2026
- By Rounak Zoeb
- URL: https://www.rounakzoeb.com/writing/ai-agent-platform-architecture-and-roadmap

---

I'm working with a co-developer on a platform for AI agents that can run tasks and maintain small applications. The initial design covers local and cloud execution, permissions and persistent state. This post explains the choices we've made so far and what we plan to build first.

The idea is a personal AI assistant that can run locally, in the cloud or both, and take on longer-running jobs rather than single chat sessions. Examples include a weekly research summary, monitoring an inbox, or a small app for managing engineering documents that an agent builds and keeps up to date. Its working title is AI App Builder.

> **Status, October 2026:** the initial design is drafted, and the core is in early development. The platform builds on my existing agent framework, [doc-processing-toolkit](https://www.rounakzoeb.com/work/doc-processing-toolkit), and tool library, [doc-processing-std-tools](https://www.rounakzoeb.com/work/doc-processing-std-tools).

## The first workflow: a document register

On engineering projects, a document register is the running list of a project's documents, such as drawings, specifications and reports, with their numbers, revisions and status. It's the first specialised application we plan to build.

Registers are part of engineering information management: keeping the information about a plant or other asset correct, complete and traceable, from design and construction into operation. A large project produces thousands of documents, and many go through several revisions. If the register falls behind the documents, it no longer shows which ones are missing, late or superseded. That matters most at handover, when the contractor has to show that every required document has been delivered.

Much of this work is still done by hand. The information is spread across a document management system, many spreadsheets, shared drives and email; document numbers and revisions sit in title blocks, cover sheets and file names; and each project's register has its own layout. The AI features that document management vendors have added mostly work on the data inside their own products, so keeping the spreadsheet registers in step with the documents is still clerical work for people.

General AI assistants, such as ChatGPT and Claude, can read a few documents in a chat and answer questions about them. A register asks for more: it covers more documents than fit in one conversation, it has to be kept current for the life of the project as new revisions arrive, every value has to be traceable to its source, and on many projects the documents can't leave the client's own systems.

The plan is to give the agent a folder of project documents and have it build a register application from them. A master document register, a transmittal register (what was sent to whom, and when) and a handover view would all be configurations of that one application. Each field the AI fills in would carry a value, a confidence score and a citation that opens the source passage. Low-confidence rows would go to a review queue, and corrections would be kept as training data.

Most of what that needs is in the software around the model. In the design, each document is parsed once into numbered blocks that keep their page and position, and the agent works through them a batch at a time, so the size of the document set isn't limited by how much text a model can take in at once (its context window). Choosing what goes into the model's context at each step, and in what form, is called context engineering. Here the model would see the blocks it's working on, the register's columns and the project's numbering rules, and little else. Each value it returns points to a block, so its citation leads to an exact place on the page without relying on the model to quote its source. Documents that haven't changed aren't read again. Different steps can use different models, and before a task starts, the platform checks which models the project's documents may be sent to.

This one workflow needs most of what the platform is meant to provide, which is why it's a good test of the design:

- The register is built across many documents and has to stay up to date, so it's a long-running task that must survive interruptions and pick up where it stopped.
- The result is an application with its own data, interface and version history, which people review and correct.
- Keeping it current means noticing when new documents arrive, without paying for a model call every few minutes to check.
- It works with project documents, so permissions and approvals matter, and each model call has a cost that should be recorded.

### Later workflows

After the register, we plan to add workflows that keep running in the background:

- monitoring a folder, a website, a data feed or a running process, and acting when something meaningful changes;
- monitoring an inbox, sorting what arrives and drafting replies for a person to approve;
- longer email tasks, where you forward the agent some documents, it emails you a question when it's unsure, and it carries on when you reply.

General assistants already offer scheduled tasks and connectors to other tools. In AI App Builder, each of these workflows is a persistent task with its own history, permissions and cost record, and its results can go into an application that people review. A monitor calls a model only when something has changed, and gives it just the context that change needs.

## Where it stands

On the roadmap, Stage 1 (initial design and architecture) is current, and Stage 2 (the core agent framework and security) is next. We plan to keep the code private until the first release.

The agent loop comes from my own framework, [doc-processing-toolkit](https://www.rounakzoeb.com/work/doc-processing-toolkit), with its companion tool library, [doc-processing-std-tools](https://www.rounakzoeb.com/work/doc-processing-std-tools). AI App Builder builds a more general-purpose platform on top of both. The framework sits behind an internal interface that can be augmented or replaced later (more on that under open questions).

As in my other projects, coding agents do most of the implementation, and I set the direction, review and sign off (how that works is in [Spec-first, test-first](https://www.rounakzoeb.com/writing/spec-first-test-first-building-with-ai-coding-agents)). The repository is being set up so agents can work from it directly, with repository knowledge as the system of record and architecture rules enforced mechanically: a short map file, a `docs/` folder as the source of truth, and plans checked in beside the code. Later we'd like agents to pick up tasks themselves from a task board, raise pull requests and review each other's work, along the lines OpenAI described in its [harness-engineering write-up](https://openai.com/index/harness-engineering/).

## Tasks and applications

A language model is like a car's engine. It provides the power, but on its own it doesn't take anyone anywhere. The rest of the car decides how that power is used: the steering and brakes, the fuel system, the instruments that tell the driver what's happening, and the safety systems that matter when something goes wrong. For an AI agent, the rest of the car is the harness: the tools it can use, the memory it keeps, the permissions it works within, the checks on its output, and the interface people use to steer it.

A more powerful engine in a car with weak brakes isn't safer to drive, and an agent built on a stronger model isn't more useful without a harness that can direct and check it. Most of our work on AI App Builder is on the harness. New engines arrive every few months, so the car has to take a more powerful one without being rebuilt: the provider layer lets us change models, and the tools, permissions, checks and cost limits stay in place whichever engine is fitted.

Two ideas sit at the centre of the design: persistent tasks and applications that agents build.

![User input becomes a task; an AI agent runs it across local, cloud or hybrid environments; permissions and cost controls sit in front of an execution environment of sandbox and tool connectors (MCP), which builds and updates generated applications; platform-wide monitoring spans everything](https://www.rounakzoeb.com/_astro/02_how_it_will_work.BCUiuNqc_1H4AWK.png)

*Proposed platform architecture. Design stage; the features shown are planned.*

A task is any piece of work the platform runs for you. A chat, a scheduled agent such as a weekly research summary, a monitor watching a folder and an email thread are all the same kind of object, so the same recording, checkpointing and resuming apply to all of them. Every fact about a task goes into one event log, which is the single source of truth.

Runs are designed to be durable. We plan to use DBOS, a library for durable workflows, on SQLite locally and Postgres in the cloud. Each agent step is a checkpoint, so an interrupted task resumes from the last completed step; the trade-off is that a step cut off part-way runs again from its start. When an unattended task needs a person's approval, the request is stored as a record, so nothing has to stay running in memory while it waits.

An application is something the agent builds and keeps for you. It has its own data, interface and version history, and it can be edited and shared. The agent can also create storage for an application, on the user's machine or in the cloud (on AWS, for example), within the limits its permissions allow. Examples range from simple tools, such as a research digest, to specialised ones like the document register. The design sorts every feature into one of three kinds:

- a small core capability of the platform;
- a thin, removable capability pack, such as email, voice or document registers;
- an application the agent builds.

A CRM (customer relationship management tool), a study helper and a register tracker are meant to be applications. If the agent can't build one of them, we'd rather improve the core than add bespoke platform code, because a special case would hide the gap. We use this check when reviewing proposed features, to stay true to what the product is for. The range of things it can do is meant to come from the applications agents build, while the platform itself stays small; each special case added to the platform would bring its own storage, interface and ways of failing for two people to maintain.

### How an application's interface is made

In generative UI, the model produces the interface as well as its content. There are roughly three kinds:

- **Pre-built components that the model chooses.** Developers build the cards, forms and charts, and the model decides which to show and fills them with data. This is safe and consistent, but limited to what someone thought of in advance.
- **An interface the model describes.** The model writes a structured description, such as a JSON layout of known components, and the application draws it. This is more flexible, but still limited to the set of components.
- **An interface the model writes.** The model writes the interface itself, as HTML, CSS and JavaScript, and it runs in a sandbox. It can produce any interface, but it's the hardest of the three to keep consistent, accessible and secure.

Most examples of the third kind, such as Google's generative UI research and Claude's artifacts, create an interface for a single answer. In AI App Builder an application is kept, versioned, shared and maintained by its agent over months, so its interface has to last.

AI App Builder is designed for the third kind, full generative UI. An application's interface is written by the agent that builds it and can take whatever shape the task needs, instead of being assembled from a fixed set of parts. We'll still provide about a dozen trusted components, such as tables, charts, forms, and document and citation viewers, because today's models do better work with them and they make small edits cheap. They work like driver aids for today's engines: they keep quality up while models improve. Each time a new model is released, an evaluation re-runs the same editing tasks and shows how much of that help is still needed. As with the rest of the harness, we're building the car for more capable engines than today's.

Full generative UI asks more of the platform than a renderer:

- Each application runs in its own sandboxed origin.
- Every version is kept, so a bad edit is one step from undone.
- You can point at part of the interface and ask for a change.
- Before a change is saved, the platform renders it at three screen sizes and checks it for errors, accessibility problems and calls the application isn't allowed to make.

The design isolates applications from each other and from the platform. Each one gets its own origin on a separate domain and runs in a sandboxed iframe with a strict content security policy. It reaches the platform only through a message bridge modelled on MCP Apps. (MCP, the Model Context Protocol, is an open standard for connecting AI models to tools and data; MCP Apps extends it to interactive interfaces.) An application doesn't hold API keys, it runs with the permissions of whoever is viewing it, and the paid calls it makes are metered. That's more set-up per application than running everything in one page, but the aim is to keep a faulty or malicious application away from other applications and from the user's credentials.

Versions are append-only, so undoing a change means pointing back to an earlier version. We considered leaving version history for later, but it's a major feature that makes a real difference to the experience, so it's in from the start.

## Local, cloud and hybrid

The platform is designed to run in three ways: locally on the user's machine, with local or hosted models; in the cloud; or hybrid, where one task uses both local and cloud resources. Different tasks can use different AI models.

The aim is to hand a task between environments where that makes sense, for example starting on a laptop and continuing in the cloud. In the design, one environment is in charge of a task at a time, and a handoff happens between agent steps, at the same checkpoints used for recovery, rather than in the middle of a step. The trade-off is that a handoff waits for the current step to finish. Processes move at checkpoints for now; moving arbitrary running processes is a later question.

## Permissions and costs

The design puts a policy layer in front of tool calls. It checks each call by risk and context, then allows it, refuses it or asks a person for approval. It fails closed: if it can't decide, the call doesn't go ahead. Low-risk reads would go through, while risky actions would wait for a person. Other parts of the design:

- file and code tools run in a sandbox, with outbound network access off by default;
- the model sees placeholders instead of secrets, and an outbound proxy swaps in the real values, so that credentials stay out of the model's context;
- a budget guard reserves money before each call and settles it afterwards.

Stage 2 is meant to build these alongside the agent runtime, so that no agent runs without the sandbox and permission checks.

Cost tracking is part of the design from the start. It records one usage row per API request, priced when the request happens and not re-priced later, so a past run keeps the cost it was charged at. Because a retry is its own request, it gets its own row; [The 6× gap](https://www.rounakzoeb.com/writing/the-6x-gap-logged-vs-billed-llm-cost) describes what happened when timed-out requests and retries were left out of my cost log. Traces are for debugging, a ledger is for money, and a hash-chained log, where each entry includes a hash of the previous one, is for audit. At first, any users will bring their own model API keys.

## Roadmap

The roadmap has five stages. The order is indicative and the stages can overlap; features such as voice and computer use may be developed alongside others. We've deliberately not put dates on it while the roadmap is still being tuned. The design work produced far more ideas for a first version than two people can build quickly, even with AI assistance, so the roadmap is ordered by scope.

![The five-stage roadmap: Stage 1 (now: initial design and architecture), Stage 2 (next: core agent framework and security), then persistent and hybrid execution; application generation and editing; and automation and initial applications.](https://www.rounakzoeb.com/_astro/03_roadmap.BIrDRx_7_Z22j8TN.png)

*Development roadmap. The sequence is indicative and may change as development progresses.*

| Stage | Includes |
|---|---|
| **1. Initial design and architecture** (now) | Product requirements and core workflows; initial architecture and technical design; the existing agent framework and tooling; the development and validation approach |
| **2. Core agent framework and security** (next) | The agent runtime and model selection; sandboxed execution and tool integrations; permissions, approvals and usage controls; execution history and cost tracking |
| **3. Persistent and hybrid execution** | Persistent task execution and recovery; local, cloud and hybrid execution, with task handoffs; desktop integration and computer use; voice input and output, and live interaction |
| **4. Application generation and editing** | Persistent applications with their own data; application generation and visual editing; version history, rollback and sharing; multi-user collaboration |
| **5. Automation and initial applications** | Scheduled agents, triggers and monitoring; agents with dedicated email inboxes, including external correspondence; meeting assistance; the first applications, for research, information monitoring and engineering document management |

A few decisions sit behind the order:

- Security comes before persistence. No agent should run without the sandbox and permission checks, so they're built in Stage 2, alongside the runtime.
- Monitoring means an agent watching something, such as a folder, a website, an inbox or a data feed, and acting when it changes. It's planned as a cost-saving design. A cheap, deterministic probe (ordinary code, with no model involved) would compute a fingerprint of whatever it watches, a short value that changes when the content does, and only a meaningful change would start an agent run. A folder watcher that called a model every minute would make 1,440 model calls a day. Some monitors will still need a model to judge whether a change matters, so the aim is to use one only where it's needed.
- Each agent will be able to have its own email address that you can cc, forward to or message. Correspondence with external contacts is planned to run within per-thread permissions and approvals, and the design treats their messages as data rather than instructions. Like the other policies, that has to be implemented and tested before it counts as protection against prompt injection, where text in a message tries to redirect the agent.
- Meeting assistance covers capturing information, summaries and follow-up actions. We're still working out the details of how it will work.
- We plan to end each stage with a test on real work, such as an interrupted task resuming where it stopped, or a prompt injection failing to reach a credential.

## Open questions

Some parts of the design will only be settled by building them:

- how far handoffs between local and cloud execution can go in practice (passing a task between the user's machine and the cloud while it's under way);
- which monitors can stay deterministic (checked by ordinary code, with no model call), and which will need a model;
- how meeting assistance should work;
- whether my own agent framework stays at the core. The design records when we'd replace it: if maintaining it costs more than it saves.

## Feedback welcome

I'll post updates as development progresses. If you work with engineering document registers, I'd like to hear which register tasks take up most of your time, since that's what the first application needs to get right. For any feedback or thoughts, please get in touch through the [contact page](https://www.rounakzoeb.com/contact).