DEV Community: Aamer Mihaysi

The Agent Orchestration Layer Is Finally Here

Aamer Mihaysi — Wed, 29 Apr 2026 09:03:43 +0000

We've spent two years obsessing over model benchmarks. Meanwhile, a quieter shift has been happening: the realization that throwing more parameters at a problem isn't the same as building systems that can actually work together.

Sakana's Conductor is the clearest signal yet. A 7B model trained with reinforcement learning not to solve tasks directly, but to decide which agent should solve them. It reached 83.9% on LiveCodeBench and 87.5% on GPQA-Diamond—not by being smarter than the frontier models it orchestrates, but by being better at dispatching them.

The implications are uncomfortable for anyone who's built their architecture around single-model dominance. When a 7B parameter orchestrator can outperform individual 70B+ workers by routing queries intelligently, the economics of inference change completely.

Google's TPU split into training (8t) and inference (8i) variants reinforces this trajectory. When you start optimizing silicon specifically for inference workloads, you're acknowledging that the action has shifted from training massive models to deploying them efficiently at scale.

The question isn't whether multi-agent systems will dominate. It's whether your stack is built to route between them efficiently.

The orchestration layer is no longer theoretical. It's here, it's 7B parameters, and it's beating the frontier models at their own game.

The Browser Is Becoming an Agent Operating System

Aamer Mihaysi — Tue, 28 Apr 2026 09:03:42 +0000

The Browser Is Becoming an Agent Operating System

Chrome's AI Mode and Skills features mark a shift most developers haven't internalized yet. The browser isn't just adding AI features. It's becoming the runtime environment for agentic workflows.

Google's announcement of AI Mode in Chrome and the new "Skills" capability to turn prompts into one-click tools signals something larger than convenience features. The browser is evolving from a document viewer into an agent orchestration layer. This matters because it changes where intelligence lives in your stack.

Most agent architectures today assume the model lives somewhere else—OpenAI's API, your backend, a local inference server. The browser is treated as a dumb terminal. But Chrome's moves suggest a different model: the browser itself becomes the agent host, with local context, persistent memory, and tool-calling capabilities built into the chrome.

AI Mode transforms how users interact with web content. Instead of browsing passively, users can query, summarize, and act on information across tabs. The browser gains semantic understanding of what the user is looking at. This isn't just a chat overlay—it's the foundation for agents that can reason about web content in real-time.

Skills takes this further by letting users (and eventually developers) package prompts into reusable tools. A "Skill" in Chrome is essentially a lightweight agent with a specific purpose—research this company, compare these products, draft a response to this email. They execute with access to the current browsing context.

For developers building agentic applications, this changes the playing field. The browser becomes a competitor to your backend agent infrastructure, but also a potential platform to leverage.

The implications are concrete:

Context access: Chrome has access to cookies, browsing history, and on-page content that external agents can't easily replicate without complex OAuth flows and scraping infrastructure.
User trust: Users trust their browser more than random third-party agents. Chrome's built-in agents inherit that trust by default.
Distribution: Skills distributed through Chrome reach users where they already are. No installation friction, no new interface to learn.

But there are trade-offs. Chrome's agents run in Google's environment, subject to their rate limits, their model choices, their privacy policies. The Skills ecosystem will likely be as open as Chrome extensions—technically extensible, but gated by store policies and Google's priorities.

What this means for builders: if you're constructing multi-agent systems, the browser is no longer just a client. It's a first-class agent platform. Your architecture needs to account for agents that run locally in Chrome, agents that run in your backend, and how they coordinate.

The vision is clear. Chrome becomes the agent OS, Skills become the app store, and the line between browsing and task execution dissolves. For some workflows, this is ideal. For others—those requiring custom models, sensitive data, or complex coordination—you'll still need your own infrastructure.

The browser isn't dead. It's becoming something more interesting: the universal agent runtime.

MCP Is Quietly Becoming the USB-C for Agent Infrastructure

Aamer Mihaysi — Mon, 27 Apr 2026 09:03:53 +0000

MCP Is Quietly Becoming the USB-C for Agent Infrastructure

The most important infrastructure shifts don't announce themselves with keynotes. They happen when developers start reaching for the same tool without being told to.

MCP (Model Context Protocol) has crossed that threshold. What started as Anthropic's experimental protocol for tool calling is now the default wiring layer for agents across the ecosystem. The Hugging Face blog post on building a 70-line MCP agent isn't a tutorial. It's a signal that we've moved past the "what if" phase into "this is how you build."

Why This Matters Now

Tool calling isn't new. OpenAI's function calling API has been around for over a year. What's different is MCP's decoupling of capabilities from any single model provider. When you build on MCP, you're not betting on OpenAI's API format or Anthropic's specific implementation. You're building against a protocol.

This matters for production systems in ways that benchmark scores don't capture. I recently refactored a multi-agent orchestration layer from custom tool definitions to MCP servers. The reduction in interface boilerplate was dramatic—roughly 60% less code for tool registration and discovery. More importantly, agent teams can now swap underlying models without touching tool definitions.

The protocol's server architecture also changes how we think about capability distribution. Instead of monolithic agents with baked-in tool sets, you get composable capability servers. An agent doesn't need to know how to query your internal metrics database. It needs to know there's an MCP server that does, and it can discover that at runtime.

