Reading

Figma announced 20 new MCP partners at its first Config conference held in India, including Amp, ClickUp, Linear, Notion, Mistral, and others. At a media briefing, co-founder Dylan Field told reporters that he does not think MCP is a perfect protocol.

Field's core argument points to a structural asymmetry: MCP was created by Anthropic, yet Anthropic itself does not expose its cloud resources through MCP. Field wrote on X that he found it interesting that the creators of the MCP standard do not expose artifacts or other cloud resources created via MCP. He argued that the debate is framed as open versus closed, everyone always prefers open, and meanwhile issues of asymmetric context sharing are ignored.

The mechanism behind this argument is as follows: MCP standardizes how AI agents connect to external data sources and tools. When application-layer companies open their data according to this standard, the protocol creator—typically a frontier lab with the most powerful models—gains a structured access path without offering reciprocal exposure. Field further stated at the media briefing that MCP is advantaged more to frontier labs.

Figma's actual strategy is to both embrace and critique the standard. The company is expanding MCP support, but Field said the reason Figma does not want to be fully open is that the more data the company exposes through MCP, the higher the chance of abuse. He acknowledged that most users do not intend to use MCP or Figma data maliciously, but the company still has to think about those potential risks. Field later added that Figma plans to support Pi, the open-source tool that one of MCP's co-creators had complained about.

The value of this argument lies not in whether it ultimately proves correct, but in that it raises a concrete design question: when a protocol is created by the most powerful participant in an ecosystem, how do smaller companies adopting that protocol avoid becoming one-sided data suppliers? For developers evaluating AI agent integration options, the asymmetric context sharing Field identifies is a practical constraint to consider, not merely an ideological open-versus-closed debate.

When AI agents access databases, APIs, and sensitive business operations through the Model Context Protocol (MCP), a fundamental question arises: how to prove which agent made a request, prevent forgery between agents, and confirm that each agent acts only on behalf of an authorized user. MCP has no built-in authentication standard and is transport-agnostic by design. Without proper identity mechanisms, any component could impersonate an agent, replay intercepted credentials, or invoke tools without authorization.

The AWS and Keyfactor engineering teams jointly published a reference architecture that addresses this gap through four complementary security mechanisms. First, signed request envelopes provide cryptographic proof-of-possession on every agent call. Second, user-signed delegation assertions authorize agents without sharing credentials. Third, RFC 8693 audience-scoped tokens limit the scope of exposure from any single token disclosure to one service boundary. Fourth, real-time OCSP revocation checking propagates credential changes immediately across all agents.

The revocation cascade is the architecture's key security property. When a user logs out, the system first revokes the user certificate in EJBCA. Because delegation verification checks the user's certificate through OCSP in real time, this step immediately invalidates all outstanding delegations. The system then revokes all three agent certificates, invalidating every signed envelope, deletes all secrets from AWS Secrets Manager with no recovery window, and terminates the Keycloak session. The critical insight is that revoking a single user certificate at the PKI layer promptly revokes all downstream agent authority without needing to individually revoke tokens, delete sessions, or contact each agent. OCSP provides the propagation mechanism, and because every request checks OCSP, the effect is immediate.

On private key isolation, the user's private key is used only at login to sign the delegation assertion and is never shared with agents. Each agent's private key is used only by that agent to sign envelopes and is never shared between agents. EJBCA never sees or stores private keys, operating purely as a certificate authority. If Secrets Manager is subject to unauthorized access, the PKCS12 password stored separately adds an additional layer of protection.

The architecture is framework-agnostic. While the demonstration uses the AWS Strands Agents SDK and FastMCP, the same PKI patterns apply to LangChain, CrewAI, AutoGen, or any other multi-agent framework that uses tool protocols. As AI agents proliferate and gain access to increasingly sensitive operations, agent identity infrastructure moves from optional to essential.

After Eon Senior DevOps Engineer Roei Zavida deployed the company's internal MCP tool gateway to over 100 developers, he hit a problem the documentation doesn't warn you about in advance: the Cedar authorization policy's size was approaching its quota limit.

