Joseph Osei-Kusi: How Artificial Harmony Silences Agile Teams Before the Real Problems Surface
Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.
"Silence can be more dangerous than conflict, because at least with conflict something is being expressed." - Joseph Osei-Kusi
Joseph shares a team story from a high-stakes migration project where the team looked mature on the outside. Meetings were calm. Nobody argued. Plans were accepted quickly. But what looked like alignment was really artificial harmony. Stakeholders brought pressure and proposed solutions, while the team softened their message instead of making risks visible. Over time, that silence created bottlenecks, delayed difficult conversations, increased technical debt, and left the team with fewer options. Joseph learned to treat unusual quietness as data. When a team agrees too quickly, he asks questions like: What would make this plan work? What would make it fail? What concerns are we not saying out loud? The goal is not to create drama. The goal is to make reality visible early, while the team and stakeholders still have room to choose.
In this segment, we talk about artificial harmony and how Scrum Masters can help teams make trade-offs visible before silence becomes expensive.
Self-reflection Question: Where might your team be choosing politeness over useful honesty?
Featured Book of the Week: The Five Dysfunctions of a Team by Patrick Lencioni
Joseph recommends The Five Dysfunctions of a Team by Patrick Lencioni because it helped him see that many team issues are trust problems before they are process problems. Poor planning, quiet retrospectives, weak working agreements, and missed commitments often point to something deeper: people avoiding conflict because the trust is not there. Vasco also mentions The Speed of Trust by Stephen M. R. Covey, a useful companion for understanding the business impact of high-trust versus low-trust environments. For Joseph, these books reinforce a core Scrum Master lesson: teams do not always need another process tweak. Sometimes they need to rebuild trust and learn how to disagree productively.
[The Scrum Master Toolbox Podcast Recommends]
🔥In the ruthless world of fintech, success isn't just about innovation—it's about coaching!🔥
Angela thought she was just there to coach a team. But now, she's caught in the middle of a corporate espionage drama that could make or break the future of digital banking. Can she help the team regain their mojo and outwit their rivals, or will the competition crush their ambitions? As alliances shift and the pressure builds, one thing becomes clear: this isn't just about the product—it's about the people.
🚨 Will Angela's coaching be enough? Find out in Shift: From Product to People—the gripping story of high-stakes innovation and corporate intrigue.
Joseph is an Agile coach and Scrum Master obsessed with the human side of delivery. He has focused on moving teams beyond just "following the process" to delivering value. He champions radical transparency and psychological safety, and believes that when you get the people part right, everything else falls into place.
How I replaced a dead IKEv2 VPN with Cloudflare Zero Trust, a Raspberry Pi 3, and zero open ports, plus the WireGuard detour that taught me what not to do.
Last year, we introducedGEM, the industry’s largest recommendation system (RecSys) foundation model. GEM established Meta’s first LLM-inspired paradigm for ads recommendation, driving major performance gains. Building on this foundation, our next goal is to further scale both compute and intelligence transfer with next-generation hardware, and expand this capability across Meta’s entire ads ecosystem. This spans dozens of surfaces and objectives, delivering seamless full-funnel optimization across awareness, consideration, and conversions.
The 2026 generation of GEM shifts from isolated per-domain optimizations — such as Facebook, Instagram, Reels — to a single central foundation model. It learns from data and signals across all of Meta’s ads platforms, bends the scaling curve at LLM-scale computation, and delivers strong advertiser outcomes through post-training techniques that provide a larger latency budget without requiring real-time evaluation of all ad candidates — all on a substantially more efficient training stack. The result is simultaneous ad performance gains across every surface and funnel stage, and deeper understanding that better matches ads to what people are looking for.
GEM has delivered 18.9% conversion improvement and 12% ad click-through rate (CTR) improvement across Meta’s ad surfaces and objectives, and additionally contributed 5.8%, 4.1%, and 1.6% conversion uplift on Facebook, Instagram, and off-site conversion for targeted users over the past year. These gains span both upper-funnel surfaces and deep-funnel optimization goals, driving stronger returns for advertisers.
GEM advances the frontier of recommender systems in the following four areas:
1. Bending the Scaling Curve, Enabling 2.5x Model Complexity
Challenge: Empirical scaling laws demonstrate that model performance predictably improves with compute, parameter, and data size using transformer model architecture. However, recommender system models do not exhibit similar scaling properties with transformer due to massive heterogeneous features and shifting distributions.
Solution: We built an LLM-style architecture — Kunlun, co-designed with the latest GPU hardware, to make larger, deeper models substantially more cost-efficient and to enable long-context learning over user engagement history. We observed an LLM-like scaling law at our largest pre-training scale with 2.5x model complexity growth from earlier versions of GEM. The pattern mirrors frontier LLMs: more capacity and longer context produce emergent gains in ranking quality that translate directly into business results.
2. Efficient Intelligence Transfer From GEM to User-Facing Models
Challenge: Serving a model at this scale in real time is prohibitively expensive and drives up latency, compromising both user experience and advertiser ROI.
Solution: The structured representation, LoopFM, a state-of-the-art post-training technique, transfers GEM’s internal representations and sequential historical memory to downstream models. Through computation sharing, it doubles the intelligence transfer together with the knowledge distillation deployed in the previous version, at no additional compute cost or latency. We also introduced elastic pre-computation (Solaris) to harvest the gains from the upstream model.
3. Accelerating the Central Compute Engine With Large-Scale Cross-Surface, Cross-Domain Learning at Meta Ads Scale
Challenge: Meta’s apps span dozens of surfaces — Facebook, Instagram, Reels, Stories, and more — with 3.6 billion people using at least one of our apps each day. Each surface and optimization objective previously had its own independent prediction system. As the platform grows in surfaces and objectives, so does the challenge of improving ad performance simultaneously.
Solution: GEM accelerates one single, unified compute engine through the central foundation model that jointly predicts clicks and conversions across all surfaces, including Facebook and Instagram, and across every key advertiser objective from off-site conversions to mobile app installs. The generalizable representations learned on data-rich click tasks transfer into data-sparse conversion tasks. A new training recipe with cost-free data mixing and the domain expert framework makes this heterogeneous, large-scale learning tractable, with predictable scale and enhanced reliability.
4. Scaling Total Training FLOPs by 4x While Doubling E2E Training Efficiency Across Thousands of GPUs
Challenge: Training a RecSys foundation model across thousands of GPUs at this scale requires careful orchestration of compute, parallelism, communication, and memory. Today’s data center GPUs and their software stacks are mostly optimized for LLM workloads, whereas recommendation workloads have a fundamentally different profile due to unique data characteristics that make it extremely difficult to achieve high GPU compute utilization while scale.
Solution: We developed custom kernels with low precision and new 5D parallelism strategies co-designed with the latest GPU hardware and Meta’s training cluster, and optimized model architecture with infrastructure together to scale efficiently across thousands of GPUs. End-to-end training efficiency is doubled to 20-25% model FLOPS utilization (MFU) with 4x total training FLOPs, enabling GEM to train at LLM-scale at Meta (see full technical story in our companion blog on Training GEM at LLM Scale).
Scaling Law: Bend Scaling Curve at Frontier Scale with Kunlun
GEM introduces a new LLM-style model architecture — Kunlun. Compared to the previous version (Interformer), Kunlun delivers 2x performance gains with the same computation scaling. Kunlun is designed around the following innovations:
Standardize and unify architecture framework by seamlessly interleaving lifelong sequence modeling with scalable recommendation-specific cross-interaction.
Introduce scalable architecture through deep co-design with the latest generation of hardware, and computation reduction with almost no model quality regression.
Innovate efficient sequence scaling to process longer user engagement contexts with offline sequence infrastructure.
The scaling law pattern on the light-weight model of GEM with small parameter size.
Efficient Architecture for Scaling Recommendations
GEM’s Kunlun architecture effectively bends the recommender system scaling curve at frontier training scales by empowering ultra-long user sequences and massive user-item interaction features. For the following technical discussion, we define two types of features: non-sequence features (such as user demographics, ad content representations), and sequence features with a sequence of events, each composed of a set of features.
This architecture introduces three fundamental advancements:
1. A Standardized and Unified Architecture Framework
We advanced the LLM-style architecture to better capture the unique characteristics of recommender system models — specifically, heterogeneous features and data dynamics.
Each layer consists of:
Attention: customize the attention and feed-forward networks to capture the long dependency pattern in user behavior by adapting to data dynamics.
Summarization Component: simplify and enhance the summarization architecture to extract critical user insights from sequences, effectively bridging sequence and non-sequence structure.
Cross Interaction: expand to the mixture-of-experts (MoE) style design, enabling large-scale modeling of complex interactions between sequence and non-sequence features.
2. Introducing Scalable Architecture Through Deep Co-design
We co-designed the architecture with the latest generation of hardware to allow it to grow deeper and wider efficiently:
Computation Complexity Reduction via Block Attention: Replacing full self-attention with block-aligned sparse attention reduces the complexity associated with sequence length from quadratic to linear relative to window size, and uses only the window size that is a multiple of block size, friendly for the kernel without partial block size.
Component Unification via Architecture Reformulation: Per-Example Feed-Forward Networks (pFFN) was introduced to adapt the traditional FFN to per-example distribution. We reformulated the pFFN component into attention operations through Generalized Dot-Product Attention (GDPA), speeding up training by targeting at unifying the model’s many attention-like operations into a single GPU kernel, delivering up to 2x forward speedup.
Scalable Cross interaction through Expert Parallelism:Our cross-interaction component utilizes a scalable, MoE-like framework that employs model-expert parallelism, allowing each GPU to process a subset of expert sub-networks in parallel.
3. Innovating Efficient Sequence Scaling
We introduced specialized component designs to make ultra-long sequences computationally tractable:
Component Skip Connection (CompSkip): The computational skip mechanism selectively activates sequence modules in each layer, and only routes outputs through residual connections. By selectively deactivating the specific components, which is based on the assumption that the network can recover quickly after re-activating, we reduce FLOPS by 43% with negligible quality loss.
Sequence Unification (OneSeq): We selectively unify user sequences chronologically after the event feature aggregation. This allows a single, unified sequence layer to process long sequences, even when individual events possess heterogeneous structures and features. In the system, we have different user sequence sources, some of which have different events features. For example, an event in a purchase sequence can be described by ad ID and account ID, while the event in a post sequence is described by actors and object ID. They cannot simply be unified from the data source level due to the different set of event features. It requires the flexible sequence unification approach to maximize GPU efficiency because of large-size tensor operations and minimizing operator fragmentation.
The GEM Architecture. On the left is the building block, and right is an illustration of the computation skip mechanism.
How Ultra-Long Sequences Matter
The new architecture makes ultra-long sequences feasible. GEM scaled the long engagement context length by 2x in production, and further enabled the capability of scaling long context to 25x, demonstrating infrastructure capability at frontier scale. Along the way, we discovered:
Prediction quality follows a power law with sequence length. The relationship is predictable and consistent across sequence lengths.
Larger models benefit disproportionately from longer sequences. This creates a virtuous cycle: scaling compute makes the model bigger, which makes longer sequences more valuable. Scaling sequence length makes the model more accurate, which justifies more compute.
The two scaling laws reinforce each other, offering investment directions to bend the overall scaling law curve beyond simply adding compute.
Post-Training: Knowledge Transfer at Scale
The value of the foundation model depends on how effectively its intelligence transfers to the hundreds of vertical models that serve ads in real time. GEM revolutionizes post training for recommendation systems through the structure representation with the deep historical memory from the central brain, achieving 2x of transfer effectiveness beyond knowledge distillation. Furthermore, async computation is introduced to a few domain-specific foundation models to transfer the knowledge to vertical models.
Structure Representation at Scale
Knowledge distillation is effective but limited in bandwidth: downstream models only receive a compressed view of GEM’s intelligence at each training process. To address the limitation, we introduce the precomputed structure representation, such as LoopFM, to understand and compress the central brain from the foundation model into a compact representation, and then structure it with deep historical memory. It enables the downstream models to learn the long context from our central brain. It consists of the following major components across the system:
Understand and Compress Intelligence: We compress the intelligence from GEM into the compact representations, which are summarized from the important layers, and used to comprehensively describe the event (or data) that is processed by the foundation model.
Structure with Deep HistoricalMemory: We structure its compact representation together with the representations that the foundation model previously generated for the same user into a sequential context window, capturing user intent dynamics across all surfaces and traffic through GEM’s memory.
Learn from Long Context Intelligence: Downstream models will learn the structure representation with long historical context through the specialized architecture during both inference and training time.
The representation generation process is precomputed and shared with the computation to generate soft labels of the foundation model for knowledge distillation without additional foundation model cost.
The structure representation paradigm.
Speculative Precomputation for Fresh Predictions
Solaris keeps knowledge transfer fresher, precomputing the user-ad representation from GEM just before vertical model inference needs it. Evaluating the large-scale model inside a live ad request is not affordable, Solaris moves it in time: It speculatively precomputes foundation model embeddings for the user-ad pairs a future request is likely to need, and delivers them just-in-time on the serving hot path. Downstream models gain access to near-real-time foundation model intelligence without being constrained by the latency. Borrowing the idea of speculative decoding from LLM serving, Solaris works through the following major components across the system:
Deliver Fresh Runtime Knowledge: It generates the user-ad embedding directly, giving vertical models real-time, point-to-point knowledge of how a specific user is likely to act on the exact ad candidate.
Speculate Ahead of the Request: As multi-stage ranking narrows a live request down to its top ad candidates, Solaris evaluates those user-ad pairs with the foundation model in asynchronous background jobs. The computation carries no latency budget with elastic capacity while it can capture rich knowledge.
Enrich Coverage Hierarchically: When an exact user-ad embedding is unavailable, the system degrades rather than drops. It substitutes an aggregate of the user’s own recent embeddings across the same ad groups, or borrows from behaviorally similar users.
Solaris speculative precomputation.
Large-Scale Cross-Domain Optimization: Optimize Across Surfaces and Funnels
We further trained GEM with the ads data at Meta scale, including all-surface data (e.g., Facebook and Instagram Feed and Reels/video) and deep funnel optimization (e.g., off-site conversion, mobile app install). GEM powers the first optimized model that jointly predicts both CTR across all the surfaces and conversion rate (CVR) across the major optimization goals. Previously, each surface and each prediction objective had its own system. This means learnings from engagement patterns across platforms can more directly be used to understand its conversion behavior (e.g., purchase) across ad surfaces. This positions GEM as the central model and compute engine for ads recommendation across Meta’s advertising surfaces.
Unlike LLMs with the static data, RecSys models need to deal with data dynamics and freshness as well as the diverse distribution across surfaces and traffic. To overcome the challenge, GEM built the first training recipe for the large-scale cross-surface, cross-domain unification through:
A Cost-Free Data Mixing Strategy: It introduced virtual data loading from different combinations of data pipelines without physically merging data together and incurring additional storage cost. It can flexibly adapt to the current ads ecosystem where the downstream models still train with the specific surface or traffic data. We also design a data mixture mechanism to control the mixture proportions during offline and online training close to the real datastream order received in real time, mitigating instability for domain switch and overmemorization for the recent domain data.
A Domain Expert Framework: A shared expert learns a unified representation across all domains, while domain-specific experts capture surface-specific patterns. Each domain expert benefits from both: the shared cross-domain knowledge and its own specialized knowledge. Experts are built on top of the Kunlun architecture framework.
Training a RecSys Model at LLM-Scale Efficiently
GEM now trains at LLM scale on several thousand of the latest-generation GPUs. Today’s data center GPUs and their software stacks are mostly optimized for LLM workloads, whereas recommendation workloads have a fundamentally different profile due to unique data characteristics and rich user & ads signal interaction patterns that make it extremely difficult to achieve high GPU compute utilization for training a foundational recommendation model of GEM’s size.
We measure training efficiency through E2E MFU, which decomposes into two factors: E2E MFU = Local MFU (compute efficiency) × Scaling Ratio (scaling efficiency). Local MFU (compute efficiency) measures how well a single GPU’s compute units are utilized — how close the workload runs to the hardware roofline. Scaling Ratio (scaling efficiency) measures how much single-GPU performance is retained when distributing across thousands of GPUs. This decomposition matters because it lets us treat compute efficiency and scaling efficiency as related but distinct optimization problems, each with its own dedicated set of techniques. Both must be addressed to maximize end-to-end MFU.
We tackled these challenges through complementary compute efficiency and scaling efficiency innovations:
Compute efficiency: Achieved through a customized recommendation kernel library — Jagged Flash Attention (JFA), GDPA, Block-Attention, etc. — and mixed ultra-low precision training (including MXFP8 attention and MLP) optimized for recommendation workloads, purpose-built to leverage the latest generation GPU architecture.
Scaling efficiency: Topology-aware 5D parallelism with Streaming Multiprocessor (SM)-free collectives — 2D FSDP + Expert Parallelism for dense parameters, combined with Fully Sharded 2D Model Parallelism for sparse parameters — co-designed with Meta’s multi-tiered network hierarchy to reduce communication overhead.
The result: We doubled GEM’s E2E training efficiency to 20-25% MFU over the past 12 months while scaling total training FLOPs by 4x. Training a foundation model at the intersection of LLMs and recommendation systems is a co-design problem, not a software problem or a hardware problem alone. This 2x efficiency gain came from carefully considering every layer of the stack for optimization — kernels, precision, parallelism, networking, and memory all had to move together.
Looking forward, we are excited to extend GEM to learn from all of Meta’s platform data, capturing behavior across organic and ads engagements spanning text, images, and video. We’re building toward LLM-scale long context, giving the model the ability to reason over longer spans of engagement context. This will unlock better ad relevance and help advertisers connect with the right audiences more efficiently.
We will continue to scale GEM on even larger compute clusters, opening new scaling opportunities. We are introducing AI-driven optimizations, such as ecosystem enhancement and architecture co-design, to accelerate future evolutions. These optimizations will iteratively refine model architecture in lockstep with hardware advancements, so that each new generation delivers more intelligence per dollar of compute. We will evolve the post-training paradigm with reasoning capability to transfer more of this intelligence to downstream models, further improving advertiser performance and user experience.
Acknowledgements
We would like to thank Laming Chen, Yasmine Badr, Shali Jiang, Hua Zheng, Boyang Liu, Qianru Li, Zhengyu Zhang, Xiaozhen Xia, Angie Huang, Xiaolong Liu, Dan Chanpuriya, Jason Rudy, Cathy Cui, Kenny Lov, Qiuling Suo, Richard Qiu, Wentao Duan, Habiya Beg, Shuo Chang, Wenlin Chen, Xiaorui Gan, John Bocharov, Santanu Kolay, Rocky Liu, Sandeep Pandey, Matt Steiner, Ernest Wang, Musharaf Sultan, Qian Zhao, Anuj Madan, Tak Yan, Viral Vimawala, Saket Gur, Chonglin Sun, GP Musumeci, Jiyan Yang, Jiayi Xu, Chen Liang, Jerry Peng, Zhaojin Wen, Zhichen Zeng, Qinjin Jia, Qinghai Zhou, Rich Zhu, Feipeng Zhao, Hanbin Zhang, Haowen Lin, Lisang Ding, Kai Wang, James Teng, Bingjie He, Donghyun Kim, Yan Deng, Jingyi Shen, Ivonne Xu, Wei Ling, Wen-Chi Yang, Ayush Bihani, Xin Liu, Zikun Liu, Ping Chen, Wankun Zhu, Xian Chen, Jazlyn Li, Hank Lo, Amit Anand Amlesahwaram, Larry Zhang, Hansey Chen, Song Zhou, Zhehui Zhou, Huaqing Xiong, Jie Zheng, Jack Hsueh, Nikhil Garg, Ritwik Tewari, Purbesh Sahoo, Shuby Mao, Fan Yang, Jae-Woo Choi, Qi Fan, Peng Zhong, Peter Lamar, Bopa Bovet, Seunghan Lee, Robert Tang, Lei Zhang, Xi Liu, Hongtao Yu, Lei Tian, Carmen Au, Jake Siso, Rustam Hashimov, Kevin Tang, Bor-Yiing Su, Jade Nie, Tianshu Peng, Subodh Iyengar, Min Si, Ruilin Chen, Max Leung, Rupert Wu, Mandeep Chadha, Angel Yang, Damian Reeves, Hairong Kuang, Ke Sang, Vibha Sinha, Yuzhen Huang, Enes Palaz, Brian Hansen, Liangbei Xu, Oana Platon, Raghav Boinepalli, Rikin Shah, Balaji Balasubramanian, Santosh Mohan, Hao Yan, Eric Falconer,Jacky Zhou, Yusuo Hu, Justin Yang, Pawel Kadluczka, Anamaya Sullerey, Han Xu, Vivienne Sung, Jiasheng Zhang, Serena Liu, Chenxiao Guan, Qiang Jin, Qin Huang, Sagar Chordia, Mingda Li, Li Yu, Ke Pan, May Wang, Sandor Abad, Sandeep Tiwari, Patrick Phelps, Paolo Massimi, Devashish Shankarand the entire team behind the development and productionization of the largest foundation model in Meta’s ads recommendation system.
Some numbers are hard to picture until you sit with them for a moment. Last week we published the Prime Day 2026 metrics, and the one that stuck with me is 2.3 quadrillion: the daily requests Amazon ElastiCache peaked at during the event. Prime Day ran back in June, so this post always lands as a retrospective, and that gap is part of what makes it worth reading. By the time the numbers reach you, the only evidence that any of it happened is that nothing went wrong.
The rest of the week pulled in a different direction: smaller, cheaper, and more constrained. Claude Haiku 5.5 arrived on Amazon Bedrock at roughly 75 percent less than Haiku 4.5, Amazon Nova 2.5 Sonic made voice agents quicker on their feet, and Strands Box showed up to put real boundaries around what an agent is allowed to do. Now, let’s get into this week’s AWS news…
Headlines All the numbers: Amazon Prime Day 2026 powered by AWS is the latest entry in a tradition that goes back to 2016, and the scale is still difficult to hold in your head. Over the four days of Prime Day, Amazon DynamoDB processed more than 59 trillion requests while peaking at 192 million requests per second, and kept single-digit millisecond responses throughout. AWS Lambda handled over 2.3 trillion invocations per day. Amazon EBS peaked above 24.8 trillion I/O operations, moving more than an exabyte of data daily. Amazon ECS launched an average of 158.3 million tasks per day on AWS Fargate, a 47.7 percent jump over last year, and AWS Graviton powered up to 49 percent of the Amazon EC2 compute that Amazon.com used.
The number I keep coming back to, though, isn’t a throughput record. The team ran more than 44,000 AWS Fault Injection Service experiments ahead of the event, more than six times what they ran in 2025. Those are deliberate failures injected on purpose, months in advance, so that the trillions of requests above turn into an ordinary shopping afternoon. If you’re preparing for your own peak moment, AWS Countdown Premium is built for exactly that kind of planning.
Last week’s launches
Here are some launches and updates from this past week that caught my attention:
Claude Haiku 5.5 is now available on AWS – You can now use the fastest model in the Claude 5.5 family on Amazon Bedrock and Claude Platform on AWS, at around 75 percent less than Claude Haiku 4.5 for most tasks. It’s the first Haiku with effort controls, so you can tune cost against intelligence per task instead of fixing one setting for a whole workload. It pairs naturally with Claude Opus 5.5: Opus plans and makes the judgment calls, and because Haiku is fast and cheap, you can run many Haiku subagents in parallel for routing, classification, and small code changes across many files.
Amazon Nova 2.5 Sonic for voice agents – You can now build real-time voice agents on a speech-to-speech Amazon Nova model with better reasoning, instruction following, and tool-calling accuracy, plus lower latency. That combination matters for multi-step work: a support agent can look up an order, check return eligibility, and start the return inside one conversation. It keeps expressive voices in seven languages, controllable turn-taking, and a 256K context window, and pairs with Strands Bidi Agents, now generally available, to get a production voice agent going in a few lines of code.
Amazon GuardDuty RDS Protection now detects data exfiltration and destruction – Amazon GuardDuty now looks past login anomalies to the queries themselves on Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL. RDS Protection for data activity builds behavioral baselines and uses ML-based anomaly detection plus threat intelligence to flag unusual data access, with no agents, extra infrastructure, or database configuration changes. This closes a real gap: once an attacker has valid credentials from phishing or a misconfiguration, their queries can look indistinguishable from your application’s.
AWS Lambda supports OAuth for self-managed Apache Kafka event sources – You can now authenticate Lambda Kafka consumers through your enterprise identity provider, such as Amazon Cognito or Okta. Event source mappings previously supported only SASL/PLAIN, SASL/SCRAM, and mTLS, which left teams in regulated industries unable to use Kafka ESM at all. Now you get the automatic scaling, batching, error handling, and event filtering of Kafka ESM with the same identity governance you apply everywhere else. It works with self-hosted clusters and managed offerings including Confluent Cloud, Aiven, and Redpanda.
For a full list of AWS announcements, be sure to keep an eye on the What’s New with AWS page.
Other AWS news
Here are some additional posts and resources that you might find interesting:
Introducing Strands Box: AI agent sandboxes powered by Dogwood – As more of us let agents run shell commands and call APIs without approving every step, isolation alone stops being enough. Strands Box is an open source sandbox (Apache 2.0, developer preview) that combines OS-level containment with fine-grained policies written in Dogwood, so permissions can depend on what the agent has already done. You can say “let the agent post to the incident channel, but no more than three times every 10 minutes” and have that enforced from outside the agent’s process. It also keeps real credentials out of the agent’s environment by attaching them at an egress gateway.
AWS Continuum sets a new standard in autonomous code security – Related to that theme, AWS Continuum for Penetration Testing now integrates into your CI/CD pipeline in public preview, turning penetration testing into a deploy-time event instead of something that happens off to the side. Developers get findings with severity, affected endpoints, and remediation guidance right in the pipeline output, and the pipeline re-tests to verify fixes.
Upcoming AWS events
Check your calendar and sign up for upcoming AWS events:
AWS re:Invent – re:Invent returns to Las Vegas from November 30 to December 4, and reserved seating is now open. The session catalog is live, so register and claim your spots in chalk talks, workshops, and builders’ sessions before they fill up.
AWS Community Days – Community-led conferences planned and delivered by community leaders, and this is a busy stretch. Upcoming stops include San Francisco (October 13), Miami (October 14), Brisbane (October 16), Cape Town (October 16), Malta (October 16), and Mumbai (October 17). Here in Brazil, the community calendar has more editions coming before the end of the year.
Join the AWS Builder Center to connect with builders, share solutions, and access content that supports your development. Browse here for upcoming AWS-led in-person and virtual events and developer-focused events.
That’s all for this week. Check back next Monday for another Weekly Roundup!
– Daniel Abib
This post is part of our Weekly Roundup series. Check back each week for a quick roundup of interesting news and announcements from AWS!
A sales director opens Copilot and asks: “Which of our opportunities need attention this week?” A few seconds later she has a clear list. There are three deals with stalled conversations, two with open support cases and one where the customer’s champion just changed jobs. That’s useful and fast, and nothing in the business has changed. She simply knows more than she did a minute ago.
Then she types a second request:
“Move the deals that had a positive meeting last week to the next sales stage, update the close dates and let the account teams know.”
This request is different. Now the AI isn’t helping her know something. It is about to change something: the pipeline forecast the CFO reads on Friday, the records five account managers rely on and the messages colleagues will act on.
It uses the same data and the same person, but it carries very different consequences.
That second kind of request is exactly where Microsoft is taking Copilot and agents right now. I think it is one of the most important shifts for business and IT leaders to understand this year.
The question is changing
For the past few years, nearly every enterprise AI conversation I have been part of has circled around one question:
What is AI allowed to see?
We worked on oversharing, permissions, sensitivity labels and which SharePoint sites Copilot can reason over. That work still matters.
Now a second question is arriving, and it is a bigger one:
What is AI allowed to change?
Right behind it comes a third:
When can an agent make that change on its own, and when does a human need to say yes?
If your organization has a good answer to the first question and no answer to the other two, you are about to have a gap.
Work IQ is becoming an enterprise action layer
Work IQ is the intelligence behind Copilot and Microsoft’s agents. It gives AI the context of your organization: your emails, meetings, chats and files, who works with whom, and increasingly your business data from Dynamics 365 and Power Apps. For a long time, I saw it mainly as the layer that helps AI understand work, by finding the right information and grounding the answer in your reality.
That picture is now changing. Microsoft itself describes Work IQ as something that lets agents reason over work and take action, and the product is following those words. Agents are getting the ability to edit Office documents, save files into Microsoft 365, create and update business records, and act in connected third-party services. All of that happens within the user’s own permissions, behind admin controls and, in many cases, with the user confirming before anything is saved.
When I put these pieces side by side, I see Work IQ becoming kind of an enterprise action layer: a common, governed place where AI goes not just to understand your business, but to change it.
Think about it as four steps:
Understand → Reason → Act → Change the state of the business
The last step is the one that matters. When AI gives a wrong answer, you notice, frown and ask again. When AI makes a wrong change, the change stays. Other people see it, reports pick it up, and tomorrow’s Copilot answers are built on it.
A wrong answer is a bad moment. A wrong change is a new reality.
The reason I’m writing about this now, rather than feature by feature, is that the individual announcements are easy to underestimate. On its own, each one looks like a handy convenience. But they are arriving in the same quarter, through the same layer and with the same kinds of controls. That isn’t a list of features. It’s a platform direction, and platform directions are what organizations need to plan for, not individual settings.
What this means
“What can AI change?” belongs next to “what can AI see?” Most AI strategies and governance models today are built around access to information. They now need an equal answer for actions: which changes AI may make, where and how much. This isn’t only an IT decision. Business owners of processes and data have to be part of it.
Know what can now be changed through AI, and what is switched on. Services that used to be “read-only for AI” are getting write capabilities, some switched off by default and some on. Someone needs to know which ones, and who decides when to enable them.
Be able to tell “the person did it” from “an agent did it”. When something important changes, you will want to know who asked for it, which agent did it and whether a human approved it. Plan for that before the first incident, not after.
This is where the real value is. Agents that do the follow-up, update the record and file the document save far more time than agents that only answer questions. This shift isn’t something to block. It’s something to steer.
Start with one concrete process and agree its risk level up front. Pick a real process, decide where the agent can act freely and where a human says yes, and pilot it. Clear agreements early are what get you to safe, real results faster.
The rest of this post looks at what is actually shipping, why reading and changing need different rules, and how to decide where humans stay in the loop.
Four signals pointing the same way
Here is what is happening:
Agents will create and edit Office documents using organizational context. A proposal or project plan can be updated by an agent, not just drafted for you. (Planned: preview November 2026, general availability January 2027.)
Agents will save files into Microsoft 365, for example into SharePoint libraries. What AI generates stops being a chat answer and becomes company information that others find and reuse. (Planned for October 2026.)
Agents can work with business records in Power Apps and Dynamics 365: listing, reading, creating, updating and deleting customer cases, opportunities or any record in a model-driven app, using plain language. (In public preview now, with general availability planned for November 2026.)
Copilot can make changes in non-Microsoft services through connectors, for example creating or updating items in third-party systems, with the user confirming each change by default. (Rolling out during October 2026.)
These are documents, files, business records and other companies’ systems, all moving in the same direction from “tell me” to “do it for me”.
A business system you can talk to
The business-records change is, in my opinion, the clearest example of the whole shift.
Microsoft’s Business Applications in Work IQ brings data and processes from Dynamics 365 Sales, Dynamics 365 Customer Service and Power Apps into Copilot and agents. A user can say “show me open cases for Contoso”. They can also say “create a follow-up case with these details” or “update the status of this record”, without opening the app.
What I like here is that Microsoft has built in some sensible guardrails:
The person reviews before anything is saved. For creating and updating records, Copilot shows the proposed values, and the user can correct them before confirming. Deleting a record also needs explicit confirmation, and the record is shown first so you can check it’s the right one.
Existing rules still apply. The app’s required fields, read-only fields and business rules are enforced, and people can only change what they already have rights to change.
When the rules can’t be enforced, the AI doesn’t write. If a form depends on custom script logic that can’t be run in this conversational mode, the change has to be made in the app itself.
Admins and app owners decide what takes part. Turning this on is a deliberate choice per environment, app and AI experience, and doing so doesn’t give anyone extra data rights.
For service owners, that last point is important. Your business logic is part of your safety model, so it pays to know where it lives.
Same data, very different decision
Here is a simple illustration you can use with your own teams. Imagine your organization keeps its supplier contracts in a business app: supplier, category, contract value, renewal date and owner.
Asking:“Which supplier contracts are up for renewal this quarter?” The agent reads the records and summarizes them. If it gets something wrong, you ask again.
Changing:“Add this new supplier contract, put it in the right category, set the renewal date and update the existing entry if we already have this supplier.” Now the agent decides whether the supplier is a duplicate, picks a category and writes a renewal date that procurement and finance will plan around.
The organizational data is the same in both cases, but the governance implications are very different.
The action doesn’t stop at company borders
This is where it gets really interesting for business innovators.
Microsoft’s Sales Development Agent helps sellers research prospects, run outreach and qualify leads, and hands qualified opportunities over to a human seller. It can now connect to Salesforce. There it can work with leads, log sales activities and record changes such as qualifying or disqualifying a lead.
A note on status: the integration itself is listed as rolling out, but the Sales Development Agent is still in public preview, and early-access enablement is required until mid-November 2026. Check your own tenant before planning around it.
Let’s be precise. This doesn’t mean Microsoft’s AI can suddenly change every application you own. It is one agent, connected to one CRM, in a specific supported way.
The direction is clear, though. A single piece of work can span Teams, Outlook, Dynamics 365 and Salesforce in one go. The agent works across the whole process, not inside one application.
Does that make your business applications less important? Not at all. Your systems of record still hold the data, the rules and the audit trail. But if a process can be carried out across four systems by one agent, governing each application separately is no longer enough. Your governance has to follow the process, not just the app.
Permission to know is not permission to change
Reading information and changing it carry very different kinds of risk. Some everyday examples:
Asking
Changing
“Which opportunities need attention?”
“Move these opportunities to the next stage.”
“What meetings do I have tomorrow?”
“Reschedule my customer meeting and notify everyone.”
“Summarize the project status.”
“Update the project plan with these new dates.”
“Which leads haven’t replied?”
“Disqualify the leads that haven’t replied.”
The left column can reveal information. The right column changes commitments, relationships and records, often before anyone notices.
Our access rights were designed for people, and people are slow. A sales manager who can edit 10,000 records has never been a problem, because she edits a few at a time and notices when something looks odd.
An agent acting for her isn’t slow. The access right is technically identical, but the business question is completely different:
Should an AI agent acting for this person be allowed to change 10,000 records?
The exact number doesn’t matter. What matters is the principle:
Permission to know is not permission to change.
Access rights tell us what is possible. They don’t tell us what is wise to delegate. Enterprise AI governance has to grow from managing what AI can know to managing both what AI can know and what AI can do.
Three questions for every agent action
1. Is it allowed? Does the person, or the agent’s identity, have the right to make this change at all?
2. Is it allowed for an agent? Even if the person could do it, has the organization agreed that an AI may do it here?
3. Does a human need to approve this specific action? Should someone see and confirm this particular change before it happens?
Here’s where we are today:
Question 1 is well covered. Work IQ acts within the user’s existing rights and can’t grant more access than the person already has. Business apps and connected third-party services apply their own security as well.
Question 2 is there but still coarse. For the most flexible agent connection to Microsoft 365, the ability to change things is switched off by default, and an admin has to turn it on deliberately. It is a good default.
Question 3 is clearly visible in interactive experiences. Record changes need confirmation. Changes in third-party services need confirmation by default, and Copilot shows what will be sent before it runs. Copilot’s longer-running tasks ask for approval before sensitive actions.
Human in the loop – not in every loop
Human-in-the-loop should not mean human-in-every-loop.
If every small action needs a confirmation click, people stop reading and click “Yes” (we all do it with cookie banners!). The value of the agent disappears, and the control becomes theater.
Unlimited autonomy isn’t an option either. One wrong update, repeated a few thousand times, isn’t a typo. It’s an incident.
So the real leadership decision is where autonomy ends. Here is a possible risk model:
Risk
Example
How much autonomy?
Low
Creating a personal draft or working notes
Agent acts on its own
Low–medium
Updating a project document that has version history
Agent acts on its own; changes stay visible and can be undone
Medium–high
Changing a deal stage or a customer record, or saving to a shared team library
Human confirms, or a clear policy allows it
High
Contacting customers, changing commercially important data, anything that materially affects another person
Stronger approval – a named approver, or limited to specific agents
Very high
Deleting important records, bulk changes
Explicit confirmation, very limited autonomy, or not allowed at all
Questions to take to your next leadership meeting
Which business actions are we willing to delegate to AI agents?
Which systems should stay read-only for agents, at least for now?
Which actions can agents take on their own, because they are low-impact and reversible?
Which actions need a human to confirm, and are we comfortable with “Always allow”?
Which actions should agents never take?
Can we always tell who or what made an important change?
Can we undo the changes that matter, and do we know which ones can’t be undone?
Were our access rights designed for humans, and are they still right when an agent acts at machine speed?
Do our data protection rules cover what agents create, not only what they read?
Which one process will we pilot first, and how will we measure it?
From understanding work to changing it
Work IQ started as the layer that helped AI understand work: who works with whom, which content matters, and what your business data means.
Now it is becoming part of how AI changes work: documents updated, files saved, records created and closed, sometimes in systems that aren’t Microsoft’s at all.
That’s the shift to prepare for. The good news is that the building blocks are arriving, and the defaults are sensible. The hard part is ours: deciding, process by process, where AI can act freely, where a human says yes, and where the answer is simply “not yet”.
The next generation of AI governance won’t only decide what agents can know. It will decide what they can do, what they can change, and where people stay in control.
Permission to know isn’t permission to change. Let’s design for both.
Where would you draw the line between autonomy and approval in your organization?
Reference – Roadmap and Message Center details
For readers who want to dig deeper. Status as of October 13, 2026. Roadmap dates are Microsoft’s estimates and can change. The Microsoft 365 Roadmap is now called the AI at Work Roadmap (MC1461528).
Capability
Roadmap
Message Center
Status
Key details
Agents create and edit Office documents
570871
– (none published yet)
In development: preview Nov 2026, GA Jan 2027
Uses organizational context. Admin controls not yet published.
Agents upload content to Microsoft 365
570850
– (none published yet)
In development: preview and GA Oct 2026
“Supported destinations” not yet listed.
Business records in Power Apps model-driven apps
571888
MC1479277
Public preview; GA planned Nov 2026
Confirmation for create, update and delete. Business rules enforced. Admin controls in the Power Platform admin center and the Microsoft 365 admin center.
Sales Development Agent with Salesforce
574105
MC1492151
Integration rolling out; the agent itself is in public preview (Frontier enablement until Nov 16, 2026)
Uses Microsoft’s Salesforce MCP server. Agent has its own mailbox. Billed in Copilot Credits from Nov 16.
Third-party connectors can create, update and delete
–
MC1476316
Rolling out Oct 2026
Confirmation by default with Allow once / Always allow. Admins can review and disable write tools. Researcher stays read-only.
Work IQ agent connection (MCP) policy
–
– (Microsoft Learn)
Available
Changes blocked by default. Policy is tenant-wide in the initial release.
Copilot long-running tasks
–
MC1479277
Frontier
“Sensitive actions require user approval.”
Data loss prevention for Copilot Cowork
–
MC1477182
GA mid–late Oct 2026
Existing Copilot DLP policies apply automatically. Prompt DLP covers prompt text only, not uploaded files.
Default library label applied to existing files
559105 (Worldwide), 575283 (GCC/GCC High/DoD)
MC1477181
Worldwide GA Oct 2026; government clouds GA planned Nov 2026
Opt-in. One policy per tenant, up to 10 sites.
Browser use in Copilot Cowork
–
MC1474461
GA Sep 2026
Off by default. Can be scoped to groups.
Agent identities for Copilot Studio agents
–
MC1478488
Migration ongoing
Entra audit logging and Conditional Access for agents.
Log in
