Agent acceptance spans the delivery chain. Key points * OpenRouter's new Auto Router and Auto Code select a model by using 11 factors for each request together with live prices, provider health and cache status, while governance policies first limit the candidate model set. The speed, cost and quality figures published by OpenRouter remain supplier test results. * Modal says that Snorkel runs millions of Agent simulations each month, and Snorkel uses production-like environments to distinguish model-capability problems from tool-environment problems. The approximately 20% reduction in sandbox bills reported by Snorkel applies only to a resource-bursting approach that is still at an early stage of adoption. * Microsoft Foundry extension 1.0 is generally available, and the extension places Agent configuration, evaluation assets and deployment processes under version control. GitHub's new storage architecture supported 5,000 concurrent Agent systems in an internal test, but the architecture currently remains in limited private preview. Model selection is moving from fixed configuration to an explainable runtime decision. On 6 November, OpenRouter released a new generation of Auto Router and Auto Code for coding Agent systems. The two routers evaluate 11 factors for each request, and the two routers combine live prices, provider health, cache status and benchmark results to select a model and reasoning intensity. OpenRouter also applies guardrail rules, zero-data-retention requirements, provider restrictions, bring-your-own-key settings and allowed-model lists before the router narrows the candidate model set. OpenRouter reports that the new routers achieved up to 4 times the performance of the previous router across different benchmarks, while the p90 latency of the routing step fell from 1.96 seconds to 0.65 seconds in live testing. OpenRouter also reports that Auto Code scored close to Claude Opus 5.5 across five benchmarks at a 74% lower cost per task. OpenRouter also states explicitly that no router can outperform the strongest single model at every point on the cost-quality curve. What this may mean for enterprise adoption For enterprise adoption, model routing needs to enter the same acceptance scope as the model itself. An enterprise needs to retain the model pool, data policy, price, cache, provider status and failure signals behind each selection, and the enterprise needs to map the routing result to task success, total cost and data-residency requirements. OpenRouter's supplier tests can indicate the direction of the product design, but the tests cannot prove that the same routing policy will produce the same results for other tasks, regions or provider combinations. Real execution environments are becoming part of Agent evaluation. On 6 November, Modal published a case study about Snorkel's Agent simulations. Modal says that Snorkel runs millions of simulations each month in graphics-processing-unit and central-processing-unit sandboxes, and that Snorkel reaches a peak of tens of thousands of sandboxes per hour. Snorkel reproduces different task environments with multi-service systems, a complete Linux kernel and graphics-processing-unit workloads, so Snorkel can distinguish failures caused by missing tools from failures caused by missing Agent capability. Snorkel has also started to let a sandbox add memory or central-processing-unit resources during execution. Modal says that about 10% to 15% of Snorkel sandboxes currently use this capability, and Snorkel reports a reduction of approximately 20% in its sandbox bill. Modal also says that adoption remains at an early stage. The available material is a Modal customer case, and the available material does not provide independent reproduction, tail-latency results, resource-contention results or a comparison across suppliers. What this may mean for enterprise adoption For enterprise adoption, an evaluation environment needs to reproduce the operating system, tools, dependencies, data and resource variation used by the target task. Only when an enterprise records the environment version, resource limits, failure cause, concurrency conditions and task result can the enterprise determine whether a score reflects model capability or a missing environment. Elastic resources can reduce unproductive runs and static reservations, but a cost change in a customer case cannot directly replace the target enterprise's verification of reliability, isolation and the complete bill. Deployment configuration and quality checks are following code versions. On 5 November, Microsoft announced that the Microsoft Foundry extension `microsoft.foundry` for Azure Developer CLI had reached version 1.0 and was generally available. The extension records model deployment, Agent source code, runtime, computing resources and Foundry project dependencies in `azure.yaml`, and a development team can review Agent changes and deployment changes in the same pull request. The development team can also use the same configuration for local tests and continuous integration and continuous delivery. The Microsoft process also stores evaluation data, scoring criteria and evaluation configuration in the code repository. A development team can use Agent Inspector to inspect local requests and responses, and the development team can run quality evaluations and threshold gates after deployment. The process requires Azure Developer CLI 1.37.0 or later, an Azure subscription, Foundry permissions and model quota in the target region, while configured resources and model calls incur charges. What this may mean for enterprise adoption For enterprise adoption, version-controlled configuration can bind a model, runtime, resources, test data and deployment target to one reviewable change. An enterprise still needs to keep runtime credentials in controlled secret storage, and the enterprise still needs to separate subscriptions, regions, permissions and quotas by environment. The toolchain can provide a repeatable entry point, but the toolchain cannot automatically prove that the scoring criteria are correct, and the toolchain cannot automatically prove that the production environment and the local environment are identical. Shared code storage needs to withstand Agent concurrency and read amplification. On 5 November, GitHub disclosed a new Git storage architecture. GitHub says that an internal test allowed 5,000 concurrent Agent systems to send 7,200 pushes per second to one repository, while the system continued to process read traffic with low latency during the test. GitHub separates object storage, reference updates and compaction work into components that can scale independently, and GitHub retains existing Git push, fetch, branch and protection workflows. GitHub also explains that every Agent push triggers later reads from continuous integration, deployment systems and other Agent systems, so read traffic is amplified by writes. GitHub's new architecture is currently available only in limited private preview, and GitHub plans to broaden availability early next year. GitHub also acknowledges that some Git paths slow more rapidly as a repository grows, so the existing internal test cannot be treated as evidence that every customer repository already receives the same throughput or latency. What this may mean for enterprise adoption For enterprise adoption, Agent concurrency connects code storage, branch protection, continuous-integration queues, deployment triggers and audit records into one capacity chain. An enterprise needs to test the chain with its own repository size, push shape, protection rules and read-amplification conditions. GitHub's architectural direction shows that shared code infrastructure is adapting to Agent concurrency, but the limited-private-preview status and the boundary of the internal test require an enterprise to continue distinguishing design capacity, an available product and an actual service commitment. Next watch What to watch next. * Can OpenRouter publish reproducible results for routing failures, model switches, cache misses and total task cost by region, governance policy and real task type? * Can Modal and Snorkel publish tail latency, resource contention, isolation failures and independent cost comparisons when elastic resources reach greater coverage? * Can Microsoft and GitHub make version-controlled evaluations, deployment configuration, code changes and production-run results queryable as a cross-platform chain? Verification Sources and verification. Golden Data has edited this briefing from the public materials listed above. The original sources govern facts and figures. The enterprise relevance sections are Golden Data editorial analysis and do not constitute an endorsement of any third-party product.

