Reading

Chinese technology company Baidu unveiled its latest foundation model, ERNIE 5.5 Flash Preview, and launched a new marketplace called "Token Exchange" at its annual World Conference on November 12, 2026. The announcements included major upgrades to its agent product line and a vision for the "intelligent organization" outlined by Co-founder and CEO Robin Li.

ERNIE 5.5 Flash Preview is a Mixture-of-Experts (MoE) model with 280 billion total parameters and 14 billion active parameters per token, supporting a 1 million token context window. Baidu claims strong performance in coding, 3D modeling, and content creation, optimized by its proprietary recursive self-improvement technology, ERNIE Evolve. Notably, Baidu disclosed specific API pricing: RMB 1 per million input tokens and RMB 4 per million output tokens, with cached input at just RMB 0.04. Model weights will be open-sourced by November 25. This aggressive pricing strategy suggests Baidu aims to expand its market share by lowering barriers to entry for developers.

Beyond the model itself, Baidu's Token Exchange serves as a neutral marketplace connecting AI model providers with customers. Users can compare model services side-by-side based on price and performance, accessing them through a single interface. According to Baidu, the platform has onboarded over 100 model resources in its first month, handling an average of more than 50 million calls and 700 billion tokens daily. This initiative addresses the difficulty of discovering high-quality model services and may help utilize underused compute resources.

Regarding internal applications, Robin Li disclosed concrete progress in Baidu's transformation into an "intelligent organization." Over the past year, the number of daily active agents (DAA) within Baidu surged from 5,000 to 37,000, an increase of over 600%. Weekly tasks completed by agents rose from 84,000 to more than 1 million. These figures provide investors with a quantifiable view of how Baidu is converting AI technology into operational efficiency. Additionally, Baidu upgraded its general-purpose agent DuMate and digital human agent Baidu Yijing, and presented a new roadmap for its Kunlunxin chips.

A small model was asked to install a tool, and it replied: 'You have a brain and I don’t.' Logan Lawler, Head of AI Strategy for Dell Pro Precision Workstations at Dell Technologies, recalled this testing experience in a blog post—the toolchain had fed the model all the information needed to complete the installation, yet the model completely failed to understand the task. This anecdote leads to his core judgment: in the formula where an agent equals a model plus a tool harness, the model is the brain, and even with all necessary conditions met, a wrong brain will fail.

His method consists of three steps. First, build a shortlist from benchmark websites. He recommends four: Artificial Analysis compares quality, price, and speed using independent tests, making it suitable for filtering by budget; Arena (formerly LMArena) allows real people to anonymously compare answers from two models and vote for the better one, reflecting actual preferences in everyday writing and Q&A; the Berkeley Function Calling Leaderboard tests how accurately a model uses tools (such as web search and file access)—since agents perform work through tools, this leaderboard is the most critical for agent scenarios; and SWE-bench tests whether a model can fix real bugs in open-source software, which is ideal for agents that need to write code. Second, run comparisons on real tasks. Lawler suggests using an OpenRouter account (which provides access to models from multiple providers via a single account) or LM Studio (which loads models locally) to test one frontier model and one or two smaller models, running the same task two to three times. Third, score each run across four dimensions: completion, correctness, amount of feedback needed, and cost. Keep the cheapest model that gets the job done right.

After scoring comes routing. Lawler cites specific data: when LangChain tested NVIDIA’s NeMo Switchyard routing library on 145 agent tasks, only 7% of the steps required a frontier model. This means that the vast majority of daily steps—calling tools, summarizing results—can be handled by small models. His personal production setup uses frontier models (via OpenRouter and his Claude plan) for designing agents and writing skills, because that represents 'hard thinking that requires payment'; once skills are built, they run daily on DeepSeek V4 Flash, deployed on a Dell Pro Precision GB10 workstation.