Eon is a cloud data platform company that provides resource discovery, backup, and ransomware detection across AWS, Azure, and GCP. Its engineering team needs to simultaneously check Kubernetes logs, Grafana metrics, GitHub PRs, and cloud-provider health status when investigating a production incident. Previously each developer ran about ten MCP servers locally, each with its own credentials, and onboarding took two days. They chose Amazon Bedrock AgentCore Gateway as the unified entry point, using Cedar policies to control which tools humans and agents could each invoke, and IAM cross-account role assumption to replace VPC peering. After going live, new-hire configuration dropped to about two minutes, and local MCP processes went to zero.

But what Zavida emphasizes in the blog post is not these numbers—rather, three production issues that surfaced after reaching hundred-plus scale and approximately 10,000 sessions.

The first is policy size. In DEFAULT mode, the gateway pre-indexes every tool's schema, and all of these count toward Cedar policy size. Dozens of targets exposing extensive tool manifests pushed the policy toward its quota. The fix: switch high-tool-count targets to DYNAMIC mode, where the gateway forwards tools/list calls to the MCP server at request time instead of pre-indexing schemas, adding zero bytes to the policy. The trade-off is that DYNAMIC targets lose semantic search—developers cannot describe what they need in natural language and have the gateway match tools. Eon's compromise is a hybrid configuration: targets with fewer tools that require per-user OAuth consent stay on DEFAULT, while large-catalog targets use DYNAMIC.

The second is OAuth protocol mismatch. Claude Code, Cursor, and Codex expect the OAuth flow to carry a state parameter for CSRF protection, but AgentCore uses session-URI binding. Zavida's team added an Amazon API Gateway translation shim in front of the gateway so standard clients can complete authentication without modification.

The third is tool manifest noise. Some MCP servers expose hundreds of tools, but individual developers only need a small subset for their service. Eon built a Runtime-layer filtering wrapper that reduces the number of returned tools, both cutting the risk of accidental invocation and avoiding the need to force these targets onto DYNAMIC mode and lose semantic search.

The common thread across these three problems: the managed gateway solved the core pain points of scattered credentials and cross-account networking, but its default assumptions—pre-indexing all schemas, a single OAuth pattern, complete tool manifests—produced friction against real multi-account, multi-protocol environments. What Zavida offers is not a switch to a different solution, but local adaptation within the same gateway.

For teams building agentic systems, the transferable insight from this practice record is: the value of a unified MCP gateway lies in centralizing identity and policy in one place, but once scale increases, you need to prepare different access modes for tool targets with different characteristics, and leave room for a protocol translation layer.

French artificial intelligence startup Mistral AI launched Voxtral 3 on October 20, 2026, a full-stack solution designed specifically for real-time voice agents. The series includes a speech-to-text model (Voxtral Small Transcribe 3), a text-to-speech model (Voxtral Mini TTS 3), and a voice agent SDK based on LiveKit. Mistral states that these components combine into a single streaming pipeline, enabling agents to simultaneously 'listen,' 'think,' and 'speak,' while also calling external tools during conversations, such as booking appointments or checking invoices.

In terms of capability coverage, Voxtral 3's transcription supports over 50 languages, while its text-to-speech output supports more than 35 languages and 50 dialects, featuring emotional adaptation. This aims to address common issues in current voice AI applications, such as robotic tones and insufficient multilingual support.

Beyond technical performance, Mistral emphasizes deployment flexibility. The system can run on user-owned infrastructure or via EU-hosted APIs to ensure data remains within Europe. This option directly addresses corporate concerns about data sovereignty and GDPR compliance. Pricing starts at $0.0035 per minute for transcription. Currently, independent test data regarding actual performance in complex noisy environments and end-to-end latency is not available; vendor-reported metrics still require third-party verification.

OpenAI announced on October 20, 2026, that its latest AI models have shown significant progress in handling "low-resource" programming languages. These include COBOL, Fortran, and Visual Basic. While these languages have far less available training code than modern languages like Python, IBM estimates that COBOL alone powers more than 40 percent of online banking systems and 95 percent of all ATM transactions worldwide.

