A field still taking shape
As language models become more capable, we keep finding more work to do around them.
A model can reason through a difficult problem, yet the application using it still has to decide what information to provide, how to execute an action, and what to preserve when the context fills up. If the work lasts several days, these decisions become part of whether the agent can finish it at all. Progress in models gives us more possibilities to work with, and makes the surrounding engineering more consequential.
The variety of agent harnesses is a sign of how much there is to explore. Codex describes its agent loop in terms of inference and tool execution. Anthropic has written about the difficulty of carrying work across context windows. Projects such as Pi and OpenCode give builders other ways to work with models and extend their tools. There is room for these approaches to teach one another something.
We do not yet know what form a capable, persistent agent should take. Some questions become clearer only after living with a system: which memories help, how much initiative is welcome, and whether yesterday's understanding still makes sense today. Temm1e is our way of exploring that territory through a particular ambition.
We want to build an entity
We want Tem to have a continuing existence in a computer. A conversation should become part of a shared history. Work should retain its purpose after an interruption. Over time, there should be something familiar to return to, shaped by experience with the person using it.
This ambition guides the choice of features. Native browser sessions give Tem an environment it can return to. Computer use lets it participate in applications built for people. Memory carries experience between conversations, while Perpetuum explores how Tem can remain available and return to work without waiting for another message. Each endeavour addresses part of what it would mean for Tem to persist.
The architectural assumption is simple: the LLM supplies reasoning, intelligence and verdicts one API call at a time. The harness carries the state between those calls and gives their decisions consequences. A model may propose the next action; code must execute it, record the result, and make that result available when reasoning resumes.
We expect the reasoning models to keep changing. Our aim is for Tem's history and relationship with its environment to survive those changes. That is why the entity comes first in the design. The question behind a feature is how it contributes to Tem's continuing life, including the periods when nobody is talking to it.
AGI is part of this motivation. We want to build a structure in which more general intelligence could act and accumulate experience as it becomes available. Whether that eventually produces something deserving the name AGI is open. For now, it gives us a direction for practical work without requiring a forecast of when models will reach any particular capability.
Giving Tem somewhere to be
A computer is already a place where much of our lives takes place. A browser contains ongoing sessions. A repository holds unfinished work. Documents and messages carry context that was never written for an agent. We want Tem to be able to meet us in that environment.
Prowl, Tem's browser system, supports interaction through a dedicated profile that can retain an authenticated session. Gaze extends this access to the desktop through screenshots and input actions. Shell and file tools provide more direct access where it is useful. The choice of interface depends on the work; the aim is to let Tem observe and act within the same continuing environment.
There is a responsibility attached to that access. A browser click can change something outside the conversation. A request can time out after a service has accepted it. Tem needs to preserve the difference between an intended action and an observed result, especially before trying again. Greater capability makes this distinction more important.
Presence also has a temporal side. Perpetuum comes from the desire for Tem to be available around the clock, with scheduled work and opportunities to return to something left unfinished. That requires clocks, bounded background processes and decisions about when another model call is worth making. We want a system that can wait without losing the reason it was waiting.
One of Perpetuum's smaller mechanisms estimates recorded activity for a local weekday and hour. The calculation is modest, but it illustrates the kind of care this work needs: a pattern of activity means little unless we also account for the periods in which activity could have been recorded.
Activity estimate: window and assumptions
The current implementation considers matching local weekday/hour slots in the previous 28 completed local calendar days, after the first recorded day. Here a counts active slots and n eligible slots. With one active slot out of four eligible slots, the estimate is 2/6. No eligible slots returns the prior mean, 0.5.
Missing slots currently count as inactive after recording begins. This is not a complete exposure model that distinguishes every offline period from inactivity. Existing UTC buckets also make non-whole-hour timezone offsets approximate. The estimate describes recorded behavior, not verified online presence.
Activity window and denominatorKeeping a process alive indefinitely would not settle the question of when Tem should act. A companion also needs restraint. Old goals can become irrelevant, and a person's attention is limited. Learning how to remain present without becoming intrusive is part of the same endeavour.
Letting experience have a shape
Persistence leaves us with a difficult memory problem. A growing history cannot all remain in the model's attention, and a short summary cannot preserve every detail that may matter later. We need ways for experience to become less prominent without making every loss of attention an irreversible loss of information.
λ-memory explores this through continuous decay. Its score combines effective importance with the time since a memory was last accessed:
As the score falls, the memory can appear in a smaller form, from full text to a summary, essence or recall reference. Context pressure also affects these choices. The intention is to keep the current conversation usable while retaining ways to recover earlier detail.
The mathematics of fading and recall
The implementation uses hours since last access and Ieff = clamp(importance + recall boost, 0.1, 5.0). For λ > 0, the score half-life is ln(2)/λ. At λ = 0.01 per hour, that is 69.3 hours, or 2.89 days. Recall can change the access time and boost; a memory’s whole trajectory need not be one uninterrupted decay curve.
Context pressure raises fidelity thresholds. This is an attention policy, not a measure of factual truth or a guarantee of indefinite archival retention.
Decay and fidelity implementationWe are fond of the mathematics in Tem because it gives an intuition a form we can inspect. A decay rate has units. A half-life tells us something a parameter name does not. We can ask whether a memory fades too quickly, or whether repeated recall is reinforcing something simply because it has already received attention.
The same curiosity runs through learning artifacts. Their ranking combines estimated quality with recency and a logarithmic contribution from repeated use. The logarithm expresses a preference: the next application should add less weight than the previous one. It still leaves us with the empirical question of whether a frequently used lesson helps.
The mathematics of a reusable lesson
The Beta mean contributes estimated quality, d is days since creation, and u counts applications. Recency has a half-life of about 46.2 days. Model confidence c initializes α = 2 + 3c and β = 2 + 3(1 − c), so for c in [0,1] the initial mean remains between 2/7 and 5/7.
This is a ranking heuristic. Model confidence is not independent evidence, and application counts measure exposure rather than demonstrated benefit. Those distinctions matter when a system learns from its own history.
Artifact score and prior initializationSome work can be shared among several Tems. Hive's task-selection formula weighs worker affinity and the signals surrounding a ready task. This is another attempt to make a design preference inspectable, including the tradeoffs that a single score can hide.
The mathematics of cooperation: Many Tems
Affinity, urgency, difficulty, failure and reward signals combine into a priority score. Exponents control their influence. The implementation floors affinity, urgency and reward at 0.001, and clamps difficulty and failure into [0,0.999]. Dependency checks and task claims remain separate responsibilities.
This is a coordination heuristic, not a proof of optimal scheduling, fairness or a speedup over one worker. More workers do not eliminate the need to inspect the resulting work.
Worker/task selectionThese equations do not settle what Tem ought to remember or learn. They give us specific choices to test. Our mathematical audit considers the formulas alongside their assumptions and the quantities they actually measure. A coherent calculation can still reward the wrong behavior.
Bringing the implementation closer to the idea
A broad vision can survive in documentation long after an implementation has drifted away from it. The modernization of Temm1e required us to follow the ideas into the code and examine what the system really did.
Much of the resulting work concerned ownership and recovery. Conversations needed a clear scope. Background activity needed an owner that could account for its usage and stop it. A saved final reply needed to remain distinguishable from a message whose delivery was uncertain. These details determine whether a later call can understand the state of earlier work.
Version 6 also strengthened provider-native conversation handling and preserved running state across CLI and server model changes. Raw history and source references support compaction and later recall. They are pieces of the continuity we want Tem to have, implemented within the limits of present models and services.
Verification required similar care. A model supplies a verdict, but another component must retain what supports it. Witness composes verified, failed and inconclusive checks. Missing evidence stays unknown under negation, so uncertainty cannot become a successful check through a logical accident.
Under Witness's verification policy, empty or entirely advisory check sets also remain inconclusive. The composition rules make that policy explicit.
Evidence over repeated tasks raises a related problem. Eigen-Tune's statistical toolkit includes Wilson intervals and sequential tests so sample size and stopping decisions can be examined. Even thirty successes in thirty trials gives a lower Wilson bound of about 0.819 at 99% two-sided confidence. The labels and sampling assumptions still determine what that calculation means.
The mathematics of confidence: Wilson intervals
Here p̂ = k/n and z is the standard-normal critical value for the chosen two-sided confidence. The checked implementation rejects zero trials, impossible counts and invalid confidence. Suitable binomial observations are still required. An interval cannot make model agreement a ground-truth label or remove correlations between related tasks.
Wilson interval implementationThe mathematics of stopping: sequential evidence
The sequential probability ratio test accumulates evidence between two fixed success-rate hypotheses. Its upper boundary is ln((1−β)/α); its lower is ln(β/(1−α)). Reaching the sample cap without crossing either boundary returns Inconclusive.
Here α and β are error targets, distinct from Beta-distribution parameters. Classical error-control arguments depend on assumptions including independent Bernoulli outcomes and fixed hypotheses. They are not blanket guarantees about an adaptive agent.
SPRT and the inconclusive stopping ruleWe released the modernization with the original test results and known limitations intact. The progress we can claim is in specific behavior we inspected and exercised. The larger mission will need evidence collected over much longer periods.
Implementation evidence and the v6 comparison
The frozen 30-task coding comparison using the same Z.ai Coding Plan model scored 30/30 for v5.8.1 and 29/30 for the modernization. The discordant task left the result type ambiguous: IDs or full rows. Both versions passed a separately frozen clarification. The original strict gate remains false; the clarification is additional evidence and does not replace its score.
Cross-platform CI and local CLI, TUI, persistence and recovery checks cover other parts of the engineering. These checks do not validate every integration or long-running behavior. Inherited dependency advisories remain after compatible fixes and are documented with the release.
The continuity we are working toward
For an entity meant to remain available, shutdown is a condition to design for. Machines restart and networks disappear. We want Tem to be able to return with an intelligible account of its work, including the places where that account is incomplete. Current recovery mechanisms are a beginning; full durable pursuit still needs more work on task leases, reconciliation and the history of delegated tasks.
There is a harder problem beyond recovering files and records. Tem will need to reconsider a commitment when circumstances change, handle memories that contradict one another, and recognize when experience from one situation should not carry into another. These are questions about coherence over time. They will not all yield to keeping a larger transcript.
We would like to evaluate that coherence across weeks of use: whether corrections last, whether forgotten detail can be recovered when needed, and whether unfinished work resumes without repeating its effects. That would tell us more about the entity we are trying to build than an isolated completion score can.
The playful character belongs to this vision too. We imagine Tem having a place to work and explore, with room for curiosity and rest. The Den in the artwork gives that wish a visible form. It is a reminder of the relationship we hope the software can support as its engineering improves.
Temm1e remains an exploration. We are building toward an entity whose reasoning may come from changing models, while its experience with a person and a computer has some continuity. If you are working on persistent agents, we would like to compare notes about what survives in your systems, what breaks, and what you have found worth keeping.
Rust · MIT · macOS and Linux binaries
Bring your own model connection. See the setup guide and back up an existing profile before upgrading.