The role of artificial intelligence agents in architecture is evolving rapidly, with identity, isolated execution, and observability becoming essential for large-scale deployment. Traditionally, building an AI agent involved selecting a model, providing context, and connecting to tools—an approach that worked for simple demonstrations but fell short when agents needed to monitor events, intervene in systems, execute code, or resume tasks after interruptions. Recent developments from Microsoft and GitHub suggest a shift: agents are becoming workloads that are not only used but also governed, with identity, permissions, execution environments, and traces playing a central role. While the choice of model remains important, it no longer solely defines the architecture. Triggering an agent should no longer require a parallel platform. Microsoft Foundry Agent Service Routines, available since September 24, allow launching an agent on a specific date, according to a recurrence, or from an event. The first event-based integrations include GitHub issues and Teams channel messages. The trigger, identity used, connections, and execution history are gathered in the Foundry project. However, the tool that allows a hosted agent to program its own resumption on the same conversation remains in preview. For architecture teams, the question arises of which schedulers, webhooks, and tracking mechanisms must still be developed and maintained. A managed capacity can simplify certain scenarios, provided the expected reliability, available integrations, and how failures are handled are verified. This also forces a governance decision: in whose name does the agent act? A Routine can use the delegated identity of its creator or the agent's own identity. This choice determines the accessible systems and permissions exercised when no one directly supervises the execution. Separating the control of the agent from where it works is crucial. An agent that analyzes a document and an agent that clones a repository, installs dependencies, and runs code present different operational risks. In a published analysis on September 23, Microsoft proposes governing the agent in Foundry and executing its tasks in isolated Azure Container Apps Sandboxes. It is a model of architecture to evaluate according to usage rather than a universal schema to apply directly. For a Platform Engineering team, this separation can become a golden path: providing each agent with an environment suitable for its task, with a defined identity, limited network access, and traceable logs. The developer obtains a ready-to-use framework; the platform team retains control over the conditions under which the generated code or the agent's tools execute. GitHub follows a similar logic on the development workstation. The local sandboxing of the Copilot application allows limiting, per project, access to files, networks, and identifiers. It is in preview and disabled by default: its adoption therefore requires explicit configuration and validation in the concerned environments. Observing the work of agents, then measuring its effects. When an agent acts in several steps, knowing its final response is not enough. It is necessary to understand which models and tools it has requested, where it failed, and why its behavior changed. The GitHub Copilot application now supports the export of OpenTelemetry traces via parameters managed by the company. The content of prompts and responses is excluded by default; any modification of this capture must be examined in light of confidentiality rules. However, technical observability alone does not indicate whether the Developer Experience is progressing. GitHub has also added to its metrics API a breakdown of the pull request review time: waiting for the first review, exchanges until the final review, and then the delay before merging. The medians and p90 values allow distinguishing a common problem from a few particularly slow cases. These new data concern eligible human reviews and are not reconstructed for previous history. This measure is valuable to avoid a common error: celebrating the acceleration of code production while changes still wait several days before being reviewed and integrated. If agents generate more proposals, the review capacity and decision rules become even more critical. The choice of model must follow that of the task. The arrival of GPT-6 Sol and Luna alongside Astra in Microsoft Foundry expands the options for production agents. Microsoft positions Astra on demanding reasoning tasks, Sol on general uses, and Luna on high-volume tasks. Deployment modes and available zones vary by model. The architectural consequence is to move away from a single model for all agents. A simple routing, a repetitive extraction, and a complex decision do not have the same requirements. It is necessary to compare the quality obtained, latency, cost per successful task, and data residency constraints on representative evaluations of real usage. These evolutions do not make platform engineering less necessary. They shift its work toward defining a common framework: how an agent is triggered, what identity it uses, where its code executes, what it can access, what is recorded, and how its result is evaluated. The next useful project is to take a limited but real use case — for example, triaging an issue or analyzing a pull request — and document its complete journey. The objective is not only to prove that the agent knows how to perform the task. It is to show that the organization can understand, control, and improve what it does when it works at scale.