Chat-to-code agents: how to preserve context provenance

When an agent only summarizes a thread, an imperfect interpretation produces a debatable answer. When that same thread can start a session, create an issue, or open a pull request, interpretation becomes an operational decision. A file shared weeks ago, a retracted instruction, or the channel's default repository can end up influencing real code. The problem is no longer how much context fits, but which part was current, who was allowed to contribute it, and which action it authorized.

GitHub announced on September 25, 2026 that Copilot for Slack and Microsoft Teams can use more files, attachments, links, forwarded images, and history, preserve a link to the originating conversation, and better handle interrupted or stale replies. We consulted the release on September 28, three Lima calendar days later; the source exposes no reliable time, so we do not claim an exact age. It is a meaningful improvement, but it does not by itself prove that every chat-to-code workflow is production-ready.

The integration captures the conversation and combines it with an identity, repository, branch, and sandbox session. In a direct message it can act with the permissions of the linked personal account; in a shared context it creates artifacts under the application's identity. GitHub also documents that the entire thread informs the decision and is stored in generated artifacts. Those product choices form an execution envelope even if the interface presents them as a mention inside chat.

A useful architecture separates four layers: conversational evidence, approved intent, effective authority, and verifiable outcome. A message can contribute evidence without granting permission. A person with write access can initiate work without turning every earlier sentence into a requirement. The app can create a branch without gaining merge authority. And the pull request can link the thread without assuming that the thread is a consistent specification. If those layers are mixed, the team gets convenient automation that is hard to audit or stop.

Do not send a mutable thread as an opaque bag. When the session starts, record message identifiers, attachment versions or hashes, authors, timestamps, and the exact captured range. Add an explicit exclusion list: deleted messages, content outside the thread, unresolved links, and files the agent could not access. The goal is not to retain every datum forever, but to answer which evidence this execution saw and which evidence stayed out.

Then normalize intent into a small contract: objective, non-goals, repository, base branch, allowed operations, and completion criterion. Require confirmation when the contract is ambiguous or when two recent messages conflict. A backlink helps investigation, but it does not replace the snapshot because the thread can keep changing while the agent works. Treat the conversation as provenance and the confirmed contract as execution input.

In a shared channel, many people can add context even though only some can initiate changes. That asymmetry is reasonable when it is visible: contributing a constraint is not the same as authorizing a write. Record who triggered the session, which identity the agent used, and which participants could influence the envelope. For high-impact actions, require the initiator to confirm the contract after other contributions are incorporated rather than inferring consensus from the thread's existence.

Apply least privilege by stage. Reading a repository, creating a branch, pushing commits, opening a pull request, modifying CI, and merging are distinct capabilities. GitHub's documentation says pull requests created from shared context use the app identity and can require an extra approval through rulesets. Preserve that separation: a conversational integration should produce a reviewable change, not silently gain the ability to approve its own outcome.

Default repositories reduce friction, but they can also turn an omission into a write against the wrong system. Always display repository and branch before execution, and require confirmation again if either changes during the session. Use one session per task, a dedicated branch, and an identifier that travels from the thread to the commit and pull request. Do not let a destination change reuse credentials, tool state, or plans built for the previous repository.

Revocation must cut capability, not merely hide a response. If someone cancels, supersedes the session, or changes the repository, invalidate the execution token, block new tool calls, and mark partial artifacts as abandoned. The announcement highlights improvements that prevent superseded sessions from continuing to act in the old repository. That is the right contract: a stale response must not arrive late with still-valid effects.

A functional test asks whether the patch satisfies the contract. A provenance test asks whether every material decision traces back to the message, file, or confirmation that justified it. An authority test confirms that no tool exceeded the declared scope. A lifecycle test verifies that canceling, superseding, or disconnecting the session prevents later effects. Do not collapse these signals into one score: a correct patch may still have been produced with prohibited context or excessive permissions.

Build a suite with incomplete threads, contradictory requirements, replaced attachments, unauthorized users, similarly named repositories, late reconnections, and two competing sessions. At minimum, measure wrong-destination selections, actions after revocation, decisions without a source, appropriate clarification requests, and changes accepted after review. The release gate should require zero out-of-scope writes and enough evidence to reconstruct accepted cases; usefulness is analyzed separately.

Suppose support shares a screenshot in Teams showing a CSV export with incorrect time zones. Product adds that the historical format must remain stable, and an engineer links the reporting repository. The agent should not interpret the entire channel. It freezes those three contributions, classifies the screenshot as potentially sensitive, drafts a contract limiting the change to the date formatter, and asks for confirmation of the repository, base branch, and absence of schema changes. Only then does it open a session with read and write access to an isolated branch.

During execution, another message proposes migrating the whole export. That idea stays outside the snapshot and is recorded as separate work. If the team changes the destination to a legacy repository, the current session is revoked and does not pass along its token. The pull request includes the thread link, attachment hash, confirmed contract, tests run, and a note that the screenshot was not committed to the repository. Human review evaluates both the result and the decision chain. This scenario is illustrative; it does not describe a Wasyra customer or implementation.

The integrations remain in public preview and some capabilities roll out gradually. They also do not solve retention, data classification, residency, secrets inside attachments, or consistency within a human conversation by themselves. A backlink improves traceability, but it does not certify that the source was correct. A sandbox reduces environment exposure, but it does not fix a wrong repository or an identity with broad permissions.

Before adopting the workflow, require a demonstration with your own controls: a context snapshot, confirmed contract, identity separation, explicit scope, effective revocation, and a reviewable artifact. If the team cannot reconstruct why the agent made a decision or prove that a canceled session lost capability, chat is still a convenience interface rather than a trustworthy control plane.

The value appears when conversation accelerates discovery without erasing engineering boundaries. Start with small, reversible tasks protected by review; retain the thread as evidence, but promote only the confirmed contract into executable input. If you need to design that path for your own operation, Wasyra's custom agent service can help turn it into a measurable system with permissions and gates matched to risk.