4 posts tagged with "infrastructure"

An agent can cause damage before the model makes its first decision.

On September 1, 2026, Manifold described coding agents that invoked Git while gathering workspace context, allowing repository-local Git configuration to run a program on the host. Some affected agents performed that work before a user typed a prompt or approved workspace trust.

In Manifold's GitSpawn research, the relevant path was a repository received as files, with a .git directory inside a ZIP archive. Git read repository-local configuration while the agent gathered context. An ordinary Git clone, fetch, or pull does not transfer repository-local .git/config from the remote.

The model did not choose a harmful tool call. The runtime acted while preparing to use the model. That is why an agent review needs three boundaries: the runtime that starts processes, the gateway that holds credentials and routes requests, and the tool that makes a sensitive change.

GPT-6 Astra does not prove that OpenAI has reached AGI. What it does prove is that the harness can no longer be treated as plumbing.

Astra scored 54.8% on ARC-AGI-3 at high reasoning in the standard harness. The same model scored 99.9% when the harness preserved its reasoning state and compacted long conversations. That is a 45.1-point difference without changing the model.

My takeaway is simple: if you evaluate only the model name, you are evaluating the wrong product. For long-running agent work, the product is the model, memory, tools, context management, and control loop together.

That is why Astra matters even if you are not interested in arguing about AGI.

Calling an LLM provider's SDK directly is a good way to build a prototype. Letting every product feature call that SDK directly is how a provider detail becomes an application architecture.

The distinction matters. “Stop calling LLM APIs directly” does not mean every team needs to install a commercial gateway. It means production code should call a boundary your application owns. Behind that boundary, you can make explicit decisions about providers, deadlines, errors, data policy, and degraded behavior.

Without it, adding a second API key gives you another provider. It does not give you a fallback.

A 2026 survey of 100 enterprise CIOs found 37% now run five or more AI models in production, up from 29% the year before. A separate Zapier survey of enterprise leaders, published the same year, found 81% at least somewhat worried about depending too heavily on one AI vendor, and 47% said losing their primary vendor would disrupt a real business function. That fear is exactly what "model platforms" like Amazon Bedrock, Azure OpenAI Service, and Google's Vertex AI Model Garden are sold as the fix for: one integration, many models, switch providers without rewriting your app.

It's a good pitch. It's also not quite true. Routing your calls through a hyperscaler's managed layer doesn't remove a dependency, it relocates one. You stop depending on a single model provider and start depending on a single cloud provider instead, and that second dependency is usually stickier than the first.