[AmiteK]

Good question.

LogicStamp treats context as deterministic output derived from the codebase, not a mutable agent-side model.

When code changes mid-session, watch mode regenerates the affected bundles, and the agent consumes the latest output. This avoids desync by relying on regeneration rather than keeping long-lived agent state in sync.

[verdverm]

> watch mode regenerates the affected bundles, and the agent consumes the latest output

How does this work in practice? How does the agent "consume" (reread) the files, with a tool call it has to decide to invoke?

[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.