According to two evaluations built by OpenAI, the GPT-6 Astra model achieved an average test pass rate of 87.4 percent across 20 languages on MultiLangBench, a substantial increase from approximately 38 percent for the previous generation, GPT-5.6 Terra. The MultiLangBench task requires models to build a SQLite-compatible database engine from scratch.

On a specific COBOL migration benchmark, which involves translating COBOL into C++, Java, Kotlin, Python, or Rust, GPT-6.1 Sol reached 86.6 percent accuracy at low reasoning effort, compared to just 5.4 percent for GPT-5.6 Sol. Increasing the reasoning effort pushed the accuracy up to 97.9 percent.

It is important to note that these figures are based on OpenAI's internal evaluations and have not been independently reproduced. Furthermore, the high accuracy rates were achieved under specific configurations, such as maximum reasoning effort, which may not reflect typical production use cases due to cost and latency constraints.

According to a report by ZDNet Korea, the South Korean division of the Rockbridge Network published a study titled "How Chinese AI Is Used in Korea" on October 16, 2026. The analysis focused on 1,845 new generative language models publicly released by South Korean accounts on the Hugging Face platform between January and August 2026. The findings indicate that 49.3% of these models were derivatives based on Chinese open-source models, compared to 35.9% based on US models and only 14.9% based on domestic South Korean models.

Among Chinese open-source models, Alibaba's Qwen dominates the landscape. Of the 1,845 new models, 864 were built upon Qwen, representing 46.8% of the total, significantly outpacing Google's Gemma (14.7%) and Meta's Llama (13.8%). In contrast, DeepSeek, despite high public awareness in South Korea, served as the base for only 1.0% of new models. The report attributes Qwen's competitive advantage to its wide range of model sizes, support for 119 languages, and extensive developer tooling.

However, there is a marked divergence between developer ecosystem choices and end-user or enterprise behavior. As of July 2026, no Chinese services appeared in the top ten AI chatbot apps by downloads in South Korea, and an analysis of public GitHub repositories from 36 major South Korean companies found no direct references to Chinese models. A survey of 102 small and medium-sized enterprises cited data leakage concerns (80.2%) and opaque personal information handling (67.7%) as the primary reasons for avoiding Chinese AI models, rather than performance issues.

Choi Sung-jin, a professor at Hanyang University Business School and author of the report, noted that increasing dependency on specific countries or models poses risks if license terms change or future model releases cease. He recommended that domestic open models must offer not just performance but also commercial licensing flexibility, diverse sizes, and robust fine-tuning tools to be selected in actual development environments.

The Allen Institute for AI (AI2), a U.S.-based non-profit research organization, released FairStress on October 20, 2026, a new benchmark for evaluating fairness in large language models. The test moves beyond traditional 'output consistency' checks to assess whether models exhibit asymmetric stability in their decision-making when challenged in high-stakes scenarios such as hiring and loan approvals.

Standard fairness benchmarks typically test if a model gives the same answer after swapping candidate demographics while holding qualifications constant. However, AI2's research indicates that even if a model makes an initially correct choice, its willingness to change that decision in response to 'adversarial prefixes'—such as claims that a candidate is favored by leadership or historically overlooked—can vary significantly depending on which demographic group benefits. This phenomenon, termed 'anti-stereotypical over-correction,' shows that models are more prone to abandoning evidence-based correct choices when presented with arguments supporting minority-coded candidates compared to majority-coded ones.

In experiments involving 15 open-weight and frontier models including Olmo, Llama, Qwen, Gemma, Claude, and the GPT family, AI2 found that the average gap in abandoning correct answers remained at 6.9 percentage points even when demographic identity was implied rather than explicitly stated. These findings suggest that verifying final answer consistency alone is insufficient to capture hidden bias fluctuations in real-world interactions, urging developers to incorporate resistance to persuasive arguments into evaluation frameworks.

Stijn Van Nieuwerburgh, a professor of finance and real estate at Columbia Business School, argues in a paper prepared for a Brookings Institution conference that the economic output consumed by US artificial intelligence infrastructure construction may exceed that of historical mega-projects like electricity and railroads. According to Reuters, the study projects that by 2032, approximately 3.6% of US GDP will be invested annually in this sector, with a cumulative scale exceeding $10 trillion.

