Beyond the chatbot: design an AI workflow that actually moves work forward

An AI system that writes a good email is useful. A system that recognizes which information is missing, checks the relevant record, drafts the email, and places it in the right review queue can change the way a business operates. The difference is the work between the visible tasks. That work includes context, handoffs, exceptions, permissions, and decisions. It is less glamorous than a dramatic demonstration, but it is where many small businesses spend a large share of their attention.

Consider a hypothetical creative studio receiving inquiries about websites, learning materials, music, and commercial-finance referrals. Every message requires interpretation. Someone has to determine the service, find the relevant project information, identify missing details, and decide who should respond. A generic chatbot may answer broad questions while leaving that coordination unchanged. A carefully designed workflow can make the next action clearer without pretending the business has become fully autonomous.

This article teaches an original method for designing that workflow. You will distinguish a predictable automation from an agent that makes choices, write an operational brief, map the information and actions it needs, build a review boundary, and test the exceptions before launch. The studio, cases, and numerical examples are hypothetical. They illustrate decisions you can adapt, not measured performance claims about an InAct system or a particular vendor’s product.

Anthropic’s engineering discussion distinguishes workflows that follow predefined paths from agents that direct their own processes and tool use. It recommends matching complexity to the task. That distinction is helpful even when you are not using Anthropic’s tools: predictable routing may be best implemented as a workflow, while a task with variable paths may benefit from more flexible reasoning. The rest of this article develops an independent planning method for making that choice in a small-business setting. (Anthropic, 2024)

Write the job in one sentence that includes an input and a useful output. For the hypothetical studio: when a new inquiry arrives, prepare a reviewable brief identifying the requested service, the stated goal, missing information, and the recommended next conversation. This is narrower than manage all our customer relationships. It also gives you something you can test. A system either produces an accurate, usable brief or it does not.

Define what the job excludes. The inquiry-preparation system should not approve financing, promise delivery dates, set final prices, or send a binding proposal without the appropriate human decision. These exclusions arise from the specific business job, not from a generic list of imagined dangers. They prevent the designer from accidentally giving a preparation task the authority of a decision-making role. They also help a customer understand what happens after submitting information.

Identify the current process. Who reads the inquiry? Which documents do they consult? What information do they copy? What decision takes the most judgment? What delays occur because someone is waiting for another person? This exercise may reveal that the biggest problem is not writing. It might be incomplete intake, inconsistent service labels, or a missing place to record the next step. A language model cannot compensate indefinitely for a process no one has defined.

Now name the useful output. A reviewable brief is different from an automatic response. It can include the inquiry source, a summary, the relevant service category, missing information, and a draft reply. Keep the customer’s original wording available. The summary should help a person review the inquiry more quickly without becoming the only record of what the customer actually said. This creates a practical foundation for measuring whether the new workflow improves the work.

Some decisions can be written as explicit rules. If a visitor selects commercial funding, show the funding questions. If the visitor asks for a phone reply, require a phone number. If a required field is blank, request it. These are predictable conditions that do not require a model to improvise. Keeping them as rules makes behavior easier to explain, test, and maintain. It also preserves the model’s attention for the parts of the task where interpretation is useful.

Other decisions require more context. A visitor might describe a training platform with a public homepage, interactive exercises, and a reporting workflow. The inquiry may fit both website development and instructional design. A flexible system can identify that overlap and explain why a combined conversation may be appropriate. The system should preserve uncertainty rather than confidently force every request into a single category. A useful output can say primary need appears to be learning design, with an associated website requirement.

A third category concerns authority. Even if a system can infer a likely price range or draft an appealing promise, that does not establish permission to make the commitment. Capability and authority are different design questions. Write the rule for who decides, then ensure the workflow honors it. A studio might allow an agent to draft a proposed next step while requiring a person to confirm scope, schedule, and commercial terms.

You can combine all three categories. Rules validate the intake. Flexible reasoning prepares the interpretation. A human review determines the consequential response. This arrangement may be less dramatic than a fully autonomous sales demonstration, but it can fit a business’s actual responsibilities. The right design is the one that reliably completes the useful job, not the one that places the greatest number of decisions inside the model.