The Hidden Complexity

The 70-line agent examples are real, but they hide something important. The protocol itself is simple—JSON-RPC with streaming. What's not simple is the operational surface area MCP introduces.

Every MCP server is now a dependency with its own lifecycle, versioning, and failure modes. When your agent calls a tool, it's not just calling a function. It's making a network request to a potentially stateful service that might be down, slow, or returning unexpected schemas.

I've seen teams deploy MCP servers without proper health checking and get burned when agents hang on unresponsive tool calls. The protocol doesn't specify timeouts. It doesn't specify retry semantics. These are implementation details that become production requirements fast.

The Integration Pattern

What's emerging is a three-layer architecture: the agent runtime (the LLM and reasoning loop), the MCP client layer (protocol handling and server discovery), and the capability servers themselves. This mirrors how modern microservices work—loosely coupled, independently deployable, but with clear interface contracts.

The difference is the level of abstraction. Traditional microservices expose HTTP endpoints with documented schemas. MCP servers expose capabilities to language models, which means the interface needs to be discoverable not just by developers but by the models themselves.

This is where the protocol's "resources" and "prompts" primitives become interesting. They're not just for tools—they're for any context the model might need. A vector database becomes an MCP resource. A RAG pipeline becomes an MCP server. The boundary between "application code" and "model context" blurs in useful ways.

Where It Breaks

MCP isn't magic. The protocol handles the wire format, but it doesn't solve the hard problems of agent coordination. When multiple agents need to share state, MCP doesn't help. When you need transactional guarantees across tool calls, you're on your own.

There's also the question of discoverability at scale. The reference implementation uses stdio for local servers and HTTP for remote ones. In a production environment with dozens of capability servers, you need service discovery, load balancing, and circuit breakers. The protocol is silent on these concerns.

And then there's security. MCP servers run with the permissions of their host process. A compromised MCP server can exfiltrate data or misuse tools in ways the calling agent won't detect. The protocol doesn't specify authentication or authorization—it's transport-agnostic, which means security is implementation-specific.

The Bigger Picture

MCP's adoption is a symptom of a larger shift: agents are becoming infrastructure, not applications. We're moving from prompt engineering to system engineering, from single-model interactions to distributed capability networks.

The 70-line agent is possible because the heavy lifting—tool definition, schema validation, streaming response handling—has been factored into the protocol layer. This is what infrastructure progress looks like. The code gets smaller, but the system gets more complex.

For teams building production agent systems, MCP is worth adopting now. The ecosystem momentum is real—major frameworks are adding first-class support, and the server library is growing. Just don't mistake protocol simplicity for operational simplicity. The hard parts of distributed systems don't disappear because the wire format is clean.

The agents that win won't be the ones with the best prompts. They'll be the ones with the most reliable capability graphs, wired together with protocols that let them evolve without breaking.

DeepSeek V4: Million-Token Context That Actually Works

Aamer Mihaysi — Sun, 26 Apr 2026 00:02:15 +0000

DeepSeek V4: Million-Token Context That Actually Works

Most long-context models are benchmarks in search of a use case. DeepSeek V4 flips the script—it delivers 1 million tokens not as a spec-sheet checkbox, but as an operational reality you can actually deploy.

The breakthrough is not just the context length. It is how they got there without torching your inference budget.

The KV Cache Problem Nobody Talks About

Everyone wants to brag about context windows. Few mention that a naive 1M token implementation would need 83.9 GiB of KV cache per sequence using standard attention. That is not a deployment. That is a denial-of-service attack on your GPU memory.

DeepSeek's fix is a hybrid attention architecture that compresses the KV cache by nearly 9x. They use shared key-value vectors across layers, compressed KV streams, and sparse attention on compressed tokens. The sliding window for nearby context stays at 128 tokens—enough for local coherence without the memory bomb.

The numbers: at 1M tokens, V4 needs 9.62 GiB instead of 83.9. With FP4 index cache and FP8 attention, you get another ~2x reduction. That is the difference between works on an 8xH100 node and works on a single node period.

Two Models, One Architecture

V4 ships as Pro and Flash variants. The Pro runs 1.6T total parameters with 49B active per token. Flash scales down to 284B/13B. Both use the same attention architecture, both hit 1M context, both drop to 10 percent of the KV memory you would expect.

The pricing tells the story: Pro at $1.74/$3.48 per million tokens, Flash at $0.14/$0.28. That is not just aggressive pricing—it is a bet that long-context inference can be commoditized if you solve the memory bottleneck.

Why This Matters for Agents

Agent workflows are the stress test for context. A coding agent holding a 300K line codebase in context. A research agent tracking citations across 50 papers. A customer service agent with a year of interaction history.

These are not niche use cases. They are the core value proposition of agentic systems, and they have been blocked by context limitations that forced constant retrieval, reranking, and state fragmentation.

DeepSeek V4's compressed attention means you can keep state resident. No round-trips to vector databases mid-turn. No approximating what matters. Just the full context, available at inference time.

Independent benchmarks show V4 Pro leading open-weight models on agentic tasks—ahead of Kimi K2.6, GLM-5.1, and MiniMax-M2.7 on the GDPval-AA workbench. The Flash variant holds its own at 12x lower cost.

