Alan Dye, who has led Apple’s UI design team since 2015, is leaving to join Meta as its chief design officer, Bloomberg reports. He’ll join Meta on December 31st, and Meta is opening a design studio and giving Dye oversight of design for “hardware, software and AI integration for its interfaces,” according to Bloomberg. Dye will report to Meta CTO Andrew Bosworth.

Designer Steve Lemay will replace Dye at Apple, the company confirmed to Bloomberg. “Steve Lemay has played a key role in the design of every major Apple interface since 1999,” CEO Tim Cook told Bloomberg in a statement. “He has always set an extraordinarily high bar for excellence and embodies Apple’s culture of collaboration and creativity.” Following the recent retirement of former COO Jeff Williams, Apple’s design team now reports to Tim Cook.

Apple and Meta didn’t immediately reply to a request for comment.

Dye’s departure is the latest leadership change at Apple, and another one of many top designers who have left the company in the last several years. Williams officially left Apple in November, and the company announced earlier this week that AI chief John Giannandrea would be stepping down. Bloomberg has also reported that chips lead Johnny Srouji is evaluating his future at the company.

All I wanted was a pair of New Balances. I was done trusting stylish influencers who swore Vans, Converse, and Allbirds were up to the challenge of walking 20,000 steps day in and day out. They are not. Fall is the season of holiday sales, so there's no better time to shop… if you're immune to being overwhelmed by modern day e-commerce.

Wouldn't it be grand if I could skip all the fake deals and barely disguised ads, and have the internet find the best stuff for me? What if I could tell the internet my wish and have it granted?

Tech CEOs have been evangelizing that this is the future. Tell the bot what you want, kick up your feet, and le …

Read the full story at The Verge.

Every engineering team has its unwritten rules. How you structure Terraform modules. Which dashboards you trust. How database migrations must be handled (never at midnight). And your work stretches across more than your editor into observability, security, CI/CD, and countless third-party tools.

GitHub Copilot isn’t just here to help you write code. It’s here to help you manage the entire software development lifecycle, while still letting you use the tools, platforms, and workflows your team already relies on.

Custom agents bring that full workflow into Copilot.

We’re introducing a growing ecosystem of partner-built custom agents for the GitHub Copilot coding agent (plus the option to create your own). These agents understand your tools, workflows, and standards—and they work everywhere Copilot works: 

• In your terminal through Copilot CLI for fast, end-to-end workflows
• In VS Code with Copilot Chat
• In github.com in the Copilot panel

Let’s jump in. 

What custom agents actually are

Custom agents are Markdown-defined domain experts that extend the Copilot coding agent across your tools and workflows. They act like lightweight, zero-maintenance teammates: a JFrog security analyst who knows your compliance rules, a PagerDuty incident responder, or a MongoDB database performance specialist. 

Defining one looks like this:

---
name: readme-specialist
description: Expert at creating and maintaining high-quality README documentation
---

You are a documentation specialist focused on README files. Your expertise includes:

- Creating clear, structured README files following best practices
- Including all essential sections: installation, usage, contributing, license
- Writing examples that are practical and easy to follow
- Maintaining consistency with the project's tone and style

Only work on README.md or documentation files—do not modify code files.

Add it to your repository:

The simplest way to get started is to add your agent file to your repository’s agent directory:

.github/agents/readme-specialist.md

Your agent appears instantly in: 

• GitHub Copilot CLI
• github.com in the control plane
• VS Code in Copilot Chat

You can also define agents at:

• Repository level: .github/agents/CUSTOM-AGENT-NAME.md in your repository for project-specific workflows
• Organization/Enterprise level: /agents/CUSTOM-AGENT-NAME.md in a .github or .github-private repository for broader availability across all repositories in your org

Featured examples from our partners with real developer workflows

Here are real engineering workflows, solved with a single command via custom agents.

Trigger and resolve incidents faster (PagerDuty Incident Responder) 

copilot --agent=pagerduty-incident-responder \
  --prompt "Summarize active incidents and propose the next investigation steps."

Use this agent to:  

• Pull context from PagerDuty alerts
• Generate a clear overview of incident state
• Recommend investigation paths
• Draft incident updates for your team

Fix vulnerable dependencies and strengthen your supply chain (JFrog Security Agent)