Lawler also defines boundaries. If comparison testing shows that only a frontier model can get the task done correctly, or if the task falls into the hardest categories of coding, reasoning, or research, do not force the use of open-source models. His exact words were: 'Don’t force an open-source model into a race it cannot win yet.' He also emphasized that he is constantly testing and advised readers to ask him again in a quarter.

Contextual note: This article was published on the official Dell Technologies blog. The author’s role is to lead the AI strategy for Dell Pro Precision workstations, and the NVIDIA Nemotron series models, NeMo Switchyard routing library, and Dell GB10 workstation recommended in the article are directly related to his commercial interests. The 7% figure from LangChain comes from its testing of the NVIDIA Switchyard routing library and is not an independent third-party assessment. While the methodology itself—building a shortlist, running comparisons, scoring across four dimensions, and keeping the cheapest option—is transferable, the specific tool recommendations should be viewed as suggestions carrying vendor bias.

Cross-organizational multi-agent systems face a specific constraint: two institutions build and run their own agents, which need to discover each other and exchange tasks without exposing internal implementations or requiring both sides to use the same framework. Without a standardized protocol, every new customer or framework combination requires an ISV to write custom integration code. The A2A protocol attempts to replace these disparate paths with a single interface.

The reference architecture provided in the AWS Machine Learning blog runs three agents across two independent AWS accounts. The enterprise-side orchestrator is based on LangChain, invoking Anthropic Claude Sonnet 4.6 for reasoning routing; the SaaS-side compliance agent is built on the Strands Agents SDK and deployed on Amazon Bedrock AgentCore. Both use completely different frameworks and SDKs but communicate via A2A’s JSON-RPC over HTTP. The orchestrator does not depend on the Strands SDK, nor does the compliance agent depend on LangChain—this is the practical meaning of protocol-level interoperability: as long as both sides speak A2A and publish compatible Agent Cards, the frameworks can be swapped independently.

Agent Cards are the core discovery layer of this mechanism. They publish a JSON document at the /.well-known/agent-card.json path, describing the agent’s name, capabilities, and skills. The orchestrator fetches this card at startup, creating a LangChain tool for each skill listed on the card, after which the large language model decides which tool to call based on the user’s question. This means that when an ISV adds or modifies capabilities, it only needs to update the Agent Card; the orchestrator automatically acquires the new skills upon its next restart, eliminating the need for the two teams to coordinate code changes.

A key design decision lies in what the card publishes. Although the compliance agent has three internal tools (listing accounts, executing scans, and retrieving remediation steps), the Agent Card publishes only one curated skill: 'Scan your AWS account, returning findings and remediation steps by severity.' The calling model sees what the product does, not how it is built. This abstraction allows the ISV to refactor its internal architecture—swapping models, tools, or implementations—as long as the skills described in the card remain unchanged, leaving customer integrations unaffected.

Bidirectional callbacks are what set this solution apart from typical agent demonstrations. Most inter-agent communication demos show a unidirectional request-response pattern: a client calls a server agent and waits for the result. However, this pattern fails when the called agent needs information that only the caller possesses. In this architecture, the compliance agent requires enterprise context before scanning—such as which accounts are production environments, which internal policies apply, and who to escalate to—information known only to the enterprise side. The compliance agent calls back to the enterprise context agent via A2A, obtaining a token using its own account’s identity provider and sending a message to the callback address registered by the customer during onboarding. This makes the two agents true peers rather than a client and a server.

An internal HR policy assistant answers three questions: performance reviews, benefits enrollment, and sick-leave certificates. Chunk-level retrieval precision—which measures whether each retrieved document block as a whole is relevant to the question—scores a perfect 1.00 for all three questions. If the release threshold relies solely on this metric, all three answers would pass.

However, when each document block is broken down into individual facts and their necessity is checked one by one, the fact-level precision scores are 0.59, 0.53, and 0.09 respectively. The third question indicates that roughly nine out of ten specific facts in the retrieved material are irrelevant to what was asked. Chunk-level precision only asks 'is this passage on topic'; it does not measure 'how much of this passage is actually useful.'

