ข่าว

Most teams building a shopping assistant or agent rebuild the same scaffolding: an agent loop, a tool layer over the catalog, an approval gate, and an eval suite. Anthropic has now released that scaffolding as code. This week, they published anthropics/commerce-agents, a reference blueprint containing a shopping agent and a merchant agent, along with four runnable verticals: retail, travel, telecom and entertainment. It ships alongside two write-ups: a product announcement and an engineering deep-dive, A guide to the anatomy of effective commerce agents. Is it deployable? Yes. The repository is Apache 2.0, runs locally on Python 3.11+ and Node 22 with an ANTHROPIC_API_KEY, and the runtimes accept any anthropic client, so the same code deploys on the Claude API, Amazon Bedrock, Microsoft Foundry or Google Cloud Vertex AI. The two agents The shopping agent lives inside a merchant’s own app. It searches the catalog, handles multi-item requests, compares options, builds the cart, and answers order and returns questions in the same conversation. Its five skills are search-discovery, purchase-research, planning-goals, customer-care and memory-personalization. A deployment implements a StorefrontBackend over its catalog, cart, order and policy systems. The merchant agent supports store staff: sales performance questions, inventory alerts, pricing and promotion recommendations, and campaign drafts. Its skills are performance-insights, catalog-listings, inventory-operations, pricing-promotions and marketing-campaigns, over a MerchantBackend. Both run three ways — the Messages API, the Claude Agent SDK, and Claude Managed Agents (beta) — from one definition of prompts, skills, tool contracts and gates. A Claude Code plugin, commerce-builder, scaffolds a new agent (/scaffold-commerce-agent) or reviews an existing one (/review-commerce-agent). Skills, not subagents The architectural claim is the most transferable part. Anthropic argues against an intent router and against one subagent per domain. A commerce session is one tightly coupled conversation, and every handoff is state-lossy: the orchestrator holds the cart, preferences and history, and each handoff can cost several times the tokens and add seconds of latency. Domains also overlap, a returns flow needs order history, the cart and the catalog at once. Agent skills give the same modularity without that tax, because skill instructions load into the agent that already holds the history. Across several enterprise deployments, Anthropic reports a single agent with skills beat both the one-big-prompt design and the subagent design on quality, often at lower cost and latency. Subagents still earn a place for narrow, self-contained work such as deep research. The prompt-versus-skill split is decided by frequency: roughly a third or more of traffic goes in the system prompt, the rest into skills. Safety rules, brand constraints and key user facts always go in the prompt. UI components are tools Most commerce responses are components, not prose. Rather than prompting the model to emit custom tags, the blueprint makes each component a tool — present_products, present_itinerary, present_plan_comparison — with typed arguments the server validates before the client renders. Because those calls sit in the messages array natively, reloading history needs no custom parser, and the agent can resolve “the first hotel” from the last presentation call. For token-level streaming, eager_input_streaming: true skips server-side buffering and its schema guarantee. Explainer: the five decisions, interactive Latency, caching, memory A rendered response runs 500–700 output tokens, which without streaming is five seconds of spinner. Anthropic separates end-to-end latency from perceived latency, streaming components as they form and rendering plain-language progress lines. Eager tool dispatch — executing each call as its arguments finish streaming, the Agent SDK default — reportedly cuts multi-second gaps to a few hundred milliseconds. Prompt caching is the main cost lever. Requests are ordered global → session → volatile, since caching is prefix-based and a timestamp at the top of the system prompt breaks the cache on every request. Cached reads cost a tenth of fresh tokens, cache writes carry a ~1.25x premium, and the best deployments run at 90–99% hit rates. Memory extraction runs asynchronously in a separate process; Anthropic measured 13% higher fact recall than an in-turn save tool. Key Takeaways Apache 2.0 blueprint with shopping and merchant agents, four verticals, and a Claude Code plugin. One agent loop plus skills outperformed subagent and single-prompt designs in Anthropic’s deployments. UI components ship as typed tools, so history stays native and layout is resolvable. Prompt caching targets 90–99% hit rates; volatile data belongs last, never first. Money, writes and IDs are gated in code — the model proposes, the harness applies. Check out the Anthropic engineering deep-dive, Product announcement, GitHub repository and Commerce demos. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Anthropic Released Claude Commerce Agents: An Apache-2.0 Blueprint for Shopping and Merchant Agents Across Retail, Travel, Telecom and Entertainment appeared first on MarkTechPost.