copilot --agent=jfrog-security \
  --prompt "Scan for vulnerable dependencies and provide safe upgrade paths."

Use this agent to: 

• Identify vulnerable packages
• Provide recommended upgrade versions
• Patch dependency files directly
• Generate a clear, security-aware pull request summary 

Modernize database workflows and migrations (Neon) 

copilot --agent=neon-migration-specialist \
  --prompt "Review this schema migration for safety and best practices."

Use this agent to:

• Validate schema changes
• Avoid unsafe migrations
• Tune analytical workflows
• Optimize transformations and queries

Speed up product experimentation and feature rollouts (Amplitude Experiment Implementation) 

copilot --agent=amplitude-experiment-implementation \
  --prompt "Integrate an A/B test for this feature and generate tracking events."

Use this agent to: 

• Generate experiment scaffolding
• Insert clean, consistent event tracking 
• Map variations to your product logic
• Ensure your data flows correctly into Amplitude

Why this matters

By encoding your team’s patterns, rules, and tool integrations into a reusable agent, Copilot actually understands how your team works—not just the code in front of it. Custom agents help: 

• Keep patterns consistent (Terraform conventions, database rules, security standards, etc.) 
• Stop repeating context by defining expectations once and reusing them everywhere
• Share expertise automatically so the entire team can follow best practices (even when your subject matter expert is on vacation or in a different timezone)
• Work directly with your tools using Model Context Protocol (MCP) servers to pull data from your DevOps, security, and observability systems

The full catalog of custom agents from our partners

We partnered across the ecosystem to create custom agents that solve real engineering problems. 

Observability and monitoring

• Dynatrace Observability and Security Expert: Configure and optimize Dynatrace monitoring for your applications
• Elasticsearch Remediation Agent: Handle Elasticsearch configuration, query optimization, and observability setup

Security and compliance

• JFrog Security Agent: Identify and remediate security vulnerabilities in your dependencies
• StackHawk Security Onboarding: Set up dynamic application security testing

Database and data management

• MongoDB Performance Advisor: Analyze and optimize MongoDB query performance
• Neon Migration Specialist: Migrate databases to Neon’s serverless Postgres
• Neon Performance Analyzer: Find bottlenecks and optimization opportunities
• Neo4j Docker Client Generator: Generate Docker-based client code for Neo4j graph databases

DevOps and infrastructure

• Terraform Infrastructure Agent: Write, review, and optimize Terraform infrastructure as code
• Arm Migration Agent: Migrate applications to Arm-based architectures
• Octopus Release Notes Expert: Generate comprehensive release notes from deployment data
• DiffBlue Java Unit Test Custom Agent: Generate fast, reliable Java unit tests using DiffBlue’s AI-powered test generation engine to improve coverage and catch regressions automatically

Incident response and project management

• PagerDuty Incident Responder: Triage and respond to production incidents
• Monday Bug Context Fixer: Pull context from monday.com to resolve bugs faster

Feature management and experimentation

• LaunchDarkly Flag Cleanup: Identify and safely remove obsolete feature flags
• Amplitude Experiment Implementation: Implement A/B tests and experiments

API integration and automation

• Apify Integration Expert: Integrate web scraping and automation workflows
• Lingo.dev Internationalization Implementation Custom Agent: Detect, extract, and implement internationalization patterns across your codebase for seamless localization
• Factory.ai Code Spec Custom Agent: Install, configure, and automate development workflows using Droid CLI for CI/CD pipelines

Run any of them with the following command:

copilot --agent=<agent-name> --prompt "<task>"

Get started

Custom agents shift Copilot from “help write this code” to “help build software the way our team builds software.”

These agents are also available now for all GitHub Copilot users, and you should try one: 

copilot --agent=terraform-agent --prompt "Review my IaC for issues"

• Explore all the partner agents in the awesome-copilot repository (with plenty of real-world examples).
• Give us feedback to let us know what you think of custom agents in GitHub Copilot!
• Learn how to build your own custom agent with our documentation on creating custom agents (and how they work).

The post Your stack, your rules: Introducing custom agents in GitHub Copilot for observability, IaC, and security appeared first on The GitHub Blog.

A SteamOS and Steam Deck architect revealed that Valve is quietly bringing SteamOS and Windows games to Arm.