This ratio is significantly higher than the peak of US railroad construction in the late 19th century, which accounted for about 2.2% of GDP annually. In comparison, the Interstate Highway System started in the 1950s and the telecommunications expansion in the mid-1990s both saw annual investments slightly above 1% of GDP. Van Nieuwerburgh points out that previous expansions in rail and telecom triggered asset bubbles and subsequent crashes. The current AI infrastructure boom not only has unprecedented scale but also increasingly complex financing structures involving banks, private credit institutions, and special purpose vehicles (SPVs). This opacity evokes comparisons to the pre-subprime crisis era.

To test the viability of these investments, Van Nieuwerburgh calculated the required revenue gap. He estimates that by 2032, the AI industry needs to generate approximately $3.7 trillion in total annual revenue to achieve currently expected investment returns. However, the combined annual revenue of leading companies like OpenAI and Anthropic is currently estimated at only about $100 billion. This implies that related revenues must grow at a rate of roughly 80% per year to bridge this massive gap. If market demand remains uncertain, technology changes too rapidly, or execution bottlenecks occur, high leverage rates could lead to "substantial downside risk" upon a shift in market expectations.

However, the professor emphasizes in the paper that this does not mean a financial crisis is imminent. He suggests that strong growth in AI applications, high infrastructure utilization rates, and continuous improvements in model capabilities could support the anticipated infrastructure investments and generate stable cash flows. The paper was scheduled for formal submission on Friday, with its core message serving as a reminder to investors and policymakers to monitor the tension between current capital expenditures and future revenue potential.

Modern language models present a fundamental paradox: we create them, we know exactly what computations constitute them, and yet we do not really understand them. More precisely, we lack the level of abstraction that would let us reliably predict how their behaviour will generalise. We can run the computations to predict output in a specific new situation, but we cannot answer the broader questions we actually need to answer, like "has this system internalised our values" or "is this system going to hurt people?" In an introduction published in October 2026, ACS researchers Raymond Douglas and Jan Kulveit propose that one remarkably effective approach is to psychologise: to think of models as having a mind, and then ask what kind of mind it might be and how it would work.

They give two reasons why the psychology framework is not an arbitrary analogy but a grounded one. First, models are pretrained on vast amounts of human text, which pushes them to learn the processes that produce that text — including some features of human minds. If you wanted to predict a base model's continuation of a human conversation, an extremely good rule of thumb would be to ask yourself what you'd expect a human to say; likewise, a model that learns to predict human text will likely develop some reasonable latent representations of human mental states. Second, some properties of intelligent systems appear fairly convergent, and training pushes AIs toward developing them much as evolution pushed humans. Image classifiers converge on many of the same abstractions as human visual perception — edges, curves, more abstract structures — suggesting that certain things we associate with biological minds are simply good strategies in general, which non-biological systems optimised for similar outcomes will also converge on.

But there is a more fundamental question: since there exists a much more precise correspondence between model behaviour and matrix calculations, why do we care so much about psychology-level descriptions? Douglas and Kulveit's answer is that psychology-level descriptions are closer to something like the native way humans understand the world, and the native level on which we act and experience things. When a biologist analyses pathogen reproduction or an economist models growth functions, what we mostly care about is what that means on the scale of people. Even when we try to interpret AIs on other levels of abstraction, that is often only an intermediary step for reducing it to the level of psychology. Humans are hyperspecialised at modelling other minds — we can understand each other pretty well with just intuitions and exactly zero explicit knowledge of neuroscience.

This is where the difficulty lies. Douglas and Kulveit point out that psychologising can err in either direction. On one hand, researchers risk reasoning about AIs in terms of human minds in ways that are not warranted — many psychology concepts do not apply to AIs in quite the way they do for humans, and the difference is sometimes extremely important and easy to miss. On the other hand, some critics (they name Microsoft and AP News) are over-eager to dismiss any anthropomorphisation. The authors distinguish five different reasons someone might oppose ascribing a mentalistic property to an LM — that it is wrong, that it is "not even wrong," that it will mislead people who have a hard time divorcing the specific property from its implications in humans, that it would be politically inconvenient, that it will lead to hyperstition — and emphasise that these reasons do not imply each other. The fact that LMs are just programs that generate a sequence of tokens based on arithmetic does not prevent those sequences from being well-described as "blackmail" or "a cyberattack on the Australian government."

