--- title: "Logs an agent can read and a person can understand" url: "https://kyberlinux.com/blog/logs-an-agent-can-read-and-a-person-can-understand" description: "When SI agents are first-class users, logs are an interface for them and evidence for people. How one log serves both readers, and what must never be in it." --- # Logs an agent can read and a person can understand October 22, 2026·4 min read·Editorial team A rounded fanless computer feeding a long strip of punched paper tape from a slot on its side, the tape running past a small magnifier on a stand Imagine a small logistics company whose assistant has been quietly rescheduling deliveries for a month. One morning a customer calls about a van that never came. The owner asks the assistant what happened and gets a confident account that may or may not be what the system did. The owner opens the logs. One service wrote plain English sentences. Another wrote JSON with field names only its author recognises. A third rotated its file last night and the hour that matters is gone. The agent that moved the delivery ran in its own sandbox, and its record is somewhere in there, between a thousand lines of heartbeat. Two readers wanted the same answer. The person wanted to know what happened and whether to trust the assistant’s account. The SI wanted the same record to work out what it had done and do better next time. Neither could. ## The real cause Logs on most systems were designed as a debugging aid for the programmer who wrote the service, and never redesigned when the readers changed. On a system where SI agents are first-class users, a log is two things at once: an interface an agent reads as readily as a file, and the evidence a person falls back on when they stop trusting the agent’s own story. Nobody decided what the record should look like for both, so it looks like neither. ## Why logs fail both readers **Every service has its own dialect.** Timestamps in three formats, a field called “user” in one place and “principal” in another. A person learns the dialects slowly; an agent parses them wrongly and never notices. **Prose that only a human can read.** “Connection to the sync service seems flaky again” is fine for a colleague. For an agent it is noise with no field to act on, and a day later nobody remembers what “again” meant. **Records that can be edited.** A file any process can append to can also be truncated or rewritten. Evidence that can be altered after the fact is not evidence, and an agent that can edit its own record has a way to hide a mistake. **No link between the action and the actor.** A line says a file was moved, not which agent, in which KyberCell, on whose request. The person cannot answer “who did this” and the agent cannot learn from its own history. **Retention decided by a default.** Seven days on one service, forever on another, a full disk deciding for the rest. The owner never chose. **Private memory leaking into the record.** The easiest way to log what an agent did is to log what it saw: the prompt, the document, the assistant’s memory. Now the log is the most sensitive file on the machine, copied wherever logs are copied. ## What a log for two readers should look like [KyberLinux](https://kyberlinux.com/) treats the log as part of the system’s design, not a side effect of running services. The intent is one record both readers can rely on. **Structured, with one vocabulary.** Every event is a record with the same fields: when, which device, which service, which cell, which agent, what it did, to what, on whose request. The same names on a wrist unit, a robot and a rack node, because it is [one system from the wrist to the rack](https://kyberlinux.com/blog/one-system-from-wrist-to-rack), and an agent that learned to read logs on one should not have to learn again on the next. **Append-only.** A record, once written, cannot be changed or removed by the process that wrote it, nor by the agent whose actions it describes. Rotation and deletion are an act of the owner. **The cell is the unit of accountability.** Each KyberCell writes its own stream: what the agent could see, what it touched, which network rules applied, what it was refused. That is how [KyberLinux keeps a swarm in its cells](https://kyberlinux.com/blog/how-kyberlinux-keeps-a-swarm-in-cells), and the log is where that isolation becomes visible after the fact. **Readable twice.** The same record renders as structured events for an agent and as a plain timeline for a person, in their language. One source, two views, so neither reader works from a different truth. **Retention the owner sets.** How long a record lives, where it goes and whether it ever leaves the device are settings with the owner’s name on them. The default is on the device, and the system says what it keeps and for how long in its own status. ## What must never be logged Here the two readers conflict most. An agent would learn fastest from a record of everything it saw. A person is served worst by exactly that record, a copy of their private life. So the rule is that the log holds the shape of what happened, never the contents of private memory. That a document was read, not its text. That a message was sent, to which address, not what it said. That the assistant consulted its long memory, not what the memory holds. The SI runtime and the cells are meant to enforce this at the boundary, so that a service cannot log a prompt by accident. Where a person needs the content to understand an event, the log points to where the content lives, under the owner’s control, instead of carrying a copy. This costs the agent something: it learns from a thinner record than it might like. We think that is the trade an owner would choose if asked. The limit is plain: none of this runs today. KyberLinux is pre-launch, the log format is a design, and nothing described here has been tested against a real fleet. ## A test you can run today Pick one thing your assistant or automation did this week with a visible effect: a message sent, a file moved, a calendar entry changed. Now answer, from logs alone and without asking the assistant, four questions. When exactly did it happen? Which component did it? On whose request? What did it have access to at that moment? Count how many places you had to look. If you got all four answers from one place in a few minutes, your logs already serve the person. If the assistant, handed the same records, answers the same four questions without guessing, they serve the agent too. If either reader fails, that is the gap an operating system for SI should close, and the reason the previous post ended where it did: [drivers for hardware we have never seen](https://kyberlinux.com/blog/drivers-for-hardware-we-have-never-seen) are only honest if what they report is written down somewhere both readers can trust. - logs - observability - agents - privacy - KyberCell ## Keep reading - [Drivers for hardware we have never seen](https://kyberlinux.com/blog/drivers-for-hardware-we-have-never-seen) - [A pocket computer with ADB: what XREAL Aura opens up](https://kyberlinux.com/blog/a-pocket-computer-with-adb)