every computer you have ever used was built on one assumption: that a person sits in front of it. agents break that assumption. they are programs that read, decide and act on their own, and they are fast becoming the busiest users of the machines we own. this is a proposal for arbor, an operating system rebuilt from the bottom up for agents and for the people who work with them: what it would be, why the systems we have cannot simply be patched into it, and how it could be built, one step at a time.

a proposal, not a product. nothing here exists yet, except the parts it borrows

the busiest users are no longer people

a computer's oldest assumption is that a person is using it. at the companies that build ai, that assumption is already failing, and one of the tools programmers trust most has been outgrown.

an operating system is the software underneath everything else on a computer. it decides which program runs when, who may open which file, how much memory each program gets, and how programs talk to each other and to the world outside. think of it as the management of a large building: it hands out rooms and keys, keeps the lights and the water running, and keeps the list of who is allowed where. macos, ios, android and linux all descend, in their ideas if not their code, from unix, which two engineers at bell labs began writing in 1969 for a machine shared by a handful of people at terminals.

an agent is a program driven by a language model, the kind of software behind claude, chatgpt and gemini, that is given a goal and works toward it on its own. it reads files, runs commands, searches the web, writes code, calls other services and, more and more often, spends money. a person asks, and the agent does the hundred small steps in between.

in may 2026, anthropic was merging about 2,500 changes a day into its code. by september it was more than 30,000, a change every three seconds, day and night. git, the tool nearly every programmer in the world uses to keep track of changes to code, was never designed for that, and neither were the systems built around it. so anthropic built its own, called scion, and described it in october (anthropic 2026).

git is the first piece of the old machinery to be outgrown, and it will not be the last. every layer of a computer, from the chips to the screen, was shaped by the same assumption, and agents lean on every one of them. the rest of this article is about what should come after.

five bets that held for fifty years

unix made five bets about who would use a computer and how. all five were right for people, and all five are wrong for agents.

none of these bets was a mistake. each one made computers simpler, cheaper and easier to understand, which is why they outlived the machines they were made for. but each one quietly assumes that the user is a person, and agents are not people.

the fourth bet is the easiest to see. unix programs were meant to be small tools that pass text from one to the next, and the rule was written down in a sentence that generations of programmers learned by heart:

Write programs to handle text streams, because that is a universal interface.

— doug mcilroy's rule for unix programs, as peter salus set it down in A Quarter Century of UNIX

for a person, text is universal. for a model, it is a guessing game. is this column a size or a date? did that command fail, or did it only print a warning? is this line a file name with a space in it, or two file names? agents spend real effort, and make real mistakes, reading output that was laid out for human eyes.

the ideas that lost, and why they win now

none of this is news to the people who study operating systems. better answers to every one of these bets were built, published and tested decades ago. they lost to unix mostly for one reason: they asked too much of the people using them.

agents change that bargain. the paperwork that made these systems tiring for people, writing labels, passing keys around, describing data, checking proofs, is precisely the kind of patient, exact, repetitive work that software does well. a safe design that cost a person an hour a day costs an agent nothing at all. the ideas that lost to unix were not wrong. they were early.

seven new building blocks

unix built everything from a handful of simple ideas: users, programs, files and text. arbor keeps that discipline, and changes the ideas.

arbor is named after the latin word for tree, because in it almost everything branches. a whole computer can branch into copies in an instant. permission branches as it is handed down from a person to an agent, and from that agent to its helpers. and every task is a branch, which is either kept or cut off. these are the seven ideas everything else is built from:

an object instead of a file

a piece of data that knows what it is, a photo, a table, a contract, a function, and is never written over. a change makes a new version and keeps the old one. each version is named by a fingerprint of what is in it, so two copies of the same thing are stored once. secrets are objects too, of a special kind: they can be used, and never read.

a world instead of a disk and its folders

everything an agent can see, as one whole. a world can be copied in an instant, because nothing is really copied until something changes, and copies can be compared, merged or thrown away like drafts of a document. git does this for code. arbor does it for everything.

