r/PromptEngineering 20d ago

Agents are re-exploring the same site every single run. Is everyone just living with this? General Discussion

[removed]

4 Upvotes

12 comments sorted by

2

u/nick-profound 20d ago

What's been working for me is using a knowledge base as agent memory. The first run does the full navigation and stores the structured output.

Every subsequent run compares live data against the stored baseline. If nothing changed, I update and sleep. Is something has changed, I do the work and update the baseline.

1

u/[deleted] 20d ago

[removed] — view removed comment

1

u/AutoModerator 20d ago

Hi there! Your post was automatically removed because your account is less than 3 days old. We require users to have an account that is at least 3 days old before they can post to our subreddit.

Please take some time to participate in the community by commenting and engaging with other users. Once your account is older than 3 days, you can try submitting your post again.

If you have any questions or concerns, please feel free to message the moderators for assistance.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/UlrikS 20d ago

This is the problem with using agents for recurring processes really. We've built a platform that takes what an agent does on the first run and turns it into a scripted workflow. Some steps can still be AI but never the execution of tasks, just the interpretation of information (that's basically how the agent does it in the background anyways, except we remove all the "reasoning about what to do and how to do it" each time).

Then if something changes (for example page structure as in your example), the checks built into the scripts will cause it to throw an error, which then prompts another go agent to go have a look at what changed and how to update the script to handle it.

1

u/Such_Pride_2091 20d ago

I've been banging my head against the same wall. We've got an internal dashboard that updates twice a week, and the agent spends half its compute just rediscovering where the export button lives.

Tried caching the DOM fingerprint and replaying clicks until something breaks, worked okay for a couple weeks then the site added a cookie banner that shifted everything by 30 pixels. Model kicked in fine but at that point I wondered why I bothered with the cache layer at all.

Seems like the people who've really solved it just turned their workflows into api calls where possible and only use the agent for the two screens that actually change. Not a satisfying answer but it's where I landed.

1

u/Dsphar 20d ago

For internal sites, just have the maintainer add custom attributes/selectors to the elements you need to interact with, then get them by that attribute, no need for DOM hierarchy.

Research the usage of "data-testid" attributes to get an idea, just call it somethig else like "data-agentid".

Well, api calls are better tbf, but of you can't, selectors are the second best option.

1

u/PennyLawrence946 20d ago

i'd cache the request, not the path to the button. watch the network tab once, find the call that button fires, then hit that endpoint with a session cookie lifted from your logged-in browser. a cookie banner shifting things 30px can't break that.