Raw capture â raw/how-ai-coding-agents-actually-use-your-technology.md
url: https://developer.microsoft.com/blog/how-ai-coding-agents-actually-use-your-technology date_fetched: 2026-07-05 backfilled: true
You ship an SDK, a CLI, an API, and developers use it. Now AI coding agents use it too, except they use it differently than humans do. Most of the time you have no idea whatâs actually happening between âdeveloper types a promptâ and âagent generates code with your technology.â Is the agent reading your docs? Is it calling your MCP server? Is it ignoring both and guessing from memory?
In the previous article, we introduced the AX stack: model, harness, and agent extensions. We talked about whatâs fixed and what you can influence. This time, letâs trace through what actually happens, step by step, when an agent encounters your technology. Because until you see the mechanics, you canât fix whatâs breaking.
A developer opens their coding agent, types a prompt: âBuild me a REST API with authentication using Contoso Identity.â Hereâs what happens next.
Before anything hits the model, the harness (Copilot, Claude Code, Cursor) assembles the context window. The VS Code team recently published a deep dive into how their harness works, covering context assembly, tool exposure, and the agent loop. The harness pulls together:
This is just an example, because every harness is different. Nonetheless, if you consider the context window size of any of the popular LLMs used for coding, you can start to see how such a setup quickly fills up the available tokens. The harness decides what makes the cut. If the developer has 20 extensions installed, the harness might summarize tool descriptions, drop some entirely, or rank them by estimated relevance. Your extensionâs description is competing for space before the model even sees it. If it exceeds the harnessâs length limit (each harness sets its own), it gets ignored entirely, no matter how relevant it is. And details youâd never think about, like the OS, or the directory path, influence the modelâs decisions. Itâll generate platform-specific code, assume different toolchains, even pick different default configurations based on what it sees here.
The model receives this assembled context and does something humans donât: it reads everything at once. The system prompt, the tool descriptions, the workspace context, the developerâs prompt. It builds a mental model of whatâs available and what the developer asked for.
Hereâs where training data matters. If the model has seen your technology during pre-training, it already has opinions. It knows (or thinks it knows) your API patterns, your SDK conventions, your common error messages. If it hasnât seen your technology, it has nothing, and itâll either ask for help or guess based on similar technologies. Either way, the modelâs job at this point is to decide what to do first: does it have enough information to start coding, or does it need to call a tool?
It turns out, that this decision is a combination of the behavior encoded in the model and the instructions the harness adds on top. Some agents are more inclined to call tools straight away, while others rely on their own knowledge and only use tools when the user asks them to. Some agents tend to search for the latest information on the internet first, while others prioritize efficiency and start working on the task if they feel they know enough. So even if you ship a great extension, one agent might call it proactively while another never touches it unless the developer explicitly asks.
If the model decides it needs more information, it looks at the available tools and skills. This is where your MCP serverâs tool descriptions and skill definitions matter. The model reads each description and decides: does this help with what the developer asked? Notice, that this decision is based on semantic matching, not keyword search. The model is interpreting intent. If the developer said âauthenticationâ and your tool is described as âconfigure identity provider settings,â the model has to bridge that gap.
And even when your description matches the intent perfectly, the model might still skip it. If the task looks simple enough, or if the model feels confident it already knows the answer, it wonât bother calling your tool. Itâll just go with what it has. This is especially painful when the model has some training data for your technology but itâs outdated: high confidence, stale information.
If the model doesnât select any tool or skill, it proceeds with whatever it already knows: itâll use pre-training data. Itâll use whatever version of your SDK the model learned from, however many months ago that training cut-off was. If your API changed since then, the generated code is wrong and neither the developer nor the agent knows it.
Say, the model selected your tool. Now it needs to call it correctly. It constructs the parameters based on the toolâs schema and the developerâs intent. But the model might map the developerâs intent to the wrong parameters, or invent values that donât match the schema.
If multiple tools match the intent, the model might call either one or both. And itâs not just about competition for relevance. Say there are two MCP tools from different servers that can provide more information. One is invokable directly, the other uses subrouting: a parent tool that returns information about subtools that actually hold the answer. This is a common technique in larger MCP servers to lower the number of tools exposed to the LLM and optimize token usage. If in the first turn one tool returns the actual information while the other returns routing instructions for the subtool, the model might decide it knows enough and never invoke the subtool, failing the routing entirely. This is why testing tools in isolation isnât enough, and you need to test them in the combinations developers actually use.
Your MCP server receives the call, processes it, and returns content. What you return matters a lot. Return too much content and the model ignores parts of it or gets confused. Return too little, and the model fills gaps with assumptions. Format the content in a confusing way, and the model misparses it. Provide wrong information and you can derail the agent from the original task entirely. Weâve seen extensions cause agents to upgrade a project to a different framework version than what the developer asked for, or switch to a different programming language mid-task. And all of it goes back into the context window, consuming tokens. If you return 3,000 tokens of documentation when 200 would do, you just pushed other relevant context out of the window. Thatâs drag.
The model takes your toolâs response and integrates it with everything else in context. It now has the developerâs intent, workspace context, and your toolâs output, and it decides whether to generate code, call another tool, or ask the developer a question. If your tool returned clear, specific content (a code sample, a schema, step-by-step instructions), the model can proceed. If your tool returned a wall of reference documentation, the model has to extract whatâs relevant, and its extraction might miss the critical detail.
How would you know? You wouldnât. The tool got called, it returned content, everything looks fine from the outside. But the model latched onto the wrong paragraph and generated code that uses an internal-only endpoint. Thatâs the worst kind of quality failure: invisible until someone runs the code.
Next, the model generates code. This is where everything upstream either pays off or falls apart. If discovery worked, the model found your extension. If selection worked, it called the right tool for the task. If the tool response was good, the model has accurate, current information, and the generated code uses the right SDK version, the right patterns, the right authentication flow.
If any step failed, the model falls back to its training data. It might use an older API version, pick a competing SDK, or invent an endpoint that doesnât exist. The developer sees working-looking code that fails at runtime, and blames the agent.
Many agents integrate with language servers (LSPs) and respond to problems reported in real time, adjusting code as itâs generated rather than waiting until the end. In VS Code, the agent also monitors the Problems panel where any active extension can surface diagnostics: type errors, lint violations, deprecation warnings. If your technology contributes to that feedback (through a VS Code extension, a language server, or a linter), youâre influencing the agentâs output during generation, not just after. Thatâs another surface you control.
The agent doesnât stop at first generation. If the harness supports it (and most do), the agent builds the code, runs tests, observes errors, and tries again. Your technology surface matters here too. If your CLI produces clear error messages, the agent can quickly and efficiently self-correct. If your build tooling or test runner returns helpful output with specific codes and suggestions, the agent fixes the problem. If your errors are cryptic (âError: operation failedâ), the agent is flying blind and might iterate in the wrong direction for 10 turns before giving up.
This is a part of AX that people overlook. Your error messages arenât just for human developers anymore. Theyâre for agents, and agents have no intuition to fall back on. They take your error message literally.
Notice the dependency chain:
A failure at step 1 cascades through everything. If the harness drops your tool description, steps 3-7 never happen. Your tool might as well not exist. If step 3 fails (the model sees your tool but doesnât connect it to the task), itâs the same result. If step 4 succeeds but the response is confusing, step 6 produces broken code.
This is why measuring only âwas my tool called?â tells you almost nothing. Your tool can be called correctly and still produce drag if the response quality is poor. Your tool can never be called despite being installed, which means your discovery is broken. And between those two extremes? A dozen ways each step can silently degrade the next.
Most AX failures are invisible. They happen upstream, silently, and you never see them. You canât diagnose them by looking at outputs alone: you need to know which step failed, because each one has a different fix. In the next article, weâll cover how to measure whether your AX work is creating lift or drag at each step.
Be the first to start the discussion.