Three public LinkedIn posts from the last two days, three different bets on what agents need next: a model fast enough that latency stops being the excuse, a world model that learns where physical points will move, and a hardware queue that keeps an agent's hands off your money. Short quotes, links and what I think. Nothing here comes from anyone's private feed.
Each item started as a public LinkedIn post; I could not open the posts themselves (LinkedIn requires a login), so every item below is verified against the public first-party source it points to: Inception's launch blog, the arXiv paper and its result tables, and Ledger's announcement. Where a number comes from the vendor's own benchmark or demo, the item says so. I read these pages on October 21, 2026.
"Across a range of benchmarks, Mercury 3 outperforms GPT-6 Luna and Claude Haiku 5.5, while running 4–8x faster at 1,000+ tokens per second."
Inception's launch blog, October 19, 2026, the post Stefano Ermon pointed to. Launch blog · Original post
My take: The claims, as published: 1,068 tokens per second on NVIDIA GPUs, a 1M-token context (up from 260K in Mercury 2.5), list pricing of $0.20 per million input and $0.70 per million output tokens with a 50% launch discount ($0.10/$0.35) and 90% off cached input, OpenAI-API compatibility, and availability on the Inception API, OpenRouter, Baseten and Vercel, with 100 million free tokens to try. The model is more than 40x larger than Mercury 1, and Inception says the scaling laws that drove autoregressive models hold for text diffusion too. If the quality claims hold up under independent evaluation, the speed tier stops being a compromise tier: a model that is both cheaper and 4-8x faster than the speed-optimized frontier options changes the math for agents that wait on a model at every step - Inception's own web-agent harness result (50% of 50 live Mind2Web tasks, ahead of GPT-6.1-Sol at the same token volume) is exactly the use case where that matters. The partner quotes (TinyFish, RevisionDojo, Octen, Lorikeet) all stress the same point: latency, not accuracy, was the bottleneck.
Not verified: Every quality and speed figure here is Inception's own benchmark selection and harness; I did not run the model, and there are no independent evals yet. "Outperforms GPT-6 Luna and Claude Haiku 5.5" is the vendor's claim on the vendor's choice of benchmarks. The launch discount is time-limited pricing, so the durable numbers are $0.20/$0.70. I read the launch blog, not Ermon's LinkedIn post itself.
"Each trajectory tracks a single point across all views, and supervising these trajectories alongside video generation therefore anchors appearance changes in every camera to a shared description of 3D motion."
From the abstract of "Learning the 4D World through Point Trajectory Forecasting" (arXiv:2610.28594), by Byungwoo Jeon, Sunghwan Hong and colleagues from KAIST, ETH Zürich, Seoul National University, NYU and RLWRLD - the open release Hong's post announced. Paper · Project page · Original post
My take: The idea is clean: multi-view video prediction alone can produce footage that looks plausible per camera while disagreeing about what is physically happening; making the model also forecast the 3D trajectory of persistent scene points forces every camera's future to describe the same event. The model (VPM) extends NVIDIA's Cosmos 3 with camera-conditioned multi-view processing plus a trajectory head, and the team released the training/eval assets: VPM-Data (10K simulated multi-view clips with point tracks) and VP-WorldBench, plus DROID-Raw and RoboCasa-VP, all on Hugging Face. The number worth checking is the ablation, because it isolates the point supervision under an equal training budget - and it holds up in the paper's own Table 2: on the 500-clip simulation splits, adding trajectory supervision cuts FVD from 78.52 to 67.35 on Robot (-14.2%) and from 101.37 to 81.92 on General (-19.2%); the effect is smaller on the 100-clip General split (62.85 to 56.48, -10.1%). The action-enabled variant, which denoises robot action tokens jointly with future video, raises manipulation success on every reported task in their table (one task goes from 50.0% to 79.2%). Supervising motion, not just appearance, is becoming the reliable trick in video world models, and this is a well-instrumented instance.
Not verified: All results are the authors' own, on their benchmark and their fine-tuned baselines; I read the paper and its tables but ran nothing. Hong's post describes an open release of paper, data, benchmark, code and weights; as of today I could confirm the paper, the project page and four Hugging Face datasets, but I did not find a public code or model-weights repository at the linked pages - those may still be pending. I read the paper, not the LinkedIn post itself.
"The agent never holds the keys. You do. When it needs them, it asks, and you confirm on a secure screen."
Ledger's announcement of Ledger Agent Intent, October 15, 2026, the product Semaan's post discusses. Announcement · Developer docs · Original post
My take: The design: agents driving Ledger Wallet or Ledger Enterprise (via Claude, Codex, Cursor or other harnesses) can research, analyze and prepare a transaction, but cannot move money unless the owner approves on the Ledger signer's secure screen, or a rule the owner set allows it. Agent Intent, announced at Ledger Op3n 2026, turns that approval step into a single asynchronous queue: agents ask and keep working, the human approves later, with per-request options of approve once, always allow, or deny. The demo partners span the realistic surface area - Grok Bot preparing an invoice payment, Venice AI shopping privately, OpenClaw queuing requests from many sub-agents, and Solana's Pay.sh letting agents pay for APIs in stablecoins within a budget the owner defines. This lands in the same place as the Week 42 safety roundup I covered earlier this week: the effective check on an agent has to sit outside the agent, with its operator. Hardware-rooted approval is the most concrete version of that principle so far - the key never leaves the device, so a compromised or lying agent still cannot sign. The budget-bounded micro-payments in Pay.sh are the part to watch: "autonomy with bounds" is exactly where policy will either hold or quietly leak.
Not verified: I read Ledger's first-party announcement and developer docs, not Semaan's post itself. Ledger sells the hardware this product requires, so the source is not neutral; availability details, the partner integrations and "eight million signers" are Ledger's statements, and the announced Ledger Atom device is reservation-only. Whether approvals stay meaningful when one person faces a daily queue of agent requests is a human-factors question the launch does not answer.
I read the public first-party pages on October 21, 2026: the Inception launch blog, the arXiv abstract and full text with result tables, the Hugging Face dataset listings, and the Ledger announcement with its developer documentation. The three LinkedIn posts that surfaced these items require a login and were not opened; the authors, dates and links above refer to the public sources. No engagement counts are used, I did not contact the authors, and nothing here comes from a private feed.