There's a support ticket that's about to become common, and it's unanswerable with the logs most apps keep today. A customer says their delivery address changed and they never touched it. The audit trail shows a request from their own logged-in session. Same cookie, same IP, same browser fingerprint. What actually happened is an increasingly ordinary pattern: they'd asked an AI assistant to check an order's status, and it operated inside their session with every permission they have. The app logged a human, because a human's credentials were used, and had no way to represent "an agent, allowed to read, not write." That gap is what the Personal Agent Protocol is aimed at. Sierra announced it on October 6 with Meta, Walmart, Shopify, Stripe and others. It's OAuth-based, an agent can start as a guest to check stock or a returns policy, and once the customer signs in they choose read-only or write access. Sessions are meant to follow the customer across channels, and a business picks how agents reach it: its website, its APIs through MCP and OpenAPI, or an agent of its own. What I found most useful was reading what hasn't been published. The spec itself isn't out; v0.1 was promised later in October. Nothing public says how an agent proves who it represents, what the tokens look like, or whether any partner runs it in production. Reporting also says OpenAI and Anthropic aren't among the partners, and Stripe and Shopify are in Visa's rival protocol too. So I wouldn't write a line of PAP-specific code yet. I'd do the parts every version of this future needs: tokens that can say read-only, an actor field in the logs, and a settings page where customers can revoke what they granted. Laravel already has the pieces: Sanctum abilities, the Context facade, Passport and Laravel MCP. Then the spec lands and the work is mapping, not rebuilding. Full breakdown in comments.

There's a failure mode in multi-server Laravel apps that never shows up as an error. It shows up as a customer asking why they got the same email three times. The cause is almost embarrassingly simple. Every server with a cron entry for schedule:run evaluates the whole schedule on its own. Each one asks which tasks are due this minute, gets the same answer, and runs them. Nothing coordinates between servers, because the scheduler has no idea the others exist. onOneServer() fixes that with a cache lock: the first server to start a task takes it, and the rest skip. The catch is that it's per task. The pull request behind Laravel 13.35 describes how people usually patch it: wrap the whole routes/console.php in a group. That works until someone adds a task outside the braces. The author's own phrasing was that it relies on everybody remembering it forever. A protection that depends on code structure and reviewer vigilance erodes silently, because an unprotected task behaves identically to a protected one on a single-server dev machine. 13.35 replaces the convention with a default. Schedule::alwaysOnOneServer() in your service provider covers every task, including ones defined after the call. What I'd actually spend time on is what it depends on. Closures without a name() are skipped silently, so they still run on every server with no warning, which is the exact symptom you were trying to cure. The lock lives in the cache, so a per-server file store means every server wins its own lock. And there's no per-task opt-out, so a schedule with real per-machine housekeeping shouldn't use the flag at all. The practical move is ten minutes of proof: grep your Schedule::call( closures, confirm the cache store, and log gethostname() from a before() hook on one real run. One hostname means it worked. The same release adds a clean way for long runInBackground() commands to stop during a deploy. That's a smaller change with the same shape: it only works if the command is written to be stopped. Full breakdown in comments.

There's a bug I keep seeing in AI features, and it never shows up as a bug. It shows up as a decision that was quietly wrong with full confidence. A moderation check flags a comment. Nobody asks how sure the model was. By the time the result reaches the if statement, a 51% guess and a 99% guess have both become the same true. The uncertainty didn't get handled badly. It got thrown away somewhere upstream, in a parsing step nobody examined closely, before your code ever had the chance to see it. I spent some time with a different approach this week. Jev, an AI model from TypeSafe, answers a typed yes/no question with a calibrated probability instead of text you then parse. The Decide with Jev course on Laravel News builds a content preflight checker around it, and the example makes the contrast concrete: a complete draft scores 0.96, a thin one that never gives a concrete step scores 0.02, and a genuinely mixed one lands somewhere that doesn't resolve to either. That mixed case is where it earns its keep. Instead of forcing it into true or false, the SDKs expose isTrue(), isFalse(), and isUncertain() with thresholds you set. Three outcomes instead of two, because the third one actually exists in the model's output. It also surfaced the cost, and it's real. You now have to decide what happens to the uncertain middle. Human review is the obvious answer, but not every feature can afford it at volume. And the threshold itself, whether 0.75 is the right line for denying a refund, isn't a technical default. It's a business decision about which mistake you'd rather make, and a boolean API let you avoid ever having to make it consciously. One honest caveat: the course is weeks old and the Laravel packages are unofficial. I found three independent wrappers published in the same short window. That's a sign of interest, and also of an ecosystem that hasn't settled yet. Full breakdown in comments.