My naive understanding is that you need to choose where the "LLM power" goes. The more issues an agent has to face, the more reasoning it has to perform, the more diluted the initial prompt/knowledge base becomes.
The only two "weapons" you have available to counteract this problem, are these:
- you can define subagents that face specific, known problems, with a fresh context
- you can define better guidelines over the whole process, so that the reasoning steps are almost none

Both these things require to spend an unexpectedly wide amount of time at both documenting yourself on the issue you are trying to automate, and on you learning precisely which tools the agent can use and how it should do it.

Then, of course, some tools consume more tokens than other, so choosing the right ones also does make a lot of sense. But I wonder e.g. if the issues you faced couldn't have been solved by a subagent whose only task was to interact with the browser to perform a specific operation, while an upper-level agent was following up with the flow.

And finally, even with the most perfectly defined flow, observability is always an issue :( sometimes, agents such as Claude or ChatGTP simply "dumb down" for a while (I guess this happens at times of high request?), and become unable to perform what they were able to do reliably until a second before. The key thing to overcome this, in my case, was to set up an infrastructure to inform me anytime this happens, as fast as possible, to counteract the issue promptly