Most engineering teams I talk to can ship an AI demo. The prototype works, stakeholders are impressed, and everyone agrees the use case has potential. Then the project hits a wall.

The reasons for this can vary, but new research shows that difficulties in collecting and parsing real-time data from multiple sources are often the problem. And it’s compounded by a growing skills shortage.

“Only 32% of organizations report having agentic AI running in production.”

According to Confluent’s 2026 Data Streaming Report, only 32% of organizations report having agentic AI running in production. At the same time, two-thirds of respondents cited data infrastructure and data quality as barriers to the success of agentic AI. The models work in controlled conditions, but production is a different story.

Why the demo-to-production gap is so wide

Demos tend to work because everything around them is controlled. The data is static and curated carefully to support exactly what the model will be asked to do. Production environments don’t always offer those luxuries.

In production, AI systems have to query data that lives across dozens of sources, including databases, event streams, application logs, and third-party feeds. Much of that data is poorly governed, and little of it is designed to be consumed by an AI agent in real time. Models that looked impressive in pilots return unreliable results because they’re working with stale, incomplete, or uncontextualized data.

The instinct is to tune the model, but the problem is more likely to be the data feeding it.

In the report, 72% of IT leaders cited insufficient infrastructure for real-time data processing as a barrier to scaling AI, up from 61% the year before. That increase suggests the problem isn’t going away; it’s getting more visible as teams move projects into production.

“The instinct is to tune the model, but the problem is more likely to be the data feeding it.”

AI systems need data that’s trustworthy, contextualized, and current, and those properties are hard to guarantee when data is sitting in siloes that weren’t built for continuous consumption. Batch pipelines almost always introduce latency, lack formal data contracts, and obfuscate lineage. The AI system ends up working with an inconsistent, partial snapshot of the business instead of what’s actually happening now.

The skills problem makes this harder

The report reveals another challenge: 71% of IT leaders cited a shortage of relevant expertise and skills as a barrier to AI adoption. 

The work of application development has shifted from encoding business logic to creating an information environment where automated systems can learn and generalize.  Building reliable AI applications requires developers to be stronger data engineers. They need to understand distributed systems, streaming architectures, data quality controls, and how to build pipelines that hold up under real-world conditions. They need to reason about data lineage, schema evolution, and what happens when an upstream source changes. And the QA patterns that work for deterministic software — where the same input yields the same output — don’t transfer to probabilistic systems.

Most developers haven’t had to think this way before. The discipline of getting the right data to the right system at the right time, in a governed and reusable way, has gone from a specialist concern to a requirement for anyone building production AI.

This affects how organizations should think about closing the demo-to-production gap. The investment in data engineering skills needs to keep pace with the investment in AI itself.

What production-ready AI actually requires

Organizations that make it out of the pilot stage treat data infrastructure as a first-class concern from the start. That means building real-time pipelines rather than batch processes. It means applying schema definitions, ownership metadata, and quality checks at the point of data production rather than in the data lake. And it means structuring data as reusable products that different teams and applications can build on, so the engineering work supporting one AI application can accelerate the next one, rather than starting from scratch.

The 2026 report found that 88% of IT leaders said data streaming platforms help address data infrastructure and quality issues for agentic AI. That’s because they address the specific reasons AI projects stall — real-time data delivery, upstream governance, and making data trustworthy enough to use at inference time.

The shift is already happening

For the first time, the report found that investments in data streaming outranked those in AI and machine learning, by 88% to 82%. Organizations that have tried to ship production AI are increasingly recognizing that the model isn’t the hardest part. 

“For the first time, the report found that investments in data streaming outranked those in AI and machine learning, by 88% to 82%.”

So if you’re stuck at the pilot stage, resist the urge to keep optimizing the model. A better question is whether the data feeding the model is fresh, accurate, and well-governed, and whether your pipelines were actually built for production AI or a demo that only had to work once.

The post The impressive AI demo is dead. Here’s what actually reaches production appeared first on The New Stack.

Meta is preparing to manufacture its own AI chip for the first time. According to an internal memo, the company expects production of its proprietary processor, Iris, to begin in September.

After clearing bug testing in about six weeks, the chip — reported on by Reuters — is expected to take on some of the inference work currently running on third-party GPUs, giving Meta more control over how it builds and scales its AI infrastructure.

It’s unmistakable that this could be the company’s most important move yet toward in-house silicon for AI workloads.

But anyone can see this isn’t really about the hardware. It’s unmistakable that this could be the company’s most important move yet toward in-house silicon for AI workloads. The timing, as Meta is locked in an aggressive multi-billion-dollar infrastructure race, is critical. It’s clear that the company’s CEO, Mark Zuckerberg, wants to grow into the AI titan he believes the company can be, but it’s nearly impossible when the competition controls the core infrastructure.

