2 ms·
> 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) t
by verdverm 10mo ago
> 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 10mo agoYes. 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 10mo agoAs 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 10mo agoI 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 10mo agoLSP 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 10mo agoOn 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 10mo agoI'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 10mo agoI 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.