A customer request arrives by email. AI summarises it, identifies the subject and suggests a response. But someone still needs to open the case, check the information, find the applicable terms, decide what happens next and update the tracking tool. The writing has moved forward. Much of the work remains.
This sequence is where an agentic workflow can help. It connects AI capabilities with tools and work steps, incorporating rules and human decisions. The aim becomes completing a request under the conditions the business requires.
At The Spark, we distinguish this from the agentic software factory used to build software. Here, agents contribute to the work the product enables: processing a case, preparing a service visit or handling a request. How they operate also affects how teams divide that work.
What we actually delegate to an agent
Take an illustrative example: a customer asks to change a service they have already ordered. This is not an account of a completed engagement. It allows us to follow the choices involved in designing this kind of process.
Someone receives the message and looks up the relevant order. They check what can still be changed, consult availability, ask for clarification if needed, then prepare a proposal. Once a decision has been made, they make the change and inform the customer.
Some steps in this journey follow stable rules. Finding an order by its number or checking that a date falls before a deadline can be handled by conventional software. Understanding a freely worded request, bringing together several pieces of information or preparing an explanation may warrant using a model.
The term “agentic” covers different degrees of autonomy. Anthropic distinguishes workflows with predefined paths from agents that have more freedom to choose their steps and tools. A single product can combine both. We can define the overall path and delegate the search for useful information to an agent within that framework.
The number of agents follows from what needs to be accomplished. For our example, one agent with a few tools may be enough, if experiments confirm that it performs the task correctly.
Which tools can support this process?
Platforms such as Dust and n8n can support these uses, from different starting points.
Dust lets teams create agents connected to company knowledge and tools. In our example, an agent could find the terms applicable to an order, relate them to the customer’s request and prepare a proposal for the team, depending on the connections and access configured.
n8n lets teams compose a process across several applications, combining conventional processing with AI agents. We could use it to organise receipt of the request, retrieval of the case, preparation of a change and updates to the tracking tool. Human approval can be required before a tool runs, for example before an action that commits the business.
These approaches can overlap. The choice depends on the tools already in use, the actions to perform and the people who will maintain the setup. An existing platform may cover much of the need; bespoke development can supplement connections or rules specific to the business. In every case, we still need to define what the agent is authorised to do and how to check that the work has been completed.
Define what “finished” means
Before building, we describe the expected outcome. For an accepted change, the order needs to be actually updated, the customer informed and the tracking record consistent. For an incomplete request, the right outcome may be a precise question sent to the customer and a case marked as awaiting a response.
This distinction matters: a well-written message does not prove that the order has changed. And a request handed over to a person may have been correctly handled by the workflow if it falls outside its authorised scope.
We therefore work with teams to clarify what can be completed automatically, what requires approval and what needs to come back to them. In our example, a change with no effect on price might follow a simple path. A commercial exception would remain subject to a human decision. These boundaries depend on the company’s commitments and the consequences of an error.
Making them explicit may also reveal an existing organisational problem: a rule interpreted differently, information without a reliable source or an unclear responsibility. That issue needs resolving so that people can understand how the workflow operates.
Connect tools without granting every permission
To prepare a change, the agent needs access to the order, the applicable terms and availability. That does not necessarily give it the right to change a price or issue a refund.
We separate access to information from permission to act. Boundaries need to be enforced by the tools and services that carry out operations. An instruction in the agent’s context is not enough to guarantee compliance.
The email’s content also remains data to interpret. Even if it asks to bypass an approval, it cannot grant new authorisation. This separation and the restriction of permissions are part of OWASP’s guidance for AI agents.
These technical choices translate into something very concrete for the team: it should be clear what the agent can view, prepare, propose and execute.
Design the point where a person takes over
In our example, an exceptional request reaches the commercial manager. To decide, they need to see the proposed change, its consequences, the relevant terms and any information still missing. Sending them an entire conversation to reread shifts the research work rather than making it easier.
Approval applies to a specific action. If the customer changes their request after the manager has agreed, that approval does not automatically cover the new proposal.
Waiting and incidents also need to be planned for. If no one is available to approve, the case retains an explicit status. If the order has been changed but the message fails to send, recovery needs to allow the message to be resent without applying the change a second time.
For this, we keep a record of actions performed, their results and approvals received. It helps us understand where the work stopped and resume from that state. It also allows a person to handle a case directly when the planned path is no longer suitable.
Evaluate the whole task, including recovery and rework
A demonstration using a straightforward request shows the principle. To decide whether to proceed, we use representative situations: a missing reference, similar orders, contradictory information, a commercial exception or an unavailable tool. Cases requiring intervention form part of the evaluation.
We examine what actually changed in the tools, whether the response was correct and whether permissions were respected. Anthropic’s work on agent evaluation highlights this distinction between what an agent claims to have done and the observable result of its actions.
We also measure the time teams spend checking, correcting and picking up interrupted work. Fast processing may lose its value if every case requires a lengthy review. Conversely, reliable preparation, even when subject to approval, can make work easier by bringing together the information needed for a decision.
The comparison is with the current process: delays, errors, handling time and cases left waiting. It helps us choose a useful level of automation, then adjust it based on use.
Build a process the team can evolve
We can start with a limited scope, allowing the agent to prepare actions without executing them. The team examines proposals using real cases they are authorised to work with, identifies errors and clarifies the conditions for moving to execution. This is the role of an experiment designed to inform a decision.
What follows requires the product and the team’s way of working to evolve together. Who maintains the rules? Who examines interrupted cases? How is a new commercial term incorporated? A change of model or tool connection needs to be testable against cases already encountered.
This is how we approach building agentic workflows at The Spark: starting from the work to be accomplished, the tools used in the business and the people responsible for it. Value is judged by the requests completed, the time the team spends on them and its ability to understand and correct what happens.