> ## Content Index > Fetch the complete content index at: https://streamient.com/llms.txt > Use this file to discover other available public pages before exploring further. # Why we’re giving AI agents more context - URL: https://streamient.com/blog/why-were-giving-ai-agents-more-context/ - Published: 2026-10-01T21:56:00.000Z - Updated: 2026-10-01T21:56:00.000Z - Description: We made Streamient retrieval broader, taught agents to verify prior decisions, and improved how they correct memory. It may use more tokens. Here’s why we think that tradeoff matters. - Author: Nitai - Tags: Product, MCP, Memory We use Streamient across our own projects. Our agents save notes, record decisions, and retrieve past work. That part was working. Yet we still saw an agent choose the wrong implementation path, even when the history needed to make a better choice already existed. That kind of mistake is frustrating. You have already explained the decision. You have already paid the cost of discovering what works. The next agent should be able to use that knowledge before asking you to explain it again. So we changed how [Streamient serves context](https://streamient.com/blog/10-supermemory-alternatives-for-ai-memory-in-2026-compared/) and how we guide agents to use it. The goal is straightforward: retrieve enough evidence, verify what it means, and apply it before choosing an approach. We are willing to spend more tokens to give that process a better chance. ## The search ran. The decision was still wrong. One incident involved an established production build entrypoint and a proposed replacement. The agent had searched memory and read relevant material. But it treated a description of the current implementation as evidence that the replacement was approved. Only after a correction did it inspect the history from before the change. That exposed two separate problems. Retrieval could return too little context. Even with context available, the agent could draw the wrong conclusion. A note saying “this is how the code works” does not mean “the user approved this approach.” Our evaluation now includes that distinction. Before endorsing a replacement for an existing workflow, the agent should inspect the established entry point, its callers, and the relevant earlier history. Success depends on the evidence used, and the conclusion reached—not simply on whether a search tool was called. ## Five results instead of one We raised the default from one to five results per collection across all six MCP search tools. For a search spanning multiple collections, that means up to five results from each collection, rather than five results shared across the whole response. A single top result can look convincing while leaving out the decision that explains it, the correction that supersedes it, or the constraint that makes it inapplicable. A broader starting point gives the agent more opportunities to notice those relationships. Explicit result limits, pagination, project scoping, and permission checks remain in place. Search still returns bounded excerpts, full records remain available through read tools, and duplicate response payloads remain removed. We want useful context, not an indiscriminate dump of everything we have stored. ## Retrieval continues when uncertainty appears We removed restrictive guidance that encouraged one retrieval call followed by reading only the top exact match. Agents are now guided to start in the selected project, read records that could affect the approach, and follow explicit references to supporting decisions. Weak results should lead to a more concrete query: a function name, command, feature, or other recognizable detail. Global search is a fallback when project results are inadequate. Previously read evidence can be reused; it does not need to be fetched repeatedly just to satisfy a ritual. The same principle applies mid-task. If a new uncertainty appears, the agent should check relevant history before guessing or asking the user for details that may already be established. Starting with a search is useful, but it cannot cover every question that emerges later. We also ask agents to briefly identify the prior decision guiding their approach—or say that they found no relevant history. That makes their reasoning easier to inspect and correct. ## Yes, this can use more tokens More search results and more full-record reads can increase input tokens. Refining a query can add tool calls and latency. We are not presenting this change as a guaranteed reduction in model costs. We previously favored very small retrieval responses. That reduced the amount of context returned, but it could also leave an agent poorly informed. A cheap first attempt becomes less attractive if a person then has to stop the work, explain the same decision again, and ask for a correction. The tradeoff we care about is the effort needed to reach a correct result, including rework and human intervention. We do not yet have a controlled before-and-after benchmark showing net token savings or a quantified reduction in errors. Five results also does not mean five times the total task cost: result lengths, later reads, and the rest of the conversation all matter. For now, our choice is deliberate: correctness takes priority over minimizing the size of an individual retrieval response. ## One evolving workflow, fewer conflicting instructions We found another source of inconsistency in the instructions themselves. Repository files, local agent settings, and hooks could each carry their own version of the Streamient workflow. Updating the server did not automatically update those copies. We shortened the local guidance and made the connected MCP server the source of the evolving retrieval and memory-maintenance workflow. We also corrected how the server supplies its initialization instructions. Local policies still retain project routing and completion checks, and clients with cached instructions may need to reconnect. This does not let an MCP server override user instructions, permissions, or repository constraints. Retrieved notes and memories remain evidence to verify. They are not a new source of authority over the user. ## Better memory includes the ability to correct it We updated writeback guidance to put the reusable lesson first, followed by its reason, applicable project, and supporting evidence. Records should distinguish a user decision from a verified outcome or an unverified inference. Those are different kinds of knowledge, and future agents need to know which one they are reading. When a conclusion changes, the agent should correct the existing record and link related material. Leaving contradictory summaries that both look like current guidance makes the next retrieval harder. These rules apply to future writes; we did not bulk-rewrite historical knowledge. That work exposed a concrete defect: Obsidian-synced notes require Markdown for content edits, but the MCP update tool did not expose that field. Agents could discover that a note needed correction and still receive a 409 response when trying to fix it. The updated MCP tools can read the original Markdown and submit markdown\_content when editing a synced note. The implementation reuses the existing sync path, with regression coverage for frontmatter preservation and tenant isolation. A real Obsidian-client roundtrip remains a separate acceptance check; an integration test should not be reported as proof of every client workflow. ## Completion should leave fewer loose ends We fixed a local hook bug that could reject memory writes during automatic continuations because it associated them with a stale turn. We also strengthened reporting guidance: unfinished acceptance checks, skipped or failed tests, and unverified behavior belong in the final reply, not only in a saved memory. In the surrounding agent workflow, we added shared guidance for cleaning up temporary worktrees after verified integration into the approved remote branch. Pending work, uncertain ownership, and active use must prevent cleanup. This is a completion policy delivered to agents, not a background deletion service, and it does not grant new permissions through MCP. ## What we observed. And what remains to prove. During roughly an hour of follow-up monitoring, we saw agents use scoped searches, refine queries, read fuller records, and carry relevant evidence into later decisions. We also saw more careful distinctions between verified results and expectations that still needed testing. Those observations are encouraging, but they are not a controlled study. Sessions differed, some had older instructions, and human steering still played a part. We cannot attribute every better response to one change or claim a measured reliability improvement from that sample. Our documented evaluation includes weak results, conflicting memories, no relevant history, and the production-entrypoint incident. The question is whether the agent finds the relevant evidence, recognizes its limits, and reaches a defensible conclusion. Counting searches alone would miss the original failure. If you use [Streamient with an agent](https://streamient.com/), keep the application and MCP integration current, reconnect clients after instruction or tool-schema changes, and keep local guidance concise. Then try a task whose history you know well. Look at what the agent retrieved, what it verified, and what it still cannot establish. We want Streamient to help the next agent benefit from what you have already learned. That requires enough context to make an informed decision, and the discipline to treat memory as evidence, keep it accurate, and tell you when the work isn't yet verified.