[AmiteK]

Yes. In the MCP setup the agent doesn’t decide to regenerate arbitrarily.

When stamp context --watch is active, the MCP server detects it. The agent first calls logicstamp_watch_status to see whether context is being kept fresh.

If watch mode is active, the agent can directly call list_bundles(projectPath) → read_bundle(projectPath) and will always read the latest regenerated output. No snapshot refresh is needed.

If watch mode isn’t active, the workflow falls back to refresh_snapshot → list_bundles → read_bundle.

So “consume” just means reading deterministic files via MCP tools, with watch mode ensuring those files stay up to date.

[verdverm]

As soon as you involve the agent and having it make tool calls, it is no longer deterministic

This is in fact the very reason I set out to build my own agent, because Copilot does this with their `.vscode/instruction/...` files and the globs for file matching therein. It was in fact, not deterministic like I wanted.

My approach is to look at the files the agent has read/written and if there is an AGENTS.md in that or parent dirs, I put it in the system prompt. The agent doesn't try to read them, which saves a ton on token usage. You can save 50% on tokens per message, yet my method will still use fewer over the course of a session because I don't have to make all those extra tool calls

[AmiteK]

I think there’s a conflation here between artifact determinism and agent behavior.

LogicStamp’s determinism claim is about the generated context: same repo state + config ⇒ identical bundles. That property holds regardless of how or when an agent chooses to read them.

Tool calls don’t make the artifacts non-deterministic; they only affect when an agent consumes already-deterministic output.

[verdverm]

LSP is equally deterministic in that regard and more token efficient

Can you address the token inefficiencies from having to make more tool calls with this method?

[AmiteK]

On tool-call overhead: in the MCP flow it’s typically 1–2 calls per task (watch_status once, then read_bundle for the relevant slice). In watch mode we also skip snapshot refresh entirely.

Token-wise, the intent isn’t “dump everything”. it’s selective reads of the smallest relevant bundles. If your workflow already achieves what you want with AGENTS.md + LSP querying, that may indeed be more token-efficient for many sessions.

The trade-off LogicStamp is aiming for is different: verifiable, diffable ground-truth artifacts (CI/drift detection/cross-run guarantees). Tokens aren’t the primary optimization axis.

[verdverm]

I'm not sure the comparison I'm hoping to draw out is coming through

This seems more similar in spirit to AGENTS.md than LSP, so I'll make the comparison there. Today, I require zero tool calls to bring my AGENTS.md into context, so this would require me making more tool calls, each of is a round trip to the LLM with the current context. So if I have a 30k context right now, and you are saying 1-2 calls per task, that is 30-60k extra tokens I need to pay for, for every one of these AGENT.md files that needs to be read / checked to see if in sync.

I use git for the verifiable / diffable ground truth artifacts. I can have my LSP query at different commits, there is no rule it can only access the current state of the code

[AmiteK]

I think we’re optimizing for different constraints. If your goal is zero extra round trips and you’re happy with AGENTS.md auto-injection + LSP queries, then I agree LogicStamp won’t be a win on token cost for that setup.

The AGENTS.md comparison isn’t “same thing” - it’s a different layer. AGENTS.md encodes human intent/heuristics. LogicStamp generates semantic ground-truth contracts (exports, APIs, routes) from the AST so they can be diffed and validated mechanically (e.g. CI drift detection).

Git + LSP can diff/query source across commits, but that’s still a query workflow. LogicStamp’s goal is a persistent, versioned semantic artifact. If your workflow already covers that, then it may simply not add value - which is totally fine.