a cell instead of a program, a container or a virtual machine

the place where work happens. a cell starts in a fraction of a millisecond, costs nothing while it waits, and can be frozen, copied to another machine, or played back exactly as it ran.

a key instead of a user account

permission to do one thing, to one object, until a set time, within a set budget. a key can be passed on only in a narrower form, and taken back at any moment. there are no users and no all-powerful administrator, only keys. computer scientists call them capabilities.

an effect new

anything that reaches the world outside: an email, a payment, a deployment, a post. an effect waits in an outbox until a rule or a person releases it.

a channel instead of pipes and sockets

a line between two cells that carries typed messages, objects and keys, and never bare text. every service on a channel describes what it does, so every service is a tool an agent can use the moment it appears.

a budget new

what a task may spend: tokens, money, time on the accelerators, energy, and the attention of the people involved.

under all seven runs the ledger, a record of every step every agent takes: what it did, who allowed it, what it read and what it cost. nothing in arbor happens off the record.

one task, start to finish

the clearest way to see the pieces is to follow one ordinary request through all of them.

a developer at a small company asks an agent for a chore every programmer knows: move the payment code to the new version of the payment provider's SDK, the library a company publishes so that other people's code can talk to its service, and put the result on staging, the private copy of the website where changes are tried before customers see them. the developer allows five dollars and two hours. what follows is imagined, but every step in it is something arbor is designed to do.¹

nothing so far has touched the real code, the real server or the team's chat. worlds a and c are thrown away whole, with nothing left over to clean up. what is left is one decision, set out on a card:

the developer presses a small physical key on the desk, the kind of security key many companies already give their staff for signing in. the change and both effects are released together, or not at all. the whole task, drawn as the tree it was:

the money is accounted for as carefully as the code. a budget in arbor is not a bill that arrives at the end of the month. it is a limit the system holds while the work happens, and every world and every check draws from it as it goes:

two days later, a tester finds a problem on staging. one command puts everything back as it was:

$ world log staging --last 2
16 oct 14:32  merged world b        allowed by you, with your key
16 oct 14:32  deployed to staging   released from the outbox
$ world revert staging --to "16 oct 14:31"
put back 18 files, and the deployment before this one.
the note in the payments channel was already read,
so a correction was posted under it.

the last line matters. some effects can be undone and some cannot: a deployment can be rolled back, but a message that has been read cannot be unread. arbor knows which is which before anything leaves the machine, and the decision card says so. an effect that cannot be undone, only answered, is marked as a one-way door.

why try three times

agents make small mistakes, and long tasks give small mistakes room to add up. if each step of a task goes right 99 times in 100, a task of a hundred steps goes right from end to end only about a third of the time. trying the same task several times at once, in separate worlds, and letting a checker keep the try that worked, changes the odds a great deal:

an agent that makes 10 mistakes in a thousand steps gets through a task of 100 steps without one

37

% of the time. given 3 worlds at once, and a checker to keep the one that worked, it comes back with a flawless result

75

% of the time.

keys, not passwords

an agent should be able to do exactly what its task needs, for as long as the task lasts, and nothing more.

some cars come with a valet key. it starts the engine and opens the doors, but it will not open the boot or the glove box, so you can hand your car to a stranger without handing over everything in it. computers today have no valet keys. an agent runs as you, which means it can do anything you can: read every file, send email in your name, spend from your card, delete your photos. the only thing standing between an agent and a disaster is the agent's own judgement, and that judgement can be hijacked.

the hijacking has a name, prompt injection: instructions hidden in something the agent reads, a web page, an email, a document, that the agent mistakes for instructions from you. a language model reads everything as one long stream of words, and it has no reliable way to tell whose words are whose.

arbor does not leave that question to the model. every word that enters a cell carries a label saying where it came from, and the label travels with everything made from it. this is what a cell sees when you ask it to summarise a web page, with your words in one ink and the page's in another:

a fooled agent in arbor is a nuisance, not a disaster. any effect that the page's words helped to cause, and that would carry your data out, stops at the outbox and waits for you. the programmer simon willison gave this danger a name that has stuck, the lethal trifecta (willison 2025). an agent becomes dangerous when it has three things at once: access to private data, exposure to words from strangers, and a way to send data out. any two are safe enough. all three let a stranger's words carry your data away. arbor turns his warning into a rule the machine enforces: a cell may hold any two, and the third needs a person.

keys can be handed on, but only in a narrower form, so authority shrinks as it travels down a chain of agents and never grows. this is the payment task from the last section, as its key was handed down:

secrets, the passwords and tokens that let software use other companies' services, get the same treatment. today an agent that can use a secret can also read it, and a secret that has been read can be repeated, logged or leaked. in arbor a secret is a handle. the cell asks for a request to be made with it, and the system adds the secret at the very edge of the machine, on the way out. the agent never sees it, so it can never give it away.

# today, the agent runs as you
export PAYMENTS_TOKEN=pt_4f9a…
export DEPLOY_TOKEN=dt_88c1…
agent --allow-everything

# it reads both, and can do anything

# in arbor, the agent holds two keys
key payments --use secret:payments
key deploy --to staging --until 2h
agent --keys payments,deploy

# it uses the first, never reads it

nothing leaves without a receipt

inside a world an agent can try anything, because nothing there is real until it leaves.

most of what an agent does is harmless while it stays inside the machine: reading, drafting, running tests, building things. the danger lies in the few actions that reach the outside: a payment, an email, a deployment, a post, a record deleted from someone else's database. arbor calls these effects, and treats them the way a careful company treats money: nothing goes out without passing a desk.

an effect is first written to an outbox, like an email waiting to be sent. rules decide what happens next. a small effect that can be undone, and that matches a rule someone has already written, goes straight out. anything else waits for a person, who sees it on a card with its cost and whether it can be taken back. either way, it leaves a receipt.

1. an agent asks
2. the outbox holds it
3. a rule or a person decides
   • released
   • refused
4. it leaves once, with a receipt

the word once matters more than it looks. computers crash and networks drop, and a program that starts again halfway through a job can easily send the same payment twice. a cell in arbor remembers which of its effects have already left, so a cell that crashes and is started again carries on from where it stopped without repeating itself. the software industry calls this durable execution, and today it comes from separate products that a program has to be written around, such as temporal (wheeler 2025). in arbor it is simply how things work.

every step lands in the ledger: what was done, by which cell, with which key, given by whom, what it read, what it cost, and how to undo it. it is the flight recorder of the machine. one line of it, from the task above, reads like this:

{
  "at": "2026-10-16T14:32:10Z",
  "cell": "payments-migrator/b",
  "did": "release effect: deploy payments to staging",
  "key": "deploy-staging, given by you, until 16:31",
  "allowed": "by you, with your hardware key",
  "read": ["world:b@7f3a91", "service:staging"],
  "cost": { "usd": 0.02, "tokens": 1840 },
  "undo": "deploy payments@4c1e07 to staging"
}