Custom silicon for inference

Iris is designed for a specific job inside Meta’s AI infrastructure as custom silicon optimized for Meta’s heavy workloads.  Iris expands Meta’s Meta Training and Inference Accelerators (MTIA) program, which is intended to move targeted AI inference workloads onto custom silicon.

The processor would handle workloads that drive content ranking, recommendations, and generative AI services across Meta’s family of applications, including Facebook, Instagram, and WhatsApp.

• The MTIA 300 is already deployed in production to run ranking and recommendation inference across Meta’s platforms.
• The 450 and 500 variants target generative image and video inference through 2027.

By shifting these high-volume inference tasks to custom silicon, Meta can lower data center costs while bypassing the traditional hardware supply bottleneck for its day-to-day operations.

Securing the AI supply chain

Meta’s modular, rapid-fire approach to custom silicon is aggressive versus traditional industry timelines. The company plans to drop a new iteration roughly every six months through 2027.

Meta is working with Broadcom to design Iris, while TSMC will manufacture the chip. But custom silicon is only one piece of the equation. Scaling AI infrastructure also requires a steady supply of memory, storage, and networking components at a time when demand for AI hardware continues to strain global supply chains.

To support that expansion, Meta has also been securing key components across its supply chain. The company has signed long-term agreements for high-bandwidth memory from Samsung Electronics, flash storage from SanDisk, and fiber-optic networking equipment from Sumitomo Electric.

The strategy mirrors similar investments by other hyperscalers. Google continues to expand its TPU program, while Amazon has developed its Trainium and Inferentia processors.

Scaling to 14 gigawatts

The Iris rollout is one component of Meta’s broader AI infrastructure expansion. The company plans to bring roughly 7 gigawatts of computing capacity online this year, then double that to 14 gigawatts in 2027. At that scale, Meta’s AI infrastructure would consume more electricity than many small countries.

At that scale, Meta’s AI infrastructure would consume more electricity than many small countries.

And, scaling AI infrastructure at this level comes with an enormous price tag. Meta has projected 2026 capital expenditures of between $125 billion and $145 billion, making it one of the largest single-year infrastructure investors in corporate history

Meta just pulled off something rare, which is essentially convincing Wall Street that spending more money is actually a good thing.

Wall Street rewards AI spending

Yet Meta just pulled off something rare: essentially convincing Wall Street that spending more money is actually a good thing. Following a trillion-dollar wipeout in tech market cap amid investor nervousness about the sheer scale of AI spending, Meta’s shares climbed roughly 8%.

With new MTIA chips planned roughly every six months through 2027, Meta is betting that vertically integrated AI hardware can deliver lower inference costs and better performance than relying exclusively on merchant silicon. By bringing chip design in-house and securing critical components across its supply chain, the company is slated to scale AI infrastructure with greater control over cost, deployment, and optimization.

The post Meta’s Iris push signals the next phase of AI infrastructure appeared first on The New Stack.

Agentic systems usually have two jobs: Build context, then use that context to produce an answer or action.

Many failures that look like LLM problems start in the context-building step. The answer the LLM gives is limited by the context it was given, or it finds through tool calls. If the agent model cannot find the right sources, then improving the generation model will not improve the overall system.

“Many failures that look like LLM problems start in the context-building step.”

A client, Specstory, wanted to give users the ability to ask questions from the agent’s history. For example, why a team chose Authlib for authentication and what alternatives they considered. The chatbot needs the right prior conversations, decisions, and tradeoffs from a large corpus of coding sessions. The model and system prompt help only after those chat turns have been retrieved and are in context.

If retrieval ranks implementation snippets above the discussion where the team weighed alternatives, the agent can still produce a confident answer. It may find code that imports Authlib and a few inline comments, then describe the decision based on implementation evidence rather than the actual trade-off discussion.

The same pattern showed up in an AnkiHub operator review in our private community. A request for help studying based on lecture slides only works if the agent’s tool calls retrieve the right flashcards. The hard part is not finding any related cards. A lecture on the function of the heart may match hundreds of cards. Ranking decides whether the core cards make it into context or whether the system has to raise top_k and flood the prompt.

The exact setup changes by product. The context-building step might use local search, semantic search, web or API calls, or database queries. It might be handled by an agent, a fixed workflow, or application code. The process stays the same: gather the right context, then generate from it.

For example, a coding agent runs rg, opens files, reads logs, and inspects tests before writing a patch. A research agent searches the web and internal notes before writing an answer. A study assistant searches deck facts and user context before suggesting what to learn next.

When context building fails, the symptoms look like generation failures.

Retrieval failures mimic generation bugs

