GitHub Copilot Now Speaks OpenTelemetry, and the Default Setting Is the Whole Story

Agent traces are becoming ordinary spans in ordinary monitoring tools. The feature ships with content capture off, which is correct and also the reason your first incident review will come up empty.

On September 22, GitHub shipped OpenTelemetry export for Copilot agents, and the sentence in the changelog worth stopping on is not the one about Splunk. It is this one: prompt and response content is excluded by default. A coding agent that can edit your repository, run commands, and call tools will now emit a complete trace of everything it did, with the contents of what it said and what it was told deliberately left out.

That is the right default. It is also a design problem handed to every team that turns this on, because a trace with no content in it has to earn its usefulness some other way, and almost nobody has thought about how.

What actually shipped

The mechanism is unglamorous, which is a compliment. An administrator sets a telemetry property in the enterprise managed-settings.json file, names an endpoint, and Copilot agent activity starts flowing as OTLP data. GitHub's docs are precise about the receiving end: some backends accept OTLP directly, and for the rest you deploy an OpenTelemetry Collector to receive, process, and forward. So the requirement is an OTLP path, not any backend at all, though in practice a Collector hop covers most of what a company already runs. GitHub's own demo shows a Copilot session landing in Splunk Observability Cloud with an expanded span hierarchy, and it is configured centrally rather than per developer, which matters more than it sounds like it does. Per-developer telemetry configuration means telemetry that exists on four machines.

The important structural fact is that the traces are OTLP, not a proprietary format. Agent spans are going to show up inside tools built years before anyone had an agent, sitting next to HTTP spans and database spans in the same waterfall. Once that is normal, the interesting artifact stops being the agent's transcript and becomes the join between a tool call the agent made and the thing that broke three services downstream forty seconds later. You cannot get that from a chat log. You can get it from a trace.

The standards side is moving at the same time, and it is moving fast enough to be slightly messy. The GenAI semantic conventions were pulled out of the main OpenTelemetry semantic-conventions repository into their own repo, open-telemetry/semantic-conventions-genai, with the original pages now carrying a redirect notice. The main registry at semconv 1.44.0 carries both a Gen AI attribute group and a separate MCP attribute group. Read that as a signal about velocity rather than about chaos: the vocabulary for describing what an agent did is being carved out right now, in public, by people shipping features on deadlines.

The position, stated plainly

Agent observability is going to be won by OpenTelemetry rather than by any vendor's console, and that is good for everyone. It also means the fight that matters is not which dashboard you buy. It is what belongs inside a span that represents one step of an agent's work.

Here is why the content default forces that question. With content capture off, a Copilot agent span can tell you that a tool ran, which tool, how long it took, whether it errored, and where it sat in the session's hierarchy. It cannot tell you what the model was asked or what it answered. So consider the shape of a real failure. An agent refactors a module, runs the test suite, sees three failures, decides to change an assertion rather than the implementation, and commits. Every one of those steps produces a clean span. Every span succeeds. The trace is green end to end, and the thing that went wrong lives entirely inside a decision that the trace, by design, does not contain.

That failure is not a bug in the feature. It is the boundary of what a content-free trace can do, and the only way past it is to decide, ahead of time, which non-content facts about a step are worth recording. Those facts exist. How many tool calls happened in this turn. Whether context was truncated or compacted before the model saw it, and how much. Which files were touched and whether they were touched more than once. Whether a step was a retry. How many turns elapsed since the last human message. None of that is prompt content. All of it is diagnostic.

The teams that get value out of this in the next six months will be the ones who treat span attribute design as real engineering work rather than as a checkbox on a rollout ticket.

Put this into practice

The lowest-friction version of this takes an afternoon and does not require you to commit to anything.

Turn it on against a throwaway collector first. Point the telemetry endpoint at a local OpenTelemetry Collector writing to a file, not at your production backend. You want to see the raw span payload before you decide what your retention policy on it should be. Configuration lives in the enterprise managed-settings.json file, documented in GitHub's OpenTelemetry for agent monitoring page.