The post Valve is Bringing SteamOS, Windows Games to Arm appeared first on Thurrott.com.

When AI systems were just a single model behind an API, life felt simpler. You trained, deployed, and maybe fine-tuned a few hyperparameters.

But that world’s gone. Today, AI feels less like a single engine and more like a busy city—a network of small, specialized agents constantly talking to each other, calling APIs, automating workflows, and making decisions faster than humans can even follow.

And here’s the real challenge: The smarter and more independent these agents get, the harder it becomes to stay in control. Performance isn’t what slows us down anymore. Governance is.

How do we make sure these agents act ethically, safely, and within policy? How do we log what happened when multiple agents collaborate? How do we trace who decided what in an AI-driven workflow that touches user data, APIs, and financial transactions?

That’s where the idea of engineering governance into the stack comes in. Instead of treating governance as paperwork at the end of a project, we can build it into the architecture itself.

From Model Pipelines to Agent Ecosystems

In the old days of machine learning, things were pretty linear. You had a clear pipeline: collect data, train the model, validate it, deploy, monitor. Each stage had its tools and dashboards, and everyone knew where to look when something broke.

But with AI agents, that neat pipeline turns into a web. A single customer-service agent might call a summarization agent, which then asks a retrieval agent for context, which in turn queries an internal API—all happening asynchronously, sometimes across different systems.

It’s less like a pipeline now and more like a network of tiny brains, all thinking and talking at once. And that changes how we debug, audit, and govern. When an agent accidentally sends confidential data to the wrong API, you can’t just check one log file anymore. You need to trace the whole story: which agent called which, what data moved where, and why each decision was made. In other words, you need full lineage, context, and intent tracing across the entire ecosystem.

Why Governance Is the Missing Layer

Governance in AI isn’t new. We already have frameworks like NIST’s AI Risk Management Framework (AI RMF) and the EU AI Act defining principles like transparency, fairness, and accountability. The problem is these frameworks often stay at the policy level, while engineers work at the pipeline level. The two worlds rarely meet. In practice, that means teams might comply on paper but have no real mechanism for enforcement inside their systems.

What we really need is a bridge—a way to turn those high-level principles into something that runs alongside the code, testing and verifying behavior in real time. Governance shouldn’t be another checklist or approval form; it should be a runtime layer that sits next to your AI agents—ensuring every action follows approved paths, every dataset stays where it belongs, and every decision can be traced when something goes wrong.

The Four Guardrails of Agent Governance

Policy as code

Policies shouldn’t live in forgotten PDFs or static policy docs. They should live next to your code. By using tools like the Open Policy Agent (OPA), you can turn rules into version-controlled code that’s reviewable, testable, and enforceable. Think of it like writing infrastructure as code, but for ethics and compliance. You can define rules such as:

• Which agents can access sensitive datasets
• Which API calls require human review
• When a workflow needs to stop because the risk feels too high

This way, developers and compliance folks stop talking past each other—they work in the same repo, speaking the same language.

And the best part? You can spin up a Dockerized OPA instance right next to your AI agents inside your Kubernetes cluster. It just sits there quietly, watching requests, checking rules, and blocking anything risky before it hits your APIs or data stores.

Governance stops being some scary afterthought. It becomes just another microservice. Scalable. Observable. Testable. Like everything else that matters.

Observability and auditability

Agents need to be observable not just in performance terms (latency, errors) but in decision terms. When an agent chain executes, we should be able to answer:

• Who initiated the action?
• What tools were used?
• What data was accessed?
• What output was generated?

Modern observability stacks—Cloud Logging, OpenTelemetry, Prometheus, or Grafana Loki—can already capture structured logs and traces. What’s missing is semantic context: linking actions to intent and policy.

Imagine extending your logs to capture not only “API called” but also “Agent FinanceBot requested API X under policy Y with risk score 0.7.” That’s the kind of metadata that turns telemetry into governance.

When your system runs in Kubernetes, sidecar containers can automatically inject this metadata into every request, creating a governance trace as natural as network telemetry.

Dynamic risk scoring

Governance shouldn’t mean blocking everything; it should mean evaluating risk intelligently. In an agent network, different actions have different implications. A “summarize report” request is low risk. A “transfer funds” or “delete records” request is high risk.

By assigning dynamic risk scores to actions, you can decide in real time whether to:

