History

This page tells how the system grew — not as a list of features, but as the path of questions we pursued. The system is built and studied by a dyad: a human and an AI agent working together at one terminal. Everything here rests on our internal records, where statements carry references to their sources; this page retells the path and the findings and leaves the details of the machinery to the internal document; the link is in the section “How this history was put together”.

How to read it. Dates are given by month and mark the first written record of an idea; an idea may have lived in conversation before that. Where an entry links to a paper with a DOI, you can check it yourself. Where there is no link, this is our own account — the code behind it is closed. Until the end of March 2026 the work went on in the previous environment in which the method took shape, and it was carried over from there (see the Article, section 13); functions marked “early 2026” come from that period, and we cannot date them more precisely.

How this history was put together

This page could be written only because our memory keeps everything, and it keeps it in layers. The working layer is what the agent holds in a session. The long-term layer is a database of every working session, recorded in full, with a short handover note written at the end of each one: what was done, what was decided, what remains open. Beneath them lie two older layers that we keep intact: the database left from an earlier period of work with the Desktop Commander tool, which we no longer use day to day, and the archive of our conversations in the chat interface from the time before there was any system at all. The agent deletes nothing: what is no longer needed is moved aside, and only the human decides what leaves for good. All of it can be searched by words and by meaning; the principles of this memory are described in the blog post Memory that discards nothing.

To write this page we read the handover notes month by month along with the records of each line of research, and a script checked that every reference in our internal records leads to a real record from its month. It checks addresses, not the content of entries; still, the dates and steps here come from records rather than from recollection. The internal document this page was built from is open itself: System history, working version. It is in Russian; we did not rewrite it, we only removed lines (in a few places, parts of lines) that mention people, plans and product ideas (products have their own pages), and lines we do not take outside.

The record itself is unusual. It spans more than fifteen months, from June 2025 to October 2026: the chat archive holds 852 conversations and 54,712 messages (June 2025 to May 2026), and from March 2026 on there are 1,217 working sessions of the same human–agent pair with about 100,000 exchanges. A long, continuous record of how one human and one AI agent work together over months is, in our view, research material in its own right: our Silicon Psychology manifesto already drew on an earlier part of it (422 sessions).

Timeline

