What Microsoft actually says
Microsoft's 2026 edition of The AI Decision Brief: A Guide to Frontier Transformation is mostly an enterprise adoption guide. It covers learning cultures, customer engagement, Zero Trust, sustainability, and a 120-day agent roadmap. Most of it is not about software engineering at all.
One page is. In his section on page 34, Microsoft CTO Kevin Scott writes that as software becomes more agentic, programming is shifting "away from writing detailed instructions and toward describing intent": the outcome being pursued, the constraints that matter, and how to tell whether the work is good. He adds that teams need to be "explicit about goals, careful about feedback and evaluation, and thoughtful about where autonomy is earned versus constrained."
That is a precise description of the problem engineering leaders now face with coding agents. It is also an incomplete one, and the gap is worth naming.
Three more signals from the same brief
Kevin Scott's page does not stand alone. Three other passages point the same direction.
- Decision rights have to be redesigned. Jared Spataro, CMO of AI at Work, writes on page 22 that most AI integration failures come from management systems built for a world where humans did all the work, and that "decision rights, review cycles, accountability, and trust all need to be rethought when outputs are co-produced by people and machines."
- The cost of mistakes rises with autonomy. The observability section on page 28 notes that as AI systems move from suggestions to "planning, coordinating, and taking actions across workflows, the cost of mistakes rises," and that developers need to be able to track every agent they build and operate.
- Agents need defined boundaries. The agent lifecycle guidance on page 38 says to define each agent's purpose, success criteria, and what it is not allowed to do, then assign a named accountable owner, limit access, and establish logging and evaluation from day one.
Read together, the brief describes a chain: intent, constraints, bounded autonomy, accountability, evidence. That chain applies to every agent an enterprise runs. It applies with particular force to coding agents, because their output persists as software that other people, and other agents, will build on for years.
Intent has to be written down somewhere
If programming becomes the act of describing intent, the obvious follow-up question is where that intent lives. For a single task, the answer is the prompt or the spec. For a codebase, most of the intent that matters was expressed long before the current task started.
A payments service calls the ledger through an internal client because of an incident two years ago. A domain layer does not import infrastructure adapters because the team decided to keep them swappable. Customer data stays in one region because of a contract. These are constraints in exactly Kevin Scott's sense: they define what a good outcome is allowed to look like. None of them appear in a task description, and an agent asked to "add retry logic to the payment flow" has no reason to discover them.
This is where intent-driven programming meets architecture. Task intent is written fresh each time. Architectural intent is standing intent: decisions the organization already made, which every future change inherits whether or not the person or agent making it knows about them. Microsoft's framing makes the task side explicit. The standing side is the part most organizations still keep in ADR folders, wiki pages, and senior engineers' memory.
Agent governance and architectural governance answer different questions
The governance the brief recommends is real and necessary: an inventory of agents, identity, least-privilege access, observability, owners, and a way to pause or retire an agent. All of it governs the agent. None of it says whether a particular change the agent makes is consistent with the architecture.
| Agent governance | Architectural governance | |
|---|---|---|
| Governs | Identity, permissions, tools, access | Architectural decisions, boundaries, patterns |
| Question | May this agent act? | May this change exist? |
| Examples | IAM, sandboxing, agent registry, DLP | Service boundaries, dependency rules, data residency decisions |
| Evidence | Agent activity and access logs | The decision that applied and the verdict it produced |
An agent can be authenticated, correctly scoped, fully observable, and owned by a named person, and still write a change that breaks a boundary the organization decided on last year. The two layers are complementary. Neither substitutes for the other, and the brief, reasonably for a document of its scope, only describes the first.
What "bounded autonomy" needs from architecture
Kevin Scott's line about autonomy being "earned versus constrained" is the most useful phrase in the brief for engineering leaders, because it implies a mechanism. Constraining autonomy is only possible if the constraints exist in a form the system can apply. For architectural constraints, that means four things:
- Authority. Which decisions are accepted and in force, and which are drafts, superseded, or someone's opinion in a thread.
- Applicability. Which of those decisions govern the files and services a given change touches.
- Enforcement. A check against the proposed change before it lands, for the decisions that can be checked mechanically.
- Evidence. A record of which decision applied and what verdict it produced, so the accountability the brief asks for has something concrete to point to.
This is our conclusion, not Microsoft's. The brief does not propose a decision index or an architectural enforcement layer, and it would overstate the document to say it does. What it does establish, from a company with an unusually wide view of enterprise adoption, is the premise: when agents execute multi-step work, explicit intent, explicit constraints, and deliberate limits on autonomy stop being good hygiene and become the engineering discipline itself.
What engineering leaders should take from it
The brief's own action plans are written for workflows in general. Translated to software delivery, they suggest a short list:
- Separate the architectural decisions that genuinely constrain implementation from general documentation.
- Record which of them are authoritative, and who accepted them.
- Attach each one to the parts of the system it governs.
- Make them retrievable by coding agents at the moment of change, not only by humans at review time.
- Check agent changes against the decisions that can be expressed as rules, and keep the result.
Do not treat the brief's return-on-investment figures as evidence for any of this. They measure broad AI adoption, not architectural outcomes, and they come from a vendor with a stake in adoption.
Where Mneme fits
Mneme applies this approach to one class of decision: architectural decisions in a repository. It compiles accepted decisions into scoped rules, returns deterministic PASS, WARN, or FAIL verdicts against proposed changes, and, through the local Decision MCP server shipped in 0.9.0, lets an agent ask which decisions apply to the paths it is working on. It does not govern agent identity or access, which belong to the platform layer the brief describes, and not every architectural decision reduces to a mechanical rule.
Microsoft is right that programming is becoming the practice of describing intent. The part that decides whether architecture survives that shift is whether the intent an organization already has is written somewhere an agent is actually bound by it.