Agentic AI Workflows in Production: State, Tools and Human Review

Agentic AI workflows are multi-step processes in which a language model decides some of the next steps: which tool to call, what to look up, whether a result is good enough and when to ask a person. A chatbot answers a message. A fixed automation runs the same steps every time. An agentic workflow sits between the two: the path can change with the input, but it moves through steps your system defines.

That flexibility is the value, and also the risk. In production, the same qualities that let an agent handle messy, real-world requests also let it skip steps, loop, call the wrong tool or act on an invented fact. Teams that run agentic AI workflows reliably do not trust the model more. They give it a smaller, clearer job and surround it with code.

The pattern we use has five parts:

1. A state machine in code that owns the workflow.
2. Tool calls validated against schemas before anything happens.
3. Context scoped to the current step.
4. Human approval for actions that are risky or cannot be undone.
5. Tracing and evaluation on every step.

Write the workflow as explicit states and allowed transitions. For an inbound lead, that might be new, identified, qualified, booked, handed over and closed. The model can propose a transition and fill in the fields that justify it, but code checks the rules before the state changes. If the model marks a lead as qualified without a budget, the transition is refused and the agent is asked for the missing field.

Persist state in your database, not in the prompt history. That makes every run resumable after a timeout or a crash, lets a person pick up exactly where the agent stopped and gives you an audit trail for free. PostgreSQL is a perfectly good home for workflow state at early scale, as our note on database architecture for startups argues.

Set hard limits too: a maximum number of steps per run, a maximum spend per run and a timeout. An agent that starts looping should stop and escalate, not keep calling the model.

Tools are where agents touch the real world, so treat every tool call as untrusted input. Define each tool with a strict schema, using a library such as Zod or Pydantic, and validate the model's arguments before execution. On a validation error, return the error message to the model for one corrected attempt. If it fails again, stop and hand the step to a person.

A few more rules prevent most incidents we see in agentic AI workflows:

• Least privilege. Each tool gets only the access it needs. A booking tool cannot delete contacts.
• Idempotency. Every write carries a key, so a retry cannot double-book, double-charge or double-send.
• Read before write. Fetch live facts such as prices, stock and availability through tools at the moment they are needed, instead of letting the model recall them.
• Dry runs for bulk actions. Anything that touches many records first produces a preview that a person or a rule approves.
• Clear tool descriptions. Short, specific descriptions and few overlapping tools make the right choice obvious to the model, which is cheaper than correcting the wrong one.

Pasting every document, log and past message into the prompt feels safe, but long context costs more, runs slower and often makes reasoning worse, because the relevant detail is buried. Give each step only what it needs: the current state, the fields required for this decision, a short summary of earlier steps and the few retrieved passages that apply.

Small, fast models are useful here as filters. They can classify the request, pick the relevant documents or summarize a long thread before a frontier model sees it. Plain code handles anything a rule can decide. This tiering keeps cost and latency predictable as volume grows, and it makes each step easier to test on its own.

Decide which actions require a person before you build, not after an incident. In most agentic AI workflows the list includes anything that moves money, commits the business to a customer, sends messages at scale, changes permissions or deletes data.

Design the approval step as a product surface, not an afterthought. The reviewer should see what the agent wants to do, why, which sources it used and what happens on approval, and should be able to approve, edit or reject in seconds. Escalation works the same way in the other direction: when the agent is unsure, out of scope or asked for a person, it hands over with full context so nobody starts from zero.

On Skalix AI, the revenue platform we built, voice and chat agents follow defined conversation steps, sync qualified details to the CRM and hand the conversation to a human rep when it needs one. The handoff is part of the workflow, not a sign that it failed.

When an agent gets something wrong, you need to know which step failed and why. Log every run as a trace: the state at each step, the context sent, the model's output, each tool call with its arguments and result, and the cost and time of each call. Traces let you replay a failure, compare versions and spot loops or slow tools before users do.

Evaluate at two levels. End to end, check that the workflow reaches the right outcome on a golden set of real cases. Step by step, check that each decision and tool call was right, because a correct final answer can hide a wrong step that will fail next time. Our guide to evaluating LLM features before shipping covers golden sets, graders and release gates in detail.

Before an agent goes live, we check each of these:

• States and allowed transitions are defined in code and enforced.
• Every tool has a schema, least-privilege access and idempotent writes.
• Step, spend and time limits stop runaway runs.
• Risky and irreversible actions wait for human approval.
• Escalation hands over with full context.
• Every run is traced and can be replayed.
• A golden set passes end to end and step by step.
• Cost per run and response times are inside budget, with alerts.
• There is a fallback path when a model provider is slow or down.

If any item is missing, the agent can still be useful, but it should run in a supervised mode where a person approves its actions until the gap is closed.

Start with one workflow where the agent does a few well-defined steps and a person reviews the risky ones. Expand autonomy only as the traces and evaluation results earn it, one action type at a time.

If you are building a new product around an agent, our guide on how to build an AI MVP covers architecture, model tiers and a realistic timeline. If you want calls, chat and follow-up automated inside your own business, our AI workflow automation work is built on exactly these patterns. You can also request a free prototype of the workflow before committing to a build.