because a cell can be recorded exactly as it ran, a whole task can also be played back, step by step, on another machine months later, to find out why something happened. programmers already do this for single programs with a tool called rr, which records a run of a program so that it can be replayed exactly, its bugs included (o'callahan and others 2017). arbor makes recording the default for everything. europe's law on artificial intelligence will require its riskiest systems to keep logs of their own working, automatically, for as long as they are in use (european union 2024). for a company that has to explain what its software did, the ledger is the explanation.

the model becomes part of the machine

today a model lives behind a web address. in arbor it is a service of the system, the way memory and the disk are.

the expensive part of an agent is the model that thinks for it, and the expensive part of the model is reading. before it writes a single word, a model has to read its instructions, the conversation so far and whatever files it was given, and it keeps what it has read in a working memory called the kv cache. an agent that re-reads the same long instructions a thousand times a day can spend most of its money reading the same thing again.

operating systems solved a problem shaped exactly like this half a century ago. a computer's memory is cut into small pages, handed out as they are needed, shared between programs that need the same thing, and moved to slower storage when nobody is using them. in 2023 a team at berkeley applied those ideas to a model's working memory, in a system they called vllm (kwon and others 2023). the systems before it put only a fifth to two fifths of that memory to use. vllm uses almost all of it:

arbor goes one step further and treats the model's memory as the system's memory. long instructions shared by many agents are read once and kept, the way programs share one copy of a library instead of each loading its own. a model's memory is saved and moved between machines with its cell. some of this already runs at scale: moonshot ai serves its kimi models with mooncake, a design built around storing that working memory and moving it between machines, and in daily use it let the same machines handle more than twice as many requests (qin and others 2025).

the same idea works for what an agent knows. today a model is fed everything that might matter, in the hope that the right thing is somewhere inside. in arbor it is handed short handles instead, names for documents, tables and earlier conversations, and it asks the system to open one when it needs it, the way a program's memory is brought in a page at a time. the model stops carrying the whole library on its back and starts working with a librarian.

the last service is the checker, which arbor calls a verifier: tests, type checkers, proof checkers, other models, anything that can tell whether a piece of work is right for less than the work cost to do. verifiers are how three worlds became one decision in the task above, and they are the reason a person reviews one finished piece of work instead of a hundred steps.

what the labs get

the companies that build models run some of the largest computers on earth, and spend a great deal of effort working around software that was designed for something else.

source control that is simply storage

scion's design reads like a sketch of arbor's storage. its servers hold the one true copy of the code and do the heavy work, merging changes and searching their history. everything is stored under a fingerprint of what is in it, so nothing is stored twice and nothing, once stored, ever changes. a change is a small record added to a log, so making one is cheap. a working copy is optional, and virtual: a file is fetched only when something opens it. and no single lock makes every change wait its turn. changes are tested after they merge and again before they are deployed, and when two of them collide, claude usually fixes the conflict (anthropic 2026). in arbor this is not a tool for code. it is how every world is stored, whatever is in it. it is also fast, and fastest for agents:

a fresh computer for every attempt

much of how a model learns to be an agent is practice. it attempts a task in a practice environment, a checker scores the attempt, and what worked is reinforced, a method called reinforcement learning. a lab runs enormous numbers of these attempts, and each one needs a fresh computer of its own that starts fast and leaves nothing behind. today that is mostly built from containers and virtual machines. firecracker, the virtual machine amazon built for its serverless computing, starts a program in under 125 milliseconds, using under 5 megabytes of memory of its own, and one server can start up to 150 of them a second (agache and others 2020). lighter sandboxes go further: wasmtime, which runs programs compiled to webassembly, can start a fresh copy of a program as large as firefox's javascript engine in five millionths of a second (fallin 2022). a world forked from a template would start as quickly, since nothing in it is copied until it changes, and an attempt that was recorded can be replayed exactly when its score looks wrong.

a machine that mends itself

the larger the computer, the more often some part of it breaks. while meta trained llama 3 on as many as 16,384 graphics processors at once, it counted 466 interruptions in 54 days: 47 planned, for upgrades and the like, and 419 that were not. most of the 419 were the hardware, and most of the hardware was the processors themselves (meta 2024):

meta's engineers kept that run training more than nine tenths of the time, and had to step in by hand only three times, with automation handling the rest (meta 2024). that is an achievement of people and tools working around the operating system. arbor would make it the system's own job: know the health of every chip, move work off one that starts to fail, save a run's state without stopping it, and treat a chip that quietly gives a wrong answer as something to expect, not a mystery to chase.

one record of where everything came from

a lab is constantly asked where something came from. which data was this model trained on? which tests did it pass before it was released? if this file turns out to be a problem, which models learned from it? today the answers are pieced together from logs, spreadsheets and memory. in arbor each step is a line in the ledger, so the whole history is a graph that can be searched:

containment, by level

laboratories that handle dangerous germs work at one of four biosafety levels, each with stricter walls than the last. anthropic already grades its own models by safety levels modelled on those, its ASLs (anthropic 2023). an operating system could give such grades walls, enforced by the machine rather than by procedure:

what everyone else gets

for a person with a laptop and an idea, arbor should feel less like an operating system and more like a well-run workshop.

building an agent today means gluing together a model, a sandbox, a pile of secrets, a queue, a database and a great deal of hope. in arbor an agent is a few cells, the keys they hold and a budget, written in one short file. this one reads invoices from a mailbox and copies them into a spreadsheet:

name  = "invoice-helper"
cells = ["reader", "writer"]
model = { name = "claude-haiku-5-5", effort = "medium" }

[keys]
reader = ["mail:invoices --read", "secret:accounting --use"]
writer = ["sheet:payments-2026 --append"]

[budget]
per_day = "2 usd"
ask_me  = ["any payment", "anything over 50 usd"]

1. the model it thinks with, and how hard it thinks.
2. the reader may read one folder of one mailbox, and use the accounting secret without ever seeing it.
3. it stops for the day at two dollars, whatever happens.
4. what still needs a person: anything that moves money, and anything large.

nothing in that file says how to sandbox the agent, where to keep the secret, how to retry when the mail server is down or how to log what happened. the system does all of that, the same way for every agent. and because every run is recorded, a run that went wrong becomes a test: replay it after the fix, and watch it go right.

every service in arbor describes itself once, and the system shows that one description to each kind of reader in the form it needs: a tool an agent can call, a typed library a program can import, and a form a person can fill in. a calendar, described once:

{
  "service": "calendar",
  "does": "book",
  "needs": { "who": "person", "when": "time", "minutes": "number" },
  "gives": "booking",
  "effect": { "sends": "invitations", "undo": "cancel" }
}

{
  "name": "calendar_book",
  "description": "book a meeting. sends invitations, which can be cancelled.",
  "input_schema": {
    "type": "object",
    "properties": {
      "who": { "type": "string" },
      "when": { "type": "string", "format": "date-time" },
      "minutes": { "type": "integer" }
    }
  }
}

import { calendar } from "arbor:services";

const booking = await calendar.book({
  who: ana,
  when: monday.at("09:00"),
  minutes: 30,
});

the middle one is the shape that tools already take for today's models, through the model context protocol, which anthropic opened up in 2024 (anthropic 2024). in arbor nobody writes it by hand. it is generated from the service, so it can never fall out of date with what the service does. agents that work with other agents have a protocol for that too, google's agent2agent (google 2025), and arbor's channels would speak both.

for most people, arbor has no command line at all. it has one screen that answers three questions: what are my agents doing, what have they spent, and what is waiting for me. everything that waits is a card, like the one in the task above. a card is approved with y, refused with n and opened in full with space, and a card approved the same way three times offers to become a rule, so the same question is never asked a fourth time. a person's attention is the scarcest thing in the whole system, and arbor counts it as carefully as money.

the hardware it asks for

software can only do so much on chips designed for another era. this is what arbor would ask of the hardware, and how much of it already exists.

start with memory. most of the worst security bugs are mistakes in how a program handles memory: reading past the end of a list, or using something after it was thrown away. they are old, well understood, and still everywhere:

CHERI, a design from the university of cambridge and sri international, fixes this in the chip itself. every pointer, the address a program uses to reach a piece of memory, carries its own limits, and the processor refuses to step outside them. microsoft's security engineers went back over the 655 memory bugs serious enough for them to fix in 2019, and estimated that cheri alone would have stopped about a third of them, and cheri with two further protections at least two thirds (joly and others 2020). arm has since built it into a prototype chip, called morello, and sent boards to researchers in 2022 (arm 2022). for arbor, cheri is the hardware form of a key: an authority that cannot be forged, built into every pointer.

two of the asks deserve a word more. the first is honesty from the chips. engineers at google have described what they call mercurial cores: processors that, every so often and without any warning, compute a wrong answer. they find a few in every several thousand machines (hochschild and others 2021), and facebook, now meta, has reported hundreds of faulty processors across hundreds of thousands of machines (dixit and others 2021). an operating system that assumes chips are always right has no defence against a chip that is sometimes wrong. arbor would ask chips to report what they know about their own health, and use its verifiers to catch what they do not.

the second is memory that can move. memory can be half of what a server costs, and in microsoft's cloud up to a quarter of it can sit stranded, unusable, because every processor beside it has been rented out (li and others 2023). CXL, a standard way to attach memory over the same connections that expansion cards use, lets machines share a pool of it. agents are bursty: a cell spends most of its life waiting for a model or a person, needing almost nothing, and then builds or tests something and needs a great deal. pooled memory is the difference between paying for every cell's peak and paying for the average.

the last ask is the smallest and the most important. the consent key is the small physical key from the task above, the kind many companies already give their staff for signing in, and arbor treats it as the one thing no agent can fake. releasing an effect that cannot be undone, granting a broad key or changing a rule takes the press of a finger. an agent can prepare everything, and only a person can say yes.

how it gets built

no one replaces an operating system in one move. arbor arrives in three steps, and each step is useful on its own.

the first step runs on top of linux, on the computers people already own. worlds are built from the copy-on-write file systems linux already has, cells from the sandboxes it already has, and the outbox is a gatekeeper at the edge of the network that every request has to pass through. nothing here needs a new kernel or a new chip, only careful work. the second step puts arbor underneath linux instead of on top of it: a small, proved kernel at the bottom, and linux programs above it, each in a cell, none the wiser. google's fuchsia already runs unmodified linux programs this way, through a layer that answers them as linux would (fuchsia 2021). the third step is the hardware, designed together with the system that runs on it.

the first thing to build is small on purpose, because a proposal like this one is believed when it can be seen. it is a demonstration that fits in a few minutes:

1. take a developer's machine as it is every file and setting, frozen into a world in seconds, without copying anything.
2. let an agent work in three copies of it each one a world of its own, each with keys that end with the task.
3. show one difference and one outbox what changed, what it cost, and everything that wants to leave the machine.
4. keep it with one press, or throw it all away and if it is kept, take it back later with one command.

that demonstration needs no permission from anyone and no new hardware. it would already make agents on today's laptops safer than they are, and it would show the rest of the idea in a form people can try.

what could sink it

a proposal that hides its problems is a sales pitch. these are the ones that could stop arbor, and what might be done about each.

why now

the case for arbor in one paragraph, and the reason it could not have been made ten years ago.

for fifty years the safest designs for a computer lost because they asked too much of people. keys, labels, proofs, transactions: all of them were right, and all of them were tiring. the users now arriving do not tire. they will fill in every label, pass every key and check every proof, and they need a machine that insists on it, because they can be fooled in ways people rarely are. unix was built for the users its makers had: a few people at terminals, sharing one machine. the users are changing, and the machine should change with them.

every computer you have ever used was built for a person sitting in front of it. the next one should be built for the people, and the agents, who share it.

words used here

agent

a program driven by a language model, given a goal and left to work toward it: reading, deciding and acting, step after step, with no person approving each step.

capability

the computer scientist's word for what this article calls a key: a token that grants one specific right, to one specific thing, and that can be handed on only in a narrower form.

cell

arbor's place for work, in the place of a program, a container or a virtual machine. it starts in a fraction of a millisecond, can be frozen, copied and moved, and can be played back exactly.

effect

anything an agent does that reaches outside the machine, such as a payment, an email or a deployment. effects wait in the outbox until they are released.

kv cache

a language model's working memory of what it has read so far in a conversation, kept so that it does not have to read it all again for every word it writes.

ledger

arbor's record of every step: what was done, by which cell, with which key, given by whom, what it read, what it cost and how to undo it.

outbox

where effects wait before they leave the machine, until a standing rule or a person releases them.

prompt injection

an attack on an agent: instructions hidden in something it reads, such as a web page or an email, written to be mistaken for instructions from its user.

verifier

anything that can check a piece of work for less than it cost to do: a test, a type checker, a proof checker, or another model.

world

everything an agent can see, as one whole that can be copied in an instant, compared with another, merged or thrown away.

notes

1. the task, its numbers and its commands are imagined, to show how the parts would fit together. every number about the world as it is, from merges a day to the causes of a training run's interruptions, comes from a source in the list below.
2. the formula is generous. it assumes that tries go wrong independently of each other, and that the checker always recognises a flawless result. real tries share blind spots, and real checkers miss things. the point survives the simplification: cheap retries and good checkers make an unreliable agent much more dependable.

references

1. Nick G. and the source control team (2026). Redesigning source control at Anthropic. Anthropic Engineering, 13 October 2026. anthropic.com/engineering/redesigning-source-control
2. Salus, P. H. (1994). A Quarter Century of UNIX. Addison-Wesley.
3. Hardy, N. (1985). KeyKOS Architecture. ACM SIGOPS Operating Systems Review, 19(4), 8–25. doi.org/10.1145/858336.858337
4. Zeldovich, N., Boyd-Wickizer, S., Kohler, E. & Mazières, D. (2006). Making Information Flow Explicit in HiStar. 7th USENIX Symposium on Operating Systems Design and Implementation (OSDI '06), 263–278. usenix.org/conference/osdi-06
5. Klein, G., Elphinstone, K., Heiser, G. et al. (2009). seL4: Formal Verification of an OS Kernel. 22nd ACM Symposium on Operating Systems Principles (SOSP '09), 207–220. doi.org/10.1145/1629575.1629596
6. Porter, D. E., Hofmann, O. S., Rossbach, C. J., Benn, A. & Witchel, E. (2009). Operating System Transactions. 22nd ACM Symposium on Operating Systems Principles (SOSP '09), 161–176. doi.org/10.1145/1629575.1629591
7. Pike, R., Presotto, D., Thompson, K., Trickey, H. & Winterbottom, P. (1992). The Use of Name Spaces in Plan 9. 5th ACM SIGOPS European Workshop. Reprinted in Operating Systems Review, 27(2), 72–76, 1993. 9p.io/sys/doc/names.html
8. Giampaolo, D. (1999). Practical File System Design with the Be File System. Morgan Kaufmann.
9. Willison, S. (2025). The lethal trifecta for AI agents: private data, untrusted content, and external communication. Simon Willison's Weblog, 16 June 2025. simonwillison.net/2025/Jun/16/the-lethal-trifecta
10. Wheeler, T. (2025). The definitive guide to Durable Execution. Temporal blog, 6 May 2025. temporal.io/blog/what-is-durable-execution
11. O'Callahan, R., Jones, C., Froyd, N., Huey, K., Noll, A. & Partush, N. (2017). Engineering Record and Replay for Deployability. 2017 USENIX Annual Technical Conference, 377–389. usenix.org/conference/atc17
12. European Union (2024). Regulation (EU) 2024/1689, the Artificial Intelligence Act, article 12: record-keeping. Official Journal of the European Union. eur-lex.europa.eu/eli/reg/2024/1689/oj
13. Kwon, W., Li, Z., Zhuang, S., Sheng, Y., Zheng, L., Yu, C. H., Gonzalez, J. E., Zhang, H. & Stoica, I. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. 29th ACM Symposium on Operating Systems Principles (SOSP '23), 611–626. doi.org/10.1145/3600006.3613165
14. Qin, R., Li, Z., He, W., Cui, J., Ren, F., Zhang, M., Wu, Y., Zheng, W. & Xu, X. (2025). Mooncake: Trading More Storage for Less Computation — A KVCache-centric Architecture for Serving LLM Chatbot. 23rd USENIX Conference on File and Storage Technologies (FAST '25), 155–170. usenix.org/conference/fast25/presentation/qin
15. Agache, A., Brooker, M., Florescu, A., Iordache, A., Liguori, A., Neugebauer, R., Piwonka, P. & Popa, D.-M. (2020). Firecracker: Lightweight Virtualization for Serverless Applications. 17th USENIX Symposium on Networked Systems Design and Implementation (NSDI '20), 419–434. usenix.org/conference/nsdi20/presentation/agache
16. Fallin, C. (2022). Wasmtime 1.0: A Look at Performance. Bytecode Alliance blog, 6 September 2022. bytecodealliance.org/articles/wasmtime-10-performance
17. Llama Team, AI @ Meta (2024). The Llama 3 Herd of Models. arXiv:2407.21783, section 3.3.4 and table 5. doi.org/10.48550/arXiv.2407.21783
18. Anthropic (2023). Anthropic's Responsible Scaling Policy. 19 September 2023. anthropic.com/news/anthropics-responsible-scaling-policy
19. Anthropic (2024). Introducing the Model Context Protocol. 25 November 2024. anthropic.com/news/model-context-protocol
20. Google (2025). Announcing the Agent2Agent Protocol (A2A). Google Developers Blog, 9 April 2025. developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability
21. MSRC Team (2019). A proactive approach to more secure code. Microsoft Security Response Center blog, 16 July 2019. microsoft.com/en-us/msrc/blog/2019/07
22. The Chromium Projects. Memory safety. chromium.org/Home/chromium-security/memory-safety
23. Joly, N., ElSherei, S. & Amar, S. (2020). Security analysis of CHERI ISA. Microsoft Security Response Center, 14 October 2020. microsoft.com/en-us/msrc/blog/2020/10
24. Arm (2022). Morello Research Program Hits Major Milestone with Hardware Now Available for Testing. Arm Newsroom, 20 January 2022. newsroom.arm.com/news
25. Cross, D. RFD 284: Loading the Host Operating System. Oxide Computer Company. rfd.shared.oxide.computer/rfd/0284
26. Cantrill, B. (2021). Hubris and Humility. Oxide Computer Company blog, 30 November 2021. oxide.computer/blog/hubris-and-humility
27. Hochschild, P. H., Turner, P., Mogul, J. C., Govindaraju, R., Ranganathan, P., Culler, D. E. & Vahdat, A. (2021). Cores that don't count. Workshop on Hot Topics in Operating Systems (HotOS '21), 9–16. doi.org/10.1145/3458336.3465297
28. Dixit, H. D., Pendharkar, S., Beadon, M., Mason, C., Chakravarthy, T., Muthiah, B. & Sankar, S. (2021). Silent Data Corruptions at Scale. arXiv:2102.11245. doi.org/10.48550/arXiv.2102.11245
29. Li, H., Berger, D. S., Hsu, L., Ernst, D., Zardoshti, P., Novakovic, S., Shah, M., Rajadnya, S., Lee, S., Agarwal, I., Hill, M. D., Fontoura, M. & Bianchini, R. (2023). Pond: CXL-Based Memory Pooling Systems for Cloud Platforms. ASPLOS '23, vol. 2, 574–587. doi.org/10.1145/3575693.3578835
30. Fuchsia (2021). RFC-0082: Running unmodified Linux programs on Fuchsia. fuchsia.dev/fuchsia-src/contribute/governance/rfcs/0082_starnix
31. The gVisor Authors. gVisor documentation. gvisor.dev/docs
32. UALink Consortium (2025). The UALink 200G 1.0 Specification, ratified 8 April 2025. ualinkconsortium.org/specification
33. Ultra Ethernet Consortium (2025). The Ultra Ethernet Specification 1.0, released 11 June 2025. ultraethernet.org