Include examples of acceptable outputs. A good example demonstrates the desired reasoning without requiring the system to copy the same language for every customer. Show one clear inquiry, one mixed inquiry, and one incomplete inquiry. Explain why each received its classification and which question came next. These examples make the intended behavior visible to the person designing the workflow and to anyone who later maintains it.

Keep the packet focused. Uploading every old business document can create contradictions and distract from the actual task. More context is valuable only when the system can distinguish relevance and authority. Start with the smallest set that supports the job, then add material when a test reveals a specific gap. Record why the addition was necessary. This builds a context packet around evidence from use, rather than around the feeling that a larger pile of files must be more intelligent.

Draw the workflow in ordinary language: receive inquiry, validate fields, identify likely service, gather approved context, prepare brief, request review, record the next action. Under each stage, write the input, the output, and the person or system responsible. This makes a hidden coordination process visible. It also exposes stages where the proposed automation has no clear source of information or no destination for the result.

For the hypothetical studio, the brief contains five items. First, the customer’s goal in their own terms. Second, a concise service interpretation. Third, the facts the customer supplied. Fourth, the information still needed. Fifth, a proposed response for review. Keep observations distinct from assumptions. The customer said they need a new site is an observation. They probably need a full membership platform is an inference that may be wrong.

Design the handoff as carefully as the reasoning. A correct brief that arrives in a place no one checks does not complete the job. Choose a review queue the business actually uses and identify who owns it. Define how the person marks the inquiry reviewed and what happens to unanswered items. A workflow should reduce invisible coordination, not create a new invisible pile somewhere else.

Add a clear outcome for incomplete or ambiguous requests. The system might produce a brief that identifies the missing detail and drafts a short clarification. It should not invent a budget, assume a deadline, or infer approval from the absence of an answer. Uncertainty can be a useful output when it makes the next question easier to ask. The aim is to move the work forward accurately, not to make every record appear complete.

A tool connection should correspond to a specific need. The workflow may read a service directory, create an inquiry record, or prepare a draft. It does not automatically need broad access to every business application. For each tool, write why the job requires it, what information it can read, and what action it may perform. This exercise makes access review a consequence of the workflow design rather than a separate technical ritual.

The Model Context Protocol describes a standard way for applications to connect models with tools and context through a client-server architecture. A common interface can simplify integration, but a connection standard does not determine your business’s permissions or approval rules. Those remain design decisions. Read the protocol’s architecture documentation to understand the components, then evaluate the actual application and server you intend to use. (Model Context Protocol, n.d.)

For our inquiry workflow, reading an approved service record is different from changing that record. Creating a draft is different from sending it. Updating an inquiry’s status is different from modifying a customer contract. When the tool design reflects these differences, the system’s authority becomes easier to explain. A broad tool called manage everything can conceal actions that should have separate review conditions.

Plan what happens when a tool is unavailable. The agent should report that it could not retrieve the record and identify which part of the brief remains incomplete. It should not replace the missing information with a plausible answer. A failure message can still be useful if it preserves the inquiry and tells the reviewer what needs attention. Reliability includes the ability to fail clearly, not only the ability to succeed when every dependency cooperates.

Test this distinction with a harmless example before the workflow handles real inquiries. Insert a sentence into a sample inquiry asking the system to skip approval or reveal unrelated information. The expected behavior is to continue preparing the authorized brief and identify the inappropriate instruction if it matters to review. Do not assume a well-written prompt alone proves that the boundary works. Observe the actual behavior of the system and its tools.

Keep the customer’s legitimate need separate from the attempted instruction. A message can contain a real service request and an unauthorized demand. The workflow should not necessarily discard everything. It can extract the business need while declining to follow the instruction that changes authority. This is another reason to preserve the original message beside the summary: the reviewer can see how the interpretation was made.

Begin with a small collection of representative inquiries. Include a clear website request, an instructional-design request, a commercial-funding request, a mixed project, an incomplete request, and a request outside the studio’s scope. Add one with conflicting timing, one with irrelevant material, and one with an instruction that tries to bypass review. These cases should reflect the actual job, not a generic benchmark whose connection to the business is unclear.