Symptom	Retrieval cause
Hallucination	The answer source never made it into context.
Context rot	Low recall forces a high top_k, so noisy results fill the context window.
Latency	Weak retrieval leads to more tool calls, larger candidate sets, and larger context windows.

A better model helps with reasoning and writing, but it cannot give a better answer without the right context.

“A better model helps with reasoning and writing, but it cannot give a better answer without the right context.”

The Mixedbread OfficeQA-Pro Eval shows the same pattern at the benchmark scale. OfficeQA-Pro uses 89,000 pages of financial documents, dense tables, scanned PDFs, and questions that require reasoning across documents. Giving Codex better search tools reduced tool calls and improved answer quality.

Plain-text tools like grep and rg work (ish) on flat code files. They do not work well when context lives in PDFs, tables, chat histories, multi-modal inputs, web results, and permissioned data. In those cases, the agent needs a retrieval that can combine exact terms, meaning, metadata, permissions, and ranking quality.

Retrieval needs traces and evals

Once retrieval enters the architecture, the next question is whether it finds the right information.

For that, you need traces and evals. For each retrieval step, the minimum trace is the input, the outputs, and a way to label whether each output was relevant.

For a coding agent using rg the input is the command, the output is the returned snippets, and the label says which snippets helped, which were noise, and which relevant files were missing.

For product retrieval, the step might be BM25, semantic search, hybrid search with reranking, a generated SQL query, or something else. Capture the query or arguments, the returned documents or chunks, and whether those results were helpful.

Trace each retrieval step by itself, then evaluate the full context-building pass. The local trace answers “Did this query return useful material?” The full trace answers “Did the system collect everything the model needed before generation?” If it did, failures are a generation problem. If not, it’s a retrieval problem.

You cannot know where the failure started or what to fix without traces.

Different failures need different fixes

“Improve retrieval” is too broad to be useful, as different problems require different solutions. If a relevant document is missing, the trace should show where it disappeared: query building, retrieval, filtering, ranking, or final context assembly.

The failed step, plus what the trace shows, tells you what change to make.

Failed step	What the trace shows	Change to make
rg / grep	A conceptual query returns literal matches while missing relevant files.	Add semantic search over files or chunks, or generate better keyword queries before calling rg.
BM25	The query uses the right concept but different words from the source material.	Add semantic search, synonyms, or query expansion.
Semantic search	Exact names, error strings, document IDs, or domain terms are missing from the results.	Add a keyword or BM25 path, or boost exact term matches.
Hybrid retrieval	The relevant passage is ranked 7th, but the context only takes the top 5.	Add or tune a reranker, or raise candidate top_k before reranking.

The right fix depends on what the system was trying to retrieve. A decision-history question requires the decision, the alternatives, and the chats in which the team worked through them. A study question depends on the lecture material, deck metadata, semantic matches, and the user’s study context.

The architecture

Once you trace individual retrieval calls, the full architecture has a simple shape: fan out to context-building tools, then fan in to generate the final output.

The retrieval layer might be a search engine, a vector database, an SQL query, a local file tool, a web search API, or a custom service. The pattern stays the same: build candidate context, narrow it, rank it, assemble it, then generate from it.

Give agents human search controls

Semantic search compares embeddings (numerical representations of meaning). It helps when wording differs, but most retrieval intents also depend on structured constraints. A meeting search box can use semantic search over transcripts and notes, but a useful interface also lets someone filter by person, date, project, and source. 

A finance search may need the latest filing, a specific quarter, or an official source in addition to the closest semantic match. In e-commerce, the best semantic match for “32×30 cargo pants” may be an out-of-stock product. The system still has to decide whether to hide it, return it with a backorder note, or show it so the user can check later. That product decision is a retrieval decision because it changes which candidates reach the agent.

In a chat interface, those controls are in the tool schema, query planner, or app logic. If an agent runs the search, it needs arguments for the same constraints a human would set with filters, sliders, tabs, and sort menus.

A retrieval system usually needs several controls working together:

Control	What it does	Example
Exact match	Matches names, IDs, error strings, quoted phrases, tickers, or product codes.	Find EADDRINUSE, Authlib, or a specific SEC accession number.
Semantic match	Finds related content when the wording differs.	Find the meeting where the team discussed authentication tradeoffs.
Hard filters	Removes invalid results before ranking.	Limit by tenant, permissions, person, date range, size, or stock status.
Sorts	Orders candidates by a structured field.	Prefer the newest, latest filing, lowest price, highest rating, or recency.
Ranking	Scores candidates based on their likely usefulness for this request.	Combine semantic match, exact match, freshness, source quality, and use.
Reranking	Uses a slower model or scorer on a smaller candidate set.	Compare the query against the top 100 candidates before returning 10.