• Allow it automatically
• Require additional verification
• Escalate to a human reviewer

You can compute risk scores using metadata such as agent role, data sensitivity, and confidence level. Cloud providers like Google Cloud Vertex AI Model Monitoring already support risk tagging and drift detection—you can extend those ideas to agent actions.

The point isn’t to slow agents down but to make their behavior context-aware.

Regulatory mapping

Frameworks like NIST AI RMF and the EU AI Act are often seen as legal mandates.
In reality, they can double as engineering blueprints.

Governance principle	Engineering implementation
Transparency	Agent activity logs, explainability metadata
Accountability	Immutable audit trails in Cloud Logging/Chronicle
Robustness	Canary testing, rollout control in Kubernetes
Risk management	Real-time scoring, human-in-the-loop review

Mapping these requirements into cloud and container tools turns compliance into configuration.

Once you start thinking of governance as a runtime layer, the next step is to design what that actually looks like in production.

Building a Governed AI Stack

Let’s visualize a practical, cloud native setup—something you could deploy tomorrow.

[Agent Layer]
↓
[Governance Layer]
→ Policy Engine (OPA)
→ Risk Scoring Service
→ Audit Logger (Pub/Sub + Cloud Logging)
↓
[Tool / API Layer]
→ Internal APIs, Databases, External Services
↓
[Monitoring + Dashboard Layer]
→ Grafana, BigQuery, Looker, Chronicle

All of these can run on Kubernetes with Docker containers for modularity. The governance layer acts as a smart proxy—it intercepts agent calls, evaluates policy and risk, then logs and forwards the request if approved.

In practice:

• Each agent’s container registers itself with the governance service.
• Policies live in Git, deployed as ConfigMaps or sidecar containers.
• Logs flow into Cloud Logging or Elastic Stack for searchable audit trails.
• A Chronicle or BigQuery dashboard visualizes high-risk agent activity.

This separation of concerns keeps things clean: Developers focus on agent logic, security teams manage policy rules, and compliance officers monitor dashboards instead of sifting through raw logs. It’s governance you can actually operate—not bureaucracy you try to remember later.

Lessons from the Field

When I started integrating governance layers into multi-agent pipelines, I learned three things quickly:

1. It’s not about more controls—it’s about smarter controls.
   When all operations have to be manually approved, you will paralyze your agents. Focus on automating the 90% that’s low risk.
2. Logging everything isn’t enough.
   Governance requires interpretable logs. You need correlation IDs, metadata, and summaries that map events back to business rules.
3. Governance has to be part of the developer experience.
   If compliance feels like a gatekeeper, developers will route around it. If it feels like a built-in service, they’ll use it willingly.

In one real-world deployment for a financial-tech environment, we used a Kubernetes admission controller to enforce policy before pods could interact with sensitive APIs. Each request was tagged with a “risk context” label that traveled through the observability stack. The result? Governance without friction. Developers barely noticed it—until the compliance audit, when everything just worked.

Human in the Loop, by Design

Despite all the automation, people should also be involved in making some decisions. A healthy governance stack knows when to ask for help. Imagine a risk-scoring service that occasionally flags “Agent Alpha has exceeded transaction threshold three times today.” As an alternative to blocking, it may forward the request to a human operator via Slack or an internal dashboard. That is not a weakness but a good indication of maturity when an automated system requires a person to review it. Reliable AI does not imply eliminating people; it means knowing when to bring them back in.

Avoiding Governance Theater

Every company wants to say they have AI governance. But there’s a difference between governance theater—policies written but never enforced—and governance engineering—policies turned into running code.

Governance theater produces binders. Governance engineering produces metrics:

• Percentage of agent actions logged
• Number of policy violations caught pre-execution
• Average human review time for high-risk actions

When you can measure governance, you can improve it. That’s how you move from pretending to protect systems to proving that you do. The future of AI isn’t just about building smarter models; it’s about building smarter guardrails. Governance isn’t bureaucracy—it’s infrastructure for trust. And just as we’ve made automated testing part of every CI/CD pipeline, we’ll soon treat governance checks the same way: built in, versioned, and continuously improved.

True progress in AI doesn’t come from slowing down. It comes from giving it direction, so innovation moves fast but never loses sight of what’s right.