Why not add exploration capabilities similar to GUI-explorer in the Agent? Is there any plan for knowledge accumulation in the project?

[a-rookie-create]

[Ashfaqbs]

On the knowledge-accumulation half of this: right now ScreenIndex (artemis/agents/explorer/screen_index.py) is explicitly documented as an "in-memory index of the current screen's UI elements," and StepMemoryService (artemis/memory/step_memory.py) scopes its summaries to one run's step history. Nothing survives past the task that produced it, so a second run against the same app re-explores from zero every time — same cost, same latency, same chance of the same wrong turn.

A lightweight version of this that would fit the existing architecture: persist a per-app screen fingerprint → element map (embed a coarse feature of the fused XML/OCR hierarchy ScreenIndex already builds, keyed by package name + a structural hash of the view hierarchy) in a small local vector/KV store between runs. On a new run, before Explorer starts probing blind, check whether a fingerprint match already has resolved element locations for the goal-relevant elements and skip straight to acting on them, falling back to normal exploration on a miss. That's additive — it never overrides ScreenIndex's live read, it just gives Explorer a prior to start from instead of nothing, and it degrades safely (a stale/wrong fingerprint hit is just a wasted lookup, not a wrong action, since the live index still resolves the actual coordinates).

This is scoped well short of full GUI-explorer-style RL — no policy learning, no reward shaping, just "have we seen a screen like this before, and if so, where did the useful elements end up." Happy to prototype a minimal version (SQLite + a cheap structural hash, no new service dependency) against a couple of the AndroidWorld benchmark tasks to see if it actually cuts explore-phase turns, if that's a direction worth spending time on.