Tool-call policy: should a model decide what AI can do? NB Nathan BekermanHead of Product Short answer: A model can screen tool calls, but it gives probabilities, so the decision that lets an AI tool touch a real system should come from deterministic rules that return the same answer for the same call, evaluated next to the credential. What is OpenRouter Armor? On October 15, 2026, OpenRouter announced Armor in beta, using TypeSafe's Jev model "to guard against out of policy tool calls." The Armor docs call it "a classifier that runs between the model and your application and evaluates every tool call the model makes." You write rules in plain English as hard deny, soft deny, or allow. For each call, a decision model reads the call, your rules, and the conversation so far, and returns a probability that the call matches each rule. A deny rule counts as matched at 0.6 by default. The docs are candid about the tradeoffs. Armor added 279 ms at the median and 334 ms at the 90th percentile in OpenRouter's own test. And in their words: "It will occasionally block a call you would have allowed, and occasionally release one you would not." Why does this matter if you don't use OpenRouter? Willow's October 15 post on runtime governance sums up the model gateway's job with the question "Which model should receive this request?" That's routing. Armor is a model gateway reaching past routing to check what the model is about to do. LLM gateways can also screen proposed tool calls; Gatekeeper governs access to the services AI tools act on. Armor shows buyers want action controls alongside routing. The open question is how the decision gets made. Should a model decide whether a tool call runs? For some calls, a model is a reasonable screen. Coding tools run shell commands that are hard to list in advance, and a plain-English rule like "don't send credentials outside the trusted repository" catches spellings a pattern match would miss. Armor's audit mode lets you measure misses on your own traffic before you enforce. For calls that move money, change production, or read customer data, you need a decision you can predict and explain later. A classifier's score does not guarantee that the action is correctly authorized. Its decision can change as the conversation changes, and that conversation is input you don't fully control. That is a change in inputs, rather than proof that identical inputs produce inconsistent decisions. How does Gatekeeper make the decision? Gatekeeper sits in front of the services your AI tools act on, like GitHub, Salesforce, or an internal API, and decides on each tool call whether it runs. Policy is deterministic: static rules plus rules written as code, deny by default, with no model in the decision path. The same call with the same context gets the same answer. That policy runs inside an enclave (TEE). Policy evaluation and credential release both happen inside that attested boundary, and no server outside the enclave holds a key. When a call passes, the credential is used for the approved request. For bearer tokens, the credential goes out with that request to the service; the AI client does not receive the reusable secret. Sensitive actions can wait for a person to approve the exact parameters, and the approval is bound to that payload, so an edited call needs a new approval. Every request, decision, and approval is written to an append-only log. How do the two approaches compare? | Comparison | Classifier on the model path | Deterministic policy in an enclave | | How rules are written | Plain English, scored by a decision model | Static rules and rules written as code | | Same call, same answer | Repeatability must be assessed with identical complete inputs; false positives and misses are a separate issue. Yes, with the same rules and trusted context; this does not guarantee that the rules are correct. | | Where it sits | Between the model and your application; it withholds flagged calls or relies on client enforcement, depending on output mode. In front of the services, inside the enclave | | After a call is allowed | The call goes to your application; service credentials are managed separately in your application and tool stack. The credential is used inside the enclave for the approved outbound request; the AI client does not receive the reusable secret. | | What the log records | A verdict per tool call in the response | Who asked, what for, which rule decided, the reason, and any approval, in an append-only log | What should you ask about any tool-call control? Three questions cover most of it. If I send the same call twice with the same rules and context, do I get the same decision, and can I see which rule made it? Who actually stops a flagged call, the gateway or my client? (Armor can withhold flagged calls itself in other output modes. Its docs are clear that in Claude Code compatible mode, "A Messages client that ignores safeguard_results will run a flagged tool_use.") And when a call is allowed, where does the credential sit, and who else can read it? Common questions about tool-call policy. Should Station70, Inc. use a classifier like Armor at all? It can help where good rules are hard to write in advance. Keep the decision that releases a credential to a system you care about in deterministic rules. Teams can run both. Can Gatekeeper policy use outside signals, like a risk score? Yes, with a limit. Policy runs with no network access at evaluation time, so outside signals have to be pushed into the policy context before the call. Does Gatekeeper use a model anywhere in the decision? No. Policy is deterministic rules, deny by default, with no model in the decision path. Next step: run one workflow in monitor mode with Station70, Inc. and see what your AI tools are already doing.