Skip to main content

Designing AI workloads with Floxar

Putting an AI agent to work on a real process is mostly a design question: what the agent should do, what it should leave to code, and when it should hand over to a person. These patterns describe how to answer it with Floxar. They apply whichever agent you use: one you build, an AI client your people connect, or, once it is available, the Operator.

Give the agent one instruction: follow the process​

Keep the agent's own instructions short and general: understand the request, find the approved flow for it, start a trail, follow it step by step, use the systems the current step calls for, record what happened, and hand over when the flow says so. Everything specific to the work belongs in the flow, where your team can read it, change it and see how it ran. The more of the procedure that lives in the agent's instructions instead, the less of it you can see or improve.

Write steps an agent can carry out​

  • One action per step. A step that asks for one thing gets one clear answer and a clean record.
  • Say what to record. Use interactive elements for every fact the process needs later, and mark them required when the process cannot go on without them.
  • Make decisions explicit. At a decision point, the step's content should state the criteria for each path, so the choice can be checked afterwards.
  • Name the system and the action. "Look up the customer's open orders in the order system" is something an agent can do; "check the customer's history" is not.

Leave exact answers to code​

A language model is good at understanding people and following instructions; it is not a calculator or a rules engine. Anything with one correct answer, such as an eligibility decision, a price, a tax amount or a validation, should be computed by a service your agent calls. The Floxar step says which service to call and what to record, and the next step branches on the recorded result. The decision is then exact, repeatable and visible on the trail.

Decide where people come in​

  • Hand over on purpose. Put the hand-off in the flow: a step that says "transfer to the claims specialists' queue" when a case needs judgement. A hand-off is a correct outcome, not a failure.
  • Leave a note. Before handing over, the agent should write what it did, what it knows and what the person needs to decide, so nobody repeats work.
  • Let work come back. After a person decides, the trail can go back to a queue the agent watches, and the agent continues from that step.
  • Keep risky actions with people. An action in another system that cannot safely be repeated or undone is a good candidate for a person to confirm.

Keep credentials out of the conversation​

When a step needs access to another system, the agent should take the credential from the Secrets Vault at the moment of use, with access granted for that agent and that credential only. Credentials never belong in a step's text, an answer on the trail, or the agent's instructions. See Working with credentials.

Start small, then widen​

  1. Pick one frequent, well-understood process and write it as a flow.
  2. Run it with people first, and tighten the steps until runs are consistent.
  3. Let an agent run the steps it handles well, with hand-offs for the rest.
  4. Watch the trails and analytics: where runs wait, where they are reopened, where people take over. Move more steps to the agent as the record shows they are handled well.

Measure what the agent does​

Every run an agent makes is recorded the same way as a person's, so you can review individual trails and compare outcomes in analytics. Feedback on individual steps, from people and agents, shows authors where a step is unclear or missing something. Use the record to decide what an agent should take on next, not guesswork.

For how Floxar relates to the rest of an AI system, see Where Floxar fits in an AI stack.

Last reviewed: 2026-10-06