Today, OpenAI released GPT-6 Astra. The company calls it its most intelligent and aligned model, and positions it primarily as a computer-use system rather than a chat model. The pitch is that Astra operates software the way a person does, across browsers, spreadsheets, desktop applications and terminals, and finishes multi-step jobs instead of describing how to do them. Is it deployable? Partly, and not on your own hardware. Astra is a closed, hosted model with no released weights, so self-hosting is not an option. It is live today only for organizations in OpenAI’s Trusted Access and Daybreak programs. What is actually new The main change for devs is context handling. Codex previously used compaction, summarizing earlier turns once context filled up. That process discards the detail an agent later needs: why a fix failed, which tests ran, which requirement was added early. Astra instead keeps notes across context windows and searches back into earlier messages and tool output. The feature ships experimental behind a config.toml setting and becomes the Codex default in the coming weeks. Astra can also ask the user a question while continuing work that does not depend on the answer. That removes a common agent failure where one unresolved decision stalls an entire job. On the model page, Astra lists a 1,050,000-token context window, 128,000 max output tokens and an April 30, 2026 knowledge cutoff. Input is text and image, output is text only. reasoning.effort adds two new levels above high: xhigh and max. Tool support covers computer use, hosted shell, apply patch, skills, MCP and tool search. Fine-tuning is not supported. The benchmark picture OpenAI reports 72.6% on OSWorld V2-Offline against 65.7% for GPT-5.6 Sol, with average task time falling from roughly 75 minutes to 40. Anthropic reports 77.9% for Claude Fable 5.1 but says it used a different OSWorld release and should not be compared directly. Astra scores 99.9% on ARC-AGI-3. That number was produced with a Responses API harness that retains reasoning between turns and uses compaction for long contexts, and OpenAI has previously shown those settings move ARC-AGI-3 scores substantially without changing the model. The result measures the model plus the agent system. Other reported figures: 97.6% on FrontierMath Tier 4, 95.9% on BenchCAD Vision2Code against 84.3% for Fable 5.1, and 64.6% on Terminal-Bench Science against Anthropic’s reported 52.6%. Epoch AI notes OpenAI funded FrontierMath and has exclusive access to part of it. Coding is the weak spot in the story. Astra scores 74.1% on DeepSWE v1.1 versus 72.7% for Sol. Meta reported 75.4% for Muse Spark 1.3 at maximum reasoning, and the public leaderboard puts Gemini 3.8 Flash and Claude Opus 5 near 74%. On a 113-task benchmark, those gaps are one or two tasks. Cyber capability drives the access model Astra is the first model OpenAI has designated as reaching the Critical cybersecurity threshold in its Preparedness Framework. In testing it developed exploits for hardened browsers and operating systems, and found two previously unknown V8 vulnerabilities that OpenAI says it is disclosing to maintainers. The consequences are practical. Standard access refuses advanced cybersecurity work including exploit discovery. For API developers, a cybersecurity safety check stops a task outright rather than pausing for approval. OpenAI’s Mia Glaese warned that users outside trusted-access programs may hit slowdowns, pauses or blocks, sometimes during unrelated work. OpenAI reports 100% on ExploitBench, an aggregate capability-coverage score rather than a pass rate, and 42.4% on ExploitGym against 30.3% for Sol, with the usual six-hour time limit removed for both. Pricing Astra costs $10 per million input tokens and $50 per million output, with cached input at $1.00. Requests above 272K input tokens bill at 2x input and 1.5x output for the full request. Batch and Flex run at 50%, Fast mode at 2x. Pro, Business and Enterprise users also get Astra Pro. Key Takeaways Astra is a computer-use model first: 72.6% OSWorld V2-Offline, task time down from ~75 to ~40 minutes. Notes replace compaction in Codex, so long agent runs stop losing failure detail. Coding gains are marginal: 74.1% DeepSWE v1.1 sits inside the leaderboard pack. First model at OpenAI’s Critical cyber threshold; standard access refuses exploit work. No open weights, $10/$50 per million tokens, 1.05M context, API and AWS in coming days. Check out the OpenAI announcement, OpenAI on X and GPT-6 Astra model page. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post OpenAI Releases GPT-6 Astra: A 1.05M-Context Computer-Use Model Gated Behind a ‘Critical’ Cyber Threshold appeared first on MarkTechPost.

