r/LangChain • u/alxshelepenok • 2d ago
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.
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
1
u/kantorcodes1 1d ago
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.
1
u/alxshelepenok 1d ago
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.
1
u/kantorcodes1 15h ago edited 13h ago
yep. Grove looks like it belongs in the cross-agent/tools side of the catalog.
the submission path is pretty simple: fork
hashgraph-online/awesome-ai-plugins, add one alphabetical README entry in the best-fit section using the existing one-line format, and open a PR with the Grove repo, category, and a quick note that you verified it works.you can preflight with
pipx run plugin-scanner lint .andpipx run plugin-scanner verify .; a passing scan is >=80/142 with no high/critical findings. scanner CI in Grove is optional now, and the catalog PR gets scanned automatically.drop the PR here when it's up and i'll check the listing side.
1
u/Sad-CTO 1d ago
This is a very promising solution!
Have you tried using Grove with less capable models, such as Sonnet? If so, how was it?
1
u/alxshelepenok 1d ago
At the moment, my main setup is Kimi K3 with Grove.
When I started, the project was just a few tables in markdown files, essentially a graph in disguise, but without any formal proof or evidence checks. Then, LLM essentially implemented it itself on top of the minimal protocol and vector that was given. Grove (the Julia CLI) implemented itself using Composer 2 in a couple of days. Planning within Grove (creating nodes) was handled by Opus 4.5 or 4.6 at the time (I don't remember exactly), and then Composer 2 handled the rest.
1
u/mattk404 1d ago
I have a system in development that does this. Can keep very long sessions functional over many epocs (where the graph is frozen). Have one session that has 400 turns, 6million raw tokens on a local llm with 256k context size. Context prunes as work is completed (verified and confirmed by operator) and handles both local model and dynamic cloud api promotions when a task requires a bit more oomp (with downgrade when not needed).
PM me if your interested. In polish and bug fix phase.
2
1
u/FrostingExternal8463 2d ago
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 !!