--- title: "New Problems in the Computing Stack" slug: new-problems-in-the-computing-stack date: 2026-07-17 category: WHY_WE_BUILT_THIS depth: conceptual author: Stephane abstract: Linux, Windows, macOS, iOS, and Android are extraordinary engineering achievements built on a shared design assumption — the privileged operator is a human being. AI agents break that assumption. Here are the structural problems that follow, and why they can't be patched away. --- # New Problems in the Computing Stack Linux powers most of the world's servers. Windows runs most enterprise desktops. macOS, iOS, and Android run the personal devices of billions of people. These are extraordinary engineering achievements, and the world depends on them. Every generation of OS design has followed the same pattern: a new class of capability creates a new class of threat, and the industry redesigns around it. Unix introduced process isolation — memory became inaccessible across process boundaries. iOS and Android went further, questioning whether the user should hold elevated privilege at all: iOS deliberately removed user-accessible root, sandboxed every app, and made the platform — not the person — the trusted entity. Each generation was an improvement. Each improvement was motivated by a threat the previous design hadn't anticipated. AI agents are the next class of capability that the current generation wasn't designed for. They don't operate at human speed, human scale, or with human accountability. When you give an AI agent elevated capabilities — access to your files, your credentials, your APIs, your data — and run it on infrastructure built for a human operator, you're applying a substrate to a problem it was never meant to solve. That mismatch creates a new class of infrastructure problems. Here are the ones we think about most. --- ## Accountability at machine speed and scale When a human operator makes a decision, you can ask them what happened. When an AI agent makes fifty thousand decisions in a day — on a server, on a laptop, on your phone, on your behalf — there is no human to ask. The only record is the log. But in every current system, that log is written by software, stored somewhere the software can reach, and modifiable by anything with sufficient privilege. An agent that behaves unexpectedly, or is compromised, or simply has a bug, can operate in a way that leaves no reliable trace. The problem compounds with volume. Audit mechanisms were designed to produce records a human — or a downstream SIEM — can query after the fact. They weren't designed to be tamper-resistant against a privileged process, to handle agent-scale event rates, or to be structured enough for automated oversight. At enterprise scale, audit infrastructure ends up perpetually playing catch-up. On consumer devices, personal AI agents that manage your calendar, email, and files produce essentially no structured, queryable record of what they did. The accountability layer was built for human speed and human volume. It doesn't hold at agent scale. --- ## Credentials that no process should ever see Credential security has already followed the generational improvement pattern once. First-generation systems handed secrets to processes directly — environment variables, config files, anything with filesystem access could read them. The second generation genuinely improved on this: Android Keystore with hardware-backed keys, and the iOS Secure Enclave, allow a cryptographic private key to never leave secure hardware. The app asks "sign this data" and receives a signature, without ever seeing the key material. That was a real advance. But it covers only one narrow class of credential: cryptographic keys used in operations the hardware understands. AI agents need a much broader class of secret — API keys, OAuth bearer tokens, service passwords, anything that has to be transmitted verbatim in an HTTP header. For all of those, the current generation has no equivalent. The credential is still visible to the process that holds it. A compromised agent, a bug in prompt handling, a supply-chain issue in a dependency — any of these can result in exfiltration with no OS-level record that the credential was ever read. The OS hands over the secret and walks away. The next generational step is to extend what iOS and Android did for cryptographic keys to the full class of secrets agents use: credential injection at the kernel level, at call time, with the raw value never surfaced to the agent process. Every access a ledger entry. --- ## Multi-agent trust without a shared human supervisor In an organisation, trust between people is maintained by shared institutional accountability. When Agent A delegates a task to Agent B — on a server orchestrating a pipeline, or on a personal device where an assistant hands work to a sub-agent — what does B have to verify that A's instruction was legitimate? Current systems provide process isolation: one process can't directly read another's memory. They don't provide instruction attestation: a way for B to verify that A's delegation was genuinely authorised, not forged, not a prompt injection, not a compromised instruction from a malicious upstream. The trust chain is only as strong as its weakest link, and the weakest link is currently invisible to the OS. One direction being explored is using internal inference models to attest instruction provenance within the trust boundary. We're looking at this. But even with model-level attestation, the OS remains unaware of the trust chain — enforcement and audit remain application-layer concerns. --- ## Memory that belongs to the agent, not the system AI agents accumulate knowledge across sessions. Application-layer approaches already exist — graph database providers like Neo4j offer structured, queryable memory stores that agents can write to and read from. They work, for the applications that choose to implement them. But application-layer memory governance has a ceiling. Every application that wants it has to build it in independently. Memory from different agents, different apps, different devices is never connected by default — universality would require every provider to agree on the same schema and integration layer, which in practice means it doesn't happen. The memory model also has to be designed upfront: types and relationships must be defined before events can be captured against them. Agents operating in novel contexts produce experience that falls through the gaps of whatever schema was specified in advance. The result is expensive to operate, slow to query across systems, and never truly real-time. OS-level memory governance changes the constraint: the kernel manages agent memory as a primitive, which means it's universal across every agent running on the system, requires no per-application integration, and adapts in real time to what agents are actually encountering — not just what the developer anticipated. --- ## Identity and execution that span devices Your phone and your laptop are governed by different operating systems with different permission models, different keystores, and different audit logs. To the OS, they are different computers. An AI agent that operates across both — reading your phone calendar to inform what your laptop assistant does, or handing off a task between a mobile session and a desktop session — crosses a security boundary that no current system was designed to govern. The agent is arbitrating cross-device trust on its own, because the substrate provides no primitive for it. This isn't a gap that existing systems are working toward closing — cross-device synchronisation is treated as an application-layer concern: cloud sync, MDM, platform APIs. On the enterprise side, an agent spanning a mobile device and a cloud node has no unified execution context. It's two separate processes on two separate systems, stitched together by the application. Noesis is designed differently: one OS, multiple devices, unified execution context. An agent's identity, permissions, memory, and audit trail are consistent whether it's running on a phone or a server — because it's the same OS on both. --- None of these are failures. Every current OS was built to solve specific problems, and it solved them well. Computing has moved into new territory. The territory has new requirements — on enterprise infrastructure and on the personal devices people carry every day. This is why we're building Noesis. Not to replace what's there, but to build the substrate that didn't need to exist before agents did: one where accountability, credential governance, multi-agent trust, auditable memory, and unified cross-device execution are OS primitives, not afterthoughts. --- *— Stephane, Pensiv Inc.* *Contact: stephane@pensiv.work*