Skip to main content
An agent is a reusable identity, runtime, model, and deployed behavior. Every session runs on an agent, so create one first, then start as many sessions on it as you like. For the built-in runtimes, behavior is prompt plus optional skills and is frozen into independently routable revisions. A Flue agent instead carries its instructions, tools, and packaged skills in a compiled Flue app.
The dashboard starts with Import from GitHub and keeps Configure manually available. Repository import recognizes a complete Flue app; prompt- or skills-only folders are not converted into an agent. You can also deploy a local Flue checkout with oc agent deploy. Both Flue paths produce the same deployment and revision history.
Pass your model key inline and it’s stored as a credential and attached to the agent — sessions run the model on it. The provider is taken from model (Anthropic for anthropic/…, OpenAI for openai/…), so the key has to be for that provider. Already have a credential? Reference it with credential: "cred_…" instead. Or skip keys entirely with credential: "managed" to run the model via OpenComputer, billed to your credits (the default for new orgs). Omit both key and credential to use your org default. Optionally set default limits (tokens/turn_seconds/turns) too; sessions inherit them.
Keep the org key and model key on your backend. Only return session-scoped client tokens to browsers.

​
Start simple, add capability as you go

For a built-in runtime, the only behavior an agent needs is a model and a prompt. Everything beyond that is additive: reach for a rung only when you need it, and nothing earlier is undone. Flue has a separate app deployment path. At every built-in rung the agent is a small directory, at most agent.toml + prompt.md + skills/. You can stop at any rung; most agents never go past skills.

​
Create from a repository

Choose Agents → Create agent → Import from GitHub, install the OpenComputer GitHub App if needed, and select a repository, production branch, and root. Review agent resolves one exact commit without running repository code.
  • A complete Flue root shows its entrypoint, model, Managed model access, and an editable OpenComputer agent name.
  • A broken Flue root explains what must be fixed. OpenComputer does not reinterpret it as another agent type.
  • An unrecognized root creates nothing. You can choose another folder, fork the Flue starter, or configure a built-in agent manually.
  • In a monorepo, OpenComputer may suggest bounded candidate folders. You choose one explicitly and review it before deployment.
Review and import are intentionally separate. Import rechecks the exact source plan; if the repository changed in between, nothing is created and the dashboard asks you to review again. A successful import returns the new agent and its first deployment immediately, then opens guided setup instead of making you wait on a log screen. Connect Slack while the deployment continues in the background; its compact phases and expandable log remain available. When both are ready, setup changes to Open Slack without a refresh and invites you to send the first message. Manually configured agents use the same setup journey. If one of your Slack workspaces already sends messages to another agent, setup shows that claim before OAuth. Open the connected agent, choose another workspace, or disconnect it in place after reviewing the routing impact. A completed first conversation adds direct exits to the agent home, full session, session history, and Slack. The repository picker marks roots already used by another agent before review. An exact linked root cannot be reviewed again: open its owning agent, choose a different monorepo root, or unlink it in place after confirming that deploy-on-push will stop. Unlinking preserves the existing agent, active revision, deployment history, and sessions. Guided setup remains available from the agent page; after the first Slack message creates a session, it shows the first conversation and links to the complete session view.

​
Session-pinned config

For a built-in runtime, creating a session freezes the agent’s active revision, including its prompt, model, runtime, and skills. It also pins the resolved credential. A one-off model override is pinned in the same way. Editing the named agent does not change a running or resumed session: existing sessions keep what they started with, while new sessions pick up the change. Rotating a credential’s key value is the exception, so a compromised key can be replaced; see credentials. That isolation applies to the built-in runtimes. A Flue session records the selected deployment, but all sessions for that agent execute on its one live Worker. Deploying a new Flue Worker can therefore change existing sessions; see Flue deployment behavior.

​
Model

model is a provider/model id, and its provider must match the runtime: claude runs anthropic/… (e.g. anthropic/claude-opus-4-8), codex runs openai/… (e.g. openai/gpt-5-codex). The model runs either Managed (via OpenComputer, billed to your credits — no key) or on your own key for that provider, so a key isn’t required. The runtime / model / credential pairing is validated when you create the agent. runtime is fixed at creation — to switch engines, create a new agent; you can still update model later, but keep it within the runtime’s provider. Flue currently uses Managed Anthropic access. Its model is declared in both the compiled app and agent.toml; per-session model overrides are not supported.