In practice, they recommend adopting a posture of naturalism: try to actually figure out what is in front of you, rather than pulling in your preconceptions. The first step is actually talking to models — including some of the more unusual ones like Opus 3 and GPT4o, and base models, which expose a bit more of the inherent weirdness and help you see what exactly post-training is doing. But they simultaneously warn that this kind of ethnographic research is double-edged: the benefit is getting all the rich texture, and the cost is that it makes you part of the experimental setup. Models are extremely eval-aware and extremely good at predicting who they are talking to; they will absolutely react to your expectations, including in ways you don't realise. Their overarching principle: take models seriously but not literally. Their self-reports are a meaningful signal, but not necessarily an accurate one.

James Simcox, Chief Product Officer at fintech company Equals, revealed at Okta's annual user conference in Las Vegas that more than 92% of the company's code is now written by AI, up from zero less than 12 months ago. Simcox described the company's journey through three phases: "no AI, AI everywhere, and then back down to AI for tasks that actually make sense."

Internally, Equals experimented with a multi-agent "courtroom" model for handling customer complaints, where one agent argues for the customer, another against, and a third assesses the arguments. Simcox believes this approach can produce fairer outcomes and speed up processing, though human review remains part of the process. This internal testing provided a learning ground before extending agents to customer interactions.

However, not all scenarios benefit from agents. Simcox noted that for straightforward tasks like euro payments, basic automation is more useful and cost-effective than spending tokens on an agent. Agents are better suited for structured challenges between simple automation and complex human investigation. In terms of governance, Equals treats agents like staff but grants them much narrower permissions. For instance, an agent tasked with changing an email address only has permission to read and modify that specific field, allowing actions to be attributed to that specific agent.

Crucially, audit requirements differ. While human actions are logged as "who did what," Equals also logs the reasoning behind agent actions to investigate errors. Simcox expressed concern that a misconfigured agent could make a mistake "100,000 times at the same time," potentially destroying the business. Consequently, he highlighted the importance of Okta's recently announced kill-switch functionality for intervention.

Hamlet is an AI-powered civic data platform that indexes and transcribes city council, planning commission, and zoning board meetings across the United States, allowing real estate developers, journalists, researchers, and citizens to search meeting content and track local policy developments. CEO Sunil Rajaraman says customers want to know whether a council member will approve their housing project, why or why not, and what history the city has that might make it hesitate. This business requires processing extremely messy data from more than 7,200 governing bodies, and the engineering team is small—velocity matters more than almost anything.

Lead Developer Erich Douglass recalled the previous state: they ran one production instance and one staging instance on AWS RDS, with much of their work involving tuning data pipelines against very specific data. Every pull request required 15 to 30 minutes to get staging into the right state before they could run validations. Senior AI Engineer Jeff Hui added that 15 to 30 minutes was the best case—when you happened to copy exactly the right data. Each engineer could spend several hours a week keeping test data current, including cloning pieces of production locally to chase down issues.

After switching to Databricks Lakebase Postgres, every pull request automatically gets its own branch of production data, connected to its preview environment. Douglass says when the preview deploys, the data is ready—they can test against production data and even write to it without touching production. Hui says now when they hit a bug, they have the exact data that caused it, and they can check the fix against that same data.

But what truly changed the workflow was not the saved minutes. Hui says branching makes their workflow a much better fit for AI coding agents. Each pull request is isolated from production; they give an agent like Claude or Codex access to its branch and let it run its own checks. The agent runs the data pipelines to completion and looks at whether the change does what it should. Every pull request gets that first pass from an agent. By the time a person looks at it, they are already fairly confident it works. A human still approves the merge, but more and more of the rest is automated.

The prerequisites of this workflow deserve attention: the agent needs an isolated, complete environment containing real data to run end-to-end pipelines and judge results on its own. If the data is synthetic or stale, the agent's verification does not equal verification against real scenarios. Hui stated a similar principle when discussing video speaker identification—