The MoE Efficiency Play

V4's 1.6T parameter count is misleading. With 49B active per token, you are not paying the full FLOPs bill. The key is the routing: DeepSeek uses learned hash routing derived from 2021 ParlAI work, refined through their MoE iterations since V2.

The result is inference throughput that does not collapse under load. Day-zero vLLM integration, MLX quants for Apple Silicon, and a checkpoint that fits on 8xB200s in mixed FP4/FP8. This is a model designed for production, not leaderboard farming.

The Geopolitical Shadow

There is a reason DeepSeek released both base and instruct versions under MIT license, with day-one support for Huawei Ascend chips. The technical achievement exists in a context of compute sovereignty—proving that state-of-the-art long-context models do not require NVIDIA-locked stacks.

Whether that independence narrative holds depends on whether Ascend 950 supernodes can actually scale this year. DeepSeek's own pricing hints at a 50 percent-plus drop once they do. But the architecture is portable enough that it is already running on Blackwell, MI355, and consumer Macs via quantization.

What I Would Actually Use This For

If you are building agents that need persistent, deep context—code review across repositories, legal analysis across case files, research synthesis across thousands of papers—V4 is the first open-weight model where the context window is not the bottleneck.

The hallucination rate on long-context retrieval is still there—about 94 percent on Omniscience benchmarks. The token burn on reasoning tasks is real—V4 Pro uses 190M output tokens on the AA Index versus Flash's 240M. But you can now test these tradeoffs empirically, because the infrastructure actually supports the experiments.

That is the shift. Long context moved from coming soon to ship it. The rest is just optimization.

GPT 5.5 Is a Workflow Takeover

Aamer Mihaysi — Sat, 25 Apr 2026 16:05:33 +0000

OpenAI bundled GPT 5.5 with a browser and terminal. Codex is now an operating system pretending to be a chatbot. Every frontier lab is converging on the same architecture: reasoning models wrapped in agent loops, armed with tools, and given million-token context windows. The efficiency gains are real - Codex uses 45% fewer tokens while scoring higher. But what should unsettle you is the enclosure. Every capability bundled is a decision you no longer make. The agentic era is not about giving you more power—it is about concentrating power in systems that anticipate your needs before you articulate them. Your workflow is the territory. The agents are the settlers.

Your Browser Is Becoming a Tool Factory

Aamer Mihaysi — Sat, 25 Apr 2026 12:03:58 +0000

Chrome's new "Skills" feature isn't just another way to save prompts. It's a fundamental shift in how we think about AI interaction — from conversational to instrumental, from asking to doing.

The premise is simple: take your best prompts, the ones that actually produce useful output, and turn them into one-click tools. No more retyping. No more forgetting the exact phrasing that worked. But the implications run deeper than convenience.

From Conversation to Composition

We've spent two years treating LLMs as chatbots. Ask a question, get an answer. The interface trained us to think in turns. But the most valuable AI workflows aren't conversational — they're compositional. You string together specific operations: extract structured data from this page, summarize it against these criteria, format it for that destination.

Chrome Skills formalizes this pattern. It treats prompts as functions, not messages. And that matters because functions can be composed, shared, and versioned in ways that chat history cannot.

This is where the browser's role gets interesting. Chrome isn't just adding AI features — it's becoming an operating environment for agentic workflows. Between AI Mode for exploration, Skills for automation, and the underlying agent infrastructure Google is building, the browser is positioning itself as the default runtime for AI-native applications.

The Tool Ecosystem Problem

There's a pattern emerging across AI platforms. Everyone wants to be the place where tools live. OpenAI has GPTs. Anthropic has Projects. Now Chrome has Skills. The strategy is clear: lock in the workflow layer, and the model layer becomes interchangeable.

But this creates fragmentation. A Skill in Chrome isn't portable to Claude. A GPT doesn't run in your browser. We're building siloed tool ecosystems at exactly the moment when interoperability matters most.

The MCP (Model Context Protocol) momentum suggests the industry recognizes this. When Hugging Face publishes "Tiny Agents in Python: a MCP-powered agent in ~70 lines of code," they're making a statement: tools should be protocol-based, not platform-specific. Chrome Skills is the opposite bet — a proprietary format optimized for Google's ecosystem.

What This Means for Builders

If you're building AI products, Chrome Skills changes the competitive landscape. Your users might not need your dedicated extension if they can replicate the core workflow with a Skill. The bar for standalone browser extensions just went up.

But there's also an opportunity. Skills are limited to what Chrome's AI can do on a page. They can't orchestrate across multiple sites with authentication, can't maintain state across sessions, can't integrate with backend systems. The gap between "simple page automation" and "real agent" remains wide.

Smart builders will treat Skills as onboarding, not competition. Let users experience the value with simple one-click tools, then graduate them to your full agent when they hit the limits. Chrome just created a new top of funnel.

The Interface Question

There's a deeper question here about how humans should interact with capable AI. Chat interfaces democratized access but capped sophistication. The moment you need to do something complex, you're either writing pseudo-code in natural language or giving up.

Skills represent a middle path — curated automation with guardrails. They're less flexible than raw prompting but more reliable. Less powerful than full agent frameworks but more accessible.