As companies scale, the technology supporting operations can become a liability just as quickly as it becomes an asset. Disconnected systems, site-specific tools, spreadsheets, and manual workarounds can create data silos that make it harder to spot problems early, coordinate responses, and make decisions with confidence. For Jabil, a global manufacturing company with more than 100 sites across more than 30 countries, the answer has been to make integration and simplification a priority. The company adopted a “simplify-first, then-innovate mindset,” says Harish Manohar, SAP IT director at Jabil, recognizing that adding new technologies without first reducing complexity risks creating more risk. The goal is to standardize processes, consolidate where possible, and establish a more consistent data backbone across the organization. “Any innovation without simplification is going to add more complexity,” Manohar says. That philosophy also changes how Jabil approaches modernization. “Any modernization or transformation should add measurable business value,” Manohar says. The company is focused on connecting processes end-to-end across its supply chain and creating a foundation that can scale consistently across regions. Integration comes first because, as Manohar puts it, “the backbone of any contemporary or modern organization is data.” Before organizations can optimize, automate, or apply AI, data needs to flow seamlessly across systems. But doing that across a global organization is hardly straightforward. Jabil’s more than 100 sites operate with different levels of process maturity, legacy systems, and localized workflows, while regulated businesses bring additional compliance requirements. As such, standardizing across different regions and business environments means changing processes and governance without disrupting the operations already in place. The value of that work extends beyond the technology to the people using it. Integrated workflows can offer employees shared visibility into data, reduce manual data reconciliation, and help them move from chasing information to acting on insights. For Jabil, the aim is also to improve real-time visibility into supply chain events, which can enable faster responses to disruptions and reduce operational risk. Looking to the future, that foundation could make AI and automation all the more useful and scalable. With trusted data and integrated systems in place, Jabil is exploring predictive supply chain insights, intelligent exception handling, and AI-driven planning and forecasting. To Manohar, the takeaway is clear: “Simplicity at scale is a very competitive advantage,” and technology investments must ultimately connect to business value and operational resilience. This episode of Business Lab is produced in partnership with SAP. Full Transcript: Megan Tatum: From MIT Technology Review, I’m Megan Tatum, and this is Business Lab, the show that helps business leaders make sense of new technologies coming out of the lab and into the marketplace. Our topic today is enterprise technology integration, and how the benefits of consolidating tools and systems across the supply chain help organizations operate more reliably at scale. When companies reduce tool sprawl and connect their systems more effectively, they gain earlier visibility, faster response, and greater resilience across production lines. My guest today is Harish Manohar, SAP IT Director at Jabil. Jabil has been on a journey to simplify its technology landscape by using SAP Integration Suite as the foundation to connect systems, retire fragmented tools, and enable more consistent operations globally. This podcast is produced in partnership with SAP. Welcome, Harish. Harish Manohar: Hello, Megan. Good morning. Megan: Thank you so much for being here, Harish. Just to start, if we could set some context, can you give us a quick overview of Jabil, the business and its overall transformation journey? Harish: All right. So, about Jabil. Jabil is a global manufacturing company headquartered in St. Petersburg, Florida, USA. We have about 60 years of experience offering comprehensive engineering, supply chain, and manufacturing solutions across different industries. We have a global footprint of about over 100 different sites across 30-plus countries, 140,000-plus employees. We are a trusted partner for more than 400 of the world’s top brands. That’s a little bit about Jabil. Megan: Fantastic. And a lot of scale there, as you’re referring to some of the stats there. As things have got more complex, where did disconnected tools and systems start to slow you down, and what ultimately drove you to make integration a really strategic priority? Harish: I talked about our global footprint across 100-plus sites. With a global footprint always comes complexity about site-specific tools. All of our sites have been in business for a long time, and over the period of years, they had their own tools for their own processes. It’s a little bit disconnected. When we are looking to scale, the first thing we wanted to start looking at is what is this mix of site-specific tools, manual workarounds, spreadsheet-based processes, legacy applications, whatnot? That’s a big technical debt that we have had over the last 25 years. That’s where we started, and that is what led Jabil to make integration a strategic priority because we had limited ability to see issues early across plants, across regions, which would help us to coordinate responses consistently, and also to be able to scale those responses consistently. This complexity created data silos, and in a way delayed robust decision-making. As the complexity increased globally, integration became extremely critical to a few things. It was critical to establishing a single trusted data backbone, which would directly enable faster coordinated responses across the network. We at Jabil, as part of our transformation journey, believe that having the right data at the right time fundamentally changes how we respond to disruptions, which is all about a manufacturing business. How we respond to disruptions. This is where we started our strategic priority towards having a integrated system that drove data consistency across our landscape. Megan: Fantastic. As you have outlined there, there was obviously a real commercial need for this, but how did you think about bringing in those new technologies without adding even more complexity to the mix? Harish: Great question. Whenever we talk about transformation, we talk about all these bleeding-edge technologies that are out there today when

