Chat Sessions Models And Agents
Source of Truth: docs/ARCHITECTURE.md
Status: Canonical repo cleanup aligned to the current VS MCP Bridge and BlogAI narrative as of 2026-05-16. Bracket-style tokens are intentional BlogEngine/GwnWikiExtension tokens.
Understanding AI Chat Sessions, Models, and Agents
Why Context, Tools, Evidence, and Boundaries Matter
One of the easiest mistakes to make with modern AI tools is assuming that a chat is a persistent intelligence that keeps thinking between messages. That is not how these systems work. Once that clicks, a lot of confusing behavior suddenly makes sense.
It also explains why the VS MCP Bridge project puts so much weight on architecture docs, durable traces, session handoffs, and source-controlled blog content. If the chat context disappears, the system still needs a way to recover the project model.
A Chat Is Not A Persistent Mind
A chat session is a temporary context window wrapped around a model call. On each turn, the application gathers instructions, prior messages, available tool results, selected files, and any other context it chooses to include. The model then generates a response from that input.
Instructions + context + tool results + current prompt -> model -> response
The model does not carry goals forward unless those goals are present in the current request. If the working context is lost, the same model can feel like a different assistant because it no longer sees the same constraints, terminology, or decisions.
A chat session is working context, not permanent memory.
Why Context Loss Feels So Disruptive
When a desktop app crashes, a session resets, or a context window is compacted, the active conversation may lose important details. Earlier decisions, operating rules, current branch state, and architectural constraints may disappear unless they were preserved somewhere outside the chat.
That is why VS MCP Bridge now treats repository files as the source of truth. AI_START.md, docs/ARCHITECTURE.md, trace workflows, logs, Mermaid sources, and session handoffs are not paperwork. They are the durable memory that a future AI session can reload.
The Main Terms
These terms often get blurred together, but separating them helps explain what the bridge is doing.
Model
The model is the reasoning engine. It generates output from the input it receives. By itself, it is stateless and does not know the project unless the current context gives it project evidence.
Session
The session is the active conversation context. It may include prior messages, instructions, selected files, tool results, and summaries. It can be extremely useful, but it is not a reliable permanent store.
Tool
A tool is a callable capability outside pure text generation. In VS MCP Bridge, tools can read Visual Studio state, list projects, create edit proposals, or execute shared bridge tools through catalog and executor boundaries.
Agent
An agent is an orchestration layer that uses a model, context, tools, and a control loop to pursue a task. That does not make it magic or autonomous in the human sense. It still needs explicit boundaries, review, observable execution, and durable evidence.
Orchestration Layer
The orchestration layer decides what context to include, which tools are available, when to call them, how to handle results, and how to continue the loop. ChatGPT, Codex, Copilot, and MCP-enabled clients differ mostly in this layer and in the tools they can reach.
Pure Chat Is Different From Tool-Backed Work
Pure chat inference can explain, summarize, and reason from the supplied prompt. Tool-backed workflows can observe or change the outside world, so they need stronger boundaries.
VS MCP Bridge exists because AI-assisted coding needs more than free-form conversation. It needs a local MCP server, a clean stdio boundary, a named-pipe bridge into Visual Studio, explicit MCP tools, proposal approval, and diagnostics that show what actually happened.
That changes the trust model. A chat answer can be reviewed as text. A tool call may read active editor state, list solution projects, or create a proposed edit. That kind of workflow needs logs, request ids, tool descriptors, policy decisions, approval states, and structured results.
How VS MCP Bridge Grounds Agentic Behavior
In VS MCP Bridge, agentic behavior is grounded by concrete boundaries:
- MCP clients talk to the local MCP server over stdio.
- The MCP server reaches Visual Studio only through the local named-pipe boundary.
- The VSIX owns Visual Studio API access and proposal UI state.
- Proposal tools create proposals; apply still requires explicit approval in the tool window.
- Shared bridge tools run through
BridgeToolExecutor, not directly from callers.
- Policy, approval, redaction, audit, correlation, and result shaping stay at the execution boundary.
Those boundaries are what keep "the agent did something" from becoming an unhelpful explanation. A future developer should be able to tell which layer received the request, which tool ran, which approval or policy decision applied, and which result was returned.
Session Continuity Needs Source-Of-Truth Files
When a session survives, the assistant can use the conversation to maintain continuity. When a session is interrupted, source files have to carry the continuity instead.
That is why the project now asks future sessions to start with repository evidence:
This is not only useful for AI sessions. It is useful engineering discipline. Durable context reduces dependency on memory, mood, and whatever happens to fit in the next prompt.
Logs, Traces, Artifacts, And Prompts Work Together
Prompts tell the assistant what to do. Architecture docs tell it what is true. Logs show what happened. Trace metadata records the run context. Mermaid diagrams explain the observed sequence. Handoffs tell the next session what to trust, what to recheck, and what remains deferred.
That combination is more reliable than any single long chat. It also lets a human reviewer challenge the work: if the diagram says a request crossed the executor boundary, the logs and code should support that claim.
Approval Is Part Of Orchestration
Agentic workflows often sound autonomous, but VS MCP Bridge deliberately keeps important operations approval-aware.
The proposal workflow is the clearest example: an MCP tool can create a proposed edit, but the edit is not applied until the user approves it in the host UI. The newer tool-execution approval seam follows the same architectural direction for future selected tools: approval is evaluated at the execution boundary, not hidden inside arbitrary tool code.
That is how AI-assisted development stays understandable. The model can suggest. The tool can prepare. The boundary can log, audit, redact, and classify. The human can review and approve.
What Context Windows Cannot Solve
Larger context windows help, but they do not eliminate the need for durable evidence.
A bigger window can include more files and more history, but it can still omit the one constraint that matters. It can still summarize away nuance. It can still be reset. It can still produce a plausible explanation that does not match the actual code.
That is why the repo treats source-of-truth documents, validation artifacts, and canonical blog content as part of the system. They make the project less dependent on any single context window.
Related Mermaid Trace Sources
The following diagram sources help make these concepts concrete:
Those .mmd files are the diagram source of truth. They matter because they turn abstract AI terminology into observed software behavior.
A Cleaner Mental Model
| Term |
Practical Meaning |
VS MCP Bridge Example |
| Model |
Generates output from supplied context |
The model behind ChatGPT, Codex, or Copilot |
| Session |
Temporary working context |
The current chat plus instructions, files, and tool results |
| Tool |
Callable capability outside pure text generation |
vs_get_active_document, proposal tools, or shared bridge tools |
| Agent |
Model plus orchestration loop and tools |
An AI client using MCP tools to inspect and propose changes |
| Evidence |
Durable record that survives context loss |
Architecture docs, logs, metadata, Mermaid diagrams, handoffs, canonical blog sources |
Takeaway
Models generate responses. Sessions provide temporary continuity. Agents orchestrate tools and context. Tools touch real systems. Evidence makes the whole workflow reviewable after the session ends.
That is the practical lesson from VS MCP Bridge and BlogAI: AI-assisted development improves when the important knowledge survives outside the chat. Observable boundaries, approval-aware workflows, source-of-truth docs, and durable traces are what keep agentic behavior from becoming AI magic.
See inference-driven for the companion discussion of inference-driven software design and Copilot's strengths and risks.