Anthropic's usage policy requires human oversight, and Spotify shares agent lessons
Anthropic's usage policy adds human-oversight duties for high-risk products, Spotify shares which multi-agent patterns held up, and a quieter day for models.
Today’s theme is boundaries. Where a policy draws the line on what you can build, where an agent’s job ends and code’s begins, where a datastore’s permissions stop. It’s a calm day otherwise.
1 · Top story
Anthropic’s new usage policy lands on November 12, and it asks for humans in the loop
Anthropic published its 2026 Usage Policy update, effective November 12. Most of it clarifies existing rules, but a few parts add duties. Products that drive hardware able to hurt someone need an operator who can watch and stop the equipment, and the equipment must “hold a safe state if Claude is disconnected.” Where outputs touch health, legal rights, finances, livelihood or essential services, a qualified person must be able to review and change the recommendation, and the affected person must be told AI was involved.
If you ship on Claude, that’s a design requirement, not a legal footnote: you need a review step with real authority to override, an audit trail, and a defined behaviour when the model link drops. The new Supported Regions wording also covers entities majority-owned by parties in unsupported regions, so customer onboarding checks ownership, not just location. Read the full policy before you assume your product is out of scope.
2 · Models & features
GPT-6.1 Sol gets an Ultrafast mode on Amazon Bedrock
AWS announced on October 8 that Ultrafast mode is now available for OpenAI’s GPT-6.1 Sol on Bedrock. The page positions it for latency-sensitive work such as coding assistants and interactive agents, and points to existing Bedrock controls for access and invocation auditing.
The announcement gives no latency figures, no pricing and no regions, so there’s nothing to plan around yet. Before you route interactive traffic to it, measure time-to-first-token and tail latency yourself, and check whether the price premium is per token or per request. Faster tiers usually cost more, and agent loops multiply that.
3 · Agents
Spotify Ads explains what broke in their multi-agent setup
At QCon AI, Pratik Rasam from Spotify Ads walked through the platform behind their advertising tools, built on Google ADK for Java with Vertex AI behind an internal gateway. Each agent is a package with one owner, dependencies are enforced by Bazel visibility rules, and moderation sits in a separate layer. He ran through five patterns (tools, pipeline, router, fan-out, generator-critic) with their failure modes, such as the router being a single point of failure and critics needing an iteration cap.
The useful part is where they put the line: agents handle intent, code handles anything checkable. An agent once output an age range of “21 to 99”, so the valid brackets now live in code. They also stopped running every guardrail on every request and put a cheap classifier in front, and they run full evals nightly rather than on every merge. These are the team’s own numbers and lessons, but the pattern is easy to copy.
4 · Research
Prune on what the model generates, not on generic text
SparseDecoding is a pruning paper with one simple idea: calibrate on activations recorded during the model’s own decoding steps, skipping prefill, instead of on a generic corpus like C4. Paired with a Triton N:M sparse kernel for batch-one decoding, it reports 1.34x to 1.48x decode speedups on an A100 at 50% sparsity, and better long-form writing and code quality than C4 calibration at the same sparsity.
I’d treat it as promising, not ready. Quality at 2:4 is still far below dense (Llama-3.1-8B scores 1.52 against 3.70 on WritingBench), the judge is an LLM with no variance reported, and the speedup comes from one GPU, one framework and batch size one. Check it at your real batch sizes before it influences a capacity plan.
5 · People worth following
Sam Newman on resilience, with a warning about AI vendors
In an interview with Gergely Orosz, Sam Newman covers idempotency keys versus fingerprints (keys are cleaner but hard to retrofit, fingerprints are easier but can reject legitimate requests), and says most outages he’s seen come down to running out of some resource. On AI, he suggests designing for several vendors and models since it’s unclear who will stay in business, and swapping LLM features for deterministic code where that’s cheaper.
His advice to define module boundaries first and let AI work freely only inside them pairs well with the Spotify story above. It’s a modest idea, and probably the one that ages best.
6 · Architecture
Governed apps on Databricks with Replit Agent and Lakebase
Databricks describes a setup where Replit Agent generates an app that deploys as a Databricks App, reads through a SQL warehouse, and writes its own state (inputs, approvals, execution state) to an auto-provisioned Lakebase Postgres database. In production each user’s token is passed through, so Unity Catalog permissions apply at runtime, and any schema change the agent proposes needs team approval before production.
The architectural point is keeping operational state inside the same permission and lineage perimeter as the analytics data, instead of bolting on an external database with its own access model. The cost is coupling: it needs a Replit Enterprise plan and a standard Databricks workspace without a compliance security profile. It’s a vendor post, so test the per-user passthrough with a deliberately under-privileged account.
That’s the lot. Friday’s allowed to be a quiet one.
Researched and drafted with AI, checked against the linked sources. How we use AI →