Core objects
Request flow
The API does not keep the original request open for the whole run. A successful create response means the work is durably queued. The caller opens a separate, resumable SSE connection to observe progress. When the model requests a caller-owned tool, OAO persists the request, changes the run towaiting_for_tool, and emits tool_call.requested. The caller claims the work,
executes it, and submits the fenced result; the worker then resumes the model.
Platform-owned tools follow the same durable model/tool loop but execute inside
the runtime worker, so they do not require the caller to submit a result.
PostgreSQL is the MVP authority
The MVP uses one PostgreSQL deployment for:- Flue’s canonical runtime persistence;
- tenant configuration and immutable agent and Skill versions;
- sessions, runs, messages, tool/approval ledgers, and audit entries;
- the short wake queue and fenced ownership records; and
- the append-only product event feed used for real-time UI updates.
LISTEN/NOTIFY may wake a reader sooner, but notifications are never the
correctness source. A reconnecting client resumes from a committed product-event
position.
At admission, OAO resolves only the exact Skill versions copied from the agent
version into the session. Flue initially shows the model their small name and
description catalog entries, then loads full instructions and individual
resources only when the model activates or reads them. See
Versioned Skills.
A coordinator version can also pin a named roster of exact child-agent
versions. Delegation creates a separate child thread and Flue instance, binds it
to the coordinator’s workspace, and returns an ID that can receive later
follow-up turns. See Multi-agent orchestration.
One active run per session thread
Only one run is admitted to Flue for a thread at a time. Later submissions stay in OAO’s PostgreSQL queue until the active run settles. This is an MVP safety invariant: current Flue cancellation is conversation-wide, so serial admission prevents cancelling one run from aborting a different run in the same session.Caller-owned tools
A caller-owned tool is a durable request, not a webhook that must succeed once. An authorized integration claims the request for a lease, receives a monotonically increasing fence, performs the work, and submits one immutable safe result. A stale worker cannot commit with an older fence. Before a successful caller result is persisted, OAO validates its value against the output schema pinned in the run’s immutable agent version. Invalid values are converted into a redactedinvalid_tool_result failure and handed back to
the model. The model retries retryable failures up to twice after the first
attempt; OAO enforces three total attempts and publishes every retry as a new
fenced tool call. Approval, cancellation, and exhausted-retry failures do not
loop.
Attach a small, deliberate set of supported files directly to a run. For a full
or changing codebase, caller-owned tools remain the recommended pattern: keep
the repository in your environment, expose narrow read/search tools, validate
paths against an allowlisted root, and return only the data the agent needs.