Teams running coding agents hit the same wall. Claude Code speaks the Anthropic Messages API, Codex CLI speaks OpenAI, and the model a team actually wants to serve sits behind vLLM, NVIDIA NIM, or Ollama. Rewriting the agent is not an option, so the translation layer has to live somewhere else. Switchyard is NVIDIA’s answer: a Rust proxy and library for LLM traffic that routes requests across providers, translates between OpenAI and Anthropic formats, records operational metrics, and exposes typed, composable routing algorithms. It is released under Apache 2.0 with documentation at docs.nvidia.com/nemo/switchyard. Is it deployable? Yes, but for evaluation only. The binary installs from crates.io and the launcher from PyPI, and it self-hosts anywhere, but NVIDIA labels Switchyard pre-alpha and experimental, warns it is not for production use, and expects the API and algorithms to change significantly before v1.0. What Switchyard does Clients keep their native API. Switchyard decodes the inbound request into provider-neutral Rust types, runs a routing algorithm to pick a backend, re-encodes the request in that backend’s own wire format, calls it, and translates the response, including streaming events, back into the shape the client expects. The server accepts three inbound formats: OpenAI Chat Completions, OpenAI Responses, and Anthropic Messages. Any of the three can address any route, and each configured LLM client selects one upstream format of its own. That decoupling is the point: the agent’s API and the backend’s API no longer have to match. Three ways to run it The launcher path targets coding agents. Install the published tool with uv tool install –python 3.12 “nemo-switchyard[cli]”, then run switchyard launch claude, switchyard launch codex, or switchyard launch openclaw against a packaged deployment or your own TOML file. The server path installs the standalone proxy with cargo install –locked switchyard-server, validates a config with –dry-run, and serves on a host and port you choose. The library path uses switchyard-libsy, which embeds the routing algorithms in a Rust application without owning an HTTP stack. It never calls a model itself; the algorithm decides which target to use and hands every model call back to the caller. Routing algorithms A route is one client-visible model ID plus the algorithm behind it. The server supports: passthrough sends every request to one target. random splits traffic across targets using optional relative weights, with an optional seed that reproduces the selection sequence. This is the A/B and cost-experiment path. llm_classifier calls a classifier target for a capability verdict, then routes to a weak or strong target. base_threshold is required; min_confidence, capability_elevated_floor, and session_affinity tune it, and anything the judge cannot decide falls through to the strong target. Setting mode = “escalation” runs every turn on the weak tier first and lets a judge decide whether to rerun it on the strong tier. stage_router scores tool-result and agent-progress signals from recent turns to pick a capable or efficient target, avoiding an extra classifier call on most turns. Strong, weak, capable, and efficient are roles inside a route, not fixed properties of a model. The same upstream model can serve different roles in different routes. Observability GET /metrics returns Prometheus text from the server’s process-wide OpenTelemetry provider. The families cover requests, errors, model-call latency, full-turn latency, prompt, completion, cached, cache-creation, and reasoning tokens, and upstream HTTP attempts by outcome and code. A tier label carries strong or weak for distinguishable classifier decisions, and classifier calls are excluded from those families. The more interesting metric is switchyard_routing_overhead_ms, which reports the algorithm’s run time minus the call that served the request. Classifier calls are not subtracted, so an LLM-classifier route reports its classification time here while passthrough and random report the sub-millisecond cost of picking a target. Buckets start at 0.1 ms. Separately, –routing-log-file appends a JSON record per completed response, and GET /v1/routing/session-stats returns per-session call and token totals from that log. Configuration A TOML deployment has three layers: llm_clients define base URL, wire format, credential environment variable, and retry policy; targets bind one upstream model ID to a client; routes expose one client-visible model ID and its algorithm. Secrets never sit in the file, since api_key_env only names an environment variable. max_retries defaults to 2 and applies to transport failures, timeouts, HTTP 408/429, and 5xx responses. Key Takeaways Switchyard is an Apache-2.0 Rust proxy and library that routes and translates LLM traffic. It bridges OpenAI Chat, OpenAI Responses, and Anthropic Messages in both directions, including streams. Four route types ship: passthrough, random, LLM-classifier, and signal-driven stage router. Prometheus metrics isolate routing overhead from model-call latency, per model and tier. It is pre-alpha and explicitly not for production, so treat it as an evaluation tool. Check out the GitHub Repo and Documentation. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Meet Switchyard: A Rust Proxy and Library That Routes and Translates LLM Traffic Across OpenAI and Anthropic APIs appeared first on MarkTechPost.