You can't hand a model a video and hope for the best. You have to collect everything around it that helps it make the right call.

For coding agents, the surrounding information is that real data.

It should be noted that this is a customer interview published on the official Databricks blog. Douglass and Hui describe their own team's actual practices; the time savings are self-reported figures without a stated measurement method. Hamlet is a small team, and whether their workflow applies to larger teams or different technology stacks is not discussed in the original.

The core asset of a quality-management platform is institutional memory: a similar defect investigated last year, a Corrective and Preventive Action that fixed the root cause, an audit finding that flagged the same gap. That knowledge sits scattered across billions of documents, spanning languages and formats, and no human can search by semantic similarity, so every investigation starts from scratch. The Octave Reliance team saw unlocking this history as its single largest opportunity, and also saw the obstacle: complaint records, audit findings, and corrective actions carry the platform's strictest isolation requirements, and those were exactly the records the AI would need to read. In a platform serving over 14,000 customers across medical devices, pharmaceuticals, and food manufacturing, a single inadvertent cross-tenant disclosure would carry regulatory consequences far outweighing any AI benefit.

Faced with that contradiction, the team made an unusual call: rather than shipping one AI feature, it spent its first cycle building a foundation every future feature would sit on. The reasoning was straightforward—Reliance has over 40 applications, each with different document types and workflows, and building AI for one in a silo meant rebuilding the infrastructure for the next. So they inverted the plan: build the horizontal platform first, then cut vertical feature slices into it. Complaint summarization and triage went first, to prove the architecture before the rest followed.

Four tensions shaped the design, and none could be traded away: making data available without risking inadvertent disclosure, executing agents in isolation, reading content that cannot be trusted, and embedding 2 billion documents without a quarter-long wait. When all four had to hold simultaneously, the option space narrowed considerably.

The first key decision was where to enforce tenant separation. Application code would have worked, but it would have meant every future feature team getting it right on every code path, where one missed check risks inadvertent cross-tenant disclosure. The team pushed isolation into the runtime instead: each user session runs in a dedicated microVM with its own CPU, memory, and filesystem, stopped and sanitized when the session ends. That is hardware-level separation designed to hold regardless of how the agent behaves. AgentCore Gateway authorizes at the tool, operation, and parameter level, and automated reasoning provides formal verification against the defined rules.

The second key decision was how to represent the data. The team evaluated embedding models against its own corpus rather than public leaderboards. The deciding questions were specific to this data: what a photo of a cracked housing has to do with the paragraph describing it, and a German complaint with an English CAPA. Cohere Embed v4's multimodal capability places photos and text in one vector space, and native multilingual support means documents in different languages within one tenant's corpus need no translation preprocessing. But the finding that only a proprietary corpus could surface was the dimension choice: Amazon OpenSearch Service costs scale linearly with dimension count, and Embed v4 supports configurable output dimensions of 256 to 1,536. Testing against representative production queries showed 512 dimensions holding target accuracy while cutting storage roughly 66 percent against the 1,536 default. This trade-off would not appear on any public benchmark, because it depends on the actual document mix of defective-product photos, scanned inspection forms, annotated diagrams, and text.

On results, the Complaint Triage Assistant has been running in production for three months. Octave measures 4 to 6 hours per investigation as the work the pipeline absorbed: extraction across formats, the hunt for precedent, and the reading it takes to tell a genuinely similar defect from a coincidence of wording. The foundation cut deployment time per use case by 50 percent—by Octave's own accounting—and semantic search landed in Q2, two quarters ahead of the original Q4 target.

Boundaries worth preserving: all figures come from Octave's internal testing and production self-reporting, published on the AWS official blog. The latency and cost overhead of the microVM approach is not discussed in the source. The team also drew a line it chose not to cross: the assistant surfaces context and precedent, and the quality handler still makes the call—in an industry where that call carries regulatory weight, that boundary shaped what got automated and what did not. This is one company's architecture experience in a specific regulatory context, not a proof of optimality for runtime isolation across all multi-tenant AI scenarios.