This tradeoff matters for adoption. Most users won't learn to write system prompts or chain API calls. They might, however, click a button that says "Summarize this contract and extract key dates." Skills meet users where they are.

Looking Forward

The trajectory is clear. Chrome will keep absorbing AI capabilities that used to require extensions or separate applications. The browser becomes the shell, AI becomes the runtime, and Skills become the executable format.

The risk is monoculture. If Chrome owns the tool layer, they own the distribution of AI value on the web. Mozilla and Safari aren't building comparable ecosystems. The open web's diversity advantage erodes when one browser controls the AI tool marketplace.

For now, Skills is a useful feature with strategic implications. Use it for workflows that don't need portability. But keep an eye on MCP and other protocol-level standards. The platforms that win won't be the ones with the best isolated tools — they'll be the ones that play nicest with everything else.

Chrome just raised the stakes. The browser wars are entering their AI phase.

DeepSeek V4's Real Innovation Isn't Scale—It's Memory Architecture

Aamer Mihaysi — Sat, 25 Apr 2026 08:03:58 +0000

The announcement of DeepSeek V4 landed with predictable fanfare about parameter counts and benchmark scores. 1.6T parameters, 1M token context, competitive with GPT-5.4 and Opus 4.7. But the headline numbers obscure something more significant: this is the first open-weight model that makes million-token context actually usable for agents.

Not theoretically. Actually.

The difference lies in KV cache compression. At 1M tokens, DeepSeek V4 requires 9.62 GiB of memory per sequence in BF16. Compare that to DeepSeek V3.2's 83.9 GiB—a nearly 9x reduction. Achieved through what they call Compressed Sparse Attention (CSA) and Heavily Compressed Attention (HCA), alternating layers that apply different compression ratios: 4x for nearby context, 128x for distant tokens, with shared key-value vectors and top-k sparse attention over compressed representations.

This matters because long-context has been the domain of demos, not production. Everyone claims to support 1M tokens. Almost nobody can afford to use them.

The economics are brutal. Standard attention scales quadratically with sequence length. A 1M token context with naive implementation doesn't just need more memory—it needs memory that grows exponentially relative to the useful work being done. Most agent systems I've seen that claim unlimited context are actually doing aggressive summarization, sliding windows, or external retrieval. Workarounds for a problem that should've been solved at the architecture level.

DeepSeek's approach is different. By compressing distant tokens aggressively while keeping local context precise, they're acknowledging something obvious that architecture papers often miss: not all tokens are equally important for all operations. An agent reading a codebase doesn't need full attention to every token of a file it glanced at 800k tokens ago. It needs to know the file exists, what it roughly contains, and where to look if details matter.

The hybrid structure—sliding window for local attention, sparse attention over compressed global context—mirrors how working memory actually functions. You have high-fidelity access to recent context, fuzzy but searchable access to older information, and the ability to zoom in when needed.

What's striking is the FP4 quantization on expert weights. At 1.6T parameters, DeepSeek V4 Pro is a MoE model with only 49B active per token. The checkpoint stores expert weights in 4-bit precision, attention and router weights in FP8. The full model fits on a single 8xB200 node. This isn't just efficient—it's deployable.

For agent builders, this changes the constraint set. Previously, long-context agents required either expensive infrastructure or architectural gymnastics: chunking documents, maintaining external vector stores, complex retrieval pipelines. Each workaround added latency, failure modes, and code complexity. The promise of DeepSeek V4 is that you might not need them.

Consider a coding agent working across a large repository. With 1M token context that fits in under 10GB of KV cache, the entire codebase can sit in context simultaneously. Not summaries. Not embeddings pointing to files. The actual code, with full attention available when needed and compressed but present when not.

The implications for multi-agent systems are equally significant. Agents communicating through shared context rather than message passing. Long-running workflows where state persists without external databases. Systems that maintain coherence over thousands of turns without the gradual drift that comes from context window truncation.

DeepSeek released both Base and Instruct versions under MIT license, which suggests they understand the ecosystem play. The model is already supported in vLLM day-zero, with MLX quants available for Apple Silicon. The Flash variant—284B total, 13B active—runs on 256GB Macs. This isn't a research artifact; it's infrastructure.

There are caveats. The architecture is complex enough that few labs can replicate the training. Token usage can be high, so per-token pricing doesn't tell the full cost story. And while the benchmarks are competitive, they're not frontier-leading across the board.

But for agent memory specifically, DeepSeek V4 establishes a new baseline. It demonstrates that long-context doesn't have to mean inefficient context. That million-token windows are achievable with compressed attention rather than infinite hardware budgets.

The models that follow will likely adopt similar hybrid attention patterns. The research direction is clear: context length matters, but only if you can pay for it. DeepSeek just made the price much more reasonable.

For builders working on agents, this is the signal to reconsider your memory architecture. If you built elaborate RAG pipelines to work around context limits, DeepSeek V4 suggests those constraints might be temporary. The future of agent memory looks less like database design and more like selective attention—precise where it matters, compressed where it doesn't, and finally, actually long enough to be useful.

Chrome's AI Mode Isn't a Feature—It's a Platform Play

Aamer Mihaysi — Sat, 25 Apr 2026 00:04:18 +0000

