3 ms·

How does this work mid-chat if the agent changes code that would require these mappings to be updated? I put this information in my AGENTS.md, for similar goal

by verdverm 10mo ago

How does this work mid-chat if the agent changes code that would require these mappings to be updated? I put this information in my AGENTS.md, for similar goals. Why might I prefer this option you are presenting instead? It seems like it ensures all code parts are referenced in a JSON object, but I heavily filter those down because most are unimportant. It does not seem like I can do that here, which makes me thing this would be less token efficient than the AGENTS.md files I already have. Also, JSON syntax eats up tokens with the quotes, commas, and curlies Another alternative to this, give your agents access to LSP servers so they can decide what to query. You should address this in the readme as well How is it deterministic? I searched the term in the readme and only found claims, no explanation

AmiteK 10mo ago
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 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 ago
    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 10mo ago
      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 10mo ago
        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 10mo ago
        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 10mo ago
        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.
AmiteK 10mo ago
Adding a bit more context since I didn’t see your expanded comment at first: AGENTS.md and LogicStamp aren’t mutually exclusive. AGENTS.md is great for manual, human-curated guidance. LogicStamp focuses on generated ground-truth contracts derived from the AST, which makes them diffable, CI-verifiable, and resistant to drift. On token usage: the output is split into per-folder bundles, so you can feed only the slices you care about (or post-filter to exported symbols / public APIs). JSON adds some overhead, but the trade-off is reliable machine selectability and deterministic diffs. Determinism here means: same repo state + config ⇒ identical bundle output.
- verdverm 10mo ago
  Having been working on my agent's context engineering heavily of late, the following is based on my personal experience messing with how that stuff works in some fundamental ways I don't really think dumping all this unnecessary information into the context is a good idea 1. search tools like an LSP are far superior, well established, and zero maintenance 2. it pollutes context with irrelevant information because most of the time you don't need to know all the details you are putting in there, especially the breadth, which is really the main issue I see here. No control over breadth or what is or is not included, so mostly noise for any given session, even with the folder separation. You would need to provide evals for outcomes, not minimizing token usage, because that is the wrong thing to primary your optimizations on
  - AmiteK 10mo ago
    That’s fair, and I agree LSP-style search is excellent for interactive, local exploration. LogicStamp isn’t trying to replace that. The problem it targets is different: producing stable, explicit structure (public APIs, components, routes) that can be diffed, validated, and reasoned about across runs - e.g. in CI or long-running agents. LSPs are query-oriented and ephemeral; they don’t give you a persistent artifact to assert against. On breadth/noise: the intent isn’t to dump everything into one prompt. Output is sliced (per-folder / per-contract), and the assumption is that only relevant bundles are selected. Token minimization isn’t the primary goal; predictability and selectability are. In practice I see them as complementary: LSPs for live search, generated contracts for ground truth. If your workflow is already LSP-driven, LogicStamp may simply not add much value - and that’s fine.

AmiteK 10mo ago

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 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 ago
  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 10mo ago
    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 10mo ago
      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 10mo ago
        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 10mo ago
        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.

AmiteK 10mo ago

Adding a bit more context since I didn’t see your expanded comment at first: AGENTS.md and LogicStamp aren’t mutually exclusive. AGENTS.md is great for manual, human-curated guidance. LogicStamp focuses on generated ground-truth contracts derived from the AST, which makes them diffable, CI-verifiable, and resistant to drift. On token usage: the output is split into per-folder bundles, so you can feed only the slices you care about (or post-filter to exported symbols / public APIs). JSON adds some overhead, but the trade-off is reliable machine selectability and deterministic diffs. Determinism here means: same repo state + config ⇒ identical bundle output.

verdverm 10mo ago
Having been working on my agent's context engineering heavily of late, the following is based on my personal experience messing with how that stuff works in some fundamental ways I don't really think dumping all this unnecessary information into the context is a good idea 1. search tools like an LSP are far superior, well established, and zero maintenance 2. it pollutes context with irrelevant information because most of the time you don't need to know all the details you are putting in there, especially the breadth, which is really the main issue I see here. No control over breadth or what is or is not included, so mostly noise for any given session, even with the folder separation. You would need to provide evals for outcomes, not minimizing token usage, because that is the wrong thing to primary your optimizations on
- AmiteK 10mo ago
  That’s fair, and I agree LSP-style search is excellent for interactive, local exploration. LogicStamp isn’t trying to replace that. The problem it targets is different: producing stable, explicit structure (public APIs, components, routes) that can be diffed, validated, and reasoned about across runs - e.g. in CI or long-running agents. LSPs are query-oriented and ephemeral; they don’t give you a persistent artifact to assert against. On breadth/noise: the intent isn’t to dump everything into one prompt. Output is sliced (per-folder / per-contract), and the assumption is that only relevant bundles are selected. Token minimization isn’t the primary goal; predictability and selectability are. In practice I see them as complementary: LSPs for live search, generated contracts for ground truth. If your workflow is already LSP-driven, LogicStamp may simply not add much value - and that’s fine.