Coding agents spend a large share of their tool budget on search. When the target is a known symbol, ripgrep answers it exactly. When the target is a behavior described in plain language, keyword matching often misses, and the agent falls back to guessing terms, reading whole files, and assembling context by hand. Each of those detours costs tool calls, tokens, and wall-clock time. The Qwen Developer team announced zg (zvec-grep), an open-source local-first search layer that puts semantic search, BM25, and ripgrep behind one interface for both humans and agents. The code ships under the zvec-ai GitHub organization with an Apache 2.0 license. Is it deployable? Yes, today. It installs from npm as @zvec/zvec-grep, requires Node.js 22 or newer on macOS, Linux, or Windows, needs no GPU with the default model, and the Apache 2.0 license permits commercial use. One index, four retrieval routes zg indexes a workspace once and then exposes several ways to query it. The retrieval pipeline docs define four routes: a hybrid default that combines intent with lexical anchors, –fts for BM25-ranked exact terms, –vector for conceptual similarity with no lexical ranking, and –rg for exhaustive literal or regex matching. The first three read the index. The –rg route needs no index at all, which matters when a repository has not been indexed yet. An anonymous workspace index lives in <root>/.zvec-grep/. Both .git and .zvec-grep are always excluded, along with common dependency, build, cache, and log directories, plus anything the repository’s own ignore rules exclude. Re-running zg index updates incrementally; changing the embedding model requires an explicit –rebuild because vector spaces from different models are incompatible even at matching dimensions. Indexed results report a freshness state of fresh or possibly_stale, so an agent can act on a good-enough result instead of running a status preflight first. The MCP surface agents actually see zg install detects Codex, Claude Code, Cursor, and OpenCode on the machine and wires up the local MCP integration. The server speaks Streamable HTTP MCP on a loopback-only endpoint at http://127.0.0.1:7999/mcp, with optional bearer authentication. The design decision worth noting is restraint. Per the MCP guide, the default agent toolset exposes exactly two tools: zvec_grep_search for when the intent is known but the exact string is not, and zvec_grep_rg for when a symbol, path, or regex is known. Index lifecycle stays with the CLI. A six-tool compatibility set that adds index create, drop, status, and server status exists but is opt-in through zg server on –mcp-toolset full, and the docs state that an agent must never silently create, rebuild, or delete a persistent index. Output is shaped for context economy. Results come back grouped by file with line spans, and indexed source previews are omitted by default unless requested. zg also rejects output-changing ripgrep flags such as –json, –count, -l, and –vimgrep so the compact result format holds. Embeddings run on device by default The embedding catalog currently documents ten local models and three remote Qwen endpoints. The quickstart default, local/potion-code-16m-v2, is a Model2Vec static model with a 256-dimension output and an 8,192-token input limit; because it uses static vector lookup, selecting a GPU does not speed it up. Heavier local options include jina-embeddings-v2-base-code, embeddinggemma-300m, and qwen3-embedding-0.6b. Remote options run to qwen/qwen3.7-text-embedding at 128,000 input tokens and the multimodal qwen/qwen3-vl-embedding. Remote use is gated. Configuring a provider credential does not authorize data transfer; that requires either –allow-remote for a single command or a signed workspace grant via zg auth grant, revocable with zg auth revoke. The launch post cites eleven on-device models against ten in the current docs, a small discrepancy worth flagging. What the benchmark numbers say The evaluation numbers appear in the launch post, not in the repository, where the benchmarks section is still a placeholder. Both runs were paired A/B tests holding agent, model, prompt, runtime, and task constraints fixed, with the zg condition adding only a prebuilt index, MCP tools, and usage guidance. Index build cost is excluded from the tables. On a 20-question SWE-QA-Bench sample, zg cut tool calls by more than half and input tokens by nearly half while raising the Judge score by 1.50 points. On an 80-question BrowseComp-Plus sample, accuracy moved from 98.67% to 99.00% while input tokens fell 37.56%, tool calls 43.52%, and agent time 38.58%. Separately, indexing the Django repository (3,457 files) is reported to finish in under 30 seconds on an Apple M4 Pro. Sample sizes of 20 and 80 questions are small, and the reported reductions come from the vendor’s own runs, so independent replication is the obvious next step. Interactive explainer Key Takeaways zg unifies ripgrep, BM25, and vector search behind one local-first interface for humans and agents. The default MCP toolset exposes only two tools; index lifecycle stays with the CLI by design. Indexing, embedding, and retrieval run on device; remote embeddings need explicit per-command or workspace authorization. Vendor A/B runs report roughly 40% to 50% cuts in tool calls and input tokens on small samples. Apache 2.0, npm-installable, Node.js 22+, no GPU needed with the default model. Check out the zvec-ai/zvec-grep, Qwen Developers launch post and Roadmap. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well. Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us The post Qwen Developers Open-Sources zg (zvec-grep): A Local-First Search Layer Unifying ripgrep, BM25, and Vector Search appeared first on MarkTechPost.

