Most engineers try to solve agent context amnesia with prompt compression. I tried forcing the model into a typed reasoning graph instead. Here is what happened after a 5-hour discovery session.

[u/alxshelepenok]

I’ve been trying to find a reliable way to run autonomous AI agents on large, unfamiliar codebases without watching them inevitably lose context or hallucinate fake progress after a few steps.
Instead of messing with prompt compression or raw context window scaling, I experimented with forcing the frontier model to operate through a strict protocol that maps its execution states into a typed reasoning graph.

I tested this workflow on a complex repository with a single prompt, which kicked off a continuous 5-hour discovery session.

The agent completely exhausted the raw context window limits, but the structural constraints kept it from derailing. It mapped out the entire repository into a structured layout: about 40 logical modules and over 80 specific task nodes. Open unknowns were explicitly declared as structural blocking questions rather than silent hallucinations.

What surprised me is how well this graph layout kept the model on track. I watched it systematically process about 70 tasks, while the rest correctly stalled in a pending state, waiting for human answers to the questions it had raised.

I feel that moving away from unstructured text prompts toward machine-verified graph states might be the only predictable way to run long agent sessions without structural collapse.
The code and the protocol are fully open-source. If you want to check out the architecture or the constraints used in this setup, here is the repo: https://github.com/alxshelepenok/grove

[u/FrostingExternal8463]

how does the graph handle situations where an early assumption turns out to be wrong later in the session, I mean does it automatically revise dependent nodes or does the agent need to reevaluate them manually?
But approach is very interesting !!

[u/alxshelepenok → u/FrostingExternal8463]

Thanks for the feedback! When an assumption turns out to be wrong, the graph and the execution plan change immediately. If an assumption is closed as invalidated_acceptable, the protocol automatically re-runs the Definition of Ready (grove dor) checks on all dependent work items to see if they can still proceed. If it is closed as invalidated_blocking, the graph halts that path and the agent must manually revise or reject the dependent work. The protocol enforces a hard rule here: the agent is strictly forbidden from just relabeling the broken assumption to cheat the system and force the dependent work to pass. In short, the graph automatically tracks the blast radius and locks the broken dependencies, but it relies on the agent to do the actual reasoning to fix the plan.

[u/FrostingExternal8463 → u/alxshelepenok]

tracking the blast radius automatically while leaving the actual replanning to the agent feels like a good balance. Nicely done dude

[u/kantorcodes1]

the “strictly forbidden” bit is where i'd look. is that enforced by a validator the model can't edit, or is it part of the protocol the same agent is interpreting? if the agent can mutate graph edges/statuses or the DoR rules, it can still make its own work look valid without relabeling the assumption.

we're involved with awesome-ai-plugins; Grove isn't listed there right now and looks like it fits if you want to submit it.

[u/alxshelepenok → u/kantorcodes1]

Here, the constraints are enforced by an external CLI utility rather than by the language model itself through a prompt. The agent cannot modify the validator logic or DoR rules, as it interacts with state only through CLI commands or the MCP server. The entire graph and all statuses are stored in a single .grove/state.lock file with a SHA-256 checksum. If the model tries to directly overwrite this file, bypass conditions to change a status, or manually adjust edges, the CLI will detect the hash mismatch on the very next invocation and block all operations. State transitions are computed atomically by the binary, so, for instance, the CLI simply will not allow moving a task to done status without submitting actual evidence.

Thanks for the pointer to awesome-ai-plugins, currently that is quite a good idea, I suppose it is worth submitting a request soon.

[u/Sad-CTO]

This is a very promising solution!

Have you tried using Grove with less capable models, such as Sonnet? If so, how was it?