Here, a chunk means a small piece of source content, and a candidate is a chunk returned by the first search step. Ranking is the scoring step that orders those candidates. Context assembly then selects which chunks and structured fields to include in the model prompt.

Better ranking improves precision, which means a larger share of the returned chunks is useful. If the relevant chunks are near the top, the system can pass fewer chunks to the model, use fewer tokens, reduce latency, and expose the model to less noise. If the right chunk is ranked 40th and the context only includes the top 10, the system behaves as if the retrieval missed it.

People and agents use the same basic search path: ask for results, inspect what comes back, and decide what to use. A person can skim ten search results, compare titles, snippets, dates, domains, and URLs, and decide whether the result set looks right. They can open the third result, ignore the rest, and search again with a better query. An agent usually receives a bounded set of returned documents and reasons from the context. If the right source falls below the cutoff, the agent may answer from partial context. To avoid this, the system has to retrieve more candidates, run more searches, or pass more evidence into the model.

A missed document can change what the agent searches for next. Suppose someone asks why the team chose Authlib. If the first search misses the transcript where the team compared Authlib with alternatives, the agent may search the codebase instead. It finds imports, callback handlers, tests, and maybe a comment. Then it asks follow-up questions about OAuth configuration. The context starts to look complete, but it supports the wrong answer. It explains how Authlib was used and why it makes sense in the codebase, not why the team chose it.

“The context starts to look complete, but it supports the wrong answer.”

But ranking cannot repair every search problem. If the agent failed to request the latest filing, a reranker may faithfully select an older document with a closer wording match. If the tool has no date_range, person, source_type, size, or in_stock argument, the model has to impose hard constraints in the search text and hope that retrieval infers them. A hard filter gives the model less to infer, making semantic search more reliable.

Scale changes the retrieval problem

Search systems already have tools for this: indexes, filters, facets, sorts, caching, bounded reranking, and freshness jobs. Agent systems need the same discipline.

A human might search, adjust a date filter, scan the first page, then search again. One agent request can do that many times in seconds: rewrite the query, run keyword and semantic search, inspect thin results, issue follow-up searches, fetch sources for citations, and ask for more context before answering. With many concurrent users or agents, the retrieval layer can become a bottleneck.

Humans often wait through a slow search if the result is good. Agent systems often turn slow and uncertain search into more work. When ranking is weak, teams compensate by raising top_k, running keyword and semantic searches in parallel, adding reranking, fetching more source documents, and passing larger evidence bundles to the model. That can improve answers, but it moves the cost into tokens, latency, and retrieval load. A better ranking lets the system return fewer, better candidates, rather than making every request carry a larger pile of possible evidence.

With a small corpus, you can still search comprehensively quickly and cheaply, even with fully agentic approaches. That’s what I recommend when you’re starting and don’t have much data. Don’t add complexity until you need it. But with millions or billions of chunks, every extra retrieval call, candidate, ranking pass, and returned token adds up quickly.

Multi-stage retrieval is the production shape

Most production systems should split retrieval into stages, even when the UI is a chat box.

Stage	What happens	Trace question
Search argument construction	The app or agent turns the request and state into a query, filters, and sort.	Did it ask for the right content with the right constraints?
Candidate generation	The system finds plausible chunks from text, vectors, or structured data.	Did the right source enter the candidate set?
Filtering	Permissions and product constraints narrow what can be returned.	Was the source correctly excluded or wrongly lost?
Sorting	Structured fields order results when order matters.	Was the latest, cheapest, highest-rated, or current item surfaced?
Ranking	The system scores the candidates based on their usefulness for this request.	Was the source present but ranked too low?
Summary return	The system returns only the fields the agent needs.	Did the app receive usable evidence and provenance?
Context assembly	The app selects, formats, and budgets evidence for the model.	Did useful evidence get dropped before generation?
Evaluation	Humans or automated checks label whether the retrieval path worked.	Can the team turn the failure into a specific fix?

Each stage leaves a different repair path. If the agent chose the wrong filters, changing the embedding model will not help. If the latest document was available but the tool never sorted by date, the fix belongs in the search arguments or retrieval API. If the right source was present but below the cutoff, the fix belongs in the ranking. If the right source came back but was dropped before generation, the bug is in context assembly.

As retrieval becomes a core part of agent architecture, teams increasingly need infrastructure that can combine semantic search, exact matching, filtering, ranking, and large-scale retrieval in a single system. Depending on requirements, this may involve search and retrieval platforms such as Vespa, Elastic, or Coveo, each of which supports different approaches to ranking, retrieval, and operational scale. 

The important point is not the specific technology choice, but recognizing that retrieval quality has become a first-class engineering concern. As agent workloads grow, retrieval systems are increasingly determining the accuracy, cost, latency, and reliability of the overall application.

