Field guide: designing a governed workflow end to end

Pick one job and write it down

Start with a single, bounded job, not a department. "Triage incoming requests and draft a reply" is a job. "Improve customer service" is not. Write the job as one sentence, name the person who owns the outcome and list what a good result looks like.

A bounded job makes every later decision easier: which tools, which knowledge, where a person decides, and what to look at when something goes wrong.

Map the steps before you build

Sketch the path on paper first: what starts it, what the agent does, which systems it touches, where the output goes. Then mark each step as read-only, reversible or hard to undo. The hard-to-undo steps are where approvals belong.

On the Cadrix canvas the same sketch becomes nodes: a trigger, an agent with its tools, conditions to route cases, a Human Input step for decisions and an output. Browse the example workflows by team for patterns to start from.

Give the agent only what it needs

• Choose the tools for this workflow. Leave out anything the job does not need.
• Store credentials as connections, so they are not pasted into prompts or nodes.
• Attach the specific knowledge base the agent should answer from, and tell it to say so when the material does not cover a question.

Place approvals before the hard-to-undo steps

Put a person in front of any step that sends something outside the company, changes a system of record, spends money or grants access. Decide who approves, and connect both the approve and the reject outputs. The approvals guide goes through placement and logging in detail.

Test with real cases, including bad ones

Use the test run in the editor with realistic inputs: a normal case, an odd one, an empty one and one the workflow should refuse. Read the run trace after each, step by step, rather than only the final answer. Fix the step that went wrong, not the symptom.

Decide who can change and run it

Set roles so that builders, runners and approvers are the right people. Put the workflow in the workspace for the team that owns it. If other systems will call it, create an API key with only the permissions that integration needs, one key per integration.

Deploy, then watch the first runs

Deploy when the test cases behave. For the first days, read the run list and open the runs that took long, failed or waited on a person. A failed step can be retried, or re-run with edits, and the original run stays on record.

Review on a schedule

Governance is not a launch task. Put a recurring review in someone's calendar: look at success rate, tokens and spend in the usage view, check which approvals were rejected and why, and refresh the knowledge the agent depends on. Change the workflow, test again, deploy again.

The checklist