Then run the incident test. Pick one real incident from your own history, something an agent did that you had to untangle afterward. Look at the spans you are now collecting and ask a single question: would this have told me anything? Not "is this interesting," but "would this have shortened that afternoon." If the honest answer is no, you have not bought observability. You have bought a dashboard, and dashboards that nobody uses during an incident are worse than nothing because they make everyone feel covered.

Write down the three attributes you wish you had. After the incident test, you will have three. Everybody does. Those three are your actual requirements, and they are what you take to whoever is instrumenting your own agent code, or what you open an issue about upstream. This is also the point at which reading the GenAI semantic conventions repo stops being homework and starts being useful, because you will be looking for something specific.

Decide about content capture on purpose, once, in writing. The switch is there. Turning it on routes developer prompts, which routinely contain code, customer data, and credentials pasted in a hurry, into a monitoring system that was scoped for HTTP latency. If you turn it on, the decision needs an owner, a retention window, and an access control story. If you leave it off, you need the attribute work above. Doing neither is the common outcome and the bad one.

Check whether your monitoring can be turned off by the thing being monitored. OpenAI published its priorities and principles for third party assessments on the same day, and buried in it is a question posed to outside assessors that generalizes well past frontier labs: is monitoring implemented in a way that cannot easily be disabled? Ask it of your own setup. If a developer can drop the telemetry block from a local config and keep working, your coverage number is fiction.

Honest limitations

A content-free trace will not tell you why an agent made a choice, and no amount of attribute design fully fixes that. Reasoning is content. You can record that context was compacted and by how much, but you cannot record what the model concluded from it. For a whole class of questions, the trace narrows the search and a human still has to read something.

This is enterprise-managed configuration, so it is not available to an individual developer on a personal plan who wants to see their own agent's spans. The feature assumes an administrator and a fleet.

The GenAI conventions being mid-migration is a real cost, not a footnote. Attribute names you build dashboards on today may get renamed, and OpenTelemetry's own track record on convention stability includes multi-year migration guides for HTTP and for database attributes. Plan for a rename. Do not build a compliance artifact on top of attribute names that are six weeks old.

And the honest counterargument to the whole premise: if your team runs one agent, occasionally, on a small codebase, none of this pays for itself. Turn it on, leave the defaults, and come back when the agent count goes up. Observability infrastructure has a floor below which it is just work.

One more limitation that is not technical. There is a failure mode where the existence of oversight machinery substitutes for oversight. A Pentagon review reported this week found that personnel relied on the AI inside a targeting system to surface stale intelligence, and it did not, and the consequence was a strike on a school. Nobody had turned the checking off. They assumed it had already happened. A green trace produces exactly that feeling. Build against it.

What to do with this

Agent telemetry is in the rare window where a small amount of attention now compounds. The schema is unsettled, the tooling is free, and the people shipping features have not yet locked in the vocabulary everyone else will inherit. If you have an opinion about what a span for an agent step should contain, this is the six months in which having one is worth something.

Start smaller than that, though. Turn it on against a local collector, run one past incident through it, and see what you wish you had. That single exercise will tell you more about your own agent risk than any framework will, and it costs you an afternoon and no money.

The trace is not the oversight. The trace is what lets you do the oversight. Knowing the difference is most of the job.

Sources: GitHub changelog, September 22, 2026 · GitHub docs, OpenTelemetry for agent monitoring · OpenTelemetry semantic conventions 1.44.0 · OpenTelemetry GenAI semantic conventions repository · OpenAI, priorities and principles for third party assessments, September 22, 2026

Medium metadata

Title: GitHub Copilot Now Speaks OpenTelemetry, and the Default Setting Is the Whole Story
Subtitle: Agent traces are becoming ordinary spans in ordinary monitoring tools. The feature ships with content capture off, which is correct and also the reason your first incident review will come up empty.
Tags: OpenTelemetry, GitHub Copilot, AI Agents, Observability, Software Engineering
Canonical: import from the fervorai.dev URL