The post Why retrieval quality is becoming the defining challenge in AI agent architecture appeared first on The New Stack.

OpenAI announced ChatGPT Work on July 9 and began rolling it out to Pro, Enterprise, and Edu users. It runs on the new GPT-5.6, opens a user’s local files, edits Google Workspace and Microsoft 365 documents, and carries a multi-step task through to a finished deliverable.

Reuters placed it directly against Anthropic’s Claude Cowork, and both target the same person — a non-coder who wants the power of a coding agent without the terminal. Counting Anthropic, Microsoft, Perplexity, and Amazon, five leading labs have now released an agent of this kind. The batch shows that the newest agents are organized more by their intended users than by their functions.

Based on the target user persona, four archetypes appear: the knowledge worker, the power user who self-hosts, the developer, and the enterprise. The personas often overlap since one individual can embody all three roles. Additionally, a product like Claude Code caters to both solo developers and platform teams.

Therefore, consider these deployment archetypes categorized by the main buyer, rather than strict separations. The archetype only represents what marketing promotes. Behind the scenes, each lab has almost consistently decided who owns the runtime, persists memory, manages credentials, and enforces policy.

Four archetypes, based on the user persona

Let’s analyze each of the four archetypes individually, as each differs in the level of control available to users.

The first archetype serves the knowledge worker. A vendor operates the runtime and sells the agent as a delegation to someone who lives in documents rather than code.

ChatGPT Work is the newest, alongside Claude Cowork, which now runs cloud sessions on web and mobile while keeping local-file access on the desktop; Microsoft’s Copilot Cowork, a cloud-hosted agent that executes long-running tasks inside the Microsoft 365 trust boundary; Perplexity Computer, which works across local files and Microsoft apps; and Amazon Quick, the successor to Q Business as that product closes to new customers at the end of July. The user grants access and supervises the result. In most cases, the vendor manages the runtime and persisted state, except for Perplexity’s local option.

A second archetype belongs to the power user who self-hosts. The provider controls the persistent agent process and chooses where to store the state and credentials, often on a Mac mini that has become a piece of personal infrastructure in its own right.

OpenClaw and Hermes are the reference examples, open source, and run on the operator’s own machine. Self-hosting involves managing the control plane rather than full local custody, since both options still allow access to a hosted model and the storage of credentials for external services.

The developer gets the third archetype, whose runtime spans the IDE, the terminal, the repository, and a cloud sandbox. Claude Code, OpenAI Codex, GitHub Copilot in agent mode, and the open-source OpenCode all live here, and Amazon’s developer agent is folding into its Kiro tool. Coding-agent execution is extending from the local IDE to vendor-managed sandboxes and asynchronous cloud workers, making this the most challenging archetype to categorize clearly.

The fourth archetype is built for enterprise workflows and integration with business processes. They run an open agent framework, such as LangGraph or CrewAI, on a managed, governed runtime. ADK on the Gemini Enterprise Agent Platform, Strands on the Bedrock AgentCore, Microsoft Agent Framework on Foundry Agent Service, and Claude Managed Agents belong to this category. OpenAI’s Agents SDK can be hosted on some of these runtimes, including AgentCore, which AWS lists as one of its supported frameworks. The vendor operates the infrastructure, and the customer configures identity, policy, and retention on top of it.

Persona	Representative products	Runtime ownership	State and credentials	Platform type
Knowledge worker	ChatGPT Work, Claude Cowork, Copilot Cowork, Perplexity Computer, Amazon Quick	Vendor cloud for most, with per-folder local access on some	Vendor persists session state, user grants scoped credentials	Packaged experience
Power user, self-host	OpenClaw, Hermes	The operator’s own machine	Operator chooses where state and tokens live, though inference is often external	Packaged experience, self-operated
Developer	Claude Code, OpenAI Codex, GitHub Copilot, OpenCode	Split across the IDE, the laptop, and a cloud sandbox	Repo and local for now, drifting into hosted sandboxes	Swing, moving toward platform
Enterprise, workflow-driven	ADK on Agent Platform, Strands on AgentCore, MAF on Foundry, Claude Managed Agents	Managed vendor runtime, customer-configurable	Customer defines identity, policy, and retention; platform brokers	Programmable platform

The line below the personas

The persona-based approach abstracts four things: where execution runs, where state is persisted, how authority is delegated, and where policy is enforced.

Anthropic describes its design as decoupling the brain from the hands. The harness that calls Claude runs separately from the sandbox where code executes, and a session, an append-only log of every model call, tool call, and result, connects the two. Because the sandbox is kept separate from the brain, the agent can start reasoning before any container exists, and the code it runs remains far from the developer’s credentials.

