Architecture

The whole system is one Worker, five Durable Objects, three API clients, and a container that only wakes up when a task needs it. This page maps what each piece owns and where the seams are.

The edge

Every Discord event arrives at a single Worker route. The Gateway Durable Object holds the WebSocket to Discord and forwards events as HTTP requests, so the rest of the system never touches a gateway connection directly.

The webhook returns quickly. Message handling continues in ctx.waitUntil, so Discord does not wait on a model call. The only work that blocks the response is de-duplication and the decision to accept the event.

Durable Objects

ConversationDO is the only shared state in the text reply path. That is deliberate: extraction, nightly consolidation, and the memory commands all read or write the same rows, and a single object gives them one transaction boundary. The task agent keeps its own conversation history per channel; it reads the channel log only through the prompt it receives.

The SQLite schema

Two tables are present but not load-bearing today: summaries is read by the reply context if a row exists, but nothing writes one yet; episodes is reserved. They are noted here so a reader does not mistake them for an active feature.

The model and tool boundary

The bot uses three external services with different jobs.

Vercel AI Gateway is OpenAI-compatible and generates text: the chat reply, the memory text, the diary line, and the style proposal. Model IDs live in src/models.ts and can be overridden with CHAT_MODEL and DECIDE_MODEL. Chat calls default to a 30-second timeout.

Jev is a decision model. It never writes prose. JevClient asks for one of three typed answers over POST /systemone:

Jina provides the task agent's web tools: Search for web_search and Reader for read_page. Each result is capped at 8,000 characters and each call has a 30-second timeout. The endpoints are overridable with JINA_SEARCH_URL and JINA_READER_URL.

A failed call is a normal branch, not an exception. Each caller decides what to do without it: reply with text, use the default stamp, skip the reaction, record no correction, or leave memories untouched.

The task agent

When Jev says the request is a complex task, the Worker hands it to TaskAgent instead of the chat model.

• The agent is a Think object from the Cloudflare Agents SDK, one session per channel. buildTaskPrompt gives it the last ten lines of the channel and the request, including who asked.
• The persona core and the active style layer are re-injected on every turn through the beforeTurn hook, the same way the text path does it.
• The agent can call three tools:

The container starts on demand with internet access and stops after five minutes of inactivity. The model chooses the commands; the container holds no credentials. /workspace keeps files for as long as the container runs, and each channel has its own agent and container.

When the turn completes, the agent's text is posted as one Discord message. If the turn fails or returns no text, runTask returns null and the normal text reply runs instead.

Scheduled work

There are two nightly jobs, and they are intentionally not the same mechanism.

The alarm is rescheduled in a finally block, so a failed run still schedules the next night. The Cron job is independent; a failure in one does not move the other.

Deployment topology

There are two Workers in this repository, with separate deploy paths and separate lifecycles.

The docs Worker is assets-only. It has no Durable Objects, no bindings, and no runtime secrets, so a docs deploy cannot affect the bot. See Deploy and operate for the build and apply steps.

Failure posture

The guiding rule is that optional work must not take down the reply. A reply may be missing when the chat model itself fails, but a reaction, memory, probe, or task failure does not remove a reply that was already produced.