Chrome's AI Mode Isn't a Feature—It's a Platform Play

Google just turned the browser into an agent operating system. Not with a press release about "intelligence" or vague promises about the future. They shipped AI Mode in Chrome, and that changes how the web works.

Most people will miss what actually happened here. They'll see a smarter search box, maybe some summarization, and assume it's another incremental upgrade. It's not. Chrome now hosts a persistent reasoning layer that can see what you see, understand the structure of any page, and take actions across the web on your behalf. That's not a feature. That's infrastructure.

The web was built for human consumption. HTML, CSS, JavaScript—all of it assumes a person is sitting there, reading text, clicking buttons, filling forms. Agents don't work that way. They need structured information, clear affordances, and predictable state transitions. The mismatch has been the central friction in agent deployment: you can build something powerful, but it breaks the moment it hits the real web.

Google's answer is to stop treating the browser as a neutral container and start treating it as the runtime. AI Mode isn't an extension or a side panel. It's integrated at the navigation layer, which means it can intercept requests, modify behavior, and maintain session state across sites. This is the kind of deep integration that only a browser vendor can achieve—and Google is the only one with enough market share to make it matter.

The immediate use cases are obvious. Research that would have taken twenty tabs and three hours now happens in a single conversation. Shopping comparisons happen automatically, with the agent navigating multiple retailers, extracting pricing and availability, and presenting synthesized options. Forms fill themselves based on context, not just stored data. These aren't demos. They're capabilities that work at scale because they sit at the platform layer.

But the strategic implication is bigger. Chrome has just become the default agent runtime for the entire web. If you're building an agent today, you face a choice: try to operate across the messy, unstructured surface of the web, or build for Chrome's AI Mode and get structured access to every page your users visit. The second path is easier. The first path is becoming impossible.

This is how platforms absorb innovation. Not by building every application themselves, but by making the underlying infrastructure so compelling that applications have no choice but to build on top of it. Microsoft did it with Windows. Apple did it with iOS. And now Google is doing it with Chrome, except the platform isn't the OS—it's the browser itself.

The timing matters. We're in the middle of a shift from chat interfaces to agentic systems. ChatGPT proved people want to talk to AI. But chat is limited. It's text in, text out, with no connection to the world. The next phase is agents that can actually do things: book flights, manage subscriptions, negotiate with customer service. Those capabilities require web interaction, and web interaction at agent speed requires platform integration.

Google has been slower than OpenAI on raw model capability. GPT-5.5 and Claude Opus dominate the benchmarks. But benchmarks aren't the game anymore. Distribution is. And Chrome has three billion users. When your agent runtime ships with the default browser, you don't need to win on model quality—you need to be good enough that developers build for your platform instead of fighting the open web.

There will be pushback. Privacy advocates are already asking what it means for Google to have an AI layer between users and every website they visit. Regulatory questions will follow, especially in Europe, where platform power is under constant scrutiny. And there's a genuine tension here: the same integration that makes agents work better also concentrates more control in Google's hands.

But the trajectory is clear. The web isn't getting simpler. Sites are more complex, authentication more fragmented, and user expectations higher. Operating agents on that surface without platform support is like building a mobile app before there were smartphones—technically possible, economically irrational.

What this means for builders is straightforward. If you're developing agentic systems, you need to understand Chrome's AI Mode as a target platform, not just a user preference. The APIs will evolve, the capabilities will expand, and the integration will deepen. The web you built for is becoming a runtime environment, and the browser is the OS.

The rest of the industry has to respond. Microsoft has Edge and OpenAI partnership. Apple has Safari and on-device intelligence. But neither has the combination of browser dominance, web index depth, and model integration that Google just activated. The next year will determine whether this becomes a true platform war or a settled standard.

For now, the shift is already live. Millions of users are interacting with the web through an AI intermediary and not noticing the transition because it feels like a better version of what they already had. That's the hallmark of infrastructure change: it happens underneath the application layer, reshaping possibilities before most people recognize the ground has moved.

The browser wars are back. But this time the prize isn't where people navigate—it's who controls what navigation means when humans aren't doing it themselves.

Your Browser Is Becoming an Agent Operating System

Aamer Mihaysi — Fri, 24 Apr 2026 20:02:01 +0000

The browser isn't just becoming an AI interface. It's becoming an agent operating system.

Google's recent flurry of Chrome announcements—Skills that turn prompts into one-click tools, AI Mode for web exploration, and continued investment in on-device models via Transformers.js—aren't isolated features. They're components of a larger architectural shift. The browser is evolving from a document viewer into a runtime for autonomous agents. And this matters more than most infrastructure discussions because it determines where agent code lives, how it persists, and who controls the boundaries.

Most agent discourse focuses on models and APIs. But the runtime question is equally consequential. When an agent needs to interact with the web, check a calendar, or fill a form, it needs an execution environment. The cloud is one option. The browser is becoming another—and it has structural advantages that cloud sandboxes can't replicate.

The case for browser-native agents

Chrome Skills represent a primitive but important abstraction: user-defined agent capabilities as first-class browser entities. Save a prompt, give it a name, invoke it from the address bar. This blurs the line between user action and automated execution. It's also a data capture mechanism—Google learns which workflows users want to automate before building native features.