The same four planes show up at the other vendors. AgentCore Runtime gives each session a dedicated microVM with an isolated CPU, memory, and filesystem, and meters compute usage. Google can route governed traffic through its Agent Gateway, where Model Armor policies inspect configured ingress and egress flows, while Agent Identity and an Agent Registry track the fleet. Microsoft assigns each hosted agent a dedicated Entra Agent ID and runs it in a per-session sandbox whose filesystem survives idle periods.

Deploying agents on a managed runtime is more like leasing a workshop than purchasing a tool… a long-term tenant installs their own locks, maintains their records, and takes their tools when the lease ends.

Deploying agents on a managed runtime is more like leasing a workshop than purchasing a tool. The landlord manages the building and supplies the power, but a long-term tenant installs their own locks, maintains their records, and takes their tools when the lease ends. The personas often conceal this difference. Currently, the vendor typically operates the runtime, so the key question is how much control the customer can still exert and what they can take away across the four planes.

Where the line falls

What differentiates each offering is not the compute operator, since vendors handle nearly all of it. It is how much of those four planes a product leaves the customer to configure and export. A packaged experience hands nearly all four to the vendor and returns supervision and a finished outcome. A programmable platform operates the infrastructure but lets the customer define identity, policy, and retention and move the code elsewhere.

Copilot Cowork shows that the two axes are separate. It is a packaged knowledge-worker experience, yet it runs on a governed enterprise platform and inherits Microsoft’s identity, compliance, and audit controls.

The persona sells the product, but the four planes decide the lock-in.

A product can be packaged on the surface and programmable underneath, which is why the personas and the control planes have to be read as different questions. ChatGPT Work makes the same point from the developer side, since OpenAI’s new desktop app folds Chat, Work, and Codex into a single surface, though OpenAI has not detailed how far the runtime or credential store are shared beneath it. The persona sells the product, but the four planes decide the lock-in.

Usecase	Agent Type	Tradeoff
Delegate a knowledge task to an agent you supervise	A knowledge-worker agent such as ChatGPT Work, Copilot Cowork, or Amazon Quick	The vendor typically operates the runtime and persists state, and you configure little below the surface beyond access and approval
Keep state and credentials on hardware you control	A self-hosted agent such as OpenClaw or Hermes, in a local configuration	You control the persistent process, though model inference and some tools may still be remote
Ship code changes across the IDE, repo, and CI	A developer coding agent such as Claude Code, Codex, or Copilot	Execution spans your tools and a cloud sandbox, so ownership is split and worth mapping before you commit
Run many governed agents with audit and identity	An enterprise runtime platform such as AgentCore, Agent Platform, Foundry, or Managed Agents	The vendor operates the infrastructure while you define identity, policy, and retention, in exchange for coupling workflow logic to one cloud

Real deployments combine the rows rather than picking one. Teams on Foundry Agent Service commonly run open-source orchestration, such as LangGraph, for agent logic while leaning on the platform for governed execution, and Microsoft’s own hosted runtime now supports long-running personal agents like OpenClaw and Hermes with durable state. The boundary between experience and platform is not a thick, well-defined boundary, but a thin line a single system can cross, bridging rival camps.

The agent market is not being decided by open against closed. Open frameworks like Strands, ADK, and Microsoft Agent Framework are precisely what the governed runtimes are built to host.

The agent market is not being decided by open against closed. Open frameworks like Strands, ADK, and Microsoft Agent Framework are precisely what the governed runtimes are built to host. Vendors now manage the runtime across nearly all archetypes, shifting the competition to who can most effectively configure and export state, identity, and underlying policy.

If coding agents enter managed sandboxes alongside knowledge-worker agents, the developer archetype will be established on the platform side. The map will then transform into what the vendors are already outlining. When enterprise teams assess agents, their most important question should be how much of execution, state, identity, and policy they can configure and extract from the product. They should not focus on which persona it presents or whether its framework is open, as the framework no longer determines the product’s value or locking-in capabilities.

The post OpenAI, Microsoft & Anthropic agree on who runs the agent. They disagree on what you can take back. appeared first on The New Stack.

Thomas Dohmke, who stepped down as GitHub’s CEO last year to become a founder again, is opening a preview of a distributed Git network on Wednesday that is designed to keep fleets of AI coding agents from overwhelming a single central server — and one that may soon compete directly with GitHub’s core service.

Entire, Dohmke’s post-GitHub startup, is launching a preview of this on Wednesday (but for now, it is behind a waitlist). With this, developers can mirror an existing GitHub repository onto Entire’s own infrastructure in one step.

