Inside Flare Control: orchestrating AI agents on Cloudflare's edge

Flare Control started from a simple question: what would an agent platform look like if it did not assume a long-running server?

Most agent examples hide a process somewhere. It polls, keeps state in memory, runs the loop, and becomes the thing you have to keep alive. That can work for a prototype, but it is a poor fit for teams that need cost control, audit trails, and human approval before real actions happen.

Flare Control is my answer: a Cloudflare-native control plane for agents, queues, memory, tools, and approvals.

Split the control plane from the runtime

The control plane is a Hono API on Workers. It handles agents, sessions, tools, schedules, and run requests. It is request-scoped and stateless by design.

The runtime is queue-driven. An agent run is represented as work, not as a forever process. Cloudflare Queues wake the consumer only when there is work to do, so idle cost stays close to zero.

That split makes the system easier to reason about:

• API requests create or inspect state.
• Queue consumers execute work.
• Durable workflows coordinate long waits.
• Durable Objects are reserved for places that truly need coordination.

Use the right Cloudflare primitive for each job

D1 stores relational state: agents, runs, tools, sessions, schedules, and audit records. R2 stores artifacts. Vectorize stores memory that benefits from semantic retrieval. Durable Objects handle narrow coordination concerns such as locks or live sessions.

The important part is restraint. Not everything belongs in a Durable Object. Not everything belongs in a vector database. The source of truth stays relational unless there is a clear reason to make it semantic or stateful.

Human approval is a system concern

For consequential actions, “fire and forget” is not acceptable. The platform needs to pause, surface the pending action, wait for a person, then resume from a known point.

That is why approvals are modeled as durable waits. The run does not rely on a browser tab, a process, or a polling loop staying alive. The system persists the waiting state and resumes when the approval arrives.

What this proves

The architecture is not just a Cloudflare demo. It is a pattern for building AI systems that need production constraints:

• near-zero idle cost
• horizontal execution
• explicit policy boundaries
• approval gates
• full run auditability

If your team is exploring agents and needs more than a toy loop, get in touch.