Flue Agent Rules

A TypeScript framework for building and deploying autonomous agents.

Overview

Flue defines how agents, harnesses, sessions, operations, and turns relate before giving development rules. Its contribution section also makes clear which workflows are available and where they stop.

Documents

├── 
├── examples
│   ├── assistant
│   │   └── 
│   ├── braintrust
│   │   └── 
│   ├── hello-world
│   │   └──  · same content as examples/braintrust/AGENTS.md
│   └── sentry
│       └──  · same content as examples/braintrust/AGENTS.md
└── 

Techniques in this file

01 / House vocabulary

Name the durable unit explicitly

The guide rules out familiar workflow and run terminology. It identifies conversations as the persistent unit and distinguishes bounded tool jobs from that lifecycle.

Source excerpt starting at line 29.
There are no workflows or runs: conversations are the only durable unit, and a bounded code job is a tool with `harness: true`. Direct HTTP agent prompts and dispatched agent inputs operate within persistent sessions; `dispatch(...)` is identified by its `submissionId`.

02 / Architecture as narrative

Separate registration from exposure

The routing paragraph explains that mounting an HTTP route does not register an agent. Registration belongs to the source scan, which prevents an agent from conflating two different mechanisms.

Source excerpt starting at line 31.
Routing is explicit: `app.ts` is the application's route map, mounting each HTTP-reachable agent (`app.route('/agents/<name>', createAgentRouter(AgentFn))`) and channel (`app.route('/channels/<x>', channel.route())`). Registration comes from the `'use agent'` scan, not from mounting.

03 / Contribution etiquette

State which contribution paths are accepted

The contribution section directs bug reports and feature requests to different places. It also states that incoming pull requests are converted rather than accepted, so code submission is not presented as the default path.

Source excerpt starting at line 11.
- **Pull requests** are not accepted; they are automatically closed and converted into one of the two contribution types above.

04

Make a verification gap visible

The file states that no tests exist instead of implying otherwise. Its commands cover installation, builds, type checks, and formatting, clearly separating those checks from behavioral tests.

Source excerpt starting at line 44.
No tests exist in the repo.

Ideas for your repo

  1. Define the persistent unit before describing agent operations.
  2. Distinguish code discovery from public route registration.
  3. Document absent verification tools alongside the checks that do exist.
  4. Tell agents which contribution channels maintainers accept.
Sponsored byModem

Give your agents the whole story.

These instructions explain how to work in Flue. Modem shows your agents what customers said, who is affected, and what changed.

See how Modem works