What is Floxar?

Floxar turns the way your team works into processes that people and AI agents can actually run, step by step, with a complete record of every run.

Most teams keep their know-how in wikis, documents and the heads of a few experienced people. Work gets done from memory: new people take months to become reliable, the same task is done differently by different people, a change to the procedure reaches some people and not others, and when someone leaves, part of the process leaves with them. Leaders see outcomes, but not how the work was actually done.

AI agents make this harder, not easier. An agent handed a whole knowledge base guesses at which parts apply, and afterwards nobody can show what it did or whether it followed the procedure your team agreed on.

Floxar replaces the procedure you read with a procedure you run.

How it works

Floxar works in four stages that feed each other: structure, execute, automate, improve.

Structure. You describe a process as a flow: a set of focused steps (bits) connected in the order they happen, with a decision point wherever the work can go different ways. Each step says exactly what to do and asks for exactly what needs to be recorded, using interactive elements such as checklists, choices, text fields and dates. Supporting material your steps rely on, such as policies and definitions, lives in references linked to those steps. You can write flows yourself in the editor, have your AI client write them for you, or let the Flow Designer draft one from a document you already have.

Execute. Running a flow creates a trail: one run of the process. Whoever runs it sees one step at a time, with only the context that step needs, and moves on by choosing among the paths the author defined. Required answers must be given before the run can move on. Work can be paused, handed to a named colleague, or placed in a shared queue for the next available person to pick up.

Automate. The same flow can be run by an AI agent instead of a person, or by both: an agent can do the steps it is suited to and hand the trail to a person for a judgement call, and a person can hand it back. The agent works inside the process your team wrote: at every decision point it chooses among the paths an author defined, and every answer it gives is recorded on the trail like anyone else's. When a step needs to act on your own systems, the credentials can be kept in the Secrets Vault, which Floxar itself can never read.

Improve. Every run leaves a record: each step visited, in order and with times, every answer, and who did it, a person or an agent, including every hand-off between them. Analytics show where work waits, where it is reopened and why runs end the way they do. The people running a step can rate it and say what is missing or unclear, and the authors are told. A change to a flow applies to the next run, with nothing to deploy and nobody to retrain from scratch.

Why it is different

• Processes you run, not documents you read. The procedure and the work are the same thing, so the procedure is followed by construction instead of by memory.
• One process for people and AI agents. The same flow, the same steps and the same record, whoever runs it. You decide which work an agent takes on, and you can move work between agents and people at any step.
• AI within guardrails your team wrote. An agent does not improvise a procedure; it follows yours, one step at a time, choosing among the paths your authors defined. Its judgement still matters within each step, which is why every choice it makes is recorded and a person can take over at any point.
• A record of every run, not a sample. The record is produced by doing the work, not written up afterwards, so you can always see who did what, in which order, and why a run ended the way it did.
• Your processes stay yours, whatever AI you use. Your flows and the history of every run belong to your account, not to an AI provider. Change the model or the provider behind your agents at any time, or use different models for different work, and your processes stay exactly as they are. See Choosing AI providers and models.

The four building blocks

Everything in Floxar is made of four things.

Bits: the steps

A bit is the smallest unit of process content: a single, focused step. Each bit holds rich content such as text, headings, lists, images and video, together with interactive elements like checklists, dropdowns, text fields and date pickers. These elements are what make a step actionable rather than just readable: when someone works through the step, what they select or type is recorded on the trail. Bits are independent: a bit is written and maintained on its own, and the same bit can be connected into more than one flow, so a shared step only needs to be written once. Interactive elements lists every element and its settings.

Flows: steps connected into a process

A flow is a navigable sequence of connected bits: a process template. Every flow begins at a start bit. From each bit, connections point to the possible next steps; when a bit has several, whoever is running the flow chooses which path to take, so one flow can handle different situations, such as different handling for different case types. Flows can be tagged with categories, which makes them easier to organize, filter and find.

Trails: a record of every run

A trail is one run of a flow. When a person or an agent starts a flow, Floxar creates a trail, and as the run moves from step to step the trail captures each bit visited, the answers given and the time spent. Trails follow how work really happens: a trail can be paused and resumed, handed to a colleague or an agent, or left in a shared queue for someone else to pick up. A trail ends when it is completed or abandoned, and its full history stays available, so the work can always be reviewed. See Running and tracking trails.

References: supporting knowledge

References are read-only supporting documents behind your process content: policies, guides, FAQs, definitions and similar material. They are written with the same tools as bits but hold no interactive elements and are never steps themselves. Instead, they are linked to bits, and while running a flow you can open a linked reference without losing your place. References are searchable alongside bits and flows. See References and the process library.

Putting it together

Authors, human or AI, write bits and connect them into flows, with references for the knowledge behind them. People and agents run those flows, each run producing a trail, and hand work to each other as the process requires. The trails show how the work really went, and what you learn from them goes back into the flows. The result is work that is consistent while it happens, visible afterwards, and ready to be shared between people and AI agents.

Last reviewed: 2026-10-06