Where Floxar fits in an AI stack

An organization that puts AI agents to work on real tasks ends up with several layers of technology, each answering a different question. Floxar is one of those layers: the one that holds how your organization expects the work to be done, and records what actually happened when it was done. It is not the AI that does the work, and it does not replace the systems the work touches.

The layers of an AI workload

Take a customer who calls about changing their insurance policy, and an AI agent that answers. Several separate things have to work together:

Layer	The question it answers	Examples of what lives there
Channel	How does the request arrive and how is the answer delivered?	Phone and voice, chat, email, a web form, an event from another system
AI model and agent	What does this person mean, and what should I say or do next?	A language model, the agent software around it, speech recognition and synthesis
Process (Floxar)	What is the approved way to handle this, where are we in it, what has happened, and what comes next?	Flows, steps, required answers, decision points, hand-offs, the record of each run
Knowledge	What does the organization know that bears on this?	Policies, product information, manuals, past cases, searched on demand
Systems of record	Who is this customer, and what do our systems say?	Customer records, billing, orders, scheduling, internal services
Rules and calculations	What is the exact answer to a question that must not be guessed?	Pricing, eligibility, risk scores, validations, run by deterministic code
Credentials	How does the agent prove it may act in another system?	Keys and passwords, held where the agent can use them without exposing them
People	Who decides what the agent should not decide alone?	Specialists, approvers, supervisors, the team queue

These are different concerns, and each is best served by a part built for it. A model that understands a caller well is not the right place to keep your approved procedure; a customer database is not the right place to record how a case was handled; a knowledge base is not the right place to decide what happens next.

What the process layer does

Without a process layer, an agent is typically handed a long set of instructions, a pile of documents and a list of tools, and left to work out the procedure each time. That works in a demonstration and becomes hard to trust in production: the procedure lives inside instructions for one particular model, nobody can say which steps were taken on a given case, and changing the procedure means rewriting and retesting the instructions.

With Floxar, the agent is told something simpler: find the approved process for this work, start a run, follow it one step at a time, use the systems the current step calls for, record what happened, and hand over to a person when the process says so. Floxar supplies:

• The approved procedure, one step at a time. A flow your team wrote, with each step stating what to do and what to record. The agent sees only the current step and the paths that lead on from it.
• Required answers. A step that needs information cannot be left until it is given, for an agent as much as for a person.
• Hand-offs between agents and people. A run can move from an agent to a person and back at any step, with everything recorded so far carried along.
• A record of every run. Each step taken, each answer, each choice of path, who made it and when. See Running and tracking trails.
• Change without redeployment. Improve a flow and the next run follows the new version, whichever agent or person runs it.

What stays outside Floxar

• The AI itself. Floxar does not need to be your model provider. Your agents run on the models and in the places you choose, and they work with Floxar through a defined, permissioned connection. See Registering an agent.
• Your business systems. Floxar does not replace your customer, billing or scheduling systems. A step tells the agent which system to use and what to do there; the agent does it with its own access.
• Exact rules and calculations. Anything that must be computed rather than judged, such as eligibility or a price, belongs in code or a rules service your agent calls. The Floxar step says to call it and record the result; the model should not work it out from prose.
• Credentials. Keys the agent needs for other systems can be kept in the Secrets Vault, released to a specific agent for a specific step, and never readable by Floxar itself.

Following a request through the stack

1. The customer calls. The channel turns speech into text, and the agent works out that they want to change their policy.
2. The agent finds the matching flow in Floxar and starts a trail for this call.
3. The first step tells it to identify the customer; it looks them up in the customer system and records who they are.
4. A later step tells it to check whether the change is allowed. It calls the rules service, records the result, and takes the path the result points to.
5. A step that needs a judgement, such as an unusual circumstance, tells it to hand over. It writes a note saying what it has done and what is left to decide, and transfers the trail to the specialists' queue.
6. A specialist picks it up, sees every step and answer so far, decides, and finishes the run or hands it back to the agent.
7. Afterwards, the trail shows exactly how the case was handled, and analytics across many trails show where this kind of work waits, fails or needs a person.

Choosing your models and tools freely

Because the procedure and the record live in Floxar rather than inside one model's instructions, you can change the model, the agent software or the channel without rewriting how the work is done. The same flows can be run by a voice agent today, a different agent tomorrow, and a person whenever one is needed. See Floxar, documentation and knowledge for how Floxar sits alongside the documents and knowledge bases you already have, and Designing AI workloads with Floxar for practical patterns.

Last reviewed: 2026-10-06