The situation
Marchant Plant Hire runs fourteen depots along the east coast, hiring excavators, telehandlers, generators and scaffolding to builders. Around six thousand hire contracts are live at any time, and the depot offices between them handle several hundred calls and emails a day.
Three of those jobs came up for automation in the same meeting, with the same proposal attached to all three: build an agent.
The first is contract questions. Does my hire cover a broken hydraulic hose? Am I charged for the weekend the site was shut? What happens if I keep the machine an extra week? The answers sit in the hire terms, the damage-waiver schedule and roughly two hundred pages of depot procedure. Staff find them by reading.
The second is rescheduling a delivery. A customer rings on Tuesday to move Thursday’s excavator drop to Monday. Someone checks whether a machine of that class is free at that depot on Monday, moves the booking, and sends a confirmation. Four minutes a time, ninety times a week.
The third is the Monday utilisation report. Pull hire days by asset class and depot for the week just gone and compare them against the fleet on the books. Work out which depots ran short and which sat on idle plant, then have it in the regional managers’ inboxes by seven.
What actually matters
Start with what an AI agent is, since the word has been doing loose work in that meeting. An AI agent is a foundation model given a goal in plain language, a catalogue of tools it is allowed to call, and a record of what it has already done, then put in a loop: read the goal, pick a tool, see what came back, decide whether to call another tool or stop and answer. Nothing fixes the order in advance, which is what makes an application agentic AI and how it finishes multi-step tasks whose steps nobody could write down when the request arrived.
Set that against the two things it is not. A single prompt is one call: text in, text out, nothing outside the reply changes, and the model cannot look anything up or alter anything. A fixed sequence of steps written in code is the other kind of certainty: the system takes real actions, and it never decides which ones, because that was settled when the code was written. An agent both acts and decides, and it pays the price of both.
AI agents’ business applications cluster in a short list worth knowing: customer service that can act on a request rather than only answer it, IT and HR request handling such as access requests and leave bookings, and booking and scheduling. Research and data gathering across several systems belongs on the list too, as does multi-step back-office processing such as matching an invoice to a delivery note and a purchase order. Running through all of them is work that crosses more than one system, where what to do next depends on what the last step gave back. The question in front of the meeting is which of these three jobs has that shape.
Two questions sort them. Does the job change anything outside the reply, and were the steps knowable before the request arrived? Contract questions change nothing and the answer already exists in a document; there is nothing to decide, only something to find. The Monday report changes nothing outside a spreadsheet and an email, and it runs the same eleven steps every week, on a schedule, with no request to react to. Rescheduling is the odd one out. Step two depends on what step one returned: if Monday is free, move the booking; if it is not, the conversation becomes a negotiation about Tuesday, a smaller machine, or a different depot, and there is no fixed script for that.
Cost behaves differently for each. A single prompt and a fixed sequence both cost a known amount per request, because the number of model calls is written down. An agent’s cost is not knowable in advance, because the loop runs until the model decides it is done. A reschedule that resolves in three turns and one that thrashes through fifteen are the same request as far as the customer is concerned. On the bill they differ by a factor of five, which is worth reading alongside what actually drives a token bill.
The last thing to weigh is what a wrong action costs. Retrieving the wrong clause produces an answer somebody can query. Moving the wrong booking sends a nine-tonne excavator to the wrong site on the wrong day, and somebody pays for the truck either way. The jobs that give an agent something useful to do are the same jobs where its mistakes leave the screen.
What we’ll filter on
- Step order: were the steps knowable before the request arrived, or does the request decide them?
- Side effects: does the job change something outside the reply, and what does a wrong action cost to undo?
- Where the answer lives: in our own documents, in our live systems, or already in the model?
- Cost per request: is the number of model calls fixed in advance or decided at run time?
- Latency: is somebody on the phone waiting, or does this run overnight?
- Debuggability: can somebody reconstruct afterwards what happened and on what basis?
The landscape
Four ways to put a foundation model behind a business job, in ascending order of what they can do and what they cost to run.
A single prompt
One call. A system prompt carrying instructions and whatever context the application chose to include, the user’s message, and the reply. The model holds nothing between calls, reaches nothing outside the prompt, and changes nothing. It is the cheapest and most predictable arrangement, and it is limited to what the model already learned plus what fits in the context window you send it.
For general knowledge and for tasks that are pure language work, such as rewriting a paragraph or classifying a message, this handles the job outright. For anything about this company’s own documents, it produces fluent text about equipment hire in general.
Retrieval Augmented Generation
Search first, then answer. The documents are indexed, the incoming question retrieves the handful of passages most likely to contain the answer, and those passages go into the prompt alongside the question. The model answers from what it was handed and cites where it came from. Amazon Bedrock Knowledge Bases does the indexing, retrieval and prompt assembly as a managed service, and answering questions from your own documents works through that setup in full.
Two model calls at most, a bounded cost, and an answer a supervisor can check against the clause it quotes. It still changes nothing outside the reply.
Workflow orchestration
The sequence is settled before any request arrives and driven by ordinary application code: query the hire ledger, join it against the fleet register, compute the ratios, render the table, send the email. A model gets called only where language is the hard part, such as turning the numbers into two paragraphs a regional manager will actually read, and never to decide what happens after that. On AWS this is a scheduled Lambda function, or Step Functions where the sequence has branches and retries worth managing separately.
The cost of a run is therefore known before it starts, and the log lists the same steps in the same order every time, so a failure names the step that broke.
An AI agent
The loop described above, pointed at a catalogue of tools with descriptions and expected inputs. Nothing about the model changes; what changes is that it is now allowed to look things up in the hire ledger and move a booking, and that it picks the order in which it does so. Two capabilities come with that shape. Tool usage is the catalogue itself, and the tool descriptions are what the model reasons over when it chooses, so a vague description is a wrong tool call waiting to happen. Memory management is what carries between turns and between conversations, which for a reschedule means the booking under discussion now and the customer’s usual delivery window months later; those two stores behave differently enough to be designed apart.
Three AWS pieces build one. Strands Agents is the open-source framework: describe the model, the tools and the job, and it supplies the loop. Amazon Bedrock AgentCore is the managed runtime for production, supplying session isolation, memory, identity and a trace of every turn, whichever framework and model you built with; wiring a model to actions that change things works through that plumbing. Model Context Protocol (MCP) is the open standard a system exposes its capabilities through once, so any agent that speaks it can discover and call them without a hand-written adapter each time. Framework builds it, runtime runs it, MCP connects it; where each sits in the wider AWS picture lays them out beside the other services.
Evaluation
Side by side
| Option | Steps fixed in advance | Cost per request known | Can change something | Fast enough for a live call | Straightforward to debug |
|---|---|---|---|---|---|
| A single prompt | ✓ | ✓ | ✗ | ✓ | ✓ |
| Retrieval Augmented Generation | ✓ | ✓ | ✗ | ✓ | ✓ |
| Workflow orchestration | ✓ | ✓ | ✓ | ✓ | ✓ |
| An AI agent | ✗ | ✗ | ✓ | ✗ | ✗ |
Read the last row against the other three. Everything an agent can do that they cannot comes from the same property: the model decides the sequence at run time. That is also why its cost, its latency and its audit trail all go soft at once. No configuration setting separates those; they arrive together.
The debuggability column deserves a caveat, because an agent is not opaque so much as expensive to reconstruct. AgentCore records each turn’s tool calls, inputs and results, so the trace exists. Reading it takes longer than reading a fixed sequence, because you are working out why the model chose what it chose rather than which line of code ran.
Latency is marked ✗ for the agent because a loop of four or five turns, each one a model call carrying the conversation so far, lands somewhere in the tens of seconds. That is fine when a customer is typing into a chat window and knows work is happening. It is poor when somebody is holding a phone.
Matching the three jobs
Three jobs that arrived as one proposal come out of the grid as three different builds. Nothing about running an agent for the third makes an agent the right shape for the other two.
The solution
Contract questions get Retrieval Augmented Generation. Index the hire terms, the damage-waiver schedule and the depot procedures into a Bedrock Knowledge Base, retrieve against the customer’s question, and answer from the retrieved passages with the clause reference attached. No tools, no loop, and an answer a supervisor can check in seconds. The document set changes when legal amends a wording, and re-indexing takes minutes.
Rescheduling gets the agent, with a deliberately small tool set: check availability for an asset class at a depot on a date, move an existing booking, and send a confirmation. Build it with Strands Agents and run it on Amazon Bedrock AgentCore, which gives per-session isolation, a place for memory management to live, and a trace of every tool call. Where the depot systems already expose their capabilities through Model Context Protocol (MCP), the agent connects to them through the protocol rather than through three hand-written adapters, and adding a fourth system later becomes configuration.
Three gotchas come with that choice. Every tool added to the catalogue widens the set of things the agent can get wrong, so a tool exists because a reschedule genuinely needs it, and a request for one more tool is a request for one more failure mode. The cost of a request is unbounded, because the loop length is decided at run time, so cap the turns and have the agent hand off to a human when it hits the cap. And side-effecting tools need protecting. Put a confirmation step in front of the move, so the agent proposes the change and the customer or the depot clerk accepts it. Give the move an idempotency key, so the same instruction retried after a timeout moves the booking once rather than twice.
The Monday report gets workflow orchestration. A scheduled job queries the hire ledger and the fleet register, computes the ratios, and calls the model once to turn the table into two paragraphs of commentary. Same steps every week, cost known before it runs, and a failure that points at a query rather than at a decision. Using an agent here would replace a job that always works with one that mostly works, for more money.
Worked example
The reschedule that goes through
Tuesday, 2:40pm. A customer messages: “Can we push Thursday’s 5-tonne to Monday? Same site.”
The agent has the customer’s live contracts in its short-term context, so it knows which booking “Thursday’s 5-tonne” refers to. Turn one, it calls the availability tool for a 5-tonne excavator at the Rocklea depot on Monday, and gets back two free units. Turn two, it proposes the change in plain language and asks the customer to confirm the new date and the same site address. The customer confirms. Turn three, it calls the move tool with the booking reference, the new date and an idempotency key. Turn four, it calls the confirmation tool and replies with the new delivery window.
Four turns, four model calls, about twenty seconds. The trace in AgentCore shows which tools ran, with what inputs, and what each returned.
The reschedule that does not
Same request, different week. The availability tool comes back with nothing free on Monday. There is no script for what follows, which is why the job needed an agent.
The agent checks Tuesday, checks the neighbouring depot, and finds a 5-tonne free at Acacia Ridge on Monday with an extra hour of haulage. It puts both options to the customer rather than choosing, because moving the depot changes the delivery charge and that is not its call to make. The customer takes Tuesday at Rocklea. The agent moves the booking and confirms.
Six turns instead of four, and no tool ran that the customer had not agreed to. Had the turn cap been reached with nothing agreed, the conversation would have gone to the depot office with the availability results already gathered. That is a worse outcome than an automated reschedule, and a much better one than a machine on the wrong site.
What’s worth remembering
- An AI agent is a foundation model given a goal, a catalogue of tools and a memory, looping until it decides the work is done, which is how agentic AI handles multi-step tasks whose steps were not knowable in advance.
- Reach for an agent when the request decides the sequence; a single prompt, RAG or workflow orchestration all beat it on cost, latency and traceability when the steps were knowable.
- AI agents’ business applications are the ones that cross several systems and act rather than only answer: customer service, IT and HR requests, booking and scheduling, research across sources, and multi-step back-office processing.
- Strands Agents is the open-source framework for building an agent, Amazon Bedrock AgentCore is the managed runtime that hosts one in production, and Model Context Protocol (MCP) is the open standard that connects it to external tools and data.
- An agent’s cost per request is unbounded because the loop length is not fixed, so cap the turns and hand off to a person at the cap.
- Tool usage widens the blast radius with every tool added, so keep the catalogue small and put confirmation or an idempotency key in front of anything that changes a booking, a payment or a record.