Quellix Insights / Guide

AI agents and orchestration. Built to stop at the right step.

A practical guide to AI agents that act across business tools: how to decide whether a workflow needs one, the parts a production agent needs, where agents fail, and what drives the effort.

By Quellix LabsUpdatedAI Agent Development Services

Use it for

Multi-step work across tools where some steps need interpretation and most cases are routine.

Skip it when

A stable rules-based task, or people only need answers, not actions.

The control that matters most

Approval gates before sensitive actions, with durable state so a retry never repeats a side effect.

The problem agents solve, and the one they create

A lot of operating work is not one decision but a chain of small steps: read a ticket, look up the account, check a policy, draft a reply, update the CRM, route the exception. The work keeps bouncing between inboxes, spreadsheets, CRMs and approvals, and people spend their day carrying context from one tool to the next.

Once software can send messages, change records or issue credits, the hard engineering is no longer the model.

A chatbot answers questions. An agent moves the work: it uses approved tools, prepares updates and routes the task, and it pauses when a person needs to decide. That difference is the reason to build one, and also the source of most of the risk. Once software can send messages, change records or issue credits, the hard engineering is no longer the model. It is permissions, task state, retries, approvals and a record of what happened.

The useful question is therefore not "can a model do this task?" but "can we define what the agent may do, where it must stop, and who owns the step when it does?" If those answers are clear, an agent can take the routine steps and leave the judgment to people. If they are not, the agent will either do too little to matter or too much to trust. For the distinction in more depth, read AI agent vs chatbot.

How to decide, including when not to build

Start with the simplest thing that meets the need. Many requests that arrive as "we need an agent" are better served by a rule in the existing helpdesk or CRM, or by a search tool that answers with citations. An agent earns its place when the work needs interpretation and tool coordination together.

Build when

  • The task runs across several systems and needs interpretation at one or more steps: classifying a request, reading a document, drafting a reply.
  • Most cases are routine, but the exceptions need human judgment, so routing and handoff matter as much as automation.
  • You can name the allowed tools, the forbidden actions, the approval points and the stop conditions before building.
  • Each step has an owner who will review, approve or take over when the agent pauses.
  • You can collect real examples, including messy and missing-data cases, to test against before launch.

Don't build when

  • The task is stable and rules-based. Existing CRM or helpdesk automation is cheaper to run and easier to audit.
  • People only need answers, not actions. A cited knowledge search is the better build; see the Enterprise Knowledge & RAG guide.
  • The decision has to happen in milliseconds, or no review, rollback or owner handoff can be defined for it.
  • Nobody can say which actions are off-limits. Without that boundary there is nothing to test or enforce.

Options, simplest first

SimplestMost involved

  1. A deterministic workflow first

    Use rules for the predictable steps and put a model only at the interpretation or drafting step where it adds value.

  2. A bounded tool-using agent

    Connect approved APIs or MCP tools with narrow permissions, durable task state, timeouts, retry limits and an inspectable action history.

  3. Multiple agents only when useful

    Separate research, drafting and review when the roles make evaluation or maintenance easier. Every extra agent adds coordination and failure points.

Reference architecture for a production agent

Every agent we would put in front of a business system has the same eight parts, whatever the model or framework. The order below follows a single task from trigger to handoff.

  1. 01Trigger and entry point
  2. 02Scoped context
  3. 03Planner and model routing
  4. 04Tool layer with strict schemas
  5. 05Durable task state
  6. 06Approval gates
  7. 07Step-level observability
  8. 08Handoff and fallback
Data inProcessingControl pointEvidence and output

  1. Trigger and entry point

    A clear event starts the task: a new ticket, an inbox request, a missing-field alert, or a chat or voice message that should lead to a controlled action.

  2. Scoped context

    The agent receives only the data needed for the current user, role and task. In a multi-tenant product, scoping happens before retrieval, so the agent cannot see another customer's records.

  3. Planner and model routing

    The model interprets the request and plans a short sequence of allowed steps. Routine steps can go to a smaller model when testing shows the quality holds; see routing before switching models.

  4. Tool layer with strict schemas

    Each action, such as placing an order, issuing a refund or updating a status, goes through a tool with narrow permissions and a strict output schema. Malformed outputs are dropped before they reach the system of record.

  5. Durable task state

    Task state is persisted outside the model call, with timeouts, retry limits and a receipt from the target system for every side effect. An interrupted task can resume without repeating an action. Durable execution covers this in detail.

  6. Approval gates

    Sensitive actions stop for an owner: sending an external message, changing a record, promising a refund. The gate shows the evidence and the proposed action together, so the reviewer can decide quickly.

  7. Step-level observability

    Every step records inputs, tool calls, outputs, approvals and errors, so a team can replay what happened. See step-level logging for agentic systems.

  8. Handoff and fallback

    When a step fails or confidence is low, the agent produces a visible handoff with the context, what it tried and the open question, instead of silently continuing.

