Do you need an answer, a workflow, or an agent?

A chat window does not tell you how the system works

“Chatbot” describes a conversational experience. “Agent” often describes how a system selects and carries out work. The terms overlap. A chatbot can look up a record or start an approved process; an agent can run from a queue without anyone opening a chat window. Ask what happens behind the interface.

Anthropic’s Building effective agents distinguishes workflows that follow predefined code paths from agents that let a model direct the process and tool use. That architectural distinction is useful for a buyer. It is not a promise that every product sold as an agent behaves the same way. The linked source supplies the distinction; the buying examples and worksheet below are DBAI’s own.

Compare the same business request three ways

Take a hypothetical order-status request. An assistant reads the authorized order record and explains the current status. That may solve the problem completely. A fixed workflow can also route a missing shipment scan to an operations queue using predefined rules. Neither job automatically requires an agent.

Now suppose the job is to investigate why an order is delayed. Depending on the evidence, the system might inspect stock, a production record, or a carrier update, then decide what to check next. That is a candidate for agent-directed investigation. The investigation still needs a boundary: proposing a recovery plan does not grant permission to change the order, issue a refund, or promise a delivery date.

Ask your provider to demonstrate the smallest version that completes the job. If a lookup plus a reliable handoff is enough, stop there. If the work requires variable investigation, compare the agent approach against a simpler baseline on the same cases. Record completion quality and the effort your staff spends checking the result.

Separate reasoning from permission

A system can choose its next research step while remaining read-only. A fixed workflow can make consequential changes when it has permission. More autonomy and more authority are separate design decisions. Make both explicit in the proposal.

• Read: identify the records the system may access and enforce the requesting user’s account scope.
• Prepare: distinguish a suggested action or saved draft from a committed change.
• Commit: specify exactly which changes are allowed and which need approval.
• Stop: define the unresolved conditions, tool failures, and effort limits that return the job to a person.

The approval must apply to the actual action and record being changed. “A manager approved the project” is different from “a manager approved this order change.” Ask to see the action record and final system state, not just a chat message claiming success.

DBAI example: one platform, different jobs

DBAI’s published Exora INK case study describes a customer chatbot, an internal staff assistant, and catalog automation connected to the storefront’s data layer. The catalog pipeline ingests and normalizes a SanMar feed through n8n before synchronizing WooCommerce. The customer assistant handles product questions and routes quote requests to the team.

Those are distinct responsibilities inside one platform. The example supports separating conversation, data movement, and staff assistance when you scope a project. It does not establish that every component makes autonomous decisions, or that an agent would outperform the existing workflow. The system’s name should not substitute for evidence about its behavior.

Give vendors a job brief they can demonstrate

# System selection — one business job
Request or trigger:
Who needs the result:
What counts as a completed job:

## Shape of the work
Can an answer or draft complete the job?
If actions are needed, are the steps and branches known?
Which decisions depend on evidence discovered during the run?
Simplest baseline to compare:

## Authority
Approved sources and record scope:
Allowed read operations:
Allowed draft operations:
Allowed committed changes:
Actions requiring approval, and approver:
Stop conditions and human handoff:

## Demonstration
Ordinary case:
Missing or contradictory information:
Unavailable tool or integration:
Repeated request that must not duplicate a change:
Evidence to inspect in the destination system:
Staff review effort to record:
Decision: assistant / fixed workflow / agent / combination

Watch the failure path before you buy

Give each provider the same ordinary request and a case with a missing fact. Then ask what happens when an integration fails after a draft has been saved. Does the system preserve its progress, create a duplicate, invent a result, or return an actionable handoff? Use approved test records and inspect the destination system.

For an answer-focused assistant, inspect whether the response matches its source and whether uncertainty is visible. For a workflow, inspect the expected sequence and resulting records. For an agent, inspect the tool actions and outcome across different paths. In every case, measure the business job rather than the fluency of the demonstration.

You can begin with a read-only assistant and add a bounded action later if the evidence justifies it. Write the next permission boundary as a separate acceptance decision. That keeps the project tied to useful work as its capabilities grow.