Start with what needs to improve
“We want an AI agent.” It is an understandable request: demonstrations show systems that can search, reason and act. Designing something useful still starts with defining the work. Which task takes too long? Where do errors occur? Which decision comes too late? Who will use the result?
A team preparing the same report every week faces a different challenge from a team investigating unpredictable incidents. They may use similar models, while giving those models very different roles in the process.
At Logbrain, we start with these situations. Our role is to connect business needs with technical choices, then check that the chosen architecture delivers enough benefit to justify its cost and complexity.
Workflow or agent: who chooses the next step?
In a workflow, code defines the process: its steps, transitions and possible branches. Some steps may use a model to extract information, classify a document or write a summary. The process can run without human intervention and include loops; its orchestration is still defined in advance.
In an agent, the model dynamically chooses the next action based on a goal and the results so far. It can call a tool, examine the response, follow a lead or stop. That freedom operates within boundaries set by the application: available tools, permissions, execution time and required approvals. Anthropic describes this distinction in “Building effective agents”.
Enlarge the diagram. The diagram illustrates two ways of deciding what happens next. Their usefulness depends on the work to be done; one application can use both.
An example: understanding cloud costs
Consider an illustrative case: a company wants to understand its cloud bill. Behind that request are two distinct needs.
Produce a regular report
Every week, the team needs to collect spending data, allocate costs to projects, compare periods and flag changes above agreed thresholds. The calculations follow known rules. A workflow makes those rules explicit and testable, and produces the report in a consistent format.
A model can then write commentary based on the validated figures. Its task has clear limits: explain the changes present in the data. Amounts, comparisons and alert rules are still calculated by the system.
The potential benefit is concrete: less preparation time, fewer corrections and clearer information for project owners. Difficult cases also need attention, such as incomplete billing data or resources without a reliable team assignment.
Investigate an unusual increase
A project owner then asks: “Why have this project’s costs increased when its activity seems stable?” Answering may require several searches: comparing services, inspecting the resources involved, checking deployment dates or identifying a change in usage.
An agent may be useful when the findings from one search determine the next. It receives a defined scope of accounts and projects, read-only tools and a precise objective. Its output should be an evidence-based explanation that separates observed facts, hypotheses and missing information.
Here, the expected benefit concerns investigation time and the quality of the diagnosis. A recommendation to shut down or resize a resource then requires a review of dependencies and business consequences. A resource with little activity may, for example, support disaster recovery.
Combine the approaches when the need justifies it
In this example, a workflow can collect data and detect a deviation. An agent investigates cases that require exploration. The system then gathers the evidence into a ticket for a person to review before any sensitive action.
This division makes responsibilities clear: rules handle known processes, the agent explores uncertainty, and approvals govern changes. It also carries an integration cost. For a low volume of cases, or deviations that are easy to explain, a simpler procedure may be sufficient.
Execution frequency and interface are separate choices. A nightly schedule, a request in Teams or a conversation in Slack can all trigger the same process. Those entry points do not, on their own, determine whether the system is a workflow or an agent.
Questions that shape the architecture
How much of the work is predictable?
Describing a few real cases helps distinguish recurring operations from decisions that depend on successive findings. This makes it possible to introduce autonomy where it could help, while keeping explicit rules where they meet the need.
What would happen if the system made a mistake?
An internal summary, a response sent to a customer and an infrastructure change have different consequences. Permissions and approvals should reflect those differences. Define when the system must stop, ask for information or hand over to a person.
Can the available data and tools answer the question?
An investigation depends on the quality of the information available. Costs without project attribution, incomplete logs or overly broad permissions make the work harder. Tool access must respect the scope of each user and team. The model does not replace that organisation or its access controls.
Can the team maintain the solution?
Operating the system includes tracking errors, adapting to changes in tools, managing access and reassessing behaviour after a model change. The architecture needs to be understandable to the people maintaining it. Documentation, execution traces and recovery procedures belong in the initial design.
Measure ROI against the work actually done
The price of a model call is not enough to assess the solution. Costs include design, integration, hosting, tools, evaluation and maintenance. They also include the time people spend checking results and recovering tasks that fail.
We recommend comparing approaches on representative cases, using criteria agreed before the trial:
- Usable outcome: is the task completed correctly, with the evidence needed to use the answer?
- Total time: how long does it take to reach a validated result, including human rework?
- Cost per successful task: what is the full cost of producing a result that meets the agreed criteria?
- Control: are permissions, execution limits and approvals respected?
- Actual use: do teams use the solution, and is the time it frees up put to productive use?
Over a defined period, an ROI estimate can compare the financial value of the benefits with the solution’s full costs. Assumptions should remain visible. An hour saved creates available capacity; it becomes a financial saving when the organisation can actually convert it into one. Improvements in quality or risk reduction also need an explicit evaluation method.
A trial may show that an agent handles complex cases more effectively, while a workflow is a better fit for routine volume. It may also show that improving the data is a higher priority than adding more automation.
What about multiple agents?
Dividing work across several agents is worth exploring when research tasks can proceed independently or specialised contexts need to stay separate. This adds communication, coordination and evaluation work. Anthropic’s account of its research system illustrates this trade-off in the specific context of parallel research.
For any given project, the team still needs to establish whether this division improves the result. The number of agents or tools is not a measure of value in itself. What matters is the quality achieved, the time taken, the cost and the ability to diagnose failures.
Our approach: define, test, transfer
The first step is to define the need with business and technical teams: the expected outcome, constraints, risks and current baseline. We can then compare options within a limited scope, using the same cases, including exceptions.
The trial should support a decision: continue, adjust the architecture or drop an approach. Once an option is selected, moving to production includes operational responsibilities, controls, cost monitoring and knowledge transfer.
Choose the level of autonomy to fit the problem. Verify its value through results and the team’s ability to use them.
Have a process to improve or an experiment to scope? Let’s discuss your situation. We can help define the decision criteria and design a trial that gives you the evidence to choose.
Sources and further reading
- Anthropic — Building effective agents: the distinction between workflows and agents, and principles for designing them.
- Anthropic — How we built our multi-agent research system: experience from building a parallel research architecture.
