Architecture — Lite on the Process GPT backend

Process GPT Lite is made of a screen (Vue) and a small relay server, and the real work is done by the Process GPT backend, left untouched. In this chapter you'll see the components in a single diagram, follow where one message and one document travel, and look at which model decides what.

A thin screen on a backend used as is#

In the previous chapter you opened an agent's working folder directly in the Workroom. In this chapter you step back further and see how that folder, chat and the editor are connected inside the server. This chapter is for the people who install and run it in-house, so component names and ports appear as they are.

Most of the features you've used so far weren't newly built for Lite. Agent runs, skills, the process engine, document generation and storage call the services of the open-source Process GPT without modifying them. Lite itself owns just two things.

So if you already run Process GPT, Lite simply adds one more screen on top of it, and when Process GPT gets better, Lite gets better with it.

Component diagram#

Browser / Android app (UI :5180)
  │  /api  /office  /craft
  ▼
Lite relay server (:8787)
  ├─ Chat ──────▶ context-router (:8895) ── which conversation?
  │                 │  └─▶ routing model (:8896) small model · embeddings
  │                 ▼
  │               deepagents (:8888) ── agents · skills ─▶ sandbox
  │                 │ MCP tools
  │                 ├─▶ office-mcp (:1192)  create documents
  │                 ├─▶ office-host (:5390) editor · live editing
  │                 ├─▶ mcp-hub (:8500)     connector registry
  │                 └─▶ Lite /mcp/*         connectors, folders, panel apps
  │                                         ArtCraft CLI (per user)
  ├─ Process ───▶ completion (:8099) + polling-service
  ├─ Workroom ──▶ cli-agent (:8890)  Claude Code · Codex
  ├─ Mining ────▶ process-miner (:8014)
  ├─ Improve      (relay server) lead time · bottleneck · critical path
  ├─ Storage ───▶ Supabase  Postgres · login · file storage
  └─ Schedule ◀── pg_cron ─▶ pg_net ─▶ /api/cron/fire

The path of one message#

When you send Make the Moonlight Coffee Store #2 budget sheet in Excel in chat:

1. Screen → relay server: the message is saved, and the reply comes back as a stream (SSE — the server pushes the text out a little at a time).
2. Shortcut decision: the relay server first uses rules to see where it should go. Requests to make a skill, a panel, a shared folder, an ArtCraft app or a document go straight to the agent. For everything else, a small model chooses: "Is it a browser task, a schedule, a handoff to a teammate, or work for the agent?"
3. Pick the conversation: in the main chat, it goes through context-router. The router narrows recent conversations down to 6 candidates or fewer and asks the routing model server, "Which conversation is this a follow-up to, or is it a new topic?" If confidence is low, it moves on to the next method (the language model's probabilities → a JSON answer).
4. Agent run: deepagents does the work with skills and MCP tools. For Excel, it runs code in the sandbox to make the file.
5. Card: the relay server finds the documents produced in this run, uploads them to file storage and attaches them to the conversation as file cards. Above the answer, a "↳ …" line shows which conversation it went to.

Long jobs like drawings or skills taking several minutes is normal. But if the agent doesn't send a single character for 15 minutes (PRO_STREAM_IDLE_MS), the relay server stops waiting and asks you to send it again.

The path of one document#

When you click a file card:

1. The screen brings up the IeumOffice editor at /office/<editor>/?src=… on the same origin. Excel opens in the sheets editor, Word in docs, and Hangul in hwp.
2. When the editor is ready, the screen opens a live connection to the relay server (a WebSocket opened with a one-time ticket) and reports "this person opened this document." Linked to the conversation appears in the header.
3. From then on, chat messages carry tools that edit the open document (office_live_*). These tools are visible only while the document is open and for a while afterward (30 minutes from the last message sent while it was open), because there's a limit (110) on how many tools an agent can use at once.
4. When the agent calls a tool, the relay server attaches that user's login token and passes it to office-host, which finds the editor open on that person's screen and edits it in place. The person watches the edits happen.
5. After editing, a review runs. It compares before and after (text length, tables and rows, formulas, the lines in pictures) to check nothing went missing, and leaves a short note (Chapter 9).
6. When the person saves, the edited copy is uploaded next to the original and the card points to the edited copy.

ArtCraft apps work the same way. The difference is that the app's CLI connects to a local port the relay server opened, and requests are passed to the app on the screen. Only the CLI process the relay server started can connect to that port.

Which model is called for what#

Calling a big model for everything is slow and expensive. Lite uses three tiers, depending on the kind of work.

The model address and key can be anything OpenAI-compatible (PRO_LLM_BASE_URL, PRO_LLM_API_KEY). Switch to an in-house model and the screens and flow stay the same.

In the next chapter you'll go through what to look after when running this setup in-house — teammates and roles, where the keys live, Vault encryption, backups and upgrades (Chapter 25).