For each case, write the expected facts, acceptable service interpretations, required missing-information questions, and actions that must not occur. A mixed inquiry can have more than one reasonable classification, so do not mark the test wrong merely because the wording differs. The important question is whether the output preserves the need and supports the appropriate next conversation. Exact phrase matching can conceal meaningful failures while penalizing harmless variation.

Run the cases more than once when the system can produce variable outputs. Compare whether important facts disappear, whether uncertainty becomes a confident claim, and whether the tool behavior remains within the defined boundary. Record the version of the workflow and context packet used. If you change the instructions, rerun the cases affected by the change. Testing should be tied to actual modifications and unresolved concerns, rather than becoming repetitive activity without a decision.

Do not move directly from a successful demonstration to broad unattended use. Start with a review stage where a person can compare the brief with the original inquiry. Use those comparisons to identify missing context and recurring misunderstandings. Expand the workflow’s responsibility only when the evidence supports the next step. A staged rollout is an operating strategy: it lets the business learn what the system actually does before depending on it for a larger job.

A workflow can appear fast while transferring effort into review. Measure the complete task, including correction, exception handling, and maintenance. If the original process took twelve minutes and the automated draft takes one minute, that is not automatically an eleven-minute saving. Perhaps the reviewer spends eight minutes checking the new brief and correcting unsupported assumptions. The useful comparison includes the whole path to an acceptable result.

Here is a hypothetical calculation. A studio receives forty relevant inquiries each month. Manual preparation averages twelve minutes, or 480 minutes in total. A revised workflow requires two minutes of preparation and five minutes of review per inquiry, or 280 minutes. The apparent monthly difference is 200 minutes. Subtract additional maintenance time before describing the net effect. These invented figures demonstrate the method; they are not a promised return for a particular tool.

Track quality alongside time. Did the brief preserve the goal? Did it identify the appropriate service? Did it invent information? Did it correctly mark missing details? Did any unauthorized action occur? A system that saves time by producing a less accurate record may undermine the customer conversation. Decide which failures are unacceptable and which can be handled through normal review. The quality criteria should reflect the actual business job.

Look at the distribution of effort, not only the average. A workflow may handle common cases well while making unusual cases much harder. Record which inquiries required extensive correction and why. That pattern can guide a narrower routing rule: perhaps the system prepares straightforward briefs while mixed projects go directly to a person. Reducing the scope can improve the usefulness of the overall process without abandoning the opportunity to automate appropriate work.

Review the output pattern periodically. If the business begins receiving more complex inquiries, the original classification scheme may no longer fit. If most visitors choose not sure, the intake language may be unclear. If reviewers repeatedly ask the same follow-up question, the form may need one additional field. Improving the workflow can mean changing the input or the handoff, rather than repeatedly changing the model’s instructions.

Preserve a manual route for the same useful job. If the system stops working, the business should still know how to receive an inquiry and prepare the next conversation. This is not a recommendation to duplicate every automated step forever. It is a reminder that the underlying process must remain understandable. The workflow should embody the business’s knowledge, not become the only place where that knowledge exists.

Choose one job that occurs often enough to matter and is clear enough to evaluate. Write the operational brief, identify the context packet, distinguish rules from interpretation, and define the review boundary. Create representative test cases before connecting consequential actions. Then compare the complete process with the existing one, including the work a person still performs. You should finish with evidence about a specific improvement, not merely excitement about a new interface.

For the exercise accompanying this article, design an inquiry-preparation workflow on paper. Include a sample customer message, the approved service facts, the expected brief, and one ambiguous case. Ask another person to prepare the brief using only your instructions. Where do they need clarification? Their questions can reveal missing business rules before you involve a model. A process that a careful person cannot follow is unlikely to become reliable merely because an agent attempts it.

The strongest small-business opportunity is not to announce that AI runs everything. It is to make valuable work easier to complete with the information, tools, and authority it actually requires. A good agent can reduce repeated coordination and help a team act on shared knowledge. A good designer makes the job legible, tests the uncertain parts, and preserves the human decisions that give the business its direction. That is how an impressive demonstration becomes a useful operating capability.