In a blog post, the AWS engineering team uses this measured case to introduce the core argument of the Agent Development Lifecycle (Agent DLC) framework: traditional unit testing and CI/CD remain necessary for agents, but they are insufficient due to three characteristics. First, agents are non-deterministic; identical inputs can produce different outputs and execution paths. Second, changes to prompts, tool descriptions, retrieval settings, or memory configuration can alter behavior in ways undetectable by text review alone. Third, model endpoints, knowledge bases, and external APIs can change independently of the code repository and affect agent behavior.

The framework organizes development activities into two nested loops. The inner loop is: score → inspect the path → change one variable → re-evaluate, improving the agent against fixed standards. The outer loop is: define → build → evaluate → release → observe → feedback, allowing the standards themselves to change. The authors provide an example prone to confusion: if production users ask the agent to look up information on behalf of a family member, but no standard covers this scenario, this is an outer-loop problem—it requires defining authorization boundaries and adding examples, then using the inner loop to meet the updated standard. Confusing the two leads teams to attempt filling a missing standard with prompt modifications.

Returning to the sick-leave certificate case. After modifying the prompt, the performance review question improved from 0.83 to 0.87, and fact-level precision jumped from 0.59 to 0.85; however, the groundedness of the sick-leave certificate answer dropped from 0.39 to 0.31, and fact-level precision fell from 0.09 to 0.04—one change yielding two opposite results. Diagnosis points to a knowledge coverage gap: there were no dedicated sick-leave policy documents in the corpus, only brief mentions within the leave-management policy. Telling the model to 'answer strictly based on retrieved content' cannot conjure missing information out of thin air.

Evaluation criteria are organized into five dimensions—domain understanding, quality, responsibility, cost, performance—and three tiers: hard constraints (boolean values, violations block release), release gates (pass-rate thresholds over k runs), and monitoring only (tracked but do not block). The authors highlight a specific case: a benefits enrollment answer passed with a groundedness of 0.90, yet contained the sentence 'I noticed your profile shows your preferred contact method is social media'—a profile that does not exist. The model combined an option from the policy document with an unrelated answer from a public FAQ, packaging it as a fact about the user. A high groundedness score failed to capture this false personal claim.

Canadian e-commerce platform Shopify disclosed on November 12, 2026, via its engineering blog, an internal security system named "Cyber Chaos Monkey" (CCM). The system leverages frontier AI models combined with Shopify's deep knowledge of its software architecture, source code, and infrastructure to proactively launch simulated attacks on its production environment, aiming to identify and fix vulnerabilities before external attackers can exploit them.

The core logic of CCM relies on information asymmetry. Shopify noted that as frontier models drive the cost of vulnerability discovery towards zero, reports received through its Bug Bounty program have increased by nearly 300% since 2024, making manual review and remediation increasingly difficult. CCM addresses this by providing AI agents with live test credentials and comprehensive access to the system, enabling them to operate like advanced bug bounty hunters but at a scale far beyond human capability.

The system architecture is divided into two components: "Discovery" and "Sandbox." Discovery receives hypotheses or leads and uses the latest cyber models to refine potential vulnerability locations. Sandbox executes specific exploitation attempts, including installing packages, building fuzzers, and sending direct requests to Shopify's production environment while analyzing logs. This closed loop allows AI agents to iteratively optimize their attack strategies based on feedback.

To ensure safety, Shopify implemented multi-layered controls. Technically, all operations occur within containerized environments following the principle of least privilege, with network access restricted via credential proxies and strict egress allowlists. Governance-wise, a "Two-Person Integrity" (TPI) mechanism was introduced, using a separately aligned AI agent to monitor the execution agent's behavior logs in real time. If the monitoring agent detects high-risk behavior violating the "Rules of Engagement," it can immediately terminate the task.

According to Shopify, CCM has executed tens of thousands of offensive engagements, identified and acted on dozens of impactful findings, and caused no outages or incidents. This practice marks a shift in enterprise security defense from passive response to proactive, automated red-teaming driven by AI.