“In the era of agents, centralized Git hosting has become a fundamental constraint, as the strain of billions of agents and developers hammering a central server shows up in the form of rate limits, high latency, or even outages,” says Dohmke in today’s announcement. “Today, we begin to return Git to its original promise, with a distributed, and soon fully decentralized and open-source network of interconnected nodes around the world. By doing so, we enable any developer or agent to host their code in-region, pushing, pulling, and cloning close to where they operate, fast and without bottlenecks, while still part of a global, collaborative network.”

The key here is that the code stays on GitHub, as Entire stresses, but coding agents can work with the Entire mirror and, as the company notes, “build without rate limits.”

Entire’s mirror is meant to absorb the constant flow of traffic that a fleet of agents can generate. That traffic, after all, is part of the reason GitHub is often buckling under pressure these days and startups like Entire have an opening.

Centralized Git hosting, Dohmke says in an interview with The New Stack, has become “a fundamental constraint” now that billions of agent and developer operations land on the same servers, showing up as rate limits, latency, and outages.

Given GitHub’s recent availability issues, it’s no surprise that startups are trying to get into this space. Entire is one — and it has the pedigree — but in June, Cursor also announced Origin, its own Git forge rebuilt for swarms of agents that are cloning and committing against a single repository in parallel.

Entire is starting with active regions in the United States, the European Union, and Australia, but the team says that now that is has spun up its first few regions, it will add more soon.

‘Git as a database’

To build its network, Entire rewrote the server part of git. GitHub, GitLab, and Bitbucket all wrap the server-side of the Git binary and build their infrastructure around it. Entire started from scratch.

“We see Git really as a database,” Dohmke says. The open source Git project has two halves, he explains: the client that an agent uses to talk to a repository, and the server a host runs to manage storage. Rather than build on that stock server, like most companies would do, “we made the decision of not going that route, and instead implemented our own Git backend.”

That only makes sense if Entire’s version has significantly better performance than the stock Git server, of course. Entire says its benchmarks have pushed the network to a sustained rate of 570,000 clones per hour, 586 pushes per second, and roughly 470 combined clone-and-push operations per second.

Pushing to a native Entire branch can run up to 25 times faster than pushing through to GitHub, Dohmke says.

Entire it will open-source both the git backend and the benchmark suite.

The foundation layer, now real

When Dohmke first described Entire’s plans to The New Stack in February, he described a three-layer platform that included a Git-compatible database at the bottom, a semantic reasoning layer in the middle, and an interface on top. Even then, he said that the database, unlike a centralized Git host, could be a globally distributed network of nodes.

But in February, Dohmke also said Entire wouldn’t necessarily end up competing with GitHub, and that code repositories would stay central to the pitch.

Pressed on whether that still holds now that Entire hosts its own copy of the GitHub repo, he calls the mirror complementary, in part because Entire can offer enterprises the ability to keep their code in a local region to fulfill local regulations. He also notes that GitHub has a huge ecosystem and an extended feature set.

“I think the question for the buyer really is, is it not better for me from an availability and reliability perspective, that I have both of these products, so if one of them is down — there’s always going to be single points of failure and human errors — then I have my mirror on the other side,” he says. “But we certainly will, in deals, compete for the dollar spent at a much smaller scale compared to the multi-billion-dollar business that is GitHub today.”

For now, that keeps the two complementary. Dohmke argues that GitHub remains the “source of truth,” or “cold storage,” while the working copy lives on Entire. But he also says that Entire will launch native repositories in the coming months, and those wouldn’t need GitHub underneath at all. All of this will be open-sourced as well.

Entire raised its $60 million seed round in February, when it had 15 employees. Felicis led it, with Microsoft’s venture arm among the backers. The company is now past 40 people and aiming for 60 by the end of the year.

Entire beyond Git: the semantic memory layer

Entire is building its middle layer — the semantic reasoning layer — in parallel with the Git platform.

The semantic layer now integrates with every major coding agent, including Claude Code, Codex, Cursor, Factory AI, and GitHub Copilot, and records each session, prompt, and tool call in the repository alongside the code.

Having this data is useful for agents, and it was the first core service the company launched. Now, it is also building more services on top of that history.

The company is adding Entire Blame, for example, which shows not just who last touched a line but the agent session and prompt behind it. There is also Entire Review, which fans out several agents for an intent-aware review, and the company is adding a code and semantic search feature that lets agents (and developers) search across code changes and the reasoning that produced them.

“Session logs are now the second most important artifact in software development, and they belong in the repository alongside the code,” Dohmke says.

The post Entire is building a Git network for agents appeared first on The New Stack.

While the household-name frontier models race forward with version numbers and context windows of at least a million tokens, a new breed of upstart data science specialists is pushing the context window into double figures. 

