# flux > A deterministic agent platform where the LLM is not the runtime. Provider-native typed stages interpret intent and propose literal calls inside an authored Flux-Lang loop. The host freezes effects into action batches and runs them through one mandatory safety envelope (authorization → approval → guarded IO). The default conversational loop never asks the model for per-turn executable Flux. The documentation below covers the agent, the language, the SDK, plugins, and operations. Full documentation as a single file: [llms-full.txt](https://codewandler.github.io/flux/llms-full.txt) ## Overview - [Overview](https://codewandler.github.io/flux/docs/intro): flux is a deterministic agent platform for building and running tool-using agents without giving the model direct control of the machine. - [What's new](https://codewandler.github.io/flux/docs/whats-new): This is the same customer changelog embedded in the binary. From a terminal, use flux changelog for the latest release, flux changelog --all for the full history, or flux changelog for one release. - [Concepts](https://codewandler.github.io/flux/docs/concepts): This page defines the words the rest of the documentation uses. Read it before the agent, language, or security guides. ## Start here - [Getting started](https://codewandler.github.io/flux/docs/getting-started): flux ships as a single flux binary. This page gets you from install to a real turn, with an offline smoke test first so you can verify the runtime without provider credentials. - [Build your first Flux app](https://codewandler.github.io/flux/docs/tutorial): This tutorial takes you from a prompt at the command line to a small application written in Flux-Lang. You will watch typed intent and evidence gathering, write a reusable flow, then discover why an important application rule belongs in a deterministic journey rather than a prompt. - [1. Run an adaptive agent safely](https://codewandler.github.io/flux/docs/tutorial/first-agent): Your first task is to read the two handbook files and write an onboarding summary. Run it with the outer-loop machinery visible: - [2. Write a reusable flow](https://codewandler.github.io/flux/docs/tutorial/first-flow): An adaptive request is useful when the route to the result is open-ended. When you already know the steps, write them as a Flux-Lang flow. Flux parses and executes that authored structure without asking a model to invent it. - [3. Make the docs assistant reliable](https://codewandler.github.io/flux/docs/tutorial/first-app): A Flux app describes a whole event-driven application in one .flux file. For the capstone, you will first build the obvious docs assistant: give an agent search, tell it to use the handbook, and route terminal questions to it. Then you will test the assumption hidden in that design and move the reliable steps into an explicit journey. ## Coding / AI-assisted development - [AI-assisted development](https://codewandler.github.io/flux/docs/coding/overview): Flux treats AI-assisted development as a durable engineering workflow, not a long prompt. The **board** says what the project is trying to accomplish and what counts as done. The **fleet** runs bounded local Flux sub-agents against that work. Repository files, commits, tests, reviews, and the final gate remain the evidence. - [Boards](https://codewandler.github.io/flux/docs/coding/boards): A Flux board is a governed collection of work plus an explicit state machine. A planning board also owns the documents that explain why the work exists. It is separate from a datasource: a datasource is a read surface over knowledge or a system of record; a board creates, transitions, comments on, and records evidence against work. - [Fleet and local sub-agents](https://codewandler.github.io/flux/docs/coding/fleet): The Flux fleet is a durable supervisor connecting planning BoardRefs to isolated local Flux sub-agent sessions. It replaces coordinator socket clients, terminal scraping, Python board generators, status collectors, and hand-built progress reports with one versioned CLI. ## Fundamentals - [Ecosystem](https://codewandler.github.io/flux/docs/ecosystem): flux is three projects that share one vocabulary. The engine, language, agent loop and core tools remain useful on their own; official external integrations cross the other two projects because their declarations and execution authority do not belong in the engine. - [Infrastructure](https://codewandler.github.io/flux/docs/infrastructure): flux is built around one boundary: **the LLM is not the runtime**. Provider-native typed stages interpret intent and propose literal operation calls inside an authored Flux-Lang outer loop. The host freezes effects into action batches; deterministic Rust code decides what is allowed and performs the work. - [Topologies](https://codewandler.github.io/flux/docs/topologies): flux can run in a lot of shapes: entirely on your laptop, confined by the OS, served over HTTP to a thin client, embedded in another Rust program, or compiled to WebAssembly. Most of these already exist, and nothing collected them — so people tend to discover the shape of the product by accident. - [Deploy a remote execution system](https://codewandler.github.io/flux/docs/remote-system-deployment): flux system serve is the shipped placement primitive for keeping the model, policy, and approval UI local while file, process, and network effects happen elsewhere. The daemon is deliberately unaware of how its host was provisioned. ## Agent - [CLI](https://codewandler.github.io/flux/docs/agent/cli): The flux binary is the reference surface for day-to-day use. It runs adaptive agent turns, executes authored flows, hosts programs, manages providers, and exposes diagnostics. - [TUI](https://codewandler.github.io/flux/docs/agent/tui): flux tui is the full-screen terminal chat UI — the same agent loop, the same safety envelope, and the same session store as flux run, driven interactively. It renders a streaming transcript, tool cards, plan trees, and an in-UI approval sheet, and it keeps the composer live while a turn is running so you can write the next message (or steer the current one) without waiting. - [Providers and models](https://codewandler.github.io/flux/docs/agent/providers): flux keeps model transport separate from the agent runtime. A provider is a wire codec plus a credential source: how a request is serialized and how it authenticates. The runtime still owns the authored outer loop, capability ceilings, action batches, approval, and guarded IO. - [Claude Code (subscription)](https://codewandler.github.io/flux/docs/agent/claude-code): The claude provider runs flux against the same backend as the anthropic provider, but authenticates with a **Claude Code / Claude Max subscription** OAuth token instead of a metered API key. If you already use Claude Code, flux imports its credential automatically — no separate key, and usage bills against the subscription you already pay for. - [Project context](https://codewandler.github.io/flux/docs/agent/project-context): Before your first message, flux assembles a typed context package for the exact directory where the session starts. The package is layered after Flux's embedded harness protocol, the selected agent profile, and any authored role instructions, so repository files cannot replace the harness-owned contract. Project context comes from an ordered chain of providers: - [Context management](https://codewandler.github.io/flux/docs/agent/context-management): Every turn re-sends the whole conversation to the provider. A long session therefore costs more each turn, and eventually reaches the model's context limit. flux's answer is **compaction**: past a character budget, the older part of the history is summarized into one message and the rest is kept verbatim. - [Skills and roles](https://codewandler.github.io/flux/docs/agent/skills-and-roles): Skills and roles change different parts of an agent: - [Claude Code compatibility](https://codewandler.github.io/flux/docs/agent/claude-compat): Flux reads Claude Code's on-disk formats where that helps you reuse an existing setup, and keeps its own semantics where they are a deliberate improvement. This page is the honest matrix: what loads from where, which metadata is honored, and where behavior differs from Claude Code. It describes what ships today; planned compatibility work is tracked in the repo roadmap under the *Claude interop* epic. - [Multi-agent programs](https://codewandler.github.io/flux/docs/agent/programs): A single agent is one loop. A multi-agent program is a whole application: permissions, agents, channels, datasources, triggers, and journeys declared in one Flux-Lang .flux file. - [Saved flows and custom operations](https://codewandler.github.io/flux/docs/agent/saved-flows): Saved flows let people and agents invoke reviewed, authored Flux-Lang control flow without inferring its structure again on every turn. Composite operations let a module give a meaningful name to a reusable sub-flow. - [Datasources](https://codewandler.github.io/flux/docs/agent/datasources): A **datasource** is a named, declared, **read-only** record surface the agent reaches through operations. Operations *do*; datasources *know* — anything that mutates is not a datasource. Every datasource has one declared access mode: - [HTTP API](https://codewandler.github.io/flux/docs/agent/http-api): flux app run --serve exposes an agent over HTTP. Three surfaces share the one router: - [Agent-to-agent (A2A)](https://codewandler.github.io/flux/docs/agent/a2a): flux implements the JSON-RPC-over-HTTP binding of the A2A v0.3.0 specification in both directions. It can expose a local flux agent to a compatible v0.3 client, and it can call a compatible v0.3 agent from the CLI. - [A2A protocol support](https://codewandler.github.io/flux/docs/agent/a2a-conformance): This is the implementation matrix for flux's JSON-RPC-over-HTTP binding of the A2A v0.3.0 specification. Use it to check which v0.3 methods, task states, agent-card fields, and error paths flux supports. - [Deploy the agent to Kubernetes](https://codewandler.github.io/flux/docs/agent/deployment): This page deploys **the agent itself** into a cluster and reaches it from your laptop. The agent plans, calls the model, runs tools and keeps its sessions in the pod; what you run locally is a thin client. - [Work boards and the fleet](https://codewandler.github.io/flux/docs/agent/fleet): The board and fleet documentation has moved into one task-oriented section: - [Endpoints](https://codewandler.github.io/flux/docs/agent/endpoints): An endpoint is a model-safe reference to a live service: where it is, what protocol it speaks, and the **location** of any credential. It never contains the credential value. Use endpoints for live systems such as PostgreSQL, Prometheus, or an in-cluster API. - [Realtime voice (experimental)](https://codewandler.github.io/flux/docs/agent/realtime): Realtime support is an SDK-level experimental surface for full-duplex voice models. It is not the normal text agent loop, and in its default mode it does not turn each utterance into a Flux-Lang plan. It exists for embedders that need a long-lived audio session while still routing effectful tool calls through the guarded executor. Since 0.15.0 the driver has a second, **flow-driven** mode: an authored flow owns the call and the realtime model is only the acoustic front-end (see Flow-driven voice below). - [The agent loop](https://codewandler.github.io/flux/docs/agent/agent-loop): Every conversational turn is driven by an authored Flux-Lang program. The CLI, SDK Client, server, sub-agents, apps, and conversational text adapters all use the same loop; Rust only supplies the provider, session, operation registry, cancellation, and safety envelope. - [Safety & approvals](https://codewandler.github.io/flux/docs/agent/safety): flux is built so every model-stage operation, built-in tool, sub-agent operation, app operation, and plugin **host-capability request** traverses one mandatory chain before flux performs real IO. This page explains that chain, what prompts, and how approval decisions interact with policy. - [Time Machine](https://codewandler.github.io/flux/docs/agent/time-machine): Time Machine is the run-history toolkit: replay an old run without live IO, fork from a recorded decision point, or diff two executions. It works because flux records accepted plans and leaf-operation results as durable artifacts. - [Usage & cost](https://codewandler.github.io/flux/docs/agent/cost): flux records model usage per call and rolls it up by session and provider. Use this page to understand what the CLI summary means, where the numbers come from, and how to price models the built-in table does not know yet. ## Integrations - [What a channel is](https://codewandler.github.io/flux/docs/channels/overview): A **channel** is how a flux app is *reached*. Everything else in flux runs because you asked it to — you type a prompt, you run a flow. A channel inverts that: it is a long-running event source that **wakes** the app when something happens outside it, whether that is a cron tick, an HTTP request, a Slack mention, or another agent calling in. - [Channel inventory and capabilities](https://codewandler.github.io/flux/docs/channels/inventory): The stock flux binary ships the channel kinds listed below. This page is the reference for what each one can actually do. For the model behind them — how a channel wakes a program and how concurrent deliveries are isolated and bounded — read what a channel is first. - [Connector channels](https://codewandler.github.io/flux/docs/channels/connector): A connector channel turns one named binding in a connector manifest into an inbound event source. The manifest supplies vendor semantics — event names, routing selectors, payload fields, verification posture, and optional reply metadata — while your program supplies deployment details such as the listen address and secrets. - [Slack channel setup](https://codewandler.github.io/flux/docs/agent/slack-channel): A program reaches Slack through a channel slack declaration. The adapter connects over Slack **Socket Mode** (an outbound WebSocket — no public URL or inbound webhook to host), listens for mentions, and posts each run's answer back into the originating thread. The adapter is compiled into the stock flux binary; no special build flags are needed. - [Using plugins](https://codewandler.github.io/flux/docs/plugins/using-plugins): Plugins are trusted subprocess binaries that extend Flux with new operations. Each declared operation is projected as a policy-gated tool, so the same authorization, approval, and guarded-IO chain that protects built-ins also protects plugin calls. - [GitLab plugin](https://codewandler.github.io/flux/docs/plugins/gitlab): A worked setup for the gitlab plugin — projects, merge requests, issues, pipelines, releases, and repository file/branch/tag operations against a GitLab instance. This page walks through the exact sequence for a real self-hosted instance, using only the flux CLI. For the general plugin mechanics (capability grants, trust model, everyday commands), see Using plugins. - [Slack plugin](https://codewandler.github.io/flux/docs/plugins/slack): A worked setup for the slack plugin — messaging, threads, search, reactions, channels, users, files, bookmarks, presence, and emoji against the Slack Web API. This page walks through the exact sequence using only the flux CLI. For the general plugin mechanics (capability grants, trust model, everyday commands), see Using plugins. - [Docker plugin](https://codewandler.github.io/flux/docs/plugins/docker): The docker plugin lets Flux manage Docker Engine resources that already exist: containers, images, networks, volumes, and daemon disk usage. It talks HTTP/1.1 to Docker Engine API v1.43 through the host's guarded Unix-socket connection capability. The plugin process never opens the socket itself. - [Kubernetes plugin](https://codewandler.github.io/flux/docs/plugins/kubernetes): A worked setup for the kubernetes plugin — cluster contexts, read-only inventory (namespaces, services, pods, deployments, containers, ingresses, nodes), debugging (logs, events, exec, rollout history), managed port-forwards, and a small set of guarded mutations. This page walks through the exact sequence using only the flux CLI. For the general plugin mechanics (capability grants, trust model, everyday commands), see Using plugins. - [SQL plugin](https://codewandler.github.io/flux/docs/plugins/sql): A worked setup for the sql plugin — read-only query and schema introspection against a PostgreSQL or MySQL/MariaDB database. This page walks through the exact sequence using only the flux CLI. For the general plugin mechanics (capability grants, trust model, everyday commands), see Using plugins. - [Plugin authoring](https://codewandler.github.io/flux/docs/plugins/authoring): A plugin is a **subprocess binary** that speaks Flux's framed flux.plugin.v1 NDJSON protocol over stdin/stdout. It advertises a **manifest** — a name, a set of operations, and the capabilities, auth purposes, and endpoints it needs — and implements each operation. Flux projects every declared operation as a policy-gated tool, so a plugin op traverses the same safety envelope as a built-in: authorization, approval, guarded IO. There are no bypass paths. ## Flux-Lang - [Overview](https://codewandler.github.io/flux/docs/language/overview): Flux-Lang is the authored workflow language at the center of flux. It places deterministic control flow around model judgment and runtime authority: typed stages may interpret or propose, while the runtime analyzes the authored program, approves effects, and executes it. The default conversational loop does not ask the model to emit per-turn executable Flux. The explicit op.register exception lets a model propose source for exactly one composite operation; the host parses, analyzes, scopes, and guards it before installation rather than executing it on receipt. - [A ten-minute tour](https://codewandler.github.io/flux/docs/language/tour): This tour builds one small Flux-Lang vocabulary at a time: flows, calls, pure values, branches, iteration, concurrency, guard rails, and context packs. Every snippet parses as-is; complete flows run as-is in a .flux file, and the shorter fragments show a flow body (wrap them in a flow header to run standalone). Every snippet uses the formatter's canonical bare symbols, brace-free named arguments, named headers, and duration units. See Symbols and Named arguments for details. - [Flux-Lang workbench](https://codewandler.github.io/flux/docs/language/playground): Every Flux code block can expand into the same workbench used by /console/: a Monaco editor with Flux syntax, live diagnostics, completion, hover, formatting, structural graph projection, input editing, run output, cancellation, and effect-bound approval prompts. - [Flows & syntax](https://codewandler.github.io/flux/docs/language/flows-and-syntax): This page is the text-syntax reference for .flux files: flow headers, indentation, symbols, literals, calls, binds, returns, and the @json escape. The node reference documents the same constructs in their JSON wire form. - [Control flow](https://codewandler.github.io/flux/docs/language/control-flow): Every branch and loop in Flux-Lang is explicit plan structure. The analyzer can inspect it before execution, reject unsafe shapes, and keep loops bounded. This page covers deterministic branching and iteration plus route, the bounded place where a model can choose among declared paths. - [Pure data shaping](https://codewandler.github.io/flux/docs/language/pure-data): Pure nodes handle the data work inside a plan: formatting, field access, JSON extraction, arithmetic, type coercion, and value assembly. They perform no IO, dispatch no operation, and never pause for approval. Use them anywhere you would otherwise shell out just to reshape data. - [Context packs](https://codewandler.github.io/flux/docs/language/context-packs): Context packs make model-visible evidence explicit. Instead of sending every tool output back through the transcript, a plan names the symbols a model call may see, explains why, and sets a budget the runtime enforces. - [Concurrency](https://codewandler.github.io/flux/docs/language/concurrency): Flux-Lang has two concurrency nodes. parallel fans out work and waits for every branch. race takes the first successful branch and cancels the rest. Both keep the run trace deterministic, and every operation in every branch still crosses the safety envelope. - [Reliability & guard rails](https://codewandler.github.io/flux/docs/language/reliability): Reliability constraints are first-class plan nodes, not instructions buried in a prompt. A retry policy, deadline, dispatch cap, or approval gate is visible before execution and enforced by the runtime during execution. - [Durability & cross-turn state](https://codewandler.github.io/flux/docs/language/durability): Durability nodes let a flow outlive one straight-line execution. They cache work, suspend for external events, resume long runs without repeating side effects, and unwind partial work when a later step fails. - [Execution model](https://codewandler.github.io/flux/docs/language/execution-model): This page explains what happens after flux receives an authored flow: parsing, analysis, optimization, execution, value storage, dispatch, errors, and suspension. Execution is deterministic except where a flow explicitly calls a model or waits for external input. - [Modules, composite ops & programs](https://codewandler.github.io/flux/docs/language/modules-and-programs): A .flux file can hold one flow, a reusable module, or an application declaration. This page covers the module-level surface: multiple flows, composite op declarations, and the program declarations that the app host understands. - [Node reference](https://codewandler.github.io/flux/docs/language/node-reference): This is the precise JSON AST reference for Flux-Lang. Authors write native .flux text, while SDK callers and host tooling may construct this shape directly and sessions store it. Text and JSON are semantically identical: every .flux construct lowers to these nodes, every node kind has a native text spelling, and @json remains as the escape for rare AST shapes the text grammar cannot preserve exactly. Native array indexing is ordinary source — response.results[0] lowers to the dot-segment path .results.0 and formats back with brackets. Only a hand-built jq whose path string itself contains brackets needs @json, alongside shapes such as non-identifier symbol names and non-invertible expr formulas. - [Types & effects](https://codewandler.github.io/flux/docs/language/types-and-effects): Flux-Lang has a deliberately small annotation system, not a structural type system. TypeRef distinguishes primitives, lists, and named types. Annotations stay visible in the AST and let the analyzer reject concrete argument mismatches against registered operation signatures; they do not recursively prove the shape of every runtime value. Values themselves remain JSON-like data owned by the value store. - [Operations](https://codewandler.github.io/flux/docs/language/ops): Operations are the callable boundary between Flux-Lang and the host runtime. A call node names an operation; the host decides whether that operation exists, how arguments are validated, and what approval or policy checks apply. - [Tooling](https://codewandler.github.io/flux/docs/language/tooling): Flux-Lang files are authored runnable artifacts. This page covers the commands that execute, parse, format, render, and round-trip them. - [Editor setup](https://codewandler.github.io/flux/docs/language/editors): Editor support for .flux files is two independent pieces, matching how modern editors split the work: - [Examples](https://codewandler.github.io/flux/docs/language/examples): The first examples are complete, parser- and formatter-checked flows. You can paste one into a .flux file and run it once the named operations and any required provider or credentials are configured. Each stays small enough to highlight one pattern. The final two sections are explicitly illustrative case studies; their current blockers are stated where they appear. ## SDK - [SDK overview](https://codewandler.github.io/flux/docs/sdk/overview): flux-sdk embeds the same policy-gated flow engine used by the CLI. You provide a model provider and a workspace root; the SDK wires the Flux-Lang agent loop, built-in operations, safety envelope, and session storage. - [Sessions & persistence](https://codewandler.github.io/flux/docs/sdk/sessions): A Client runs turns against a **session** — one conversation, recorded in an event store. By default that store is in-memory and dies with the process. Point the client at a directory instead and its sessions become durable: you can close the process, reopen it, and pick the conversation back up by id — including a conversation that paused waiting for a human answer. - [Streaming & cancellation](https://codewandler.github.io/flux/docs/sdk/streaming): Session::send runs a turn to completion and hands back a collected TurnOutput. When you want to show progress — the assistant's text as it arrives, each tool call and its result, plan headlines — a Session gives you two streaming shapes over the same engine, plus cancellation. - [FlowClient](https://codewandler.github.io/flux/docs/sdk/flow-client): FlowClient is the recommended SDK surface when your application owns a flow. It exposes the Flux-Lang lifecycle directly while reusing flux-flow's analyzer, runtime adapter, value store, operation registry, and safety envelope. - [Datasources](https://codewandler.github.io/flux/docs/sdk/datasources): A datasource is a named, declared, **read-only** record surface — operations *do*; datasources *know* — and it has exactly one declared access mode. The SDK supports both: - [Agent Lab](https://codewandler.github.io/flux/docs/sdk/agent-lab): A recorded flux run contains canonical accepted-plan text, durable usage, and redacted cassette cells for leaf-op results. The accepted-plan terminology names the durable replay contract: on the adaptive loop, its Flux-Lang text is host-derived replay metadata, not control flow emitted by the model. The Agent Lab exposes three distinct uses of that substrate: ## Security - [Security overview](https://codewandler.github.io/flux/docs/security/overview): flux runs real tools, plugins, and network calls on your behalf. This section explains the guarantees that hold by construction, the trust boundaries you still own, and the pages to read for each part of the model. - [Security in plain terms](https://codewandler.github.io/flux/docs/security/plain-terms): This page is for people who **use** flux and want to know it's safe — no engineering background needed. If you're a developer or you run flux for a team, the Security overview goes deeper. - [Credentials & secrets](https://codewandler.github.io/flux/docs/security/credentials): This page covers outbound authentication: provider keys, subscription credentials, plugin OAuth tokens, secret references, and redaction. Flux has two secret-handling models. Some paths prevent a value from entering a process or component at all; other paths materialize plaintext and rely on containment. The distinction matters because only the first makes a missed scrub harmless. - [Plugin capability sandbox](https://codewandler.github.io/flux/docs/security/plugin-sandbox): The plugin sandbox is flux's confinement model for plugin capabilities. It governs what a plugin can ask the host to do — HTTP, subprocesses, secrets, connections, and private-network access — while the plugin is running. - [OS process sandboxing](https://codewandler.github.io/flux/docs/security/os-sandbox): flux can wrap shell/exec ops and, above all, **stdio plugin subprocesses** in a platform sandbox: bubblewrap on Linux, Seatbelt (sandbox-exec) on macOS. A small set of trusted host/browser launches is explicitly exempt and documented below. This is defense-in-depth **underneath** the safety envelope, applied at flux's single process choke point. Ordinary interactive use is opt-in and off by default. The CLI selects a fail-closed posture automatically for the specific auto-approved and --serve forms listed below. - [Plugin trust & signing](https://codewandler.github.io/flux/docs/security/plugin-trust): Plugin trust is the supply-chain side of plugin safety: proving which binary is installed and which binary is spawned. It is separate from the capability sandbox, which controls what that binary can reach through Flux once it is running. - [Server authentication & tenancy](https://codewandler.github.io/flux/docs/security/server-auth): This page covers inbound authentication for a hosted flux server: who may call it, how bearer tokens are validated, and how tenants are isolated. Authentication establishes caller identity; authorization of what that caller may do remains with the safety envelope. ## Reference - [Troubleshooting](https://codewandler.github.io/flux/docs/troubleshooting): This page covers the common failures that block a first run or a local development loop. Each entry starts with the command or config to check, then explains why flux behaves that way. - [Configuration](https://codewandler.github.io/flux/docs/reference/config): flux works without a config file. User defaults live in ~/.flux/config.toml; a project can add .flux/config.toml in the directory where flux is launched. flux reads that exact directory and does not search parent directories for a repository root. An operator can additionally pin an organization-wide floor ahead of both — see Managed configuration tier below. - [Storage & persistence](https://codewandler.github.io/flux/docs/reference/storage): flux stores sessions, run traces, and usage telemetry as append-only events. Conversations, flow execution, and per-turn metrics share one ordered log; every user-facing view is a projection over that log. ## Direction - [Connector-native integrations](https://codewandler.github.io/flux/docs/direction/connector-native-integrations): Flux is moving from two official integration models to one: - [Portable WebAssembly runtime status](https://codewandler.github.io/flux/docs/direction/portable-wasm-runtime): The flux_portable example compiles the flux-lang parser and reference interpreter to wasm32-unknown-unknown. Its small evaluation ABI accepts UTF-8 .flux source and returns a JSON result through three exports: flux_alloc, flux_eval, and flux_dealloc. - [Evaluation and improvement](https://codewandler.github.io/flux/docs/agent/improvement): Two different things used to share this page. They have been separated, because only one of them moved: