Look for a team that engineers the whole execution path, not only the prompts: workflow design, adapters for older systems, saved state, retries, idempotency, rollback, permissions and human approval. Then test each candidate with a failure scenario from your own estate, such as a write that times out halfway, and judge them on how they recover it.
What a multi-step agent needs from a partner
A multi-step agent reads from one system, decides something, and writes to another. A typical chain might read a customer record from a CRM, check a balance in a billing system, call a third-party API and update an ERP. Every step crosses a boundary owned by a different team, with its own authentication, its own error behaviour and its own idea of what "done" means.
The model is a small part of that work. Most of the engineering sits around it, and that is where a partner earns its place:
- Workflow design. Deciding which steps need model judgement and which should be plain, deterministic code.
- Interfaces to older systems. Adapters for SOAP services, stored procedures, file drops, message queues and, where nothing else exists, screens.
- State. Recording where a task has reached, so it can resume after a crash or a timeout rather than start again.
- Idempotency and compensation. Making sure a retried step does not repeat a payment or a record change, and knowing how to undo a step when a later one fails.
- Identity and permissions. Carrying the identity the agent acts for into every call, enforced by the system underneath rather than by the prompt.
- Approval. Putting a named person between a proposed change and its execution where the change matters.
- Evidence. Traces and audit records that let someone reconstruct what happened, step by step.
A partner who talks mostly about models and prompts is describing a small fraction of the job.
Screen for workflow judgement before agent enthusiasm
The most useful early signal is a partner willing to say "this step should not be an agent". Anthropic's engineering guidance on building effective agents separates workflows, where models and tools follow predefined code paths, from agents, where the model directs its own process, and recommends the simplest solution that works.
For a multi-step process across several systems, the right design is often mostly workflow with a few points of model judgement: classifying an incoming request, extracting fields from an unstructured document, or drafting a proposal for a person to review. A partner who wants to make every step autonomous is adding risk you will pay for in testing and operations. The posts on when an AI agent is the wrong solution and agentic AI versus AI automation go further into that distinction.
Ask how they reach systems with no clean API
Legacy systems rarely offer a tidy REST API. Ask each candidate how they would reach every system in your chain, and what they would build to make that access safe. Useful prompts:
- A SOAP or older RPC service. How do they wrap it as a narrow, named operation the agent can call, with validation on the way in?
- A database with business rules in stored procedures. Do they call the procedures, or write to tables directly and bypass the rules?
- A file exchange or batch job. How does the agent know when its request has actually been processed?
- A system with only a user interface. When is browser automation acceptable, and what makes it fragile? The post on whether an agent should use a browser or an API covers the trade.
- A message queue or event bus. How do they handle duplicate and out-of-order messages?
Good answers describe an adapter that does more than pass calls through: it validates, limits, records and refuses. The post on making existing systems agentic without a rewrite explains what that adapter layer has to do.
Give them a failure scenario and listen to the answer
The fastest way to separate a delivery team from a demonstration team is a concrete failure. Take one from your own estate, or use this hypothetical:
An agent handles a customer's request for a goodwill credit. It reads the account in the CRM, checks the billing history, issues the credit through the payment provider, then updates the ERP and emails the customer. The payment provider confirms the credit, but the ERP update times out.
A strong answer covers most of the following without prompting:
- The credit was issued with an idempotency key, so a retry cannot credit the customer twice.
- The task's state was saved after each step, so it resumes at the ERP update instead of starting again.
- The ERP write is retried a limited number of times with the same key, then handed to a person with the evidence attached.
- The customer email waits until the ledger and the ERP agree.
- The credit itself sat behind an approval, because it moves money.
- Every attempt, success and refusal appears in the trace, linked to the original request.
Weak answers sound like "the model will work it out", "we retry until it succeeds" or "we add monitoring after launch". The posts on what an agent should do when a tool call fails and running agent tasks that take days describe the mechanics a good answer relies on.
Check where approval sits in the sequence
In a multi-step workflow, the question is not only whether a person approves, but what they approve and when. CodeDTX's working principle is Agents propose. Humans decide. Systems execute. The agent gathers evidence and prepares a complete proposed change. A person with the authority approves that specific version. A separate executor carries out only what was approved.
Ask each candidate to show you where approval would sit in your workflow, what the reviewer would see, and what happens if the underlying data changes between approval and execution. The post on keeping a human in the loop without friction describes how to do this without turning review into a bottleneck.
Questions to put to every candidate
- Which steps in our workflow would you make deterministic code, and why?
- How will the agent reach each system, and what does each adapter enforce?
- Whose identity does each call carry, and where is that permission checked?
- How is task state stored, and how does a failed task resume?
- Which steps are idempotent, and how do you compensate for a step that cannot be undone?
- Where does human approval sit, and what does the reviewer see?
- How will you test the workflow before launch, including the paths where something fails?
- What will we be able to see in production, and who operates the agent after launch?
Warning signs in a proposal
- A demonstration that only ever runs the happy path.
- One service account with broad access for every system in the chain.
- No mention of retries, timeouts or partial failure.
- Approval described as a chat message rather than a recorded decision tied to a proposal.
- Evaluation and monitoring scheduled for "phase two".
- No clear answer to who runs the system after handover.
How CodeDTX approaches this work
CodeDTX is an enterprise AI product engineering company. We build and modernise production web, mobile and backend systems, and engineer AI into them. Multi-step agents that span existing systems are part of our AI agent development work, and reaching older systems safely is the core of our enterprise AI integration work. If you want the longer argument for why demonstrations stall, read why AI prototypes fail in production. To walk through a failure scenario from your own estate, talk to CodeDTX.
Frequently asked questions
Should a multi-step agent be one agent or several?
Usually one agent, or a single workflow with a few points of model judgement, is easier to test, observe and govern. Several cooperating agents add handoffs, shared state and questions about accountability. They can make sense when steps need genuinely different tools, permissions or owners. Ask a partner to justify each additional agent in terms of a boundary it enforces, not as an architectural preference.
Do we need to modernise our legacy systems before adding agents?
Not usually. Agents can reach existing systems through interfaces those systems already expose, or through a thin adapter built for the purpose. What matters is whether a narrow, governable interface can be put in front of each system. Modernisation may still be worth doing, but it should be driven by the system's own needs, not treated as a precondition for every agent.
How do we compare partners who all claim agent experience?
Give every candidate the same failure scenario from your own workflow and compare the answers. Look for idempotency, saved state, limited retries, compensation, approval before consequential actions and a usable trace. Ask to see the artefacts they would hand over: tool contracts, test cases, runbooks. Specific, inspectable answers separate engineering teams from teams that mainly demonstrate models.
What should the first piece of work with a new partner be?
A small, paid piece of work on one real workflow, with agreed acceptance evidence. It should include the integration to at least one awkward system, an evaluation set, and the failure handling, not just a happy-path demonstration. That shows how the partner works on your estate before you commit to a larger programme, and leaves you with artefacts you can keep.