Subquadratic debuted a 12-million-token window in May of this year, and Silicon Valley and South Africa-based Refiant launched its 10-million-token context-window model, Protea, on Wednesday. It’s a move that may signal the long-context AI race is now on.

Model inefficiency & workarounds are commonplace

But more context windows alone are not enough. This is because even the most capable models have a few hundred thousand tokens in working memory, which can force workarounds to compensate for what the model can’t access.

Refiant co-founder Dr. Viroshan Naicker tells The New Stack that he believes modern LLMs “fail to be organically efficient at an elemental level” and that his organization’s approach mimics how systems in nature, from ant colonies to beehives, find efficient solutions to complex problems.

“This is no case of pseudoscientific puff; nature is the most computationally efficient system that we know, and many algorithms used in science are nature-inspired,” Naicker says. “This is a road well-traveled in science. There are multiple teams globally working in this particular (nature-inspired) direction, trying to bridge the gap between AI inference as we know it and the energy efficiency of natural systems.”

“Fish and birds coordinate their movements to converge on the mathematically shortest, most efficient routes — honeybees, fireflies and bacteria are also programmed to use degrees of swarm-style optimization.”

What can the birds & the bees teach us about AI?

Did Naicker just mention ant colonies and honeybees?

Yes, because Refiant uses swarm-style optimization. It’s seen in ant colonies, which initially move randomly until a food source is detected, after which they leave a pheromone trail for other ants to optimize their journeys. Fish and birds also coordinate their movements to converge on the mathematically shortest, most efficient routes. Honeybees, fireflies, and bacteria are also programmed to use degrees of swarm-style optimization.

Naiker, along with his co-founders, Siddharth Gutta and Mathew Haswell, form a team with experience spanning quantum mathematics, traditional finance, and commercial scaling. Applying swarm-style optimization to data in Protea means inference is performed through a combination of compression and context management.

“From our perspective, we are also advancing a technology which provides context-specific inference models grounded in data,” Naicker clarifies. “We think this has value for reducing model hallucinations, replacing RAG, and constructing better, more reliable, agentic workflows. This adds a layer of trust in sensitive application scenarios, rather like an added insurance, rather than taking it away.”

Just how much is 10 million tokens?

The Refiant team describes 10 million tokens as equivalent to 7.5 million words in a single conversation (and we know from Anthropic’s own benchmarks this year that Claude has a 1-million context window), or five years of a user’s emails, 83 novels, or 830 podcast episodes, all held in active memory at the same time.

The team claims Protea is capable of working on entire enterprise codebases or decades of clinical trial data — datasets that previously had to be broken apart and fed to models in fragments — so they can be processed in a single pass with full fidelity. Engineers on Protea also submit that they can successfully tackle the “lost in the middle” problem — a limitation of million-plus-token windows, where models stay accurate at the start and end of the context but lose the thread of everything buried in between.

Refiant first applied these techniques to model compression, shrinking OpenAI’s GPT-OSS-120B so it could run on a MacBook Pro with 18GB of RAM. 

“Rather than publishing benchmarks, we’re inviting users to run the models and try them out.”

The Protea series is open and live, and Refiant is inviting teams to stress-test the context window across different industries and use cases. But should we trust sensitive hould enterprise data archives to a completely unproven startup founded only one year ago?

Bring-your-own-cloud, a possible progression

“We adhere to data management best practices, processes and compliance requirements,” Naiker confirms. “This is reasonable for a startup at our particular stage. Privacy and data sovereignty are important values for us, and we are actively exploring edge, self-hosted, and bring-your-own-cloud data models.”

But a 10 million-token context window is big. Won’t that fall short when Protea starts to suffer from massive latency spikes when processing a full dataset? Naiker agrees that “latency is a core issue with long-context inference models,” but in the tests his company has run, it has delivered inference at a reasonable latency, even with large token windows.

“We have internal reports and tests that validate the technology, including Ruler, MRCR and Babilong, but we aren’t asking anyone to take our word on this. Rather than publishing benchmarks, we’re inviting users to run the models and try them out,” adds Naiker.

What comes next, a 100-million context window?

Although the technology industry is littered with apocryphal statements and Bill Gates almost certainly never said “64K ought to be enough for anyone” in real life, we have to ask ourselves today whether we’ll be laughing about those “silly little” 10 million token context windows by the end of the decade.

It may not take that long. Internally, Refiant maintains that it has already demonstrated a working prototype with a 100-million-context window and is exploring how best to benchmark and productionize it at that scale in the future.

Coming next, then, as Dr. Evil from Austin Powers would say, the one-hundred-billion-context window, right?

The post “Nature is the most computationally efficient system we know”: How Refiant used swarm optimization to build a 10-million-token AI model appeared first on The New Stack.