There is a version of the agent conversation that treats the loop as the hard part. Plan, call a tool, observe the result, decide what to do next. It is in every framework, it is a few hundred lines if you write it yourself, and it is not where projects die.
Projects die on the tools.
The loop is commodity, the tools are your company
An agent is only as capable as the things it can actually do, and the things it can actually do are your systems. A sales agent needs your CRM. An operations agent needs your ERP. A support agent needs the ticketing system, the order records and the returns policy — three systems that have never spoken to each other and were never designed to.
So the work is not “build an agent”. The work is: give a non-deterministic caller a safe, narrow, reliable interface onto systems that were built for humans clicking buttons or for a nightly batch job. That is an integration problem. We have been doing integration work since 2013, and almost none of what makes it hard has changed because the caller is now a model.
What has changed is the failure mode. A human who gets a confusing API error stops and asks someone. A nightly batch job fails loudly and waits for morning. An agent retries.
Four questions nobody asks during the demo
What happens when a call fails halfway through a multi-step task? The agent has updated the CRM record and not yet sent the confirmation. It is now holding inconsistent state across two systems and deciding what to do about it. If you have not designed that path, the agent will improvise one.
How do you stop a retry repeating something that already succeeded? A timeout is not a failure. The call may well have landed. An agent that retries a non-idempotent write after a timeout has just charged the customer twice, and it will do it at three in the morning without anyone watching. Every tool an agent can reach needs to be idempotent, which usually means designing an idempotency key into the tool layer rather than hoping the underlying API has one.
Who approves the irreversible steps? Reading a record is reversible. Sending an email to a customer is not. Issuing a refund is very much not. The line between what the agent may do alone and what queues for a person is a product decision, made deliberately, with the business — not a framework default and not something to discover in production.
What did it actually do last Tuesday? If you cannot answer that from a trace, you cannot debug the agent, and in a regulated context you cannot defend it either.
What a tool layer looks like when it is built properly
Not a model pointed at your API. A service in between, which:
- Exposes a narrow surface. The agent gets
create_support_ticket(order_id, category, note), not the ticketing system’s full REST API. Narrow tools are easier to describe to a model, easier to evaluate, and dramatically harder to misuse. - Is idempotent by construction. Every write carries a key. A repeat with the same key returns the original result rather than performing the action again.
- Holds scoped credentials. The agent’s identity can reach exactly what its task requires and nothing else. Not an admin token because that was quicker to set up.
- Has timeouts and a circuit breaker. A slow downstream system should degrade the agent, not hang it.
- Refuses in a structured way. “I cannot do that because the order is already closed” is a result the agent can reason about. A 500 is not.
None of that is AI engineering. All of it decides whether the AI engineering works.
The uncomfortable implication
If the tools are the hard part, then the advantage in agent work does not belong to whoever adopted the newest framework. It belongs to whoever already understands the systems the agent has to operate inside — the permission model, the data shape, the places where the API lies about what it did.
That is an unfashionable conclusion, and we think it is the right one. The most useful thing we bring to an agent project is usually not something we learned in the last two years.
Where to start
Pick one workflow. High volume, mechanical rather than judgement-heavy, systems with reachable APIs, and — this is the one that eliminates most candidates — a clear definition of what a correct outcome looks like. If nobody in the room can say what “done correctly” means, the agent cannot be evaluated, and the project has no way to finish.
Build the tool layer first. Then the agent. In our experience the ratio is roughly four to one, and the four is not the interesting part to talk about at a conference.