Ed Burns is a Principal Software Engineer focused on bringing idiomatic Java experiences to Microsoft and GitHub technologies. He has worked with Java since 1997 across client, server, cloud, and artificial intelligence applications.
## Professional Focus
- Works at Microsoft and GitHub.
- Concentrates on making Java development feel natural and idiomatic within their technologies.
## Experience
- Has used Java since 1997.
- His experience spans:
- Client-side development
- Server-side systems
- Cloud technologies
- Artificial intelligence
No specific blog topic or technical argument is included in the provided content.
The post introduces “Agents Week” by reframing the question from what an Agent Cloud should be to what agents themselves need. Unlike today’s human-oriented cloud and web, an Agent Cloud must provide agent-native primitives while also translating between existing human-designed systems and an emerging agent-shaped web. The week will explore how infrastructure, development, security, organizational access, and web interactions should evolve for agents.
## Why the Existing Cloud Falls Short
- Today’s cloud and web assume a human is monitoring and interacting with them.
- Interfaces are built around attention, visual dashboards, clicking, reading, and human decision-making.
- Agents have different priorities: speed, structure, reliable access, and the ability to operate continuously without fatigue or distraction.
## Two Responsibilities of an Agent Cloud
- Build an agent-native foundation with primitives designed for agents from the beginning rather than adapted from human tools.
- Serve as a translation layer between:
- The existing human-shaped web and infrastructure.
- The agent-shaped systems being developed for the future.
## Topics for Agents Week
The series will examine:
- Storage, compute, and execution primitives required by agents.
- An agentic development lifecycle, or “ADLC,” that reduces or removes humans from routine development loops.
- Secure ways for employees and agents to access organizational systems of record and perform meaningful work.
- The evolution of the agentic web, including discovery, access, and payments.
- How humans and agents will work together during the transition to agent-oriented systems.
## Invitation to Ask Agents Directly
The post encourages readers to ask their own agents what they need from an Agent Cloud instead of relying only on human assumptions. Suggested areas include cloud infrastructure, development processes, secure enterprise access, and web interactions, with readers invited to share their agents’ responses.
In practical terms, designing an Agent Cloud requires starting with agents’ operational needs while supporting compatibility with the human-oriented systems that still dominate today.
Retired smartphones can become low-carbon cloud infrastructure by reusing their still-capable motherboards instead of manufacturing new servers. Researchers at UC San Diego, with Google’s support, are developing clusters of stripped-down Pixel phones managed by Kubernetes. Their planned 2,000-phone datacenter aims to provide affordable computing for education and research while reducing hardware-related emissions.
## The Carbon Case for Reusing Smartphones
- Computing emissions come from:
- **Operational carbon**, produced by electricity consumed during use.
- **Embodied carbon**, produced during hardware manufacturing and raw-material extraction.
- Reusing phones primarily addresses embodied carbon by extending the life of components that remain functional.
- Since people typically replace phones every four years, many retired devices still contain capable processors, accelerators, memory, and storage.
## Smartphone Performance and Limitations
- Modern smartphone performance cores can match or exceed the per-core performance of some data-center servers.
- Smartphones have significant limitations compared with servers:
- Fewer, heterogeneous processor cores.
- Only 8–12 GB of memory.
- Less capacity for large, multithreaded workloads.
- The platform therefore targets workloads that fit on a phone or can be distributed across multiple devices.
## Converting Phones into Datacenter Hardware
- Unmodified phones are unsuitable for datacenters because they include unnecessary and potentially hazardous components such as:
- Displays and cameras.
- Batteries not designed for sustained datacenter operation.
- Consumer-oriented chassis and peripherals.
- Researchers remove everything except the motherboard, which accounts for roughly 50% of a phone’s embodied carbon.
- Android’s mobile userspace is replaced with a general-purpose Linux distribution.
- This removes mobile-specific restrictions such as Android’s “low memory killer” and enables broader server-style programmability.
- Kubernetes manages containerized applications across clusters of approximately 25–50 phones, equivalent to roughly one conventional server.
## Applications for Education and Research
- Many university workloads—including Jupyter notebooks, grading systems, and research applications—require modest resources that a single smartphone can provide.
- Early tests showed that a 20-phone cluster could handle peak grading demand for a class of more than 75 students while achieving latency below a typical AWS backend.
- The planned 2,000-phone cluster could support around 100 comparable classes simultaneously.
- The deployment would provide approximately 50 server-equivalents at substantially lower cost.
## Testing Computing at Scale
- The project will evaluate whether consumer smartphone hardware can operate reliably under sustained datacenter workloads.
- It will also serve as a large-scale testbed for distributed smartphone computing.
- The system is expected to launch at UC San Diego in fall 2026.
Repurposing retired phones offers a practical way to reduce demand for newly manufactured computing hardware, especially for lightweight academic and cloud workloads. The approach is most promising when applications can tolerate distributed resources and the reliability challenges of consumer-grade components.
Face recognition has evolved from manually recorded facial measurements to deep-learning systems capable of identifying people with near-perfect accuracy. The technology’s progression depended on automated feature extraction, robust local descriptors, neural networks, and increasingly large datasets. Face payment represents its next major application, combining convenience with layered security designed to address biometric privacy risks.
## From Manual Measurements to Automated Recognition
- In the 1960s, Woodrow Wilson Bledsoe pioneered face recognition through a classified government project.
- Researchers manually recorded coordinates for features such as eye spacing, nose-to-mouth distance, and ear positions.
- Computers performed calculations, but humans still identified the facial landmarks.
- In 1973, Takeo Kanade developed a system that automatically detected the eyes, nose, and mouth.
- His work demonstrated that computers could extract meaningful facial information without manually supplied coordinates.
## Eigenfaces and Statistical Representation
- In 1991, Matthew Turk and Alex Pentland introduced Eigenfaces using Principal Components Analysis (PCA).
- The system created an average face and represented individual faces by how they differed from that average.
- These differences formed “Eigenfaces,” mathematical components that worked like an alphabet for describing faces.
- Recognition became a matter of comparing the combination weights assigned to two facial images.
## Coping with Lighting and Real-World Conditions
- Early systems struggled when the same face appeared under different lighting, angles, or shadows.
- Researchers shifted from analyzing the entire face to examining local regions and textures.
- Local Binary Patterns (LBP) compared each pixel with its neighbors, making facial descriptions less dependent on absolute brightness.
- Hand-crafted features were combined with classifiers such as:
- **SVM**, which finds separating boundaries between identities.
- **AdaBoost**, which combines weak classifiers into a stronger recognition system.
- These methods improved robustness even though they could not learn features automatically like modern deep-learning models.
## Deep Learning Surpasses Human-Level Benchmarks
- Facebook’s 2014 DeepFace system used deep neural networks trained on approximately four million face images.
- It achieved 97.35% accuracy on the LFW benchmark, approaching the reported human score of 97.53%.
- Google FaceNet later introduced Triplet Loss and reached 99.63% on LFW.
- SphereFace, CosFace, and ArcFace continued improving discriminative facial representations.
- The field shifted from proving that recognition was possible to optimizing accuracy and reliability.
## The Role of Large-Scale Datasets
- **FERET:** Established an early standardized benchmark with 1,199 people and 14,126 grayscale images.
- **LFW:** Contained 13,233 images of 5,749 people collected from natural, uncontrolled environments.
- **VGGFace:** Provided 2.7 million images of 2,600 people, reinforcing the relationship between data scale and deep-learning performance.
- **MS-Celeb-1M:** Pursued celebrity recognition at massive scale but was later withdrawn over privacy concerns.
- **WebFace260M:** Started with 260 million images and refined them into roughly 42 million images covering two million people.
- These datasets improved recognition while also highlighting the tension between technical progress, data quality, and privacy.
## Face Recognition as a Payment Method
- Face recognition had already reached smartphones, airports, and office access systems, but payments required stricter standards.
- Unlike device unlocking, payment errors can directly cause financial loss.
- Toss FacePay launched in South Korea in September 2025, aiming to combine strong security with a frictionless experience.
- Face payment offers:
- Availability without carrying a wallet or charged phone.
- Hands-free checkout.
- Faster payment without searching for cards or opening an app.
## How FacePay Works
- A terminal camera identifies the customer among registered users.
- The system must also reject unregistered users and apply additional authentication in ambiguous cases, such as similar-looking individuals or twins.
- Once identified, the system connects the customer to a registered credit card, debit card, or another selected payment method.
- Face payment adds customer identification and payment-method lookup to the conventional POS, VAN, and card-issuer approval flow.
## Edge and Cloud Processing
- **Edge processing** offers low latency and better privacy because images need not leave the terminal.
- Its limitations include restricted hardware, smaller models, lower potential accuracy, and difficult device-by-device updates.
- **Cloud processing** enables stronger models, centralized logging, and simpler model updates.
- It introduces transmission delays and increases the importance of network and server security.
- FacePay combines both approaches: the terminal performs initial processing, while the server handles facial-feature extraction, recognition, and payment operations.
## Layered Biometric Security
- Communications between terminals and servers are protected with TLS, while images receive additional AES-256 encryption.
- Matrix Projection creates cancellable biometric vectors: changing the key produces a different representation of the same face.
- If a biometric vector were compromised, it could theoretically be reissued with a new key, similar to changing a password.
- The stored biometric representation is designed not to correspond one-to-one with the original face image or allow easy reconstruction.
- Access to biometric data is restricted, logged, and limited to operational needs.
- FacePay also underwent review by South Korea’s Personal Information Protection Commission and offers full compensation for fraudulent payments through its protection program.
The development of face payment reflects six decades of progress in computer vision, machine learning, data infrastructure, and security engineering. Its practical success depends not only on recognition accuracy, but also on cancellable biometric protection, strict access controls, privacy oversight, and effective defenses against spoofing.
Cloudflare announced plans to eliminate more than 1,100 jobs as it restructures for an “agentic AI era.” The company says the decision reflects a fundamental redesign of internal processes, teams, and roles—not individual performance or a conventional cost-cutting exercise. Leaders argue that acting decisively now will reduce prolonged uncertainty and create a faster, more innovative organization.
## Restructuring Around Agentic AI
- Cloudflare’s internal AI usage has increased by more than 600% in three months.
- Employees across engineering, HR, finance, marketing, and other departments run thousands of AI-agent sessions daily.
- Because Cloudflare uses AI extensively itself, leadership says the company must redesign how work is organized to capture its benefits.
- The restructuring covers internal processes, teams, and roles across the company.
## A Company-Wide Workforce Reduction
- More than 1,100 employees globally will leave Cloudflare.
- The company emphasizes that departures are not judgments about employees’ talent or performance.
- Founders Matthew Prince and Michelle Zatlyn are communicating the decision directly rather than routing notices through managers.
- Every employee is receiving an email explaining how the changes affect them.
## Severance and Treatment of Departing Employees
- Departing employees will receive the equivalent of their full base salary through the end of 2026.
- U.S. healthcare support will continue through the end of 2026.
- Equity will continue vesting through August 15.
- Employees who had not reached their one-year vesting cliffs will receive prorated vesting through August.
- Cloudflare frames these benefits as an effort to treat departing employees with empathy and exceed typical industry standards.
## Why Cloudflare Chose Decisive Action
- Leadership argues that smaller, repeated layoffs or a prolonged reorganization would create continuing emotional uncertainty.
- Completing the changes at once is intended to provide clarity to departing employees and stability for those who remain.
- Cloudflare believes its original cloud-native structure helped it surpass older companies with slower systems and processes.
- As the company has grown, it says it must avoid relying on organizational structures that worked in the past.
## Looking Ahead
- Cloudflare expects the reshaped organization to operate more quickly and innovate more effectively.
- The founders planned to discuss the announcement during the company’s earnings call and an all-hands meeting.
- They presented the restructuring as necessary to continue advancing Cloudflare’s mission of building a better Internet.
The practical conclusion is that Cloudflare is making a large, one-time organizational reset to align its workforce with AI-driven operations, while offering unusually extensive severance intended to reduce the disruption for affected employees.
Atlassian plans to use customer metadata and in-app content from Jira, Confluence, and other cloud products to train AI services beginning August 17, 2026. Collection will be enabled by default, with mandatory metadata collection for Free, Standard, and Premium customers; only Enterprise customers can opt out. The post argues this weakens data governance, particularly for regulated organizations, while presenting GitLab’s no-collection, no-training approach as a stronger privacy model.
## What Atlassian’s Policy Change Covers
- Atlassian will collect:
- Metadata such as story points, sprint dates, SLA values, and signals from Teamwork Graph and connected apps.
- In-app content including Confluence pages, Jira issue titles, descriptions, and comments.
- Atlassian says data will be de-identified and aggregated before training.
- Data may be retained for up to seven years.
- After opting out, in-app data is reportedly removed within 30 days and models retrained within 90 days.
- Customers using customer-managed encryption keys, Government Cloud, Isolated Cloud, or HIPAA-related configurations are excluded.
- The change reverses Atlassian’s previous position that customer data would not be used to train or improve AI services.
## Problems with Opt-Out-by-Default Governance
- Customers must notice the policy change, assess its legal and security impact, and act within the available timeframe.
- Free, Standard, and Premium customers cannot disable metadata collection.
- Enterprise is the only opt-out route, requiring at least 801 users and custom pricing.
- “De-identified” metadata can still reveal team performance, project structure, delivery cadence, and competitive operational intelligence.
- The policy turns data protection into a purchasing decision rather than a default customer right.
## Why Atlassian Customers Face Greater Exposure
- Jira and Confluence often contain:
- Project plans and sprint data
- Security tickets and incident postmortems
- Internal documentation
- Bug, release, and portfolio management information
- Organizations using Bitbucket and Bamboo may also expose source-code metadata and CI/CD configuration signals.
- Teamwork Graph connectors can extend the data scope to tools such as Slack, Figma, Google Drive, Salesforce, and ServiceNow.
- Customers migrating from Data Center or Server editions to Atlassian Cloud must now evaluate not only cloud migration, but also the possibility of default AI training.
## Compliance and Regulatory Implications
- Financial institutions may need to reassess vendor controls under frameworks such as SR 11-7 and DORA.
- Public-sector organizations must consider NIST 800-53 and FISMA requirements around sensitive-data flows.
- Healthcare organizations need to evaluate potential HIPAA implications.
- EU AI Act obligations may create additional concerns because European expectations often favor opt-in consent.
- Existing vendor-risk, model-risk, and data-processing assessments should be updated before August 17, 2026.
## GitLab’s Contrasting Approach
- GitLab is presented as opposing opt-out-by-default collection.
- Its stated principles are:
- No collection of customer data
- No AI training on customer data
- The same privacy commitment regardless of subscription tier
- This approach avoids making stronger data protection dependent on Enterprise pricing and simplifies compliance reviews.
Organizations should inventory the data and integrations connected to Atlassian, review contractual and regulatory obligations, and determine whether they can opt out or need to reconsider their platform strategy.
GitLab is expanding its integration with Anthropic Claude to provide enterprise teams with more capable AI inside a governed software development platform. Claude supports GitLab Duo Agent Platform features such as code generation, review, agentic chat, and vulnerability resolution. The central argument is that organizations should not have to trade advanced AI capabilities for security, compliance, and auditability.
## Governed AI across the SDLC
- Claude-generated changes follow GitLab’s existing merge request process, approval rules, security scans, and audit trails.
- AI agents do not bypass controls; their actions remain attributable, reviewable, and subject to policy enforcement.
- This governance becomes increasingly important as agents autonomously plan, code, test, secure, and deploy software.
- GitLab positions built-in governance as a core architectural differentiator rather than an added feature.
## Flexible enterprise deployment
- Claude is available in GitLab through:
- Google Cloud Vertex AI
- Amazon Bedrock
- Organizations can use existing cloud contracts, governance frameworks, and data-residency arrangements.
- GitLab’s availability in the Claude Marketplace lets customers purchase GitLab Credits and apply them toward Anthropic spending commitments.
- These options simplify procurement and consolidate AI spending.
## Supporting an agentic development model
- GitLab is selecting model partners based on reasoning ability, reliability, and safety.
- The platform is designed to maintain visibility into what AI agents do, when they act, and how their changes are tracked.
- As agents take on more complex engineering tasks, GitLab argues that strong models must be paired with equally strong governance.
## Implications for customers
- Existing GitLab Duo users gain deeper Claude-powered assistance without changing their established governance processes.
- Organizations evaluating AI development platforms can access advanced models while retaining enterprise control.
- GitLab presents the integration as a way to accelerate development without compromising compliance or oversight.
The practical recommendation is to evaluate AI platforms not only by model capability, but also by how well they integrate governance, auditability, cloud deployment options, and existing enterprise workflows.
Netflix built its Media Production Suite (MPS) to automate repetitive media workflows, improve consistency, and give filmmakers more time for creative work. Rather than develop an image-processing engine internally, Netflix partnered with FilmLight and integrated its FilmLight API (FLAPI) into Netflix’s cloud infrastructure. This combination provides reliable, camera-aware processing at global scale while supporting open standards, auditability, and rapid turnaround.
## Why Netflix Built MPS
- Netflix productions use a wide range of cameras, formats, workflows, regions, and vendors.
- File-based workflows created recurring problems:
- Manual file wrangling reduced creative time.
- Media handling varied between productions.
- Human-driven processes were difficult to audit.
- Teams repeatedly rebuilt similar workflows.
- MPS aims to:
- Standardize media management and movement from production through post-production.
- Improve efficiency, consistency, and quality control.
- Reduce errors and non-creative administrative work.
## Choosing FilmLight’s Processing Engine
- Building a complete image-processing engine would require long-term collaboration with camera manufacturers and the broader industry.
- Netflix needed a system that could:
- Inspect, trim, and transcode camera-original files.
- Preserve trusted color science and metadata.
- Support many current and future camera formats.
- Run within Netflix’s scalable, observable encoding infrastructure.
- FilmLight’s Baselight and Daylight products already serve professional color grading, dailies, and transcoding workflows.
- FLAPI allowed Netflix to use this proven processing technology as a backend API instead of duplicating it internally.
## Camera Metadata Inspection
- Productions upload media with ASC Media Hash List (MHL) files to verify ingest completeness and integrity.
- During the subsequent inspection phase, FLAPI:
- Extracts metadata from original camera files.
- Maps critical fields into Netflix’s normalized schema.
- Makes the metadata searchable and reusable.
- The metadata supports:
- Matching footage by timing and reel name.
- Automated retrieval.
- Pipeline validation and troubleshooting.
- Investigating why footage appears a certain way after processing.
- Packaging FLAPI in Docker allows nearly identical deployments across Netflix’s cloud and global production compute environments.
## VFX Plates and Media Deliverables
- MPS generates VFX plates and other outputs while preserving framing, color management, and camera-specific decoding behavior.
- FLAPI is used to:
- Debayer original camera files with format-appropriate parameters.
- Crop and de-squeeze images according to ASC Framing Decision Lists.
- Apply ACES Metadata Files for repeatable color workflows.
- Produce deliverables in multiple formats.
- The workflows are automated, repeatable, and auditable.
- AMF files accompany OpenEXR outputs so recipients can identify which color transformations have already been applied.
- Because the backend uses FilmLight technology, Netflix specialists can validate automated decisions in Baselight before production begins.
## Cloud-Native Media Processing
- Traditional facilities often rely on powerful GPU systems and specialized high-performance storage.
- Netflix instead designed its processing around the Cosmos compute and storage platform.
- Cloud-compatible tools must:
- Run as short-lived serverless functions in Linux Docker containers.
- Operate effectively on CPU-only instances.
- Support headless execution through Java, Python, or command-line interfaces.
- Remain stateless so failed workers can be terminated and relaunched.
- This model favors parallel processing across many workers rather than maximizing the power of one machine.
- It improves cost and performance efficiency while maintaining production turnaround targets.
- FLAPI’s API-driven, container-friendly, and low-state architecture made it straightforward for Netflix to integrate and operate reliably.
Netflix’s approach demonstrates the value of combining established industry expertise with cloud-scale orchestration. By using FLAPI for specialized media processing and Cosmos for elastic execution, MPS can deliver consistent, traceable camera-file workflows without requiring Netflix to build and maintain every component itself.
AWS has announced its first 2026 Heroes cohort, recognizing Maurizio, Ray Goh, and Sheyla Leacock for combining technical expertise with community leadership. Their work spans cloud architecture, generative AI, machine learning, and cybersecurity, while emphasizing mentorship, education, and meaningful human connections. Together, they demonstrate how technology leaders can expand access to skills and strengthen communities globally.
## Maurizio – Pignola, Italy
- CTO and organizer of the AWS User Group Basilicata.
- Has spent more than a decade developing cloud communities and technology ecosystems in areas where they previously did not exist.
- Founded an international technology conference in a small mountain village, connecting global experts with local developers.
- Covers topics including cloud architecture, DevOps, and web scaling, alongside creative networking opportunities.
- Mentors children, university students, and professionals transitioning into cloud careers.
- Combines technical leadership with inclusive, cross-generational community building.
## Ray Goh – Singapore
- AI and machine learning community leader involved in AWS programs since 2018.
- Founded The Gen-C in 2024, offering public library workshops on generative AI, LLM fine-tuning, and AWS AI agents.
- Has spoken at major AWS events and contributed to the AWS Machine Learning Blog.
- Led DBS Bank’s AWS DeepRacer initiative, which trained more than 3,100 employees.
- Trained over 1,300 ASEAN students in LLM techniques in 2025.
- Supports skills-based programs teaching AI and machine learning to women, children, and young people.
## Sheyla Leacock – Panama City, Panama
- IT security professional, mentor, technical writer, and international speaker.
- Leads the AWS User Group in Panama and participates in AWS Community Days and regional meetups.
- Has spoken at AWS Summits, AWS re:Invent PeerTalk sessions, and more than 20 international conferences.
- Publishes educational content focused on AWS cloud computing and cybersecurity.
- Works with universities as a guest lecturer to help develop future technology and security professionals.
- Strengthens the cloud and cybersecurity ecosystem through education, knowledge sharing, and community leadership.
The new cohort highlights the broader impact of community-driven technology leadership. Readers can visit the AWS Heroes webpage to learn more about the program or connect with a Hero.
Google Research’s AIMS studies evaluated whether machine learning could support the UK’s mammography double-reading workflow. Across five NHS screening services, the AI system improved cancer detection sensitivity without reducing specificity, detected some cancers missed by human readers, and processed cases far faster. The studies also showed that safe deployment requires local calibration, monitoring for distribution shifts, and evaluation of how clinicians interact with AI results.
## NHS Screening Challenges
- The UK NHS uses two human readers for each mammogram, with arbitration when their assessments require review.
- A projected shortage of clinical radiologists—currently around 30% and expected to reach 40% by 2028—threatens the sustainability of this model.
- AI could help increase detection while reducing pressure on radiology services.
## Study 1: Standalone Performance
- The retrospective evaluation included mammograms from approximately 116,000 women screened across five NHS services.
- The services represented three different double-reading and arbitration workflows.
- AI thresholds were calibrated separately for each service to account for local populations and procedures.
- Performance was measured against the original first reader using a 39-month follow-up period, including interval and subsequent-round cancers.
- Researchers also assessed:
- Comparisons with second and consensus readers
- Lesion-level localization
- Performance across demographic groups
## Study 1: Results
- Cancer detection increased from 7.54 to 9.33 cases per 1,000 women.
- The AI system achieved significantly higher sensitivity than the original first reader without compromising specificity.
- It detected 25% of interval cancers missed by the original double-reading process.
- Performance was especially strong for invasive cancers and women attending their first screening.
- The study found no notable systematic disparities by age, ethnicity, breast density, or socioeconomic status.
## Prospective Technical Deployment
- The system was deployed non-interventionally at 12 sites across two London screening services.
- It processed 9,266 cases over roughly two months per service.
- Mammograms were pseudonymized and sent to a secure Google Cloud-based system.
- Median AI processing time was 17.7 minutes, compared with more than two days for the first human read.
- The deployment detected a distribution shift between historical training data and current clinical data.
- Researchers adjusted operating points during deployment to maintain safe and appropriate recall rates for local workflows.
## Study 2: AI in the Double-Reading Workflow
- The second study examined how human readers performed when using AI as part of arbitration, rather than evaluating AI in isolation.
- Twenty-two readers reviewed thousands of cases using real screening-service rules.
- Two workflows were compared:
- **Standard care:** decisions from the historical first and second human readers
- **AI-enabled care:** the historical first-reader decision paired with the AI decision
- This design aimed to assess the practical effects of replacing the second human read with an AI reader.
The findings support AI as a potential second reader in breast cancer screening, but broader prospective clinical validation is still needed. Successful adoption should include phased deployment, local calibration, continuous monitoring, and careful evaluation of human-AI decision-making.
GitLab 18.9 introduces critical updates designed to provide regulated enterprises with governed, agentic AI capabilities through self-hosted infrastructure and model flexibility. By combining the Duo Agent Platform with Bring Your Own Model (BYOM) support, organizations in sectors like finance and government can now automate complex DevSecOps workflows while maintaining total control over data residency. This release transforms GitLab into a high-security AI control plane that balances the need for advanced automation with the rigid sovereignty requirements of high-compliance environments.
## Self-Hosted Duo Agent Platform for Online Cloud Licenses
The Duo Agent Platform allows engineering teams to automate sequences of tasks, such as hardening CI/CD pipelines and triaging vulnerabilities, but was previously difficult to deploy for customers under strict online cloud licensing. This update makes the platform generally available for these environments, bridging the gap between cloud-based licensing and self-hosted security needs.
* **Usage-Based Billing:** The platform now utilizes GitLab Credits to provide transparent, per-request metering, which is essential for internal chargeback and regulatory reporting.
* **Infrastructure Control:** Enterprises can host models on their own internal infrastructure or within approved cloud environments, ensuring that inference traffic is routed according to internal security policies.
* **Deployment Readiness:** By removing the requirement to route data through external AI vendors, the platform is now a viable option for critical infrastructure and government agencies.
## Bring Your Own Model (BYOM) Integration
Recognizing that many enterprises have already invested in domain-tuned LLMs or air-gapped deployments, GitLab now allows customers to integrate their existing models directly into the Duo Agent Platform. This ensures that organizations are not locked into a specific vendor and can leverage models that have already passed internal risk assessments.
* **AI Gateway Connectivity:** Administrators can connect third-party or internal models via the GitLab AI Gateway, allowing these models to function as enterprise-ready options within the GitLab ecosystem.
* **Granular Model Mapping:** The system provides the ability to map specific models to individual Duo Agent Platform flows or features, giving admins fine-grained control over which agent uses which model.
* **Administrative Ownership:** While GitLab provides the orchestration layer, administrators retain full responsibility for model validation, performance tuning, and risk evaluation for the models they choose to bring.
For organizations operating in high-compliance sectors, these updates offer a path to consolidate fragmented AI tools into a single, governed platform. Engineering leaders should evaluate their current model investments and leverage the GitLab AI Gateway to unify their automation workflows under one secure DevSecOps umbrella.
AWS’s February 16, 2026 roundup highlights the launch of Amazon EC2 M8azn instances, which deliver substantial performance gains for compute-intensive workloads. It also covers expanded Amazon Bedrock model and networking support, improved observability in EKS Auto Mode, more efficient OpenSearch Serverless capacity management, and configurable RDS backup settings during snapshot restoration. The post concludes with upcoming AWS conferences, summits, and community events.
## Amazon EC2 M8azn Instances
- Powered by fifth-generation AMD EPYC processors with a maximum frequency of 5 GHz.
- Compared with M5zn instances, they provide:
- Up to 2× compute performance
- 4.3× higher memory bandwidth
- 10× larger L3 cache
- Up to 2× networking throughput
- Up to 3× EBS throughput
- Built on the AWS Nitro System with sixth-generation Nitro Cards.
- Available in nine sizes, from 2 to 96 vCPUs and up to 384 GiB of memory, including two bare-metal options.
- Designed for high-performance workloads such as financial analytics, high-frequency trading, CI/CD, gaming, simulations, and HPC.
## New Open-Weight Models in Amazon Bedrock
- Bedrock now supports six fully managed models:
- DeepSeek V3.2
- MiniMax M2.1
- GLM 4.7
- GLM 4.7 Flash
- Kimi K2.5
- Qwen3 Coder Next
- The models target reasoning, agentic intelligence, autonomous coding, and cost-efficient production deployments.
- They use Project Mantle and support OpenAI-compatible APIs.
- DeepSeek V3.2, MiniMax 2.1, and Qwen3 Coder Next are also available in Kiro.
## Amazon Bedrock PrivateLink Support
- AWS PrivateLink now supports the `bedrock-mantle` endpoint in addition to `bedrock-runtime`.
- Project Mantle provides serverless inference, quality-of-service controls, automated capacity management, and OpenAI API compatibility.
- PrivateLink support for OpenAI-compatible endpoints is available in 14 AWS Regions.
## EKS Auto Mode Logging
- EKS Auto Mode now supports CloudWatch Vended Logs for managed capabilities such as:
- Compute autoscaling
- Block storage
- Load balancing
- Pod networking
- Logs can be delivered to CloudWatch Logs, Amazon S3, or Amazon Data Firehose.
- The feature includes AWS authentication and authorization and is offered at a lower price than standard CloudWatch Logs.
## OpenSearch Serverless Collection Groups
- Collection Groups allow multiple collections to share OpenSearch Compute Units while retaining separate KMS keys and access controls.
- Shared capacity can reduce OCU costs.
- Administrators can define both minimum and maximum OCU limits, ensuring baseline capacity for latency-sensitive applications.
## RDS Snapshot Restore Improvements
- RDS now lets users view and configure backup retention periods and preferred backup windows before or during snapshot restoration.
- Restored databases no longer need post-restore backup configuration changes.
- The feature supports all major RDS engines, Aurora editions, commercial AWS Regions, and GovCloud at no additional cost.
## Upcoming AWS Events
- AWS Summits in Paris, London, and Bengaluru during April 2026.
- AWS AI and Data Conference in Ireland on March 12, focusing on Bedrock, SageMaker, QuickSight, agent deployment, data integration, and governance.
- AWS Community Days in Ahmedabad, Slovakia, and Pune.
Overall, the announcements emphasize faster specialized compute, broader managed AI model access, stronger private connectivity, and improved operational controls across AWS services.
Netflix argues that LLM post-training at production scale is as much an infrastructure challenge as a modeling challenge. Its internal framework abstracts distributed data processing, model sharding, GPU orchestration, checkpointing, and complex training workflows so developers can focus on experimentation. The result is a flexible system supporting SFT, DPO, reinforcement learning, and knowledge distillation across hundreds of GPUs.
## Why Post-Training Becomes an Engineering Problem
- Pre-training provides general language ability, but post-training adapts models to Netflix’s catalog, member histories, recommendation tasks, personalization, and search.
- Production-scale training introduces challenges involving:
- Large proprietary datasets
- Multi-node GPU coordination
- Distributed model state
- Workflows that combine training and inference
- Failure recovery and experiment tracking
- A simple Hugging Face fine-tuning script is insufficient for reliable, large-scale jobs.
## Preparing Data Correctly
- Chat templates serialize conversations but do not determine which tokens should contribute to the loss.
- Netflix applies explicit loss masking so training focuses on assistant responses rather than prompts or other non-target text.
- Variable-length examples can waste GPU memory through padding and create synchronization overhead across FSDP workers.
- Sequence packing combines multiple samples into fixed-length sequences.
- A document mask prevents attention across separately packed samples while improving GPU utilization.
## Loading and Optimizing Large Models
- Models that do not fit on one GPU require sharding strategies such as FSDP or tensor parallelism.
- Partial weights should be loaded directly onto the device mesh rather than materializing the entire checkpoint on a single device.
- Developers can choose full fine-tuning or LoRA and use:
- Activation checkpointing
- Compilation
- Appropriate precision settings
- Reinforcement learning requires compatible precision between rollout generation and policy training.
- Large vocabularies create memory pressure because logits have dimensions `[batch, seq_len, vocab]`.
- The framework reduces peak memory by removing ignored tokens before projection and computing logits and loss in sequence chunks.
## Distributed Training and Workflow Management
- The framework supports standard forward/backward training for SFT as well as workflows that interleave:
- Rollout generation
- Reward-model and reference-model inference
- Policy updates
- Ray actors orchestrate distributed jobs while keeping hardware concerns separate from modeling code.
- Experiment tracking covers both quality metrics, such as loss, and efficiency metrics, such as Model FLOPS Utilization (MFU).
- Standardized checkpointing allows jobs to resume after failures.
## Netflix’s Post-Training Framework
- The stack is built on:
- Mako for AWS GPU provisioning
- PyTorch, Ray, and vLLM
- Netflix’s framework library for reusable utilities and training recipes
- Jobs are generally defined through configuration files that select a recipe and provide task-specific components.
- Unlike narrower fine-tuning systems, the framework supports:
- Custom output heads
- Expanded vocabularies and semantic IDs
- Special tokens
- Transformer models trained on non-natural-language sequences
- This flexibility is important for Netflix-specific recommendation and personalization use cases.
## Four Core Abstractions
### Data
- Dataset abstractions cover SFT, reward modeling, and RL.
- Streaming supports datasets larger than local disk capacity.
- Asynchronous sequence packing overlaps CPU preprocessing with GPU execution to reduce idle time.
### Model
- The framework supports architectures such as Qwen3 and Gemma3, including Mixture-of-Experts variants.
- LoRA is integrated into model definitions.
- High-level sharding APIs distribute models across device meshes without requiring developers to write low-level distributed code.
### Compute
- A unified job interface scales from one node to hundreds of GPUs.
- MFU measurement remains accurate for custom architectures and LoRA configurations.
- Checkpoints include parameters, optimizer state, dataloader state, and data-mixer state, enabling exact resumption.
### Workflow
- The system supports SFT, DPO, RL, and knowledge distillation.
- Online RL uses a hybrid architecture combining a single controller with Single Program, Multiple Data (SPMD) workers.
- This extends conventional SPMD training to multi-stage workflows that cannot be represented as a simple training loop.
Netflix’s approach is to standardize the difficult operational parts of post-training while preserving enough flexibility for unconventional models and objectives. A framework built around reusable data, model, compute, and workflow abstractions can help teams iterate faster and scale experiments without repeatedly rebuilding distributed infrastructure.
The post presents scheduling algorithms for non-preemptive jobs when cloud capacity changes over time because of failures, maintenance, power limits, or higher-priority workloads. The goal is to maximize completed job value while respecting release times, deadlines, processing durations, and fluctuating parallel capacity. The research establishes the first constant-factor guarantees for several offline and online variants, including a 1/11 competitive ratio for a demanding common-deadline model.
## Scheduling with Time-Varying Capacity
- A capacity profile specifies how many jobs can run simultaneously at each point in time.
- Each job has:
- A release time
- A hard deadline
- A processing duration
- A weight or profit
- Jobs must run continuously once started in the non-preemptive setting.
- If capacity drops during execution, an interrupted job loses its progress.
- The objective is to select and schedule jobs maximizing total completed weight.
- The study considers:
- **Offline scheduling**, where future jobs and capacity changes are known.
- **Online scheduling**, where jobs arrive dynamically and decisions cannot be reversed.
## Offline Scheduling Results
- The optimal problem is NP-hard, so the work focuses on approximation guarantees.
- For unit-profit jobs, an earliest-finish-time Greedy algorithm achieves a **1/2-approximation**.
- It completes at least half as many jobs as an optimal schedule.
- This matches the classic guarantee for single-capacity scheduling.
- For jobs with different weights, a primal-dual algorithm achieves a **1/4-approximation**.
## Why Online Non-Preemptive Scheduling Is Difficult
- Online schedulers must commit without knowing future jobs.
- Starting a long job can block many shorter jobs that arrive later.
- Because each completed job may have equal value regardless of duration, one poor decision can sharply reduce throughput.
- Consequently, standard non-preemptive online algorithms have competitive ratios approaching zero.
## Interruption with Restarts
- An active job may be interrupted, but its completed work is discarded and the job can be retried later.
- A modified earliest-finish-time Greedy algorithm achieves a **1/2 competitive ratio**.
- This means it can guarantee at least half the throughput of an optimal schedule with complete knowledge of future arrivals.
## Interruption Without Restarts
- If an interrupted job is permanently discarded, online scheduling becomes substantially harder.
- In general, every online algorithm can be forced into decisions that prevent it from completing much future work.
- The competitive ratio again approaches zero.
- The authors therefore study a practical special case in which all jobs share a common deadline.
## A Common-Deadline Algorithm
For a unit-capacity system, the algorithm maintains a tentative schedule of jobs in disjoint time intervals. When a new job arrives, it applies the first suitable action:
1. Place the job in an empty interval.
2. Replace a scheduled future job if the new job is significantly shorter.
3. Interrupt the current job if the new job is shorter than its remaining processing time.
4. Discard the new job.
- The approach balances immediate execution against preserving capacity for shorter future jobs.
- A generalized version works with arbitrary capacity profiles.
- The resulting algorithm achieves the first constant competitive guarantee for this setting: **1/11**.
The results suggest that schedulers for volatile cloud environments need controlled interruption and carefully designed replacement policies. Allowing restarts offers strong guarantees, while stricter interruption rules require additional structure—such as a shared deadline—to achieve predictable performance.
Figma has achieved C5 accreditation, Germany’s cloud security standard developed by the Federal Office for Information Security (BSI). The milestone strengthens Figma’s credibility with customers in Germany, Austria, and Switzerland by independently validating its security, availability, confidentiality, risk management, and operational transparency. It also supports organizations with strict regulatory and compliance requirements.
## C5 Accreditation and Cloud Security
- C5 provides a recognized framework for evaluating cloud service security and reliability.
- Independent accreditation confirms that Figma meets rigorous requirements for:
- Information security
- Risk management
- Service availability
- Confidentiality
- Operational transparency
- Figma is now listed in the BSI C5 register, allowing customers to review its security controls and operational practices more easily.
## Benefits for DACH Organizations
- The accreditation gives organizations greater confidence when using Figma for cloud-based collaboration.
- It is particularly relevant to customers in:
- Government and the public sector
- Financial services
- Other highly regulated industries
- Customers can more easily assess Figma against internal compliance, security, and assurance requirements.
## Continued Investment in the Region
- Figma’s regional initiatives include:
- Full German-language localization
- European Union data storage options for enterprise customers
- Expanded enterprise security and compliance capabilities
- Nearly 90% of DAX 40 companies use Figma to design and build products collaboratively.
Figma’s C5 accreditation reinforces its position as an enterprise-ready collaboration platform for organizations across the DACH region, especially those facing complex regulatory and security demands.
