AI agents or automation: how to choose your company’s first project

The choice starts with the process, not the technology

Choose a company’s first AI project by examining the structure of the work. List one real request, the inputs it receives, the decisions required, the systems consulted, and the expected result. Then ask how many exceptions exist and whether the path to the result can be described in advance.

Automation is the strongest candidate when the rules are explicit, the inputs are structured, and every output can be validated in code. A workflow with a language model is useful when the text varies but the steps remain known. An agent makes sense when the system must decide which steps to execute, in what order, using tools and intermediate results to continue.

The editorial recommendation is to begin with the simplest solution that can be measured. Agentic systems often add latency, operating cost, and failure points. Anthropic’s reference also distinguishes workflows, which follow predefined paths, from agents, which dynamically direct their own process. It recommends increasing complexity only when that demonstrably improves the result.

Sources and references: [1]

A decision tree for the first project

Use this decision tree before choosing a platform or model. It turns an abstract discussion into a process diagnosis.

• 1. Can the work be described as if-then rules, with few ambiguous cases? If yes, start with traditional automation, integrations, validations, and queues. If not, continue.
• 2. Does the work have fixed steps, such as classifying, extracting fields, consulting a system, and drafting a response? If yes, implement a workflow. The model can interpret language, but code controls the sequence.
• 3. Are the categories clearly separated, with each one having its own instructions or tools? If yes, use routing to send the request to a specialized flow. Do not turn every category into a separate agent without evidence that this improves the result.
• 4. Does the number or order of steps depend on the content of each request? If yes, consider an agent with limited tools. Require stopping conditions, iteration limits, and records of its decisions.
• 5. Can the system change data, send messages, grant credit, cancel orders, or perform another irreversible action? If yes, treat this as a control project, not only a text generation project. Separate reading from writing, validate arguments, and require confirmation or authorization at the point of action.
• 6. Can you define what it means to resolve the case? If not, postpone the project or reduce its scope. Without an observable result, it is difficult to know whether autonomy added value or merely added complexity.

Sources and references: [1][3]

Hypothetical example: triaging internal requests

Imagine a company that receives requests by email and through an internal portal. Requests include system access, reimbursement questions, technical failures, and profile changes. The initial goal is not to answer everything automatically. It is to identify the category, extract useful data, route the request to the right team, and tell the requester what happens next.

The recommended first version would be a workflow. One model classifies the request as access, finance, technical support, profile, or undefined. A following step extracts structured fields such as the employee identifier, affected system, deadline, and ticket number. Code validates formats, checks existing rules, and sends the case to the appropriate queue. If the category is undefined, a required field is missing, or the data conflicts, the system sends the case to an exception queue instead of guessing.

Example input: “I need to recover access to the purchasing system. My username is ana.silva, and I need this resolved before today’s closing.” The structured output could be category access, system purchasing, user ana.silva, requested urgency today, and action open an access ticket. The response to the user simply confirms receipt and routing. It does not grant access or change permissions.

This case does not require an agent at the beginning because the steps are known. An agent could be considered later if complex requests required consulting several systems, discovering which information was missing, comparing policies, and choosing a variable sequence of queries. Even then, the tools should be narrow, with validated arguments and minimum necessary permissions.

Sources and references: [1][3]

When to promote a workflow to an agent

Promotion should be a decision based on observed cases, not an architectural preference. Collect representative requests, including short texts, typing errors, multiple intents, attachments, and requests that combine different subjects. Record where the workflow fails: ambiguous classification, missing data, an insufficient query, or the need for a variable order of actions.

An agent is justified when the path cannot be anticipated without creating a large rule tree, and when verifiable feedback exists at each step. For example, a tool reports that the consulted system is unavailable, so the agent tries an authorized alternative source or stops the case with an explanation. This differs from allowing the model to improvise actions without observing the environment.

Keep the agent small. Give it access only to the necessary tools, describe their parameters precisely, include examples of valid inputs, and make dangerous operations difficult to call by mistake. External text, such as received messages, can contain malicious instructions. Untrusted data should be isolated, converted into structured fields when possible, and prevented from directly controlling privileged tools.

Sources and references: [1][3]

How to evaluate before production

Do not evaluate the project based on the impression that its responses look good. Build a set of historical or synthetic cases that represents the expected traffic. Include normal examples, boundaries between categories, incomplete requests, multiple intents, attempts to mislead the system, and unexpected tool returns.

For the hypothetical triage system, measure at least: correct category, correct field extraction, selected queue, absence of improper action, handling of missing data, and clarity of the message sent. For an agent, also measure tool selection, argument accuracy, number of steps, respect for limits, and appropriate termination. OpenAI’s evaluation guidance recommends task-specific tests, case logging, and continuous evaluation after each change.

Also compare the cost of failure. Routing a common question to the wrong queue does not have the same impact as granting access, changing a profile, or sending private data. The initial architecture should be more conservative where the consequence is greater. A good test may require the system to return “unclassified” instead of producing a confident decision without sufficient basis.

Sources and references: [2]

Decision and implementation checklist

Use this checklist in a scoping meeting. If several answers are negative, reduce the project before adding autonomy.

• Define a single request or narrow family of requests.
• Describe the expected result in observable terms.
• Separate reading, classification, consultation, and writing tasks.
• Check whether the steps are fixed or genuinely depend on the case.
• Choose automation, a workflow, or an agent based on that difference.
• Define categories, required fields, exception states, and stopping conditions.
• Limit tools by function and validate every argument before execution.

Questions that prevent a poor first project

Does the process need to interpret language, or does it only move data between systems? If the answer is data movement, a conventional integration is probably sufficient.

What is the most serious action the system could perform by mistake? That answer defines permissions, confirmations, tests, and the autonomy limit.

What evidence will show that the new version is better than the current one? If there is no metric, test set, or stopping criterion, the project is not ready for implementation.