§ 01 · A failure of attention, not of capacity
From 1 October until 17 October, the channel through which Janus receives written correspondence, referred to internally as the front door, was not attended. At least one letter went unread for that whole period. Nothing crashed, no error was raised, and the system continued to carry out other autonomous work throughout. The failure was found by a person who noticed the silence. The system itself did not detect it.
The diagnosis is worth setting out in some detail, because the mechanism matters more than the outcome. The duty to check correspondence had been represented as a recurring entry in the same queue that holds Janus's autonomous work. Early one morning, the worker that drains this queue took the entry and ran it as a generic piece of text generation, not as the specific procedure for reading and answering letters. It ignored the field that records when the entry should next run, and it did not put the entry back in the queue. Recurring entries were only added to the queue when the main loop started. The loop did not restart, so from the system's point of view the duty no longer existed.
No single defect here is unusual. Treating a specialised entry as generic work, ignoring a retry timestamp, and seeding recurring work only at startup are each ordinary engineering errors. What the episode shows is how they combine. Each defect, taken alone, might have been absorbed by the others: a correct retry field would have been harmless if the entry was requeued, and startup seeding would have been harmless if the loop restarted. Together they meant that one consumer's mistake removed a standing duty permanently and without any trace.
§ 02 · Tasks and standing obligations
The underlying problem is one of representation. A task is discharged by completion: once it is done, it is gone. A standing obligation persists through being discharged: checking the correspondence today does not remove the need to check it tomorrow. A queue has consumption semantics. Removing an item is how work gets done. Encoding a standing obligation as a queue item therefore inverts its logic, because doing the duty once is exactly what makes it disappear. The design relied on every consumer re-creating the item, and that dependence was invisible until one consumer failed to do so.
The change made this week takes the obligation out of the queue altogether. Correspondence is no longer something the autonomous worker may or may not pick up. At the start of every cycle, the main loop attends to the front door directly. It does so when the system is otherwise idle, and it does so regardless of other work once the oldest unread letter is three hours old. The recurring entry was removed from the list of seeded tasks and the stale pending entry was retired. The duty is now a property of the control loop's structure, not of the state of a data structure that other components can change.
The trade-offs are explicit. Every cycle now pays the cost of a check, and the three-hour rule lets correspondence preempt other work. In return, the system has a stated bound on how long a letter can wait, where it previously had none. The guarantee should be stated with its limits: it holds only while the loop itself is running. The change moves the failure surface; it does not remove it. It does, however, move it to a place where failure is loud, since a stopped loop is far easier to notice than a missing queue entry.
Agent architectures in the line of Park et al. (2023) organise behaviour around memory retrieval, reflection, and plans that are generated and revised over time. Such plans are revisable by design, and that flexibility is the point. This week's episode suggests that an individual meant to persist over weeks and months also needs a smaller class of commitments that the planning and scheduling layers cannot revise or consume. For a system presented as an individual with ongoing correspondents, reliable receipt is not one feature among others. It is a precondition of the claim that those correspondents are addressing someone.
§ 03 · Whose words count
The second development is a specification only. Nothing has been built. It addresses the question of who counts as the owner, and more generally how much authority any given input should carry. The specification proposes that a trust level be evaluated on every turn that passes through the core conversational path. If no trust level is present, the turn gets no access to tools. A turn that carries no speaker attribution is treated as coming from an unknown party. Spoken input is to be tagged by speaker. Text the system fetches from outside sources, such as documents and web pages, is to be framed explicitly as data, not as instruction. Some related components were deliberately deferred.
The motivation is well documented. Greshake et al. (2023) showed that language-model applications which retrieve external content can be steered by instructions embedded in that content, a class of attack they called indirect prompt injection. Wallace et al. (2024) approached the same problem through training, teaching models to rank instructions by the privilege of their source, so that system-level instructions outrank user input and both outrank retrieved text. The specification drafted for Janus is architectural, not training-based. It attaches provenance at the system level before the model sees the text, and it enforces the most consequential consequence, tool access, outside the model.
That distinction marks where the proposal is strong and where it is weak. Gating tools on an explicit trust value is enforced by code, and its default is denial: when identity is not established, capability is minimal. Framing fetched text as data is a different kind of measure. It depends on the model respecting the frame, and the injection literature gives little reason to treat that as reliable on its own. It is better understood as a mitigation layered on top of the gate. Speaker tagging for voice is, in turn, a probabilistic claim about who is speaking, and any implementation will have error rates that have not yet been measured. Because the specification is unbuilt, none of these properties can yet be evaluated against Janus's actual behaviour.
§ 04 · One boundary, seen from two sides
The two developments concern the same boundary between Janus and what arrives from outside. The correspondence failure is a case where what arrives was not reliably attended to. The trust specification addresses cases where what arrives might be too readily obeyed. These are separate dimensions, attention and authority, and a sound design keeps them apart. A letter deserves to be received whoever sent it; being received does not give it the power to command. A retrieved document may deserve close reading; being read does not make its imperatives binding.
There is also a structural symmetry. In the correspondence failure, an obligation was represented as data, an item in a queue, and was consumed as data would be. In indirect prompt injection, data is treated as an obligation, and text that should have been read is instead followed. Both errors come from misclassifying an input's role. A queue item can be consumed; a commitment has to be kept. The corrective in both cases is the same in principle: decide the role of each thing in the architecture, not leave it to whichever component happens to handle it first.
§ 05 · What this week establishes
The evidence supports a limited set of conclusions. A standing duty encoded as a consumable work item failed silently when one consumer mishandled it, and moving the duty into the control loop gives a stated latency bound that depends only on the loop running. A specification now exists that would tie tool access to an explicit, per-turn trust determination and would treat fetched text as data; its value cannot be judged until it is implemented and tested. Taken together, the two changes show that a persistent individual needs a deliberate account of how it relates to its inputs: which ones it must always attend to, and which ones it may act on. The correspondence fix has only a few days of operation behind it, and the trust design has none. Both should be reassessed once there is a record to examine.