Flue
Flue 2.x boundaries, verified sources, and Slack agent architecture on Cloudflare
Where Flue Fits
Flue is the conversation-scoped agent execution layer in this architecture. A conversation has a stable instance identity, accepts messages from application code, and keeps its own durable agent history. Channel packages provide verified provider ingress that application code mounts explicitly. Those framework responsibilities are documented in Flue's tagged durability guide and channels guide.
For this site, that makes Flue a good boundary for receiving a Slack delivery, selecting a tenant-aware conversation, and running a narrowly tooled agent. The existing Worker Backend and Events sections remain the source for Slack request verification, acknowledgement, and transport mechanics.
Architecture boundary
Flue is not the canonical store for business records, Slack OAuth installations, or Slack List ownership. It is also not an arbitrary durable filesystem, a sandbox/file persistence guarantee, or a general workflow database. Keep those concerns in application-owned stores and services; expose only narrow, authorized tools to the agent.
Slack messages and Lists are interaction or projection surfaces, not automatic sources of truth. Use the Lists section for the Lists API contract and Data Surfaces for choosing what Slack should display.
How Claims Are Labeled
This section separates evidence from design advice. Treat these labels as part of the contract:
Verified fact
Confirmed against the version-matched primary-source hierarchy onSource Map and Versioning. A verified fact still belongs to the stated version and verification date.
Inference
A conclusion derived from verified behavior, but not promised directly by the cited source. Recheck the premises before relying on it as a hard guarantee.
Proposed contract
A recommended application interface or architecture authored by this site. It is a design proposal, not an existing Flue, Slack, or Cloudflare API.
Unverified behavior
A claim that primary documentation or repository inspection did not settle. Do not promote it to a fact without a focused test and recorded evidence.
Nine-Page Section Map
The complete section is organized in this order. Every title links to the finished page, and the category navigation below provides the same ordered entry points.
| Page | Role | Default claim posture |
|---|---|---|
| Flue (this page) | Scope, boundaries, and evidence labels | Architecture boundary backed by verified framework scope |
| Source Map and Versioning | Version baseline, authority order, and known source drift | Verified facts and recorded discrepancies |
| Core Concepts and API | Agent functions, conversations, dispatch, state, and tools | Version-verified framework behavior |
| Getting Started on Cloudflare | Vite integration, generated Durable Objects, bindings, migrations, and secrets | Version-verified setup plus platform boundaries |
| Slack Request Handling | Authenticated channel ingress, routing, dedupe, authorization, and outbound tools | Verified provider contracts plus application policy |
| Testing and Operations | Deterministic tests, schedules, retries, privacy-safe observability, and upgrades | Verified behavior plus operational recommendations |
| Inquiry and Slack List Workflows | Separation of conversation, canonical business, and Slack projection state | Proposed application architecture with limitations labeled |
| Proposed Text and Calendar Tools | Narrow future tool contracts for remote text and calendar access | Proposed contracts, never existing-API claims |
| Agent Behind an Ingress | Unmounted router, server-minted conversation addresses, credential and deletion ownership | Proposed architecture built on verified framework gaps |