Quellix calls this operating pattern the Reviewed Action Loop: a clear task, allowed tools, approval points, retry limits and handoff notes, so the work stays visible to the people who own the process.

Common failure modes

Most agent failures are ordinary distributed-systems failures with a model in the loop. They are predictable, which means they can be tested before launch.

  1. Duplicate side effects after a timeout

    A tool call times out, the agent retries, and the customer receives a second credit. Fix it with idempotency keys and by checking the target system's receipt before any retry.

  2. Lost state across pauses

    A task waits hours for an approval and resumes without the context it gathered. Persist the session and task state outside the model; see durable session layers.

  3. Tool permissions wider than the task

    An agent that can write to any CRM field will eventually write to the wrong one. Grant each tool the narrowest scope the task needs.

  4. Instructions arriving through data

    Tickets, emails and retrieved documents can contain text that reads like instructions. Treat tool output as data, and test forbidden actions and prompt-injection resistance explicitly.

  5. Off-policy commitments

    A friendly reply that promises a refund or a delivery date nobody approved. Check answers and actions against policy rules before they leave the system.

  6. Silent failure

    The agent stops, loops or gives up, and nobody notices until a customer does. Step-level logs, alerts and a defined handoff turn this into a visible queue item.

  7. Approval fatigue

    If every step needs sign-off, reviewers start approving without reading. Put gates at the actions that carry risk and let low-risk steps run with logging.

  8. Coordination overhead

    Splitting work across many agents can make a simple task harder to trace. Add agents only when separate roles improve testing or maintenance.

Cost and effort drivers

Agent cost is mostly integration and control work, not model calls. These are the factors that move a scope up or down.

  • Integration surface

    Clean, documented APIs are the cheapest path. Browser tasks and legacy systems often need a middleware layer that wraps the old system and syncs data both ways.

  • Action risk

    Read-only and draft-only agents are quicker to ship. Each writeback, external message or financial action adds approval design, validation rules and tests.

  • Recovery requirements

    Long-running tasks that pause for approvals or depend on slow systems need durable state, idempotent tools and resume tests.

  • Evaluation data

    Collecting real examples, edge cases and the correct outcome for each takes time from the people who know the work. It is also what makes launch decisions defensible.

  • Model calls per task

    Steps per task multiplied by context size sets the running cost. Model routing, caching and shorter context reduce it; measure it as cost per accepted outcome, not per call.

  • Operating after launch

    Monitoring, tuning and maintenance are scoped where the engagement needs them, because tools, policies and models change after release.

Quellix scopes this work in three steps: a free AI Fit Review of the workflow, a focused working POC for qualified opportunities, then production delivery against agreed milestones and acceptance criteria. See how we work and pricing.

Service and case studies

ServiceAI Agent Development ServicesHow Quellix scopes, builds and hands over this kind of system.

The case studies show workflow and review design. They do not establish a universal completion rate or authorize unrestricted autonomous actions.

Start here

The articles below go deeper on the parts of this guide that teams ask about most, in a sensible reading order.

  1. Durable Execution for AI Agents: When a Tool Times OutWhat safe recovery looks like when an agent times out after a side effect.
  2. Step-Level Logging for Agentic AI SystemsStep-level logs and traces that show what an agent actually did.
  3. Building AI Agents: What B2B Teams Should AutomateA decision framework for choosing which B2B work to automate.
  4. AI Agents: Workflows, Approvals, and GuardrailsWhere autonomy creates value, where controls belong, and when not to build.
  5. AI Agent vs Chatbot: Choosing the Right BuildHow to tell whether the workflow needs an agent or a chatbot.
  6. Evaluate AI Agents by ROI, Reliability, and RiskMeasuring agents by outcomes, failure modes, approvals and operating cost.
  7. Durable Session Layer for AI AgentsKeeping agent state across retries, pauses, approvals and handoffs.
  8. Human-in-the-Loop AI: Scaling Support Without RiskSupport triage that keeps people in control of critical escalations.

Every AI Agents & Orchestration article

All 19 published field notes in this cluster, newest first.

Browse by category: AI Agents & Orchestration

Next step

Have a workflow that keeps bouncing between tools?

Bring one workflow, the systems it touches and the step where a person has to decide. An engineer will map whether it needs an agent, a rule or neither.

Talk to an AI Engineer