Not surprised by the 73%. Even people who never carry cash anymore can see the problem with going fully digital — you're one outage or one policy change away from not being able to buy groceries. Cash doesn't need wifi, doesn't need approval, doesn't go down for maintenance.
The 30% usage stat makes it even more interesting. These aren't cash diehards. These are people who tap their card for everything but still don't want the analog option killed off. You protect the thing you might need, not just the thing you use every day.
The framing in this thread is full-duplex vs composable pipeline, but I think the real architecture is both running simultaneously — and this library is already halfway there.
The fact that qwen3-asr-swift bundles ASR, TTS, and PersonaPlex in one Swift package means you already have all the pieces. PersonaPlex handles the "mouth" — low-latency backchanneling, natural turn-taking, filler responses at RTF 0.87. Meanwhile a separate LLM with tool calling operates as the "brain", and when it returns a result you can fall back to the ASR+LLM+TTS path for the factual answer. taf2's fork (running a parallel LLM to infer when to call tools) already demonstrates this pattern. It's basically how humans work — we say "hmm, let me think about that" while our brain is actually retrieving the answer. We don't go silent for 2 seconds.
The hard unsolved part is the orchestration between the two. When does the brain override the mouth? How do you prevent PersonaPlex from confidently answering something the reasoning model hasn't verified? How do you handle the moment a tool result contradicts what the fast model already started saying?
The bit about multiplication being ~12x faster than addition is worth pausing on. In silicon, addition is the "easy" operation — but here the complexity hierarchy completely inverts. Makes sense once you think about it: multiplication decomposes into parallel byte-pair lookups (which neural nets handle trivially as table approximation), while addition has a sequential carry chain you can't fully parallelize away.
Funny enough, analog computing had the same inversion — a Gilbert cell does multiplication cheaply, while addition needs more complex summing circuits. Completely different path to the same result.
What I haven't seen discussed: if the whole CPU is neural nets, the execution pipeline is differentiable end-to-end. You could backprop through program execution. Useless for booting Linux, but potentially interesting for program synthesis — learning instruction sequences via gradient descent instead of search. Feels like that's the more promising research direction here than trying to make it fast.
I think everyone's focusing on the core count, but the packaging story is way more interesting here. This thing is 12 separate chiplets on 18A stacked on base dies made on Intel 3, connected to I/O tiles on Intel 7. Three different process nodes in one package, shipping at volume. That's nuts.
And it's clearly an IFS play too. Intel Foundry needs a proof point — you can publish PDKs all day, but nothing sells foundry credibility like eating your own cooking in a 288-core server part at 450W. If Foveros Direct works here, it's the best ad Intel could run for potential foundry customers.
The chiplet sizing is smart for another reason nobody's mentioned: yield. 18A is brand new, yields are probably rough. But 24 cores per die is small enough that even bad yields give you enough good chiplets. Basically AMD's Zen playbook but with a 3D twist.
Also — 64 CXL 2.0 lanes! Several comments here are complaining about DDR5 prices, which is fair. But CXL memory pooling across a rack could change that math completely. I wonder if Intel is betting the real value isn't the cores but being the best CXL hub in the datacenter.
The ARM competition is still the elephant in the room though. "Many efficient cores" is what ARM has always done natively, and 17% IPC uplift on Darkmont doesn't close that gap by itself.
Agree entirely with your take. The packaging story is awesome, I wish there were more details on the stacking used on this one.
But I am at a loss to how Intel are really going to get any traction with IFS. How can anyone trust Intel as a long-term foundry partner. Even if they priced it more aggressively, the opportunity cost in picking a supplier who decides to quit next year would be catastrophic for many. The only way this works is if they practically give their services away to someone big, who can afford to take that risk and can also make it worth Intel's continued investment. Any ideas who that would be, I've got nothing.
I suspect that timing might help Intel here, with so much of the better established foundries near fully allocated for the next two years, it may be more a question of availability than brand name risk. And for whatever problems Intel has, it's pretty unlikely they'd go completely under and disolve in less than a year. Good non completion clauses in the contracts can mitigate a good chunk of the remaining risk.
Not to mention potential customers who would prefer a US based foundry regardless. My guess is that there's a pretty large part of the market that would be perfectly fine with using Intel.
Worthless. Just looks how IFS worked out the previous two times they gave it a go. If you're not in the industry you may not even be aware it was a thing. And then not. Twice.
And that's why it's got to be a big company that takes this on, you need deep pockets to successfully sue a company like Intel. It's not realistic for most. Plus the huge opportunity cost of missing your market and wasting years having to start over. Again, a bigger company can survive that with multiple projects in parallel.
The strongest point here is one that rarely gets enough attention: the leap from "very smart" to "all-powerful" is completely unjustified. Even if you grant every assumption about alignment failures and emergent goals, you still need to explain how a neural network acquires physical resources, energy, supply chains, and weapons. Nobody ever does. It's just assumed that intelligence = omnipotence, which is basically theology.
Where I think the paper goes wrong is in treating the whole alignment problem as anthropomorphism. You don't need a machine to be "alive" or "want" things for misaligned optimization to be dangerous. A system relentlessly optimizing for a bad proxy metric can do real damage without any consciousness whatsoever — we already see this with recommendation algorithms. The paper waves this away by saying we caught the lab examples, but that's the whole point: we caught the easy ones.
The governance framing at the end is correct though and I wish it got more airtime. Regulating "AI" as one thing makes about as much sense as regulating "software" as one thing.
I run AI agents connected to databases, APIs, and filesystems. The problem: every agent gets full access to everything, with no enforcement layer between intent and execution.
SentinelGate is a firewall that sits between the agent and the system. Start the server, wrap any agent:
sentinel-gate start # MCP proxy only
sentinel-gate run -- python my_agent.py # full protection
It auto-detects the runtime (Claude Code, Gemini CLI, Python, Node.js) and injects interceptors. Every action is evaluated against CEL policy rules before execution. Denied actions never happen.
Three layers: MCP proxy, HTTP gateway, runtime hooks — one port, one Go binary, one Admin UI with audit trail.
Honest about limitations: runtime hooks are best-effort — a hostile agent can bypass them via FFI or raw sockets. The HTTP gateway adds network-level enforcement. Together they give you defense in depth, not an OS-level sandbox.
The proxy vs packet capture debate is a bit of a non-debate in practice — the moment TLS is on (and it should always be on), packet capture sees nothing useful. eBPF is interesting for observability but it works at the network/syscall level — doing actual SQL-level inspection or blocking through eBPF would mean reassembling TCP streams and parsing the Postgres wire protocol in kernel space, which is not really practical.
I've been building a Postgres wire protocol proxy in Go and the latency concern is the thing people always bring up first, but it's the wrong thing to worry about. A proxy adds microseconds, your queries take milliseconds. Nobody will ever notice. The actual hard part — the thing that will eat weeks of your life — is implementing the wire protocol correctly. Everyone starts with simple query messages and thinks they're 80% done. Then you hit the extended query protocol (Parse/Bind/Execute), prepared statements, COPY, notifications, and you realize the simple path was maybe 20% of what Postgres actually does. Once you get through that though, monitoring becomes almost a side effect. You're already parsing every query, so you can filter them, enforce policies, do tenant-level isolation, rotate credentials — things that are fundamentally impossible with any passive approach.
You can decode TLS traffic with a little bit of effort, tho you have to control the endpoints which makes it a bit moot as if you control them you can just... enable query logging
True, but logging tells you what happened, a proxy lets you decide what's allowed to happen before it hits the database. Policy enforcement, tenant isolation, that kind of thing. They're complementary really.
Yeah, more and more. Zero-trust is pushing TLS everywhere, even inside VPNs — lateral movement is a real thing. And several compliance frameworks now expect encryption in transit regardless of network topology. With connection pooling the overhead is basically zero anyway.
Indeed, if you're running the db in production and aren't using TLS, you're doing it wrong nowadays. Nearly every compliance framework will require it, and it's a very good idea anyway even if you don't care about compliance.
Encrypted in transit yes, but only between the VPN endpoints. Anything already inside the network (compromised host, rogue container, bad route) sees your queries in cleartext.
TLS on the connection itself gives you end-to-end encryption between your app and Postgres, no matter what's going on in the network in between. Same reason people moved to HTTPS everywhere instead of just trusting the corporate firewall. And with connection pooling you pay the TLS handshake once and reuse it, so the overhead is basically nothing.
Fair point, if it's a true point-to-point VPN between just the two boxes, there's not much "in between" to worry about. TLS on top is mostly defense in depth at that point. What I had in mind was the more common setup where your app and DB sit on a shared network (VPC, corporate LAN). The traffic between them is unencrypted, and you're trusting every piece of infrastructure in that path (switches, hypervisors, sidecar containers) to not be compromised.
The prompt injection thing is especially nasty for agents because they process untrusted input (web pages, emails, documents) and can take real actions. With a chatbot, prompt injection makes it say something dumb. With an agent that acts as you, a malicious payload hidden in an email could make it forward your contacts, reply on your behalf, whatever. You can't fix this in the model alone — you need an enforcement layer outside the model that limits what it can actually do regardless of what it thinks it should do. I'd bet Apple is working on exactly this and it's why they're taking their time.
RLS on Postgres is fine — I use it in production for tenant isolation and it works great. The problem is that Supabase puts it as the only thing standing between the public internet and your data. PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over. Behind a normal backend, a bad RLS policy is a defense-in-depth failure. In Supabase's model, it's a breach. That's a huge difference, and it gets worse when LLMs are writing the code because they'll happily scaffold a full app without ever thinking about access control.
> PostgREST translates HTTP straight into SQL, so if you get a policy wrong (or forget one), game over
Do note that by default in PostgreSQL/PostgREST, RLS is the third layer of AuthZ defense, you have table and column level security before and these are closed by default.
> In Supabase's model, it's a breach.
Supabase is currently working on being closed by default.
You're right, the GRANT layer is closed by default in PostgreSQL and PostgREST respects that. But in practice with Supabase, the very first thing you do is `GRANT ALL ON table TO authenticated` (and often `anon`) because nothing works through the client SDK without it. Every tutorial does this, every LLM-generated scaffold does this. At that point the first two layers are effectively gone and RLS is what's left. That's what I meant — not that PostgreSQL lacks defense in depth, but that Supabase's typical workflow collapses it down to one layer pretty quickly.
Good to hear they're working on closed-by-default though. Kind of proves the point that the current model has been a problem in practice.
MCP gives agents access to tools — databases, file systems, APIs. The problem is there's no access control layer. An agent with a database tool can run any query. An agent with file access can read anything. The only safeguard right now is a user clicking "Allow" on a prompt they probably won't read.
Sentinel Gate is a proxy that sits between your MCP client and servers. Every tool call gets checked against RBAC policies before it reaches the server.
The key design decision: *deterministic rules, not AI*. Policies are written in CEL (Common Expression Language). If a rule says deny, it denies. No LLM in the security path, no prompt injection possible against the firewall itself. You get a full audit log of every tool call — what was requested, what was allowed, what was blocked.
Built in Go. Self-hosted. PostgreSQL for audit logs, Redis for sessions. AGPL-3.0.
It's early — we're looking for feedback from teams running MCP in production or planning to. What's missing? What would make this useful for your setup?
The 30% usage stat makes it even more interesting. These aren't cash diehards. These are people who tap their card for everything but still don't want the analog option killed off. You protect the thing you might need, not just the thing you use every day.
reply