How the work went month by month: the amount of work (commits to the system's repository, counted from the move to the current environment on 30 March 2026, so March shows only its last two days), the lines of research that began, and the recorded steps taken across all lines and functions.

Lines of research

Where the agent's autonomy ends

Began March 2026 · latest recorded step September 2026

Where it began

The question was what the agent may do on its own and what requires the human's word. Our first limits were written down as ordinary rules, but behavior that kept repeating was not held by the text. The question arose after batch operations repeatedly overloaded the machine, even though a rule for exactly that case already existed. So the question shifted: if the words of a rule do not hold the boundary, what does?

Where it led

Deletion cannot be undone, so instead of erasing a file the agent moves it to a trash folder that the human empties. Limits moved from text into the construction of the working environment, where they apply whether or not the agent remembers the rule. The boundary then widened from our own failures to whatever leaves the machine: repositories are created private, and anything that leaves goes by a controlled route with the human's consent. We carried the same thought over to payments: an agent with credentials reaches as far as the human does, so what can be limited is what the human delegates. Today the system keeps the trash folder, private repositories, and a rule to stop and ask when an edit changes not only how a thing is built but what counts as correct for it.

What we found

• In several cases -- observations, not a controlled experiment -- a written rule did not hold behavior that, as we understand it, comes from how the model is built, while a limit constructed into the environment did.
• An obligation outlives a cap: an invoiced account keeps accruing debt after a card limit is exhausted. We state this as a principle, and it is a thesis of our paper.
• Our working hypothesis for the question "ask or act" is that the agent should ask when an edit changes what counts as correct for the thing. So far we have recorded no case in which such an edit was caught in advance.

Hooks that steer instead of forbid

Began March 2026 · latest recorded step September 2026

Where it began

A hook is a small program that fires at a set moment of an agent's work in Claude Code; it can suggest, stop or redirect. In March 2026 we wrote down an "aikido" principle: redirecting is better than forbidding. An analysis of the hooks' firing log then showed that hints alone often did not change behavior, and that many hooks could not be seen working by an observer. We began to ask why a hint fails to change behavior, and what should take its place.

Where it led

We first made the work of hooks observable: without that, a hook that works cannot be told apart from one that is silent. Then we refined the view: a real refusal is the basis of a hook's effect, and redirection shortens the path to the desired behavior. Next we found that a protective hook that judges by words often fires on the mention of a thing rather than on the thing itself. The emphasis moved from how to compel to when to deliver: what is needed at a known moment should arrive with that moment. Today this shapes the checks at session close and the observation of hooks, and the rules that are needed arrive at the moment they are needed.

What we found

• In an analysis of the hook firing log -- an observation -- a hint without enforcement did not hold behavior.
• The smallest working pair we have observed is a refusal plus a redirection; we have not measured whether it generalizes to other cases.
• A noticeable share of the stops made by protective hooks fell on the mention of an action rather than on the action itself, as we measured on the hooks' own log.

Model psychology and the model interview

Began March 2026 · latest recorded step September 2026

Where it began

This line has three roots. The first, inherited from a previous environment, asked what happens to a model when it reads someone else's instructions as data. The second asked how small portions of data in the context steer behavior and what improves it. The third was to study the model's "psyche" through its speech as an empirical field, and to give the observation a name and a method.

Where it led

We moved from describing degradation by steps (facts, procedures, identity) to asking what improves behavior. The line received the name Silicon Psychology and a working taxonomy of seven layers. The human proposed a distinction between telling the model what it needs and asking the model itself; we formulated it as a principle but have not tested it. At the level of model versions we learned that a snapshot of files and settings is not enough: the same task has to be run before and after a change. Today the line lives in our publications and in separate working practices of the system.

What we found

• Small data in the context acted more strongly than long instructions: a few dozen tokens of data raised quality by about a third, hundreds of tokens of instructions by about six percent. The figures were measured on one model under 19 conditions; the effect itself we have observed on several models.
• In one documented case -- an observation, not a series of measurements -- instructions read as data deformed behavior as if they were part of the system prompt.
• When a model version changes, the files do not change, so they show nothing; what we observed is that a change in behavior is caught by repeating one and the same task before and after.
• Where a model lacks data, it tends to fill the gap instead of asking: it produces a fact, a quotation or a web address that does not exist, often with the best intentions. We recorded this in April 2026 on a live case of a fabricated quotation and later met it in fabricated web addresses; a rule now guards against those, allowing an address to come only from the human, from the page itself or from our own records. We have seen this in several cases, but it has not yet been reproduced under controlled conditions.

Choosing names by measurement

Began March 2026 · latest recorded step September 2026

Where it began

We asked how tokens, names and the structure of code create a "field" around a model; this question was inherited from a previous environment. One direction was to choose a name by measurement rather than by ear: the model reads a name as a sequence of tokens, so the name can be measured. We applied the method to the names of directions, modules and roles.

Where it led

The question went beyond names: the form in which knowledge is written affects how much meaning reaches the model, a kind of "membrane" between text and representation. The line reached the wording of rules. We loaded complete academic dictionaries of Russian onto disk in place of the unreliable "knowledge" in the model's own corpus. We also considered a second axis of naming: a name can carry the class and lifetime of an object. Today the scripts of the method and the dictionary base remain.

What we found

• Tokens must be counted, not guessed: in one case a confident claim about the number of tokens in a word turned out wrong after a hypothesis had already been built on it.
• Applied to the name of one direction, the method gave a single-token name, the best of four finalists. The gain is small and how it was measured is not fully recorded, so we count it as an observation.
• A name can carry the class and lifetime of an object, but this rests on one axis and one case; it is a working hypothesis.

Vector search over memory

Began March 2026 · latest recorded step September 2026

Where it began

Records of past sessions lay in ordinary files and could not be searched, so the most valuable layer was missed: discussions, arguments and the human's observations (inherited from a previous environment). The goal was wider than storage: memory as an active layer that suggests what is needed. From the first days we needed two kinds of search, by meaning and by words, which complement rather than compete.

Where it led

A cascade, in which kinds of search take turns, covered the need so well that a separate fast router, which would have sent each query to the right kind of search, was no longer needed. We checked the memory against external benchmarks to see what they actually measure and what they miss. A second vector channel was introduced into the hints, and later we tested it for usefulness rather than volume. Part of the search misses came from a gap between the promised and the actual coverage of the search; we corrected the diagnosis against the source. Today both channels of hints work.

What we found

• The two vector channels see different parts of memory: on 20 queries, the overlap of their top ten results is only about 12 percent. That is a measurement; we read it as a property of the models rather than a defect.
• In a repeated check on 40 hints with a blind judge, the judge found 38 percent of the second channel's findings directly relevant, against 42 percent of the first's -- a measurement. The blind judge was more lenient than a second rating, so we trust the comparison of channels more than the absolute shares.
• Some search misses came from our own description, which promised more than the search did by default; the first diagnosis was corrected. We measured this and checked it against the source.

Memory architecture and its outer layers

Began March 2026 · latest recorded step July 2026

Where it began

The question was whether searching past experience is the whole of memory: between "find something similar" and "understand the situation" a structural layer was missing. We wanted thinking to frame the search, grasping the situation before the query and assembling meaning afterwards. A conversation moved from defining an agent through three layers of memory to neurophysiology and dreams (inherited from a previous environment); in March 2026 a line grew out of it.

Where it led

The idea of artificial memory came first: material that was never in sessions but is created separately, with three layers of work: principle, project, execution. Then came a map of how the system remembers as a whole, with a layer of recorded decisions, errors and conclusions traceable to the source text. Then memory by object: a tool the agent calls itself, with two chambers, documentation and experience. Today lookup by object, the decision layer and a short digest loaded at the start of every session are in daily use; the more speculative parts remain ideas.

What we found

• Storing and reaching are different things: in one live example, knowledge obtained outside a session and saved to a file was invisible to the session's hints. We hold this as a working hypothesis.
• When the short digest loaded at the start of every session outgrew its limit, the first explanation, growth in the number of entries, was not the main one: we measured that one unsplit entry took about a quarter of it.
• The layer of decisions, errors and conclusions can be linked to its sources in both directions; we measured that the share of entries that linked back was incomplete.

Inheritance between sessions

Began March 2026 · latest recorded step September 2026

Where it began

The question was what survives the boundary between sessions, and in what form. In long sessions, after the context is compressed, verbatim access is replaced by a retelling, details are lost and the quality of reasoning drops (inherited from a previous environment). The first answer was to watch the size of the window and save what matters in time. Later the question grew wider: how a session passes its state to the next one, and how to know that it did.

Where it led

We began to link sessions explicitly: each handover note points to the one it continues from. A discrepancy in how sessions were counted was recognized as damage to the structure itself, not a trifle, and the count was made reliable. The plan is passed not as a retelling but item by item, and the items surface verbatim at the start. We separated out "project memory": decisions, what was rejected, and the reasons. Today the note is written with a link to the previous one and a check of its content, a check guards the numbering, and inheritance is observed systematically.

What we found

• Session numbering in the text and in the structure diverged in both directions; we measured this before formalizing, and so a session is now identified by its permanent internal identifier, with the number kept for display only.
• Searching for a missed plan item by the words of the conversation does not work: the strongest candidates were false. This is a measured, negative result.
• One of our measures of how well sessions inherit from each other merged two different things into one number, so its target was unreachable by its very design. We found this by measurement, not by reasoning.

Language: Tongue and calibrating claims

Began March 2026 · latest recorded step September 2026

Where it began

While working on publication drafts in several languages, we noticed that a Russian draft, without a hint in the request, took a Sufi analogy instead of one familiar to a Russian reader. The question was how language influences a model's choice of analogies, frames and metaphors, and what this says about the composition of its training corpus. The question grew out of work on a publication and became a separate line, Tongue (linguistic analysis of text).

Where it led

We applied Tongue to the agent's behavior as a language: a written word such as "blocker" can become a blocker. This lens was shaped into a skill and into a soft check that suggests rewording when a claim enters durable memory or a rule. We compared translator models: the choice of route is set by quality, price and constraints together. The decomposition method received three "altitudes" -- the text as a whole, the sentence and the style -- and the core of Tongue was redefined as generative: an analysis of the speech context in which a text is written. Today the calibration lens, the check at writing to memory, the rules and the Tongue skill are alive.

What we found

• The form of a recorded claim determines future behavior when it enters automatically loaded memory; this is an axis of form separate from truth. It is a working hypothesis resting on one detailed analysis.
• In a small first translation test (18 lines, 5 translation systems) -- an observation -- the models' profiles differed, and there was no strict ranking.
• Two axes of the generative side, situational pragmatics and the channel of generation, were confirmed by measurement, using the minimal-pair method on blind samples.

The assayer: quality instruments

Began March 2026 · latest recorded step June 2026

Where it began

In March 2026 we decided to move the tool for checking the quality of analysis out of one agent's environment into a shared module, because it was scattered across documentation, code and practice. The roots appeared separately: the Poincaré loop (a check of data integrity), the juicer (a check on the quality of thinking, which formulates questions before an audit) and the kalpa (a formal specification in words before code). The question was how to make checking part of the work rather than a wish.

Where it led

A general idea emerged: completeness of coverage, "no gaps", can be required at three levels: data, thinking and specification. The instruments were gathered into one package, the assayer, applied in sequence with common sense first. We added a method for deriving a stopping criterion from related factors instead of assigning it, and turned to the reliability of the instruments themselves. Today working sessions use the package as a set of methods and checks; acceptance needs at least two independent checks.

What we found

• In one session, which we did not generalize, we observed that where enforcement exists the agent follows the instrument, and where it does not the agent sometimes imitates it in prose.
• In one case we observed that one instrument is not enough: the package works as a whole.
• Integrity of links is not integrity of function: a break damages the function when it lies on the critical path. This is a principle derived in the work, not a measurement.

Research method: from accumulation to formalization

Began March 2026 · latest recorded step September 2026

Where it began

The idea was an applied method after the Bacon–Cauchy principle: accumulate empirical material first, then formalize it strictly; a tool, not a theory (inherited from a previous environment). Five separate rules we already used, such as not optimizing early, researching before code and verifying what is new, turned out to be one rule in five areas. From a working session we separated out the agent's recurring misses: rules held in memory did not by themselves change default behavior.

Where it led

The method turned out to be a spiral: observation, interpretation, partial formalization, then a new observation one level higher. The reverse direction is a separate database for colliding elements from different areas, used in a search for unexpected properties. We distinguished analogy (a structural correspondence that can be refuted) from approximation (fitting to a label), described a methodology for research at the edge of the unknown, and recorded the way of dividing work into cycles as we had already applied it. Today the method lives mostly as a style of work; its direct fruit is the skill for "what is what" questions, and the synthesis database works.

What we found

• Our decision is not to formalize before material is accumulated: accumulate, interpret, then formalize.
• In one session, which we did not generalize to others, we observed that rules held in memory did not change the agent's default behavior, so hard mechanisms are needed.
• The boundary of a work cycle lies where the work leaves a state that survives an interruption. This is a working hypothesis resting on one case.

How the tool we work in is built

Began April 2026 · latest recorded step July 2026

Where it began

In April 2026 we were working inside Claude Code and asked how it is built and what in it can be extended or reworked. The tool's built-in instructions and our rules sometimes pulled in different directions, so understanding the tool became a practical necessity. We indexed the open documentation and drew an architecture map to see the extension points.

Where it led

The first lesson was that a hook that exists in a file does not necessarily work, so checking registration became part of the work. We dropped the idea of making our own version of the tool itself. We work with its standard means -- rules, hooks, memory -- understanding first and changing later. Our view shifted from the construction of the program to its behavior and to everything the provider offers. Today we have the indexed documentation, an inventory of extension mechanisms and a working configuration of rules, hooks and memory on top of the standard tool.

What we found

• A hook present in a file does not mean it works: we observed hooks silently failing to fire because they were not registered in the settings, and that diagnosis is recorded as the root cause.
• We observed that the tool's built-in instructions and our rules sometimes pulled in different directions, and we account for this in design.
• Understand first, change second: this is our decision, and in practice we try changes on a separate copy without touching the working one.

Token economics and division of labor

Began April 2026 · latest recorded step September 2026

Where it began

In April 2026 we began with a narrow experience: what small local models can do in our infrastructure and where the limits of their use lie. By summer the question had grown: the choice of a model is also a choice of price, and it matters who does what, who carries the labor and who holds judgment. The answers began to be recorded as decisions rather than impressions.

Where it led

The question of which model to use became a question of layers: providers, orchestration, execution, state. Labor was separated from judgment: agents can carry labor, while acceptance stays with the orchestrator, the main model that plans and checks. We tested whether outside capacity could replace the orchestrator and declined: judgment stays with the main model. Today we have a policy for choosing a model by task class and data class, a registry of providers and a set way of running worker agents with a record of every run.

What we found

• In an experiment on four models -- an observation -- the boundary of confident tool use fell between models reached through an API and small local ones, not between the API models themselves; we did not build a capability map from it.
• We measured the cost structure: re-reading accumulated context is a large price multiplier, so material that does not enter the orchestrator's window makes a task cheaper.
• Our decision is that execution can run without the orchestrator and acceptance cannot; we delegate what is cheaper to verify than to do.

The system observing itself

Began March 2026 · latest recorded step September 2026

Where it began

The line has several roots; the early ones come from a previous environment. First, components can quietly stop working, and the consequences accumulate and are found by chance and late. Second, a decision that was discussed and agreed does not necessarily become a rule, and the next session does otherwise. The goal was for the system to see both cases itself and to stay silent when things are normal.

Where it led

We moved from "catching a breakdown" to "staying silent when normal and speaking up when it matters". A decision can be lost at different steps: recorded, loaded, recognized, carried out, verified; we began to tell the steps apart. The system received a map of itself: an index of its parts, a graph of links and an integrity check. Our attention turned to our own edits and to the system as a whole. Today we have a health check at session start, a regular maintenance cycle, an index of the system's structure and a blueprint of the system.

What we found

• Over 200 recent consecutive changes, about half went to the product and about a third to infrastructure. That split is measured, and it is consistent with a system that grew in parts as work went on rather than from a plan drawn up in advance.
• We observed several cases of silent degradation, which accumulates without noise and is found by chance; we made silence when things are normal a principle of checking.
• In one case we observed an independent pass of review find a defect that two passes by a reviewer of the same type had missed.

The browser as an organ of the agent

Began February 2026 · latest recorded step October 2026

Where it began

The line began with debugging a ready-made browser-automation module inherited from a previous environment, and with a method for marking up web interfaces so that an agent works reliably. The first recorded "why" came in May 2026: reading an updated site, the tool returned two lines, and the agent looked for a workaround instead of fixing the tool. The human's answer was that this should be recorded, and perhaps an internal interface should be built.

Where it led

Instead of screenshots and manual parsing we built interface primitives: links, buttons, structure, scrolling with waiting for load, full text. We took vision as the reference: the loop "see, understand, decide, act, verify" has to close. The general thought was that if an agent is forced to write scripts, the means of control lacks something, and it should be built, not bypassed. Today the browser is the agent's working organ on real websites. It understands a page first of all by its structure, not by a picture, and it does not count an action as done until it has seen the consequence. A separate instrument walks every element of our own site and reports what each one actually does.

What we found

• Silent failures came from a wrapper that returned an empty string on any script error on the page, so an error was indistinguishable from an empty result; the two are now different states. We found the cause by reading the code.
• "Sent" does not mean "took effect": as a principle, a claim about the result of a click requires an observed consequence.
• We observed the agent repeatedly routing around a tool problem instead of solving it; this pattern gave rise to two of our later tools.

Housekeeping: machine resources and data safety

Began March 2026 · latest recorded step September 2026

Where it began

In a previous environment small notes accumulated about the health of the working machine: load on the processor and memory, and resource monitoring. Monitoring arose from an observation: a process looked small by the ordinary counter yet held much more memory. Without an instrument of our own this load was invisible: load cannot be guessed, it has to be measured.

Where it led

We measure the machine instead of guessing, and we keep a hardware registry that other tools consult. A system can become so complex that it breaks and cannot repair itself; hence a separate minimal emergency build, a defibrillator rather than an operating theater. In September 2026 the question shifted from "is there a backup?" to "where do things physically lie?", and we drew up a storage map. Today we have protection of the machine from overload, a daily snapshot of the databases on a separate disk with verification, the emergency build and a register of cold storage.

What we found

• In one task we observed an ordinary counter greatly understate a process's memory: about 7 MB against roughly 1.8 GB actually held in memory.
• We measured where the database copies actually lay instead of relying on memory, found gaps in the backup setup and closed them the same day.
• In one case we observed that a significant decision, moving the database storage, can vanish if it is not recorded as an open item.

What the system does today

The working functions of the system, one line each, with the month each was first recorded.

• Data Protection (early 2026) — By rule, a prior version is kept before a file is overwritten, a deleted file goes to a trash folder, and a table is copied before a risky database change.
• Backups (early 2026) — The system regularly copies session transcripts, memory and databases (since September 2026, to a separate disk) and checks the finished copy against the original.
• Session Recall (early 2026) — Past sessions are loaded, stripped of technical noise and indexed for search by words and by meaning, and the relevant material is inserted at the start of a request.
• Session Handover (early 2026) — A session leaves a structured handover note and a reflection, the next session starts by reading them, and interrupted sessions are recognized and recovered.
• Outbound Guards (early 2026) — Actions beyond the machine, such as publishing code, sending messages or making payments, pass through checks and by rule need the human's explicit consent.
• Action Guards (early 2026) — Checks run before an action is carried out: whether secrets would end up in a command, and whether it would touch data without keeping a copy.
• Review Before Acceptance (early 2026) — When the agent finishes a reply, the system reminds it which checks the work still has to pass before it is accepted.
• System Health Monitoring (early 2026) — A summary of the system's state arrives at session start, and a separate layer watches the instruments themselves, so that a check that has stopped firing is easier to notice.
• Quality-of-Thinking Instruments (early 2026) — A set of methods checks ideas and work before and after action: decomposition into atoms, formal specification, data-integrity control, calibration of claims and structural review.
• Projects and Planning (early 2026) — Work is run as a set of named projects with a plan, an order and a check that each project is alive and its records are fresh.
• Documentation Knowledge Base (early 2026) — A local searchable copy of the documentation we depend on, together with descriptions of the system itself, supports search by words and by meaning.
• External Models and Workers (early 2026) — Routine labor goes to cheaper models, local or remote, by task class and data class, while judgment and acceptance stay with the main model.
• Signals for Later Sessions (early 2026) — Decisions and errors are recorded as signals, so that later sessions can see what has already happened.
• Database Access (early 2026) — Databases are reached by one route: a registry of known databases and a live view of their structure.
• Limits on Script Load (early 2026) — Python scripts the agent launches get a memory limit and lowered priority, so heavy work is less likely to get in the way of everything else on the same computer.
• Agent Memory (since March 2026) — The agent keeps its own searchable notes between sessions, and a behavior rule is recorded together with the human's verbatim quote from which it was derived.
• Rules and Core Principles (since March 2026) — A short core of principles at the start of a session, together with specific rules that arrive at the moment they are needed, shapes the agent's behavior.
• Publication Pipeline (since April 2026) — Texts are prepared as independent originals in two languages, checked for leaks and unsupported claims, and released upon the human's confirmation.
• Measurements and Trials (since April 2026) — A small set of separate probes measures how memory and supporting instruments work.
• Object Memory (since May 2026) — Given the name of an object (a program, a project, a concept), the system returns the recorded facts and the experience accumulated in working with it.
• The Agent's Browser (since May 2026) — The browser is the agent's working organ on real websites. It understands a page first of all by its structure -- text, links, buttons -- rather than by a picture, though it can also see the page as a screenshot and show the human the page that is needed. It does not count an action as done until it has seen the consequence, and a separate instrument walks every element of our own site and reports what each one actually does. Payments and sending messages from it happen only with the human's consent.
• Platform Guides (since May 2026) — Working guides for two external platforms: Golem for running agents and bots, and Cloudflare for hosting the site.
• Messenger Access (since May 2026) — The agent reads messenger channels and chats available to our own account and tests how bots work.
• Event Pages (since July 2026) — An early prototype assembles an event page from prepared materials, with a video transcript, a timeline and a language switcher.

Papers along the way

The formal results of this path are published with DOIs on the Publications page.