For years, legacy technology has been a problem companies knew they needed to solve, but one they often struggled to tackle. The cost, complexity, and risk of replacing business-critical systems could make modernization feel like a disruption to manage instead of an opportunity to pursue. But with the rise in customer expectations and the changes AI brought to the economics of software development, that calculation is changing. Bupa’s modernization of its My Bupa mobile application offers a case study in what becomes possible when a legacy migration is treated as a business transformation rather than a technology rewrite. Bupa CIO of health insurance Asifa Sherazi describes the risks of waiting for legacy systems to become an emergency: “The end-of-life technology is a risk that compounds quietly, and then arrives all at once.” For Bupa, moving its application from Xamarin to native Swift and Kotlin improved the app rating from 3.7 to 4.7, while the user-perceived crash rate fell by nearly 24 percentage points on Android and eight points on iOS. “What they’ll notice is that when they need us, often at a stressful moment, it just simply works,” Sherazi says. Sanjeev Tripathi, senior vice president and region head of BFSI, healthcare, and public sector for Australia, New Zealand, and Southeast Asia at Infosys, contends that AI is helping change the equation. “The emergence of AI is fundamentally shifting the economics of modernization,” he says, reducing the effort, risk, and time traditionally associated with these programs. At Bupa, combining AI-assisted reverse engineering with forward engineering helped deliver the transformation in approximately 60% less time than would have been possible in the pre-AI era. Sherazi and Tripathi also highlight the human dimension of modernization: preserving institutional knowledge, giving teams capacity to adapt, and creating an environment where employees can surface problems early. Looking ahead, both experts see modernized platforms as foundations for more personalized, predictive and AI-driven experiences. The payoff of modernization may be less about replacing aging technology and more about building the flexibility needed for whatever comes next.  “Modern platforms will become the base for far more intelligent AI-driven ecosystems, where AI is not just an add-on, but it is built into everything from design to operations. That’s how the modern platforms will evolve, and the customer experiences will become far more personalized and predictive,” says Tripathi. For Sherazi, that shift is already changing the questions organizations can ask: “It used to be, can our platform support that? Now, it’s: is that the right thing to do for our customers?” This episode of Business Lab is produced in partnership with Infosys. Full Transcript: Megan Tatum: From MIT Technology Review, I’m Megan Tatum, and this is Business Lab, the show that helps business leaders make sense of new technologies coming out of the lab and into the marketplace. Our topic today is legacy modernization. Companies across industries continue to struggle to bring AI modernization to legacy technology stacks, increasing the risk of losing vendor support, degraded customer experience, and limited capacity for innovation. Two words for you: future-ready foundation. My guests are Asifa Sherazi, who is CIO of health insurance at Bupa, and Sanjeev Tripathi, who is senior vice president, region head of BFSI, healthcare, and public sector for Australia, New Zealand, and Southeast Asia at Infosys. This podcast is produced in association with Infosys. Welcome, Asifa and Sanjeev. Asifa Sherazi: Thank you, Megan. Delighted to be here. Sanjeev Tripathi: Thanks, Megan. Wonderful to be here. And good talking to you again, Asifa. Megan: Thank you both so much for being here. Asifa, if I could start with you just to set the context for our conversation. There are seven million healthcare customers across the Asia-Pacific. Could you tell us a bit more about Bupa and the challenges it’s faced in its modernization plan? Asifa: Yes, absolutely. Let me start with something about Bupa that shapes everything we do. We are a global healthcare organization. Think hospitals, clinics, dental, age care, digital health, alongside our insurance business. We reinvest back into the organization, so into our services, our capability, our teams, and our outcomes that we deliver for our customers. In Asia-Pacific, we serve around, as you said, seven million customers across health insurance and health services, individuals, families, corporate clients, patients. Our purpose, helping people live longer, healthier, happier lives is more than just a statement. It actually shapes our strategy, guides our investment decisions, and influences the choices our teams make every day. Now, for most of our health insurance members, the day-to-day digital relationship with Bupa begins through My Bupa, our self-service platform. It’s the front door for managing cover, updating policy details, submitting claims, checking entitlements. Alongside of it, Blua plays a complimentary role. Where My Bupa helps members manage their cover, Blua helps them manage their health, digital healthcare services, clinical support, preventative health. And together, they let us move beyond transactional interactions towards more personalized, proactive care. Here was our challenge. Our mobile app, My Bupa, was built on Xamarin, and Microsoft support for it ended sometime in 2024. We had extended support in place, so our customers remained protected throughout, but we were clear-eyed that this was a bridge, not a destination. The runway was finite, and it was shortening for us. We made the decision to modernize from a position of stability proactively for the long-term safety and experiences of our customer rather than waiting until circumstances forced our hand, because the platform carrying our most important customer relationship was in effect standing still while the world around it was moving. Megan: Right. So you decided to act really proactively in that sense. And so, Asifa, what are some of the risks then of sticking with end-of-life technologies, and how will moving away from legacy technologies help you improve the customer experience? Asifa: Yeah. Look, the end-of-life technology is a risk that compounds quietly, and then arrives all at once. We saw it in three ways. The first is security and compliance.