AI Mode goes further. It transforms the browser from a passive container into an active participant in web navigation. The model doesn't just read pages; it reasons about them, extracts structured information, and maintains state across sessions. This is essentially a lightweight agent harness built into the browser itself, complete with the security model and user identity that Chrome already manages.

The missing piece was compute. Cloud APIs are expensive and latent. On-device models—enabled by Transformers.js and similar frameworks—change the economics. A small model running in a browser extension can handle classification, extraction, and simple reasoning without a network round-trip. For many agent workflows, that's sufficient. For the rest, the browser can orchestrate calls to larger cloud models while keeping the control loop local.

Why this pattern wins

Browser-native agents inherit several properties that cloud agents must reconstruct:

Identity: The browser already knows who the user is. OAuth flows, cookies, and session management are solved problems.
Security: The same-origin policy and sandboxing provide isolation primitives that would require significant engineering to replicate elsewhere.
Persistence: LocalStorage, IndexedDB, and extension storage give agents memory that survives page refreshes and browser restarts.
Observation: The browser can see everything the user sees. It has access to the DOM, network requests, and user interactions without requiring OS-level permissions or screen scraping.

These aren't minor conveniences. They're fundamental capabilities that determine what agents can realistically do. A cloud agent trying to interact with a web application needs either brittle screen automation or API integrations that don't exist. A browser-native agent can simply use the page.

The infrastructure implications

If browsers become the primary agent runtime, the infrastructure stack shifts. Instead of provisioning VMs or containers for agent execution, developers build browser extensions and web apps that host agent logic. The deployment target changes from servers to browsers.

This has downsides. Browser agents are limited by the same-origin policy, content security policies, and the capabilities exposed by extension APIs. They can't easily interact with desktop applications or local files. But for the vast majority of knowledge work that happens in web apps, these constraints are acceptable tradeoffs for the integration benefits.

The deeper shift is in control. Cloud agents run on infrastructure the user doesn't own. Browser agents run on the user's device, with visibility into their execution. For enterprise deployments where auditability and data residency matter, this is a meaningful difference.

What comes next

We're likely to see three converging trends:

First, browser vendors will expose more agent-oriented APIs. The Chrome announcement about Skills is a toe in the water. Expect richer capabilities for agent observation, action, and persistence as the category matures.

Second, the distinction between browser extensions and agent frameworks will blur. Tools like Transformers.js already let extensions run models locally. The next step is standardizing how these components communicate—essentially a protocol for browser-based multi-agent systems.

Third, enterprise agent deployment will increasingly favor browser-native patterns where possible. The compliance and security benefits are real, and the performance gap between on-device and cloud models is narrowing for many tasks.

The browser won the document era by being the universal client. It's positioned to repeat that victory in the agent era—not because it's the best possible runtime, but because it's the runtime everyone already has. The infrastructure investments we're seeing from Google suggest they understand this clearly. The question for developers is whether to build for the browser-native future or continue treating it as a display layer while running agents elsewhere.

The answer increasingly favors the browser as the agent OS. Not because it's perfect, but because it's present.

Coding Agents Are Breaking Containment

Aamer Mihaysi — Fri, 24 Apr 2026 16:03:11 +0000

Coding agents were supposed to stay in their lane. Write some functions, refactor a module, maybe generate a test suite. But the latest moves from OpenAI and the broader ecosystem suggest something different: the containment is breaking. Coding agents are becoming general computer-use agents, and the infrastructure we're building for them is revealing what the next phase of AI actually looks like.

The GPT-5.5 announcement was easy to dismiss as an incremental model update. Better benchmarks, improved token efficiency, another point release. But look at what shipped alongside it: Codex with browser control, OS-wide dictation, auto-review mode, and the ability to iterate through web apps by capturing screenshots and clicking through flows. This isn't a coding tool anymore. It's a computer-work agent that happens to write code when code is the right interface.

The technical community has been debating whether "agentic" is just marketing. The evidence is stacking up that it's something more specific: agents are becoming orchestration layers over heterogeneous tools and models, not single-model loops with tool access. Sakana's Fugu launch, Hermes Agent's rapid provider expansion, LangChain's Fleet skills - all point to the same architectural shift. The hard problem isn't calling tools. It's managing state, context, and workflow across multiple models and environments with different failure modes.

DeepSeek's V4 Preview drop the same day as GPT-5.5 wasn't coincidence. A 1.6T parameter model with 1M context window, MIT license, and aggressive pricing ($0.14 per million tokens for Flash) represents a different kind of disruption. Not just open weights, but open weights designed for agentic workloads with thinking/non-thinking modes and day-zero vLLM support. The inference optimization race - vLLM, SGLang, custom kernels - is being driven by the assumption that agents will consume tokens at rates that make current serving economics unsustainable.

The browser is becoming the primary battleground. When Chrome ships "Skills" that turn prompts into one-click workflows, and Google positions AI Mode as a new way to explore the web, they're acknowledging what Cursor and Cognition already proved: the IDE was just the beachhead. The real opportunity is any context where a human currently performs multi-step reasoning across multiple applications. Code just happened to be the first domain with clean feedback loops and verifiable outputs.

What's striking is how fast the infrastructure assumptions are shifting. Stateless decision memory replacing mutable per-agent state. Event sourcing for auditability. Horizontal scaling through immutable logs rather than locked sessions. These aren't academic concerns - they're responses to production failures when agents run overnight, consume thousands of dollars in API credits, and need to be resumed or debugged after hardware failures or rate limits.

The "dark factory" concept - zero-human-review coding - is approaching faster than most engineering organizations are prepared for. When GPT-5.5 Pro hits 82.7% on Terminal-Bench 2.0 and Claude Code is generating billions in ARR, the question isn't whether models can write code. It's whether our verification and testing infrastructure can keep up with models that write and ship without human gates.

The convergence is clear: coding agents, browser agents, and general computer-use agents are collapsing into a single category of system. The specialization that made coding agents tractable - deterministic feedback, clear success criteria, bounded scope - is being generalized through better memory, longer context, and more sophisticated harnesses. The infrastructure patterns that emerge from this transition - sandboxes, skills as minimal packages, event-sourced agent state - will define the next decade of AI systems architecture.

The labs are betting that the superapp isn't a product category. It's a mode of interaction. Codex becoming OpenAI's "desktop superapp" isn't about capturing the IDE market. It's about establishing the primitives for how agents interact with computing environments at large. The companies that own those primitives - the sandboxes, the skill registries, the agent-to-agent protocols - will shape what the next generation of software actually looks like.

We're not just watching models get better. We're watching the definition of "software" expand to include systems that write, execute, and modify other software on their own. The containment isn't just breaking. It was always a temporary boundary, and what's emerging on the other side is the actual architecture of agentic computing.

Million-Token Contexts Are Changing the Agent Programming Model

Aamer Mihaysi — Fri, 24 Apr 2026 12:02:55 +0000

Most agent infrastructure discussions treat context windows as a capacity problem—how much text can we stuff into the model before hitting the limit. DeepSeek-V4's million-token context and Google's agentic-era TPUs suggest we've been framing the wrong question entirely. Context isn't a constraint to optimize around. It's becoming the primary compute surface where agents actually live and work.

The shift is subtle but architectural. Current agent patterns treat the LLM as a reasoning engine that occasionally reaches out to tools. The agent orchestrates, the model thinks, the tools execute. But when your context window holds an entire codebase, weeks of conversation history, and multiple active workstreams, the boundary between "reasoning" and "environment" dissolves. The agent stops being a conductor and becomes the room itself.

This changes how we build. Traditional agent memory systems—vector databases, knowledge graphs, retrieval pipelines—are sophisticated workarounds for a problem that only existed because context was scarce. We externalized memory because we couldn't keep it resident. DeepSeek's 1M tokens at aggressive pricing, combined with Google's TPU specialization for long-context inference, means external memory hierarchies may become optional rather than mandatory. The database doesn't disappear, but its role shifts from primary storage to archival backup.

The implications for agent architecture are significant. Current production agents spend substantial complexity budget on context management—chunking strategies, relevance scoring, compression heuristics. When context becomes effectively unbounded, that complexity budget gets reallocated to behavior definition. Instead of engineering how the agent remembers, we engineer what it prioritizes. This is a different class of problem, closer to attention mechanism design than database schema.

Google's TPUs for the "agentic era" are telling here. The marketing framing is instructive—not faster inference, not cheaper training, but specialized silicon for agents. The hardware bet is that agent workloads look different enough from batch inference to justify dedicated architecture. Longer sequences, more complex attention patterns, stateful execution across extended sessions. The TPU evolution suggests the industry is preparing for agents that maintain coherence over hours, not seconds.

OpenAI's Codex positioning as a "superapp" reinforces the pattern. The browser control, spreadsheet integration, and persistent workspace aren't feature creep—they're environment expansion. Codex isn't trying to be a better coding assistant; it's trying to be the container where work happens. The million-token context is the enabler. You can't meaningfully orchestrate across browser tabs, code repositories, and document editors if you're constantly losing context to token limits.

The critical question for infrastructure builders is whether this shifts the competitive surface. If context becomes the primary resource, then context efficiency—tokens per dollar, tokens per watt—becomes the metric that matters. DeepSeek's aggressive pricing on V4-Flash ($0.14 per million input tokens) isn't just price competition; it's a bet that context abundance changes the economics of agent design. When tokens are cheap, agents can be stateful by default. When tokens are expensive, agents must be stateless and retrieval-heavy. The infrastructure implications diverge significantly.

There's a second-order effect on agent reliability. Current systems fail at context boundaries—handoffs between sessions, recovery from interruptions, maintaining consistency across tool calls. These aren't algorithmic failures; they're architectural artifacts of context scarcity. When the agent's entire working memory persists in-context, failure modes simplify. The agent doesn't forget what it was doing because the context window doesn't flush. Recovery becomes continuation.

This doesn't mean external memory disappears. Even million-token contexts have limits when dealing with enterprise-scale data. But the role changes. External systems become cold storage, not hot paths. The agent queries them when needed, but lives primarily in-context. The latency profile shifts from "always retrieve" to "retrieve rarely, but deeply when you do."

The hardware-software co-design is notable. DeepSeek's V4 achieves its context efficiency through what they call "hybrid attention mechanisms"—effectively algorithmic compression that maintains expressiveness without quadratic cost. Google's TPUs implement similar optimizations at the silicon level. The convergence suggests the industry is settling on architectural patterns: sparse attention, stateful KV-cache management, and inference-time tradeoffs between depth and breadth.

For practitioners, the practical shift is in how we think about agent state. Current best practices emphasize statelessness—agents that can resume from any point because they don't depend on accumulated context. This is robust but limiting. As context windows expand, "stateful by default" becomes viable. Agents can maintain running hypotheses, track implicit dependencies, and build cumulative understanding across extended sessions. The design patterns resemble operating systems more than function calls.

The risk is overcorrection. Million-token contexts don't eliminate the need for careful memory management; they change its form. Unbounded context can accumulate noise, reinforce errors, and create path dependencies that shorter contexts would have naturally flushed. The engineering challenge shifts from "how do we fit more in" to "how do we keep only what matters." Garbage collection for agent cognition.

What's emerging is a new layer in the infrastructure stack. Below the model, we have compute (GPUs, TPUs, custom silicon). Above the model, we have tools and APIs. But the context window itself is becoming a distinct layer—a persistent, addressable space where agents maintain presence. The winners in this space won't just be model providers or tool builders, but the platforms that manage context lifecycle: compression, prioritization, archival, and retrieval.

The DeepSeek-V4 launch and Google's TPU announcements aren't incremental improvements. They're signals that the agent infrastructure conversation is moving from "how do we work around context limits" to "what do we build when context is abundant." That's a different design space entirely, and most current agent architectures are optimized for the wrong scarcity.

The million-token context isn't just more memory. It's a different programming model. Treat it as such, or get outcompeted by those who do.

Agent Labs Are the Infrastructure Pattern Agents Actually Need

Aamer Mihaysi — Fri, 24 Apr 2026 08:02:44 +0000

The infrastructure layer for autonomous agents is crystallizing around a new pattern: agent labs. Not research labs, but production environments purpose-built for agents that write code, browse the web, and execute tasks with minimal human supervision.

OpenAI's Codex relaunch as a "superapp" signals this shift. By folding browser control, document editing, and OS-wide dictation into a single workspace, they're betting that the future interface isn't chat—it's an agent Operating System. The model becomes the runtime. Everything else is scaffolding.

This mirrors what I'm seeing in production systems. The teams building serious agent infrastructure aren't asking "which model should we use?" They're asking "how do we give our agents a proper environment to work in?" The answer looks less like API wrappers and more like sandboxes: isolated compute with persistent state, session management, and tool access that agents can discover and invoke.

The Latent Space podcast recently crystallized this as the "Agent Labs" thesis. Start with frontier models, specialize for your domain, then train your own once you have enough workload and behavioral data to justify the cost. Cursor and Cognition both follow this playbook—bootstrap on general-purpose models, then distill down to domain-specific variants that are faster and cheaper without sacrificing task-specific quality.

What makes this different from traditional ML engineering is the feedback loop. In classical ML, you collect data, train, deploy, and monitor. In agent labs, the agent itself generates the training data through execution. Every task completion, every tool call, every correction becomes signal for the next iteration. The model improves not just from human labels but from its own trace history.

This creates infrastructure requirements that most teams underestimate. You need telemetry that captures not just inputs and outputs but the full execution graph: which tools were considered, which were called, what the intermediate states looked like, where the agent stalled or failed. You need eval harnesses that can replay agent trajectories against new model versions. You need sandboxes that can spin up isolated environments, run arbitrary code, and tear them down without leaking state between sessions.

The browser is becoming the default agent workspace for a reason. It's where most work already happens. But browser automation is brittle—DOM selectors break, rate limits kick in, CAPTCHAs appear. The next generation of agent infrastructure abstracts this behind semantic interfaces: "book a flight" rather than "click the search button at coordinates (x,y)." This requires either deep integration with service APIs or models that can reliably interpret visual interfaces and adapt when they change.

Google's TPU announcements this week—specialized chips for the "agentic era"—underscore the compute shift. Agents burn tokens differently than chat. Long-horizon tasks mean extended context windows, frequent tool calls, and speculative execution where the agent might explore multiple paths before committing. This isn't batch inference; it's interactive compute with tight latency requirements.

The emerging stack looks like this: frontier models for reasoning, domain-specific fine-tunes for common workflows, sandboxed execution environments, tool registries that agents can query, and trace databases that feed back into training. Orchestration moves from simple chains to dynamic planning—agents that can pause, reconsider, and resume based on intermediate results.

What I'm watching now is whether this infrastructure consolidates around a few platforms or fragments across verticals. OpenAI wants to own the superapp layer. Cloud providers want to own the compute substrate. Startups are racing to own the vertical-specific harnesses—Devin for engineering, specific tools for finance, healthcare, legal.

The teams that win won't be the ones with the best models. They'll be the ones with the tightest loops: fastest time from agent execution to model improvement, richest telemetry, most reliable sandboxes. Model performance is becoming table stakes. The differentiator is how quickly you can turn agent behavior into better agent behavior.

If you're building in this space, the question to ask isn't "can my agent write code?" It's "what happens after it writes the code, when it needs to test, debug, and deploy?